6 Ways to Build an Insecure Mobile Application

1. 6 Ways to Build an Insecure Mobile Application How to avoid the most common mobile vulnerabilities Daniel MiesslerPrincipal Security Architect, HP FortifyNovember 2013

2. Agenda • Introduction • Why mobile security matters • Mobile security differences • Common developer mistakes • Takeaways • Questions

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

4. Why mobile security matters

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

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?

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

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)

9. Mobile security differences

10. Mobile security differences Q:What’s the difference between “regular” security and mobile security?

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

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 • Credentials in memory • Credentials on filesystem • Data stored on filesystem • Poor cert management

13. 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 • Credentials in memory • Credentials on filesystem • Data stored on filesystem • Poor cert management • Cleartext credentials • Cleartext data • Backdoor data • Data leakage

14. Mobile security differences: Thick-client testing Client Network Server • Injection flaws • Authentication • Session management • Access control • Logic flaws • 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

15. Mobile security differences Q:What’s the difference between this and mobile?

16. Mobile security differences: Mobile security Client Network Server • Injection flaws • Authentication • Session management • Access control • Logic flaws • 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

17. 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 • As with most other types of computer, once the attacker has physical access, it’s over • Magnified physical vulnerability

18. Common mobile vulnerabilities2013 edition

19. 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 manyissues • Evaluating any given application is likely to yield significant vulnerabilities • The newer, more eager the shop– the higher the chance of issues

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

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

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%

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

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

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

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

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

29. Common vulnerabilities: Promiscuous client-side storage • Abuse 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

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

31. 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 • Developers are often contractors, and have customer names in paths

32. Common vulnerabilities: Failure to harden binaries • There are a number of binary defenses that developers are not implementing • Abuse 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

33. Common vulnerabilities: Failure to harden binaries • Use 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

34. Common vulnerabilities: Privacy violations • Many 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?)

35. 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 (Appthority, HP Risker)

36. 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 data stores are often shared! • Shared hosting means compromise of multiple customers

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

38. Takeaways

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

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

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

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

43. Takeaways • iOSSecurity 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 • Resources

44. Reach out Daniel.Miessler@hp.com

45. Questions