Designing Secure Mobile Apps


Published on

There are more ways to your mobile phone can be compromised than theft.

Published in: Technology
1 Comment
  • The mobile ecosystem presents developers with both challenges and opportunities. Before getting into the nuts and bolts of data security, consider the landscape:
    Make someone responsible for security.
    Take stock of the data you collect and retain.
    Understand differences between mobile platforms.
    Don’t rely on a platform alone to protect your users.
    Generate credentials securely.
    Use transit encryption for usernames, passwords, and other important data.
    Protect your servers, too.
    Don’t store passwords in plain text.
    You’re not done once you release your app. Stay aware and communicate with your users.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Designing Secure Mobile Apps

  1. 1. Designing Secure Mobile Apps Guerilla Training Camp Security BSides Austin Dan Cornell© Copyright 2011 Denim Group - All Rights Reserved
  2. 2. My Background • Dan Cornell, founder and CTO of Denim Group • Software developer by background (Java, .NET, etc) • OWASP San Antonio, Global Membership Committee • Denim Group – Build software with special security, performance, reliability requirements – Help organizations deal with the risk associated with their software • Code reviews and application assessments • SDLC consulting • Secure development training – instructor-led and eLearning© Copyright 2011 Denim Group - All Rights Reserved 1
  3. 3. Agenda • Generic Mobile Application Threat Model • Mobile Application Design Concerns – Bypassing Platform Environment Restrictions – Application Permission Model – Local Storage and Encryption – Network Communication and Encryption – Native Code Execution – Browser Behavior • In-depth Look at Mobile Browser Content Handling • Questions© Copyright 2011 Denim Group - All Rights Reserved 2
  4. 4. Tradeoffs: Value versus Risk • Mobile applications can create tremendous value for organizations – New classes of applications utilizing mobile capabilities: GPS, camera, etc – Innovating applications for employees and customers • Mobile devices and mobile applications can create tremendous risks – Sensitive data inevitably stored on the device (email, contacts) – Connect to a lot of untrusted networks (carrier, WiFi) • Most developers are not trained to develop secure applications – Fact of life, but slowing getting better • Most developers are new to creating mobile applications – Different platforms have different security characteristics and capabilities© Copyright 2011 Denim Group - All Rights Reserved 3
  5. 5. Smart Phones, Dumb Apps • Lots of media focus on device and platform security – Important because successful attacks give tremendous attacker leverage • Most organizations: – Accept realities of device and platform security – Concerned about the security of their custom applications – Concerned about sensitive data on the device because of their apps – Concerned about network-available resources that support their apps • Who has smartphone application deployed for customers? • Who has had smartphone applications deployed without their knowledge? – *$!%$# marketing department…© Copyright 2011 Denim Group - All Rights Reserved 4
  6. 6. Secure Mobile Development Reference • Platform-specific recommendations • Key topic areas • Provide specific, proscriptive guidance to developers building mobile applications© Copyright 2011 Denim Group - All Rights Reserved 5
  7. 7. Specific Platforms • iOS (iPhone, iPad) • Android • Blackberry (in progress) • Windows Phone 7 (in progress) – Windows Mobile 6.5 (?) • Symbian (?) • Others (?) • Will be guided by demand, which is focused by new development activity© Copyright 2011 Denim Group - All Rights Reserved 6
  8. 8. Topics Areas • Topic Areas – Overview of Application Development – Overview of Secure Development – Defeating Platform Environment Restrictions – Installing Applications – Application Permissions Model – Local Storage – Encryption APIs – Network Communications – Protecting Network Communications – Native Code Execution – Application Licensing and Payments – Browser URL Handling© Copyright 2011 Denim Group - All Rights Reserved 7
  9. 9. Generic Mobile Application Threat Model© Copyright 2011 Denim Group - All Rights Reserved 8
  10. 10. Some Assumptions for Developers • Smartphone applications are essentially thick-client applications – That people carry in their pockets – And drop in toilets – And put on eBay when the new iPhone comes out – And leave on airplanes – And so on… • Attackers will be able to access: – Target user (victim) devices – Your application binaries • What else should you assume they know or will find out?© Copyright 2011 Denim Group - All Rights Reserved 9
  11. 11. Bypassing Platform Environment Restrictions • Mobile platforms, by default, make certain promises about their environment • Do not depend on these promises to keep your data and code safe – iPhone: devices can be jailbroken – Android: devices can be rooted • Impact: – Install arbitrary applications – Run applications in a debugger – Bypass file access restrictions • Malicious users will do this on purpose – Legitimate users might have it done without their knowledge© Copyright 2011 Denim Group - All Rights Reserved 10
  12. 12. Application Permissions Model • Mobile devices have access to all sorts of fun stuff: – GPS location, camera, microphone, emails, contacts, SMS, etc • How do you determine what an application can do? – iPhone: Prompts for access – Android: Permissions defined in the AndroidManifest.xml file • As a developer you should (obviously) know what your application should be able to do – Beware 3rd party code included in your application© Copyright 2011 Denim Group - All Rights Reserved 11
  13. 13. Local Storage and Encryption • Best solution: Just do not store anything sensitive on the device – Force the user to log in for every usage – no storage of usernames and passwords – Do not cache sensitive data like account numbers, etc • But I really want to… – Encrypt the data, but… – Realize that key management issues make this a reasonably futile pursuit • Example: iOS keyring – “Correct” way to store application secrets – – Oops… – Android is even worse • Hope on the horizon? –© Copyright 2011 Denim Group - All Rights Reserved 12
  14. 14. Network Communication and Encryption • Data returned from calls to network endpoints should be treated as untrusted – Make sure to inform your static analysis tool… • Mobile devices connect to a variety of networks – Carrier, trusted wifi, untrusted wifi, bluetooth • Encrypt your network traffic – And verify server certificates… – (Android has a helper class that WORKS AROUND THIS PROTECTION) • SSLCertificateSocketFactory© Copyright 2011 Denim Group - All Rights Reserved 13
  15. 15. Native Code Execution • iOS: Objective C compiled down to ARM machine code – All native, all the time • Android: Java compiled to DEX bytecode – Can make native calls via the Native Development Kit (NDK) • Windows Phone 7: – No access to native code – Unless you are among a handful of ISVs like Adobe© Copyright 2011 Denim Group - All Rights Reserved 14
  16. 16. Browser Behavior • Many mobile application are a combination of “apps” and web content • Keep track of WebKit vulnerabilities: – • Most mobile browsers aggressively cache and might ignore standard cache behavior© Copyright 2011 Denim Group - All Rights Reserved 15
  17. 17. In-Depth: Mobile Browser Content Handling • Many mobile platforms allow you to designate applications to handle content found in web pages – By URI protocol – By content type • Provide a “premium” experience for users who have the target app installed • Examples: – tel:// URLs initiating phone calls – maps:// URLs to display maps© Copyright 2011 Denim Group - All Rights Reserved 16
  18. 18. iPhone/iPad URL Schemes • iOS applications can be set up to “handle” certain URL schemes • Defined in the application’s Info.plist • Binary format: annoying© Copyright 2011 Denim Group - All Rights Reserved 17
  19. 19. Decoding plist Files • plutil -convert xml1 Info.plist • Much nicer© Copyright 2011 Denim Group - All Rights Reserved 18
  20. 20. iOS URL Handlers • XPath: Look for: /plist/dict/array/dict[key=CFBundleURLSchemes]/array/string • Now you know the URL Schemes the app handles • SANS blog post on this issue in iOS: – apples- ios/?utm_source%253Drss%2526utm_medium%253Drss%2526utm_campaign%2 53Dinsecure-handling-url-schemes-apples-ios – Too long to type?© Copyright 2011 Denim Group - All Rights Reserved 19
  21. 21. Android Intents • Intents are facilities for late-binding messaging between applications – • One use is to allow applications to register to receive messages from the Browser when certain types of content are received – Like iOS URL Schemes but an even more comprehensive IPC mechanism© Copyright 2011 Denim Group - All Rights Reserved 20
  22. 22. What’s Up With My XML Files? • Binary encoding • Use to convert them to text© Copyright 2011 Denim Group - All Rights Reserved 21
  23. 23. Much Better • Now we see: – Screens in application – Permissions required by the application – Intents applications is registered to consume – And so on© Copyright 2011 Denim Group - All Rights Reserved 22
  24. 24. Intent Filter Example <intent-filter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="danco" /> </intent-filter> • Action: What to do? • Data: Scheme is URI “protocol” to handle • Category BROWSABLE: Allow this Action to be initiated by the browser© Copyright 2011 Denim Group - All Rights Reserved 23
  25. 25. Intent Filter Demo – Manual Launch, HTML Page© Copyright 2011 Denim Group - All Rights Reserved 24
  26. 26. Intent Filter Demo – Anchor Launch, IFrame Launch© Copyright 2011 Denim Group - All Rights Reserved 25
  27. 27. I’m a Security Tester. Why Do I Care? • URL handlers are remotely-accessible attack surface • This is a way for you to “reach out and touch” applications installed on a device if you can get a user to navigate to a malicious page • Send in arbitrary URLs via links or (easier) embedded IFRAMEs • Example: iOS Skype application used to automatically launch the Skype application and initiate a call when it encountered a skype:// URL – Apple’s native Phone handle for tel:// URLs would confirm before a call was made© Copyright 2011 Denim Group - All Rights Reserved 26
  28. 28. I’m a Developer. Why Do I Care? • See the previous slide. Bad guys care. So should you. Please. • Content passed in via these handlers must be treated as untrusted – Positively validate – Enforce proper logic restrictions • All: – Should a malicious web page be able to cause this behavior? • Make phone call, transmit location, take photo, start audio recording, etc • iOS: – Validate inputs to handleOpenURL: message • Android: – Validate data brought in from Action.getIntent() method© Copyright 2011 Denim Group - All Rights Reserved 27
  29. 29. So What Should Developers Do? • Threat model your smartphone applications – More complicated architectures -> more opportunities for problems • Watch what you store on the device – May have PCI, HIPAA implications • Be careful consuming 3rd party services – Who do you love? Who do you trust? • Be careful deploying enterprise web services – Very attractive target for bad guys – Often deployed “under the radar”© Copyright 2011 Denim Group - All Rights Reserved 28
  30. 30. So What Should Security People Do? • Find out about smartphone projects – Not always done by your usual development teams – R&D, “Office of the CTO,” Marketing • Assess the security implications of smartphone applications – What data is stored on the device? – What services are you consuming? – Are new enterprise services being deployed to support the application?© Copyright 2011 Denim Group - All Rights Reserved 29
  31. 31. Online • Code, slides and videos online:© Copyright 2011 Denim Group - All Rights Reserved 30
  32. 32. Questions? Dan Cornell Twitter: @danielcornell (210) 572-4400© Copyright 2011 Denim Group - All Rights Reserved 31