Upload
hinto
View
52
Download
0
Tags:
Embed Size (px)
DESCRIPTION
6 Ways to Build an Insecure Mobile Application. How to avoid the most common mobile vulnerabilities. Daniel Miessler Principal Security Architect, HP Fortify November 2013. Agenda. Introduction Why mobile security matters Mobile security differences Common developer mistakes Takeaways - PowerPoint PPT Presentation
Citation preview
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
6 Ways to Build an Insecure Mobile Application
Daniel MiesslerPrincipal Security Architect, HP FortifyNovember 2013
How to avoid the most common mobile vulnerabilities
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
Agenda
• Introduction• Why mobile security matters• Mobile security differences• Common developer mistakes• Takeaways• Questions
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.3
Introductions
Daniel Miessler, CISSP, CISA, GCIAPrincipal Security Architect, HP Application Security
- Work on Fortify on Demand Team- Cloud-based Application Security- Penetration Testing Background- Enterprise Security Architecture- Application Security Program Development
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Why mobile security matters
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.5Data from Smart Insights, Yankee Group 2012
Considerations: Mobile traffic increases
• Global mobile data traffic will increase 26-fold between 2010 and 2015
• There will be nearly one mobile device per capita by 2015 (~7 billion)
• Mobile payments will exceed 984 Billion by 2014
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.6
Considerations: Mobile ubiquity
• Mobile performance is becoming extraordinary
• Using a non-mobile computer will become increasingly rare
• “Home computer” will come to mean better input and display options for your mobile system
• Apple replacing desktop with mobile?
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.7
Considerations: Mobile ubiquity II
• 2014 is considered the year that mobile web traffic will surpass non-mobile web traffic
• Mobile computing will soon be known as “computing”
• Computing somewhere other than
your mobile device will be the activity that requires a name
• Attackers follow the users
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.8
Considerations: Mobile insecurity• Mobile development is the hottest type of
development right now. New surface area equals dangerous surface area
• If anyone’s going to put features over security to get the product out the door, it’s likely to be a mobile team
• Many enterprise mobile developers haven’t had the security training that other types of developers have had
• Many assume that because mobile back ends aren’t visited directly they are more secure (obscurity assumption)
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Mobile security differences
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.10
Q: What’s the difference between “regular” security and mobile security?
Mobile security differences
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.11
Client
Mobile security differences: Thick-client testing
Server
• ABAP• C/C++• Java• Objective
C• Python• VB6• COBOL• Cold
Fusion• XML• SQL
• ASP.NET• VB.NET• C#• Classic ASP• HTML• Flex• JavaScript/
AJAX• JSP• PHP• VBScript
Network
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.12
Client
Mobile security differences: Thick-client testing
Server
• ABAP• C/C++• Java• Objective
C• Python• VB6• COBOL• Cold
Fusion• XML• SQL
• ASP.NET• VB.NET• C#• Classic ASP• HTML• Flex• JavaScript/
AJAX• JSP• PHP• VBScript
• Credentials in memory• Credentials on
filesystem• Data stored on
filesystem• Poor cert
management
Network
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.13
Client
Mobile security differences: Thick-client testing
Network Server
• ABAP• C/C++• Java• Objective
C• Python• VB6• COBOL• Cold
Fusion• XML• SQL
• ASP.NET• VB.NET• C#• Classic ASP• HTML• Flex• JavaScript/
AJAX• JSP• PHP• VBScript
• Credentials in memory• Credentials on
filesystem• Data stored on
filesystem• Poor cert
management
• Cleartext credentials• Cleartext data• Backdoor data• Data leakage
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.14
Client
Mobile security differences: Thick-client testing
Network Server
• ABAP• C/C++• Java• Objective
C• Python• VB6• COBOL• Cold
Fusion• XML• SQL
• ASP.NET• VB.NET• C#• Classic ASP• HTML• Flex• JavaScript/
AJAX• JSP• PHP• VBScript
• Credentials in memory• Credentials on
filesystem• Data stored on
filesystem• Poor cert
management
• Cleartext credentials• Cleartext data• Backdoor data• Data leakage
• Injection flaws• Authentication• Session
management• Access control• Logic flaws
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.15
Q: What’s the difference between this and mobile?
Mobile security differences
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.16
Client
Mobile security differences: Mobile security
Network Server
• ABAP• C/C++• Java• Objective
C• Python• VB6• COBOL• Cold
Fusion• XML• SQL
• ASP.NET• VB.NET• C#• Classic ASP• HTML• Flex• JavaScript/
AJAX• JSP• PHP• VBScript
• Credentials in memory• Credentials on
filesystem• Data stored on
filesystem• Poor cert
management
• Cleartext credentials• Cleartext data• Backdoor data• Data leakage
• Injection flaws• Authentication• Session
management• Access control• Logic flaws
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.17
Two key differences
Mobile security differences: Expanded mobile risk
Magnified physical vulnerability
As with most other types of computer, once the attacker has physical access, it’s over
Magnified network vulnerability
Your network traffic is more likely to be visible to others with a mobile device than at work or home
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Common mobile vulnerabilities2013 edition
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.19
Common vulnerabilities: Most apps are vulnerableMost high-scrutiny (see: previously hacked) mobile apps are decently secure now, but the next tier down still have many issues
• Evaluating any given application is likely to yield significant vulnerabilities
• The newer, more eager the shop– the higher the chance of issues
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.20
Common vulnerabilities: OWASPOpen Web Application Security Project
• Thought leader in web security• Runs many projects designed to
help industry security their applications
• OWASP Top 10• Risk Rating Methodology• Vulnerability Prevention Cheat
sheets• Our team is heading up the
Mobile Top 10 2013
http://www.owasp.org/
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.21
OWASP Mobile Top 10 Risks
M1 – Insecure Data Storage M6 – Improper Session Handling
M2 – Weak Server Side Controls M7 – Security Decisions via Untrusted Inputs
M3 – Insufficient Transport Layer Protection M8 – Side Channel Data Leakage
M4 – Client Side Injection M9 – Broken Cryptography
M5 – Poor Authorization and Authentication M10 – Sensitive Information Disclosure
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.22
Common vulnerabilities: Real-world perspective• Definitely check out the OWASP
Top 10, but this is more about what we’re seeing in the wild
• We constantly test mobile applications from the top companies in the world, and these are the top categories of issue we find in those applications
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.23
Common vulnerabilities: Real-world results
• Case study of 120 Mobile applications for a single enterprise customer (results are typical)
• 66% of applications contained a critical or high vulnerability that either:• Disclosed 1 or more users’
personal data• Compromised the backend system
66%
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.24
Common vulnerabilities: Logic flaws
Logic flaws are due to faulty developer assumptions, i.e. not thinking like an attacker
• Changing an arbitrary user’s password
• Bypassing multi-step authentication
• Free product by skipping payment step
• Product + refund by submitting negative number
• Defeating a business limit by entering a high negative number
• Getting a bulk discount on only one item by modifying the cart manually afterwards
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.25
Common vulnerabilities: Logic flaw defenseLogic flaws are avoided by performing exhaustive vulnerability assessments before going to production
• Fully understand the anticipated flow of the application
• Assume the mind of the attacker• Identify places that developers
likely made assumptions• Attempt to take advantage of
those assumptions• As a developer, think in terms of
abuse vs. just regular use
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.26
Common vulnerabilities: Poor TLS implementationsMany mobile developers are allowing SSL communication with any host
• Trusting any certificate it sees• Allows expired certificates• Allows trivial MiTM attacks• Can connect to HTTPS once, and
then fall back• Once in the middle, attackers can
model your app’s functionality enroute to breaking it
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.27
Common vulnerabilities: Poor TLS implementationTLS protection has multiple levels of security
• Ensure HTTPS is always enabled• Attempt to match the name of the
remote certificate• Certificate pinning*• Recognize that nothing is fool-
proof, and adjust according to your app’s specific needs
• Remember that pinning was a defense against compromised CAs, not against MiTM
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.28
Common vulnerabilities: Promiscuous client-side storagePerhaps the most abused functionality is client-side storage
• Storage of credentials in plist files, SQLite databases
• Failure to use KeyChain to store credentials
• Storage of sensitive application data on filesystem
• Apps (e.g.: banks) storing their images in the public folder rather than in their sandbox
• Applications logging to the system log, but sending sensitive app data along with it
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.29
Common vulnerabilities: Promiscuous client-side storageAbuse case • Application protected by voice
password
• Password checked server side
• File was stored locally
• Retrieved the file from the file system
• Played the file back to itself
• Gained access
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.30
Common vulnerabilities: Promiscuous client-side storageBe cautious of anything you save—anywhere—including on the client-side
• Ensure you’re using the platform-recommended solution to store credentials
• Ensure you use the Data Protection API to store any sensitive data; it will not be protected by default: (See: NSFileProtectionComplete in developer documentation)
• Ensure you are storing everything from your app into the app sandbox so it cannot be read by other applications
• Check all logging functionality and note what you’re sending
• Observe your log files within the XCode log viewer and ensure you are not storing anything sensitive
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.31
Common vulnerabilities: Failure to harden binariesThere are a number of binary defenses that developers are not implementing
• ASLR PIE (memory randomization)
• Stack Smashing Protection Enabled (Canary-based)
• Automatic Reference Counting (memory resources)
• Binary debug not disabled – User path information disclosure
• Developers are often contractors, and have customer names in paths
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.32
Common vulnerabilities: Failure to harden binariesThere are a number of binary defenses that developers are not implementingAbuse case
• Found developer name in path• Was no longer with company• Checked Github• Had all source available for
apps• Mobile and backend• Lead to complete compromise
of server
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.33
Common vulnerabilities: Failure to harden binariesUse all defenses possible to harden your binaries before release
• Ensure binary protections are in place
• Some are not security-specific, but improve the overall quality of your applications
• Ensure no information disclosure is present
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.34
Common vulnerabilities: Privacy violationsMany applications violate privacy without developers being aware
• Does the application access GeoLocation data?
• Does the application access the Address Book?
• Does the application access your Photos?
• If so, what is your app doing with this data?
• Does your application use analytics engines?
• If so, what does it send there? (UUID, app data?)
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.35
Common vulnerabilities: Privacy violationsGo with an absolute least-privilege approach
• Don’t access any data that could be considered private if you don’t need it
• There are applications out there that can evaluate what a given binary accesses (Appthority, HP Risker)
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.36
Common vulnerabilities: Assumption of web obscurityA massive number of applications we see and compromise are compromised due to backend vulnerabilities
• Promiscuous web services• Full SQL statements right in web
service calls (saved money on MSSQL Server Manager)
• Blatant SQLi, XSS, CSRF, File Includes, etc.
• Many developers assume “who’s coming here?”
• The data stores are often shared!
• Shared hosting means compromise of multiple customers
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.37
Common vulnerabilities: Assumption of web obscurityHarden your web backend as if the mobile app didn’t even exist
• Remember how easy it is to MiTM a mobile app
• Assume everyone can see your traffic
• This means they can see all the paths and parameters for your backend
• Assume attackers will come knocking
• Consider the risks of shared hosting, as others might not be taking these steps—even if you did
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Takeaways
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.39
Takeaways
Security as an enabler vs. obstacle
• Formula 1 cars have brakes to allow them to go faster, not slower
• The business is able to move faster because security enables that flexibility to happen safely
• Try to frame your conversations around enabling safe agility vs. placing restrictions on it
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.40
Takeaways
It’s an interesting time for mobile security
• Everyone’s heading to mobile, and the attackers are following
• Mobile is on the leading edge of development, so mobile projects are especially susceptible to security shortcuts
• Most applications have major vulnerabilities that are easily found
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.41
Takeaways
Adopt the attacker mindset• Don’t be afraid to look at your own
apps using SCA and WebInspect. Classic security fundamentals apply!
• Think like an attacker and follow some basic steps to help you evaluate your own applications without much cost
• Assume the attacker has access to the device and visibility of all traffic going to and from the server, and code accordingly (learn from cryptography)
• As part of a threat modeling step, track your sensitive data through your app, from user to device to network to server; see where it’s vulnerable
• Don’t store PII if you don’t have to
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.42
HP Fortify on Demand
• Cloud-based application security testing
• Both static and dynamic testing, using automated and manual techniques
• Integrates with your SDLC and build environment to provide critical security checkpoint
• Single portal for code uploads and reviewing results
• Always hiring• Test your apps for free at: https://
fortifymyapp.com
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.43
Takeaways
Resources iOS Security Guidehttp://images.apple.com/iphone/business/docs/iOS_Security_Oct12.pdf
Android Security Guidehttp://source.android.com/tech/security/
OWASP Mobile Top 10https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
OWASP SecLists Projecthttps://www.owasp.org/index.php/OWASP_SecLists_Project
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Reach out
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Questions