Security Engineering by Ross Andersson Chapter 18. API Security. Presented by: Uri Ariel Nepomniashchy 31/05/2016

Similar documents
Web Security: Vulnerabilities & Attacks

CIS 4360 Secure Computer Systems XSS

Copyright

Security and Privacy. SWE 432, Fall 2016 Design and Implementation of Software for the Web


WEB SECURITY: XSS & CSRF

Provide you with a quick introduction to web application security Increase you awareness and knowledge of security in general Show you that any

Bank Infrastructure - Video - 1

How to perform the DDoS Testing of Web Applications

Application Security Introduction. Tara Gu IBM Product Security Incident Response Team

W e b A p p l i c a t i o n S e c u r i t y : T h e D e v i l i s i n t h e D e t a i l s

Aguascalientes Local Chapter. Kickoff

Application vulnerabilities and defences

Advanced Web Technology 10) XSS, CSRF and SQL Injection

OWASP Top 10 The Ten Most Critical Web Application Security Risks

Web basics: HTTP cookies

Web basics: HTTP cookies

C1: Define Security Requirements

How is state managed in HTTP sessions. Web basics: HTTP cookies. Hidden fields (2) The principle. Disadvantage of this approach

CSCE 813 Internet Security Case Study II: XSS

CIS 700/002 : Special Topics : OWASP ZED (ZAP)

EasyCrypt passes an independent security audit

Web insecurity Security strategies General security Listing of server-side risks Language specific security. Web Security.

Web Application Security. Philippe Bogaerts

This slide shows the OWASP Top 10 Web Application Security Risks of 2017, which is a list of the currently most dangerous web vulnerabilities in

Attacks Against Websites. Tom Chothia Computer Security, Lecture 11

SECURITY STORY WE NEVER SEE, TOUCH NOR HOLD YOUR DATA

Excerpts of Web Application Security focusing on Data Validation. adapted for F.I.S.T. 2004, Frankfurt

Attacks Against Websites 3 The OWASP Top 10. Tom Chothia Computer Security, Lecture 14

Web Attacks CMSC 414. September 25 & 27, 2017

Web Security Computer Security Peter Reiher December 9, 2014

Security+ Guide to Network Security Fundamentals, Third Edition. Chapter 3 Protecting Systems

Application Layer Attacks. Application Layer Attacks. Application Layer. Application Layer. Internet Protocols. Application Layer.

Mobile Payment Application Security. Security steps to take while developing Mobile Application s. SISA Webinar.

OWASP TOP Release. Andy Willingham June 12, 2018 OWASP Cincinnati

OWASP Top 10. Copyright 2017 Ergon Informatik AG 2/13

Application Security through a Hacker s Eyes James Walden Northern Kentucky University

WEB SECURITY WORKSHOP TEXSAW Presented by Solomon Boyd and Jiayang Wang

CSWAE Certified Secure Web Application Engineer

Combating Common Web App Authentication Threats

NET 311 INFORMATION SECURITY

P2_L12 Web Security Page 1

OWASP Top 10 Risks. Many thanks to Dave Wichers & OWASP

John Coggeshall Copyright 2006, Zend Technologies Inc.

Computer Security 3e. Dieter Gollmann. Chapter 18: 1

Security for the Web. Thanks to Dave Levin for some slides

Web Application Security

Ethical Hacking and Countermeasures: Web Applications, Second Edition. Chapter 3 Web Application Vulnerabilities

Web Security II. Slides from M. Hicks, University of Maryland

Robust Defenses for Cross-Site Request Forgery

Computer Forensics: Investigating Network Intrusions and Cyber Crime, 2nd Edition. Chapter 3 Investigating Web Attacks

WebGoat Lab session overview

Configuring User Defined Patterns

Security for the Web. Thanks to Dave Levin for some slides

INNOV-09 How to Keep Hackers Out of your Web Application

1 About Web Security. What is application security? So what can happen? see [?]

CS 142 Winter Session Management. Dan Boneh

2/16/18. CYSE 411/AIT 681 Secure Software Engineering. Secure Coding. The Web. Topic #11. Web Security. Instructor: Dr. Kun Sun

The security of Mozilla Firefox s Extensions. Kristjan Krips

Web Application Whitepaper

CS 161 Computer Security

Drone /12/2018. Threat Model. Description. Threats. Threat Source Risk Status Date Created

Application Layer Security

INF3700 Informasjonsteknologi og samfunn. Application Security. Audun Jøsang University of Oslo Spring 2015

Robust Defenses for Cross-Site Request Forgery Review

Title: Multiple Remote Command Execution vulnerabilities on Avaya Intuity Audix LX (plus some client-side bugs)

COMP9321 Web Application Engineering

Andrew Muller, Canberra Managing Director, Ionize, Canberra The challenges of Security Testing. Security Testing. Taming the Wild West

OWASP Thailand. Proxy Caches and Web Application Security. OWASP AppSec Asia October 21, Using the Recent Google Docs 0-Day as an Example

TIBCO Cloud Integration Security Overview

So Many Ways to Slap a YoHo: Hacking Facebook & YoVille

COPYRIGHTED MATERIAL. Contents. Part I: The Basics in Depth 1. Chapter 1: Windows Attacks 3. Chapter 2: Conventional and Unconventional Defenses 51

RKN 2015 Application Layer Short Summary

DEFENSIVE PROGRAMMING. Lecture for EDA 263 Magnus Almgren Department of Computer Science and Engineering Chalmers University of Technology

GUI based and very easy to use, no security expertise required. Reporting in both HTML and RTF formats - Click here to view the sample report.

Common Websites Security Issues. Ziv Perry

19.1. Security must consider external environment of the system, and protect it from:

Webapps Vulnerability Report

Fortify Software Security Content 2017 Update 4 December 15, 2017

RBS NetGain Enterprise Manager Multiple Vulnerabilities of 11

THREAT MODELING IN SOCIAL NETWORKS. Molulaqhooa Maoyi Rotondwa Ratshidaho Sanele Macanda

Information Security CS 526 Topic 8

Certified Secure Web Application Engineer

2/16/18. Secure Coding. CYSE 411/AIT 681 Secure Software Engineering. Web Security Outline. The Web. The Web, Basically.

Solutions Business Manager Web Application Security Assessment

Security Course. WebGoat Lab sessions

Cross-Site Request Forgery: The Sleeping Giant. Jeremiah Grossman Founder and CTO, WhiteHat Security

Secure Parameter Filter (SPF) (AKA Protecting Vulnerable Applications with IIS7) Justin Clarke, Andrew Carey Nairn

Hacking Intranet Websites from the Outside

Attacking the Application OWASP. The OWASP Foundation. Dave Ferguson, CISSP Security Consultant FishNet Security.

Information Security CS 526 Topic 11

PHP Security. Kevin Schroeder Zend Technologies. Copyright 2007, Zend Technologies Inc.

Kishin Fatnani. Founder & Director K-Secure. Workshop : Application Security: Latest Trends by Cert-In, 30 th Jan, 2009

Security. SWE 432, Fall 2017 Design and Implementation of Software for the Web

HP 2012 Cyber Security Risk Report Overview

Web Application Vulnerabilities: OWASP Top 10 Revisited

Web security: an introduction to attack techniques and defense methods

Hacker Attacks on the Horizon: Web 2.0 Attack Vectors

Don't Trust The Locals: Exploiting Persistent Client-Side Cross-Site Scripting in the Wild

Defend Your Web Applications Against the OWASP Top 10 Security Risks. Speaker Name, Job Title

Transcription:

Security Engineering by Ross Andersson Chapter 18 API Security Presented by: Uri Ariel Nepomniashchy 31/5/216

Content What is API API developing risks Attacks on APIs Summary

What is API? Interface for communication between: Different applications Application and OS Software and Hardware Client and server

The usage of APIs APIs are everywhere Web Applications (Facebook, Twitter ) Application development (WhatsApp, Instagram ) OS System Calls Internet Of Things

Who are playing a role here? Product Client Product Developer API Developer

Who are playing a role here? Product Developer API Developer Product Client

So what's the problem? APIs are Vulnerable! Door to the outer world. Untrusted sources give commands. The existence itself of the API could lead to unexpected security flaws.

API Developing Risks

Risk 1- Relying on the product developer Many feel that security is as much the responsibility of the product developer as it is a responsibility of the API provider. - nordicapis.com

Risk 1- Relying on the product developer Security is best implemented at the lowest possible level. It should be the problem of the API developer, and the API developer alone.

Risk 1- Relying on the product developer The product developer not always can utilize important security tools like: input control secure protocols (HTTPS, SSL, SSH) type checking etc without the API developer first design the system to use these solutions.

Risk 1- Relying on the product developer Moreover, the developer using our API might be a malicious attacker trying to mess with our API.

Risk 1- Relying on the product developer The takeaway - Secure Your System, It s YOUR System!

Risk 2 Lazy coding The code in question is just enough for functionality. Without the greater concern of how it ties into the platform as a whole, and how security concerns are dealt with.

Risk 2 Lazy coding Poor error handling Lame value checking Ignoring memory overflows and more can lead to massive vulnerability issues.

Risk 3 Misunderstanding your needs Many developers adopt these new technologies without fully understanding what they do, and what they mean for the API security. Vulnerabilities can quickly become far larger than they have any right to be.

Risk 4 Trusting the user API developers often trust the user far too much allowing too much data manipulation Not limiting password complexity and usage Sometimes even allowing repeat session ID tokens.

Attacks on APIs

Attacks: Attack on VISA security module Attack on IBM 4758 HTML5 Fullscreen API Attack Cross Site Scripting (XSS) SQL Injection Buffer Overflow

Attack on Visa Security Module

Attack on Visa Security Module API Hardware device for secure bank transactions. Not enough storage for all the keys it might have to use. Stores a single master key, in tamper-resistant memory. Stores all other keys outside encrypted under M.

Attack on Visa Security Module API PIN generation: E PINVerify A num The ATM sends PINs to the VSM for verification.

Attack on Visa Security Module API We will look at the Terminal Key creation for ATMs. ATM security is based on dual key control generated by the VSM. VSM api VSM api E M (K 1 ) E M (K 2 ) Host Host The VSM returns it encrypted to the host.

Attack on Visa Security Module API Terminal Key creation: Two keys are entered into the VSM. Host E M K 1, E M (K 2 ) VSM api The VSM generates Terminal Key by XOR them. VSM api E M K 1 K 2 Host Terminal Key K = k 1 k 2

Attack on Visa Security Module API Terminal Key creation: Terminal Key K = k 1 k 2 What happens if we insert the same encrypted key twice? K = k 1 k 1 =. Host VSM api E M K 1, E M (K 1 ) E M K 1 K 1 VSM api Host Zero key inside the system.

Attack on Visa Security Module API So what can be done now? The VSM had a transaction to encrypt any key K supplied encrypted under M, under any other key that itself is encrypted under M. Host VSM api E M K, E M (P) E K P VSM api Host

Attack on Visa Security Module API The bank s PIN verification key was also stored outside the module encrypted under M. It was made for offline PIN verification support. Host VSM api E M K, E M (PIN Verify ) E K PIN Verify VSM api Host

Attack on Visa Security Module API But now, K = K 1 K 1 = encrypted under M either. So we can encrypt" the bank s PIN verification key under our key. We decrypted the bank s crown jewels, who was even kept outside the module. Host VSM api E M, E M (PIN Verify ) E PIN Verify VSM api Host

PINs retrieval 11 a.k.a. another attack The next attack was found by building a formal model of the key types. Host MAC, E M (K) VSM api The VSM had another transaction of entering unencrypted MAC key, and getting it encrypted under you guessed it - any other key K that itself encrypted under M. VSM api E K MAC Host

PINs retrieval 11 a.k.a. another attack Wait a minute! We can get the MAC encrypted under PIN Verify. What will happen if we enter account number A num instead of legit MAC? Host VSM api A num, E M (PIN Verify ) E PINVerify A num VSM api Host

PINs retrieval 11 a.k.a. another attack Wait a minute! We can get the MAC encrypted under PIN Verify. What will happen if we enter account number A num instead of legit MAC? We just got the actual PIN number just by inputting the victim s account number. Host VSM api A num, E M (PIN Verify ) E PINVerify A num VSM api Host

Attack on IBM PIN Generation

Attack on IBM PIN Generation In IBM PIN code generation, PIN C depends on 3 values: PIN Verify bank s master PIN. A num account number. offset for memorable (weak) PIN. H = E PINVerify (A num ) D = Decimalize(H) by Dec Table PIN C = D 4 1 + offset

Attack on IBM PIN Generation Lets take an example where: A num = 88712345691715 PIN Verify = FEFEFEFEFEFEFEFE offset = 6565 Dec Table : E PINVerify A num = a2ce126c69aec82d Decimalize(H) = 2241262694823 PIN C = 224 + 6565 = 6789 1 2 3 4 5 6 7 8 9 A B C D E F 1 2 3 4 5 6 7 8 9 1 2 3 4 5

Attack on IBM PIN Generation Hey! Lets let the user supply the Dec Table!

Attack on IBM PIN Generation Why?

Attack on IBM PIN Generation Set Dec Table = Get E(PIN C ) = F E D C B A 9 8 7 6 5 4 3 2 1 F E D C B A 9 8 7 6 5 4 3 2 1 1 Set Dec Table = If E PIN C has changed, then it contained a.

Attack on IBM PIN Generation And so on. With a few dozen queries PIN C can be found

Attack on IBM PIN Generation IBM s solution : Dec Table Must contain at least 8 different characters, that appear at most 4 times.

Attack on IBM PIN Generation Set Dec Table = Get E(PIN C ) Set Dec Table = Again, If E PIN C has changed, then it contained a. F E D C B A 9 8 7 6 5 4 3 2 1 5 4 3 2 1 9 8 7 6 5 4 3 2 1 F E D C B A 9 8 7 6 5 4 3 2 1 5 4 3 2 1 9 8 7 6 5 4 3 2 1 1

HTML 5 Fullscreen API attack

HTML 5 Fullscreen API attack What is the Full-Screen API? The Fullscreen API provides an easy way for web content to be presented using the user's entire screen. The API lets you easily direct the browser to make an element and its children, occupy the Fullscreen, eliminating all browser UI and other applications from the screen for the duration.

HTML 5 Fullscreen API attack Using the Fullscreen API to present the user with an image that legitimizes the forged site. http://feross.org/html5-fullscreen-api-attack/

The XSS family

XSS Cross Site Scripting o XSS is a type vulnerability that occurs when attacker uses a webapp to inject client-side scripts into web pages viewed by other users. o Every month roughly 1-25 XSS exploits are discovered in commercial products.

XSS Cross Site Scripting

XSS Cross Site Scripting o There are (arguably) three types of XSS o Persistent (Stored) XSS o Non-Persistent (Reflected) XSS o Local (DOM-Based) XSS

Stored (Persistent) XSS 1. The attacker uses one of the website's forms to insert a malicious string into the website's database. 2. The victim requests a page from the website. 3. The website includes the malicious string from the database in the response and sends it to the victim. 4. The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.

Reflected (Non-Persistent) XSS 1. The attacker crafts a URL containing a malicious string and sends it to the victim. 2. The victim is tricked by the attacker into requesting the URL from the website. 3. The website includes the malicious string from the URL in the response. 4. The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.

Local (DOM Based) XSS 1. The attacker crafts a URL containing a malicious string and sends it to the victim. 2. The victim is tricked by the attacker into requesting the URL from the website. 3. The website receives the request, but does not include the malicious string in the response. 4. The victim's browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page. 5. The victim's browser executes the malicious script inserted into the page, sending the victim's cookies to the attacker's server.

SQL Injections

SQL injection Many APIs use SQL transactions in the background. The code is written in advance, and the parameters are taken from the API call. If the parameter isn t checked, SQL code can be Injected and executed.

SQL injection SQL code: select from believers where name = $$ ; Expected parameter ($$): High Sparrow Attacker s parameter: High Sparrow ); insert into believers values ( Tomen Baratheon When inserted: select from believers where name = ( High Sparrow ); insert into believers values ( Tomen Baratheon );

SQL injection

Buffer Overflow

Buffer Overflow Every API reads input from the user. No computer has an infinite input buffer. Devastating attacks can be executed if input string length is not checked. What is the problem here?

Buffer Overflow The Stack Stack gets locals BP return addr param - buffer gets frame buffer BP return addr main frame

Buffer Overflow The attack Stack gets locals main finishes as usual The Computer is infected BP return addr param - buffer buffer BP return addr Code: download( GoT.mkv ) while( 1 ) play( Got.mkv )

The takeaway When implementing an API you should: Trust yourself only, and secure your software. Understand your needs and don t push it.

The takeaway Input check. The code which handles the user s input is extremely critical It should be treated that way.

Defend and Secure the perfect guide

Thank you for not falling a sleep! Hodor?