1 / 53

The Mobile Threat Landscape

The Mobile Threat Landscape. Daniel Miessler Principal Security Architect, HP Fortify June 2013. 6 Ways to Build an Insecure Mobile Application. Daniel Miessler Principal Security Architect, HP Fortify June 2013. Agenda. Introduction Why Mobile Security Matters Mobile Security Differences

blaine
Download Presentation

The Mobile Threat Landscape

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Mobile Threat Landscape Daniel MiesslerPrincipal Security Architect, HP FortifyJune 2013

  2. 6 Ways to Build an Insecure Mobile Application Daniel MiesslerPrincipal Security Architect, HP FortifyJune 2013

  3. Agenda • Introduction • Why Mobile Security Matters • Mobile Security Differences • Attacker Perspective • Common Mobile Vulnerabilities • Takeaways • Questions

  4. 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 • daniel.miessler@hp.com

  5. Why Mobile Security Matters

  6. 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

  7. Considerations | Mobile Ubiquity • 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

  8. Considerations | Mobile Ubiquity II • 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

  9. 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)

  10. Mobile Security Differences

  11. Mobile Security Differences Q: What’s the difference between “regular” security and mobile security?

  12. Mobile Security Differences |Thick-client Testing Client 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

  13. Mobile Security Differences |Thick-client Testing: Client Client 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

  14. Mobile Security Differences |Thick-client Testing: Network Client 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 • Cleartext credentials • Cleartext data • Backdoor data • Data leakage • Credentials in memory • Credentials on filesystem • Data stored on filesystem • Poor cert management

  15. Mobile Security Differences |Thick-client Testing: Server Client 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 • Injection Flaws • Authentication • Session Management • Access Control • Logic Flaws • Cleartext credentials • Cleartext data • Backdoor data • Data leakage • Credentials in memory • Credentials on filesystem • Data stored on filesystem • Poor cert management

  16. Mobile Security Differences Q: What’s the difference between this and mobile?

  17. Mobile Security Differences |Mobile Security Client 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 • Injection Flaws • Authentication • Session Management • Access Control • Logic Flaws • Cleartext credentials • Cleartext data • Backdoor data • Data leakage • Credentials in memory • Credentials on filesystem • Data stored on filesystem • Poor cert management

  18. Mobile Security Differences A: Not much.

  19. 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

  20. Attacker Perspective

  21. Attacker Perspective • Much of security comes down to seeing things from a different perspective, and mobile is no different

  22. Attacker Perspective |What Users See Get Sales Data Get the username Get the password Edit my account Remember the User Generate Reports

  23. Attacker Perspective |What Attackers See Insufficient Data Storage SQL Injection Data Leakage Cross Site Scripting Sensitive Information Disclosure Improper Session Handling Weak Server Side Controls Client Side Injection

  24. Attacker Perspective |What Users See

  25. Attacker Perspective |What Attackers See

  26. Common Mobile Vulnerabilities2013 Edition ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

  27. 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

  28. 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/

  29. 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

  30. 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%

  31. 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

  32. 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

  33. 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

  34. 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

  35. Common Vulnerabilities |PromiscuousClient-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

  36. Common Vulnerabilities |PromiscuousClient-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

  37. Common Vulnerabilities |PromiscuousClient-side Storage Q: What data on your iOS device is protected by the built-in encryption, i.e. the passcode?

  38. Common Vulnerabilities |PromiscuousClient-side Storage A: By default, onlyemail and texts. In other words, most application data being stored on an iOS device is available to anyone who steals your phone—evenif it is locked and has a passcode.

  39. Common Vulnerabilities |PromiscuousClient-side Storage • Corporate issued iPhone • Latest software (6.1.4) • Not jailbroken • Locked • With passcode • DEMO

  40. Common Vulnerabilities |PromiscuousClient-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

  41. 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

  42. 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

  43. 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?)

  44. 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)

  45. 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

  46. 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

  47. Takeaways

  48. 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

  49. 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

More Related