Designing Secure Mobile Apps
           Guerilla Training Camp
           Security BSides Austin

           Dan Cornell




© Copyright 2011 Denim Group - All Rights Reserved
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
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
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
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
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
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
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
Generic Mobile Application Threat Model




© Copyright 2011 Denim Group - All Rights Reserved   8
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
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
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
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
         –     http://www.sit.fraunhofer.de/en/forschungsbereiche/projekte/Lost_iPhone.jsp
         –     Oops…
         –     Android is even worse
 • Hope on the horizon?
         –     http://www.engadget.com/2011/02/02/android-3-0-honeycomb-can-encrypt-all-your-data-needs-a-full/


© Copyright 2011 Denim Group - All Rights Reserved                                                                12
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
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
Browser Behavior
 • Many mobile application are a combination of “apps” and web content
 • Keep track of WebKit vulnerabilities:
         – http://www.webkit.org/
 • Most mobile browsers aggressively cache and might ignore standard
   cache behavior




© Copyright 2011 Denim Group - All Rights Reserved                       15
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
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
Decoding plist Files
                                                     • plutil -convert xml1 Info.plist
                                                     • Much nicer




© Copyright 2011 Denim Group - All Rights Reserved                                       18
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:
         – http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-
           apples-
           ios/?utm_source%253Drss%2526utm_medium%253Drss%2526utm_campaign%2
           53Dinsecure-handling-url-schemes-apples-ios
         – Too long to type? http://bit.ly/ezqdK9




© Copyright 2011 Denim Group - All Rights Reserved                                            19
Android Intents
 • Intents are facilities for late-binding messaging between applications
         – http://developer.android.com/guide/topics/intents/intents-filters.html


 • 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
What’s Up With My XML Files?
                                                     • Binary encoding

                                                     • Use axml2xml.pl to
                                                       convert them to text




                                                     http://code.google.com/p/android-random/downloads/detail?name=axml2xml.pl



© Copyright 2011 Denim Group - All Rights Reserved                                                                               21
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
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
Intent Filter Demo – Manual Launch, HTML Page




© Copyright 2011 Denim Group - All Rights Reserved   24
Intent Filter Demo – Anchor Launch, IFrame
 Launch




© Copyright 2011 Denim Group - All Rights Reserved   25
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
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
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
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
Online
 • Code, slides and videos online:

         www.smartphonesdumbapps.com




© Copyright 2011 Denim Group - All Rights Reserved   30
Questions?
 Dan Cornell
 dan@denimgroup.com
 Twitter: @danielcornell

 www.denimgroup.com
 (210) 572-4400




© Copyright 2011 Denim Group - All Rights Reserved   31

Designing Secure Mobile Apps

  • 1.
    Designing Secure MobileApps Guerilla Training Camp Security BSides Austin Dan Cornell © Copyright 2011 Denim Group - All Rights Reserved
  • 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.
    Agenda • GenericMobile 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.
    Tradeoffs: Value versusRisk • 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.
    Smart Phones, DumbApps • 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.
    Secure Mobile DevelopmentReference • Platform-specific recommendations • Key topic areas • Provide specific, proscriptive guidance to developers building mobile applications © Copyright 2011 Denim Group - All Rights Reserved 5
  • 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.
    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.
    Generic Mobile ApplicationThreat Model © Copyright 2011 Denim Group - All Rights Reserved 8
  • 10.
    Some Assumptions forDevelopers • 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.
    Bypassing Platform EnvironmentRestrictions • 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.
    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.
    Local Storage andEncryption • 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 – http://www.sit.fraunhofer.de/en/forschungsbereiche/projekte/Lost_iPhone.jsp – Oops… – Android is even worse • Hope on the horizon? – http://www.engadget.com/2011/02/02/android-3-0-honeycomb-can-encrypt-all-your-data-needs-a-full/ © Copyright 2011 Denim Group - All Rights Reserved 12
  • 14.
    Network Communication andEncryption • 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.
    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.
    Browser Behavior •Many mobile application are a combination of “apps” and web content • Keep track of WebKit vulnerabilities: – http://www.webkit.org/ • Most mobile browsers aggressively cache and might ignore standard cache behavior © Copyright 2011 Denim Group - All Rights Reserved 15
  • 17.
    In-Depth: Mobile BrowserContent 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.
    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.
    Decoding plist Files • plutil -convert xml1 Info.plist • Much nicer © Copyright 2011 Denim Group - All Rights Reserved 18
  • 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: – http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes- apples- ios/?utm_source%253Drss%2526utm_medium%253Drss%2526utm_campaign%2 53Dinsecure-handling-url-schemes-apples-ios – Too long to type? http://bit.ly/ezqdK9 © Copyright 2011 Denim Group - All Rights Reserved 19
  • 21.
    Android Intents •Intents are facilities for late-binding messaging between applications – http://developer.android.com/guide/topics/intents/intents-filters.html • 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.
    What’s Up WithMy XML Files? • Binary encoding • Use axml2xml.pl to convert them to text http://code.google.com/p/android-random/downloads/detail?name=axml2xml.pl © Copyright 2011 Denim Group - All Rights Reserved 21
  • 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.
    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.
    Intent Filter Demo– Manual Launch, HTML Page © Copyright 2011 Denim Group - All Rights Reserved 24
  • 26.
    Intent Filter Demo– Anchor Launch, IFrame Launch © Copyright 2011 Denim Group - All Rights Reserved 25
  • 27.
    I’m a SecurityTester. 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.
    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.
    So What ShouldDevelopers 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.
    So What ShouldSecurity 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.
    Online • Code,slides and videos online: www.smartphonesdumbapps.com © Copyright 2011 Denim Group - All Rights Reserved 30
  • 32.
    Questions? Dan Cornell dan@denimgroup.com Twitter: @danielcornell www.denimgroup.com (210) 572-4400 © Copyright 2011 Denim Group - All Rights Reserved 31