© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
The Mobile Threat Landscape
Daniel MiesslerPrincipal Security Architect, HP FortifyJune 2013
© 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 FortifyJune 2013
Agenda
- Introduction
- Why Mobile Security Matters
- Mobile Security Differences
- Attacker Perspective
- Common Mobile Vulnerabilities
- Takeaways
- Questions
Introduction
Daniel Miessler, CISSP, CISA, GCIAPrincipal Security Architect, HP Fortify
- 10 years experience doing security testing- 5 years experience doing appsec testing- Web Application Vulnerability Assessments- Mobile Application Vulnerability Assessments- Application Security Process Development- Enterprise Security Consulting
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Why Mobile Security Matters
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
Data from Smart Insights, Yankee Group 2012
• Mobile performance is becoming extraordinary
• Using a desktop (static) computer will become increasingly rare
• “Home computer” will come to mean better input and display options
Considerations | Mobile Ubiquity
• 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
Considerations | Mobile Ubiquity II
• 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)
Considerations | Mobile Insecurity
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Mobile Security Differences
Q: What’s the difference between “regular” security and mobile security?
Mobile Security Differences
Mobile Security Differences | Thick-client Testing
Client ServerNetwork
• 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
Mobile Security Differences | Thick-client Testing: Client
Client ServerNetwork
• 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
Mobile Security Differences | Thick-client Testing: Network
Client ServerNetwork
• 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
Mobile Security Differences | Thick-client Testing: Server
Client ServerNetwork
• 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
Q: What’s the difference between this and mobile?
Mobile Security Differences
Mobile Security Differences | Mobile Security
Client ServerNetwork
• 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
A: Not much.
Mobile Security Differences
Mobile Security Differences | Expanded Mobile Risk
Two key differences
Magnified network vulnerability
Your network traffic is more likely to be visible to others with a mobile device than at work or home
Magnified physical vulnerability
As with most other types of computer, once the attacker has physical access, it’s over
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Attacker Perspective
Attacker Perspective
Much of security comes down to seeing things from a different perspective, and mobile is no different
Attacker Perspective | What Users See
Get the username
Get the password
Remember the User
Get Sales Data
Edit my account
Generate Reports
SQL Injection
Cross Site Scripting
Improper Session Handling
Data Leakage
Sensitive Information Disclosure
Weak Server Side ControlsClient Side Injection
Insufficient Data Storage
Attacker Perspective | What Attackers See
Attacker Perspective | What Users See
ACME Corp
Home
Coffee Shop
Web
eComm
Store
POS
App
VPN
VPN functionality Remote working Happy workforce
Shorter time to checkout Fewer checkout workers Increased sales
Mobile convenience Access anywhere Increased productivity
Attacker Perspective | What Attackers See
ACME Corp
Home
Coffee Shop
Web
eComm
Store
POS
App
VPN
Malware on home machines Trusted VPN connection
Modification of POS equipment Interception of wireless traffic in store Vulnerabilities in mobile application
Open wireless traffic Device theft
SQL Injection XSS Authentication flaws
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Common Mobile Vulnerabilities
2013 Edition
??
??
? ??
?
???? ? ??
?
Common Vulnerabilities | Most Apps Are Vulnerable
Most 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 younger, more eager the shop– the higher the chance of issues
Common Vulnerabilities | OWASP
Open 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/
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
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
• 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
Common Vulnerabilities | Real-world Results
66%
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
Common Vulnerabilities | Logic Flaw Defense
Logic 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
Common Vulnerabilities | Poor TLS Implementations
Many 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
Common Vulnerabilities | Poor TLS Implementation
TLS 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
Common Vulnerabilities | Promiscuous Client-side Storage
Perhaps 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
Common Vulnerabilities | Promiscuous Client-side Storage
Be cautious of anything you save—anywhere—including on the client-side
Ensure you’re using the platform-recommended solution to store credentials
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
Q: What data on your iOS device is protected by the built-in encryption, i.e. the passcode?
Common Vulnerabilities | Promiscuous Client-side Storage
A: By default, only email and texts.
In other words, most application data being stored on an iOS device is available to anyone who steals your phone—even if it is locked and has a passcode.
Common Vulnerabilities | Promiscuous Client-side Storage
Common Vulnerabilities | Promiscuous Client-side Storage
DEMO Corporate issued
iPhone Latest software
(6.1.4) Not jailbroken Locked With passcode
Common Vulnerabilities | Promiscuous Client-side Storage
Be 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 documenetation)
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
Common Vulnerabilities | Failure to Harden Binaries
There 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
Common Vulnerabilities | Failure to Harden Binaries
Use all defenses possible to harden your binaries before release
While some are not critical security issues, they still can have an impact on the overall quality of your application
Common Vulnerabilities | Privacy Violations
Many applications violate privacy without developers being aware
Does the application access GeoLocation data? Does the application access your 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?)
Common Vulnerabilities | Privacy Violations
Go 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 (AppAuthority, HP Risker)
Common Vulnerabilities | Assumption of Web Obscurity
A 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 datastores are often shared! Shared hosting means compromise of multiple
customers
Common Vulnerabilities | Assumption of Web Obscurity
Harden 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
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 non-scrutinized applications have major vulnerabilities that are easily found
Takeaways
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
Takeaways
Remember that you must explicitly use the Data Protection APIs otherwise your data will still be available to a thief
Don’t be intimidated by “mobile” security; the fundamentals are the same
Use industry-tested methods for implementing security; be extremely weary of DIY solutions for input validation, encryption, authentication, etc.
Take advantage of the resources available to help you, e.g.: platform secure coding guides, OWASP, etc.
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 iOS Developer Cheat sheethttps://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Thank You
Top Related