OWASP Day - OWASP Day - Lets secure!
-
Upload
prathan-phongthiproek -
Category
Internet
-
view
582 -
download
1
Transcript of OWASP Day - OWASP Day - Lets secure!
OWASP Top 10 Mobile Risks 2016(RC)
Prathan Phongthiproek
OWASP Mobile Security Team
Overview
Arxan 5th Annual State of Application Security reportThe new research analyzed 126 popular mobile health and finance apps from the US, UK, Germany, and Japan
Key findings:
Consumers and app executives believe their mobile health and finance apps are secure. A combined 84 percent of mobile app users and mobile app executives believe that their mobile health and finance apps are “adequately secure,”
The majority of mobile health and finance apps contain critical security vulnerabilities. 90 percent of the mobile health and finance apps tested had at least two of the Open Web Application Security Project (OWASP) Mobile Top 10 Risks.
The security and safety risks are real and significant. 98 percent of the mobile apps tested lacked binary protection. 83 percent of the mobile apps had insufficient transport layer protection.
Most consumers would change providers if they knew their apps were not secure. 80 percent of mobile app users would change providers if they knew the apps they were using were not secure. 82 percent would change providers if they knew alternative apps offered by similar service providers were more secure.
The Open Web Application Security Project (OWASP)– OWASP Top 10 Mobile Risks 2014 and 2016(RC)https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
Guideline for Mobile Application Security
OWASP Top 10 Mobile 2014 OWASP Top 10 Mobile 2016(RC)
M1: Weak Server Side Controls M1 - Improper Platform Usage
M2: Insecure Data Storage M2 - Insecure Data Storage
M3: Insufficient Transport Layer Protection M3 - Insecure Communication
M4: Unintended Data Leakage M4 - Insecure Authentication
M5: Poor Authorization and Authentication M5 - Insufficient Cryptography
M6: Broken Cryptography M6 - Insecure Authorization
M7: Client Side Injection M7 - Client Code Quality
M8: Security Decisions Via Untrusted Inputs M8 - Code Tampering
M9: Improper Session Handling M9 - Reverse Engineering
M10: Lack of Binary Protections M10 - Extraneous Functionality
The Open Web Application Security Project (OWASP)– OWASP Mobile Security Testing Guide (MSTG)https://github.com/OWASP/owasp-mstg
Guideline for Mobile Application Security
Ref: https://docs.google.com/document/d/132Ose0jdQwN6Z_Fp0VOJtVdGCufIwligwmf6oT0lmK8/edit
The Open Web Application Security Project (OWASP)– OWASP Mobile Top 10 Controlshttps://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_10_Mobile_Controls
Guideline for Mobile Application Security
The Open Web Application Security Project (OWASP)– OWASP Mobile Application Security Verification Standard (MASVS)https://github.com/OWASP/owasp-masvs
Guideline for Mobile Application Security
V1: Architecture, Design and Threat Modelling
Requirements
V2: Data Storage and Privacy Requirements
V3: Cryptography Verification
Requirements
V4: Authentication and Session Management
Requirements
V5: Network Communication Requirements
V6: Environmental Interaction
Requirements
V7: Code Quality and Build Setting
Requirements
V8: Resiliency Against Reverse Engineering
Requirements
OWASP Top 10 Mobile Risks – 2016 (RC)
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
M1 – IMPROPER PLATFORM USAGE
M1 – Improper Platform UsageMisuse of a platform feature or failure to use platform security controls
• Unintentional misuse of Android Intent, TouchID, Keychain
• Requesting too many permissions, or the wrong permissions
• Includes security control that is part of the mobile operating system
M1 – Improper Platform UsageAbusing Android Content Provider for obtaining sensitive information from application database.
Sensitive Information
.DBContentProvider
M1 – Improper Platform UsageCVE-2015-1835: Remote exploit of secondary configuration variables in Apache Cordova on Android
M2 – INSECURE DATA STORAGE
M2 – Insecure Data StorageThis covers insecure data storage (M2) and unintended data leakage (M4).
2014 M2 Insecure Data Storage 2014 M4 Unintended Data Leakage
SQLite Databases URL Caching
Log Files Keystroke logging
Plist Files Screenshots (Task switcher)
XML Data stores /Manifest Files Logs (system, crash)
Binary data stores Copy/Paste buffer caching
Cookie stores Temp directories
SD card
Keychain
Cloud sync’d folders
M2 – Insecure Data StorageInsecure Data Storage lead to Client-side based authentication flaw and File manipulation
M2 – Insecure Data StorageSide-Channel Data Leakage through Android Clipboard and iOS generalPasteboard
M2 – Insecure Data StorageInformation Leakage through Application backgrounding
M3 – INSECURE COMMUNICATION
M3 – Insecure Communication
• Poor handshaking
• Incorrect SSL version
• Weak negotiation
• Clear-text communication of sensitive assets; IMEI and hardware addresses, phone number or home address
• SSL certificate validity
M3 – Insecure Communication
M4 – INSECURE AUTHENTICATION
M4 – Insecure AuthenticationNotions of authenticating the end user or bad session management. This can include:
• Failure to identify the user at all when that should be required
• Failure to maintain the user's identity when it is required
• Weaknesses in session management
• Lack of Adequate Timeout Protection
• Using device identifier (UDID, IP, MAC address, IMEI) to identify a user or a session
• Using SMS Out-of-Band Authentication (OOBA) which can be exploited based upon the fact that SMS was never designed to have the Confidentiality and Integrity that we as security professionals look for in systems.
• NIST SP 800-63-3: Digital Authentication Guideline
M4 – Insecure AuthenticationBypass Client-side authentication using AM
M4 – Insecure AuthenticationBypass Client-side authentication using AM
M5 – INSUFFICIENT CRYPTOGRAPHY
M5 – Insufficient Cryptography
• Encoding != Encryption
• Creation and Use of Custom Encryption Protocols
• Use of Insecure and/or deprecated algorithmso RC2
o MD4
o MD5
o SHA1
M5 – Insufficient Cryptography
M6 – INSECURE AUTHORIZATION
M6 – Insecure Authorization
• Poor or missing authorization schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app
• If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required)
M6 – Insecure AuthorizationBreaking Business Logic Flaw #1
Breaking Business Logic Flaw #2
M7 – CLIENT CODE QUALITY
M7 – Client Code Quality
• Code-level implementation problems in the mobile client. That's distinct from server-side coding mistakes.
M7 – Client Code QualityAttacking Protocols Handlers (URL Scheme) - Sea Surf
dvia://highaltitudehacks.com/call_number/?phone=1234567890
M7 – Client Code QualitySQLite Injection
M8 – CODE TAMPERING
M8 – Code Tampering• Binary patching
• Local resource modification
• Method hooking or swizzling
• Dynamic memory modification.
M8 – Code TamperingInstrumenting Android Applications with Frida using Brute-Force technique
M8 – Code TamperingRuntime manipulation using Method Swizzling
M8 – Code TamperingBreaking Business Logic flaws and Bypassing End-to-end encryption
Binary file was decrypted in order to obtain classes/methods using Classdump
The encryption and decryption classes were addresses
cy#
Encryption/Decryption classes were intercepted by hooking using custom Cycript scripts
HTTPS Request/Response were obtained
cy#
Custom script were created for replacing the XML request/response in order to break business logic flaws (E.g. Authentication/Authorization/Indirect Object Reference)
M9 – REVERSE ENGINEERING
M9 – Reverse Engineering• Unfortunately, it is extremely common for apps to be deployed without binary protection
• A lack of binary protections results in a mobile app that can be analyzed, reverse-engineered, and modified by an adversary
• Can use an automated tool to easily visualize the control-flow and pseudo-code of the application
M9 – Reverse EngineeringReverse-Engineering on iOS
M10 – EXTRANEOUS FUNCTIONALITY
M10 – Extraneous Functionality• Developers include hidden backdoor functionality or other internal development security controls that are
not intended to be released into a production environment.
• For example, a developer may accidentally include a password as a comment in a hybrid app.
• Disabling of 2-factor authentication during testing.
Thank you
Q&A
References
• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
• https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
• https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_10_Mobile_Controls
• https://github.com/OWASP/owasp-mstg
• https://github.com/OWASP/owasp-masvshttps://blog.ul-ts.com/posts/nist-to-deprecate-sms-for-out-of-band-authentication-what-is-the-impact/
• http://integricell.com/sms-out-of-band-authentication-a-false-sense-of-security/