iOS and Android Security Mechanisms and Exploit Mitigations

The amount of conflicting information regarding mobile security today makes it almost impossible to distinguish topics that matter from topics that don’t. It’s harder than ever for developers to sift through the resources available to them and get meaningful information out of it. By using a clear, concise and logical approach to mobile security mechanisms, this talk will discuss the security posture of both iOS and Android. Both Apple and Google are implementing a vast amount of operating system security mechanisms, exploit mitigations, marketplace security mechanisms, general mobile application security mechanisms, etc. but developers are still unsure of the individual implications of these features. What does all of this mean to you and your apps? This talk will walk through the basics of each of these topics and leave attendees with a firm understanding of the secure and defensive mechanisms present in mobile devices and applications today.

Transcript

1. Android & iOS Security
   Mike Arpaia
   @mikearpaia
   mdevcon 2013 - March 15, 2013
   

   View Slide

2. Who am I?
   • Mike Arpaia
   - Software Engineer on Etsy’s Security team
   - Formerly a Security Consultant at iSEC Partners
   - Slightly opinionated mobile security researcher
   

   View Slide

3. Agenda
   

   View Slide

4. Android Security
   • The Basics
   • OS Security Mechanisms
   • Exploit Mitigations
   • Marketplace Security
   Mechanisms
   • Impossible Tasks
   • Conclusions
   

   View Slide

5. The Basics Android Security Overview
   

   View Slide

6. Linux Kernel The Basics
   Security features provided by the Linux Kernel
   • A user-based permissions model
   • Process isolation
   • Extensible mechanisms for secure IPC
   • The ability to remove superfluous / insecure parts of the kernel
   The Sandbox
   • Unique UIDs and GIDs per application
   

   View Slide

7. OS Security Mechanisms Android Security Overview
   

   View Slide

8. The Keychain OS Security Mechanisms
   android.security.KeyChain
   • “The KeyChain class provides access to private keys and their corresponding
   certificate chains in credential storage.”
   • Unfortunately, not much functionality is exposed
   - createInstallIntent()
   - ChoosePrivateKeyAlias(...)
   - getPrivateKey(...)
   - getCertificateChain(...)
   

   View Slide

9. The Keychain OS Security Mechanisms
   android.security.KeyChain
   • The bad news
   - Only in Android 4.0 and above
   - Not hardware backed
   - Can’t delete individual keys and user certificates
   - Once in use, screen lock cannot be removed
   - Still no low-level access to the underlying keystore
   - The CA certificate install dialog doesn’t display certificate details
   

   View Slide

10. File System Encryption OS Security Mechanisms
    • AES using a key derived from the user password
    • PBKDF2 magic to prevent brute-forcing
    • The bad news
    - Only available in Android 3.0 and above
    - Screen lock password and encryption password must be the same
    - How often do you walk around with your phone turned off?
    

    View Slide

11. Exploit Mitigations Android Security Overview
    

    View Slide

12. NX - No eXecute Exploit Mitigations
    • Memory can store instructions or data but never both
    • Introduced in Android 2.3
    - Non-executable pages by default
    • The bad news
    - Not code signing
    • Partial ROP vs. Full ROP
    • Code signing is the most effective and misunderstood mobile exploit
    mitigation
    

    View Slide

13. ASLR - Address Space
    Layout Randomization Exploit Mitigations
    • Randomizes where memory is mapped
    • Works well with other mitigations to make exploitation more difficult
    • The bad news
    - Partial ASLR wasn’t introduced until Android 4.0
    - Full ASLR is only available in Android 4.1+
    - Meaningless against local exploitation, which is all Android sees
    

    View Slide

14. Android Exploit
    Mitigation Timeline Exploit Mitigations
    • Android 2.3+
    - Format string vulnerability protections
    - Hardware-based No Execute
    - Null pointer dereference privilege escalation mitigations
    • Android 4.0+
    - ASLR to randomize key locations in memory
    • Android 4.1+
    - PIE (Position Independent Executable) support
    - Read-only relocations
    - Memory leak mitigations
    • Android 4.2+
    - FORTIFY_SOURCE for system code
    http://source.android.com/tech/security/index.html#memory-management-security-enhancements
    

    View Slide

15. Google Can’t React To
    Jailbreaks Exploit Mitigations
    0%
    10%
    20%
    30%
    40%
    50%
    60%
    70%
    80%
    90%
    100%
    4/1/12 6/1/12 8/1/12
    1.X - Cupcake/Donut
    2.1 - Eclair
    2.2 - Froyo
    2.3 - Gingerbread
    3.x - HoneyComb
    4.x - ICS/JB
    Android Exploit Time to Patch 50%
    Exploid (2.1) 294 days
    RageAgainstTheCage (2.2.1) 240 days +
    

    View Slide

16. Marketplace Security
    Mechanisms Android Security Overview
    

    View Slide

17. Overview Bouncer
    Android and Security
    Thursday, February 2, 2012 | 12:03 PM
    By Hiroshi Lockheimer, VP of Engineering, Android
    Today we’re revealing a service we’ve developed, codenamed Bouncer, which provides
    automated scanning of Android Market for potentially malicious software
    without disrupting the user experience of Android Market or requiring developers to go
    through an application approval process.
    The service performs a set of analyses on new applications, applications already in
    Android Market, and developer accounts. Here’s how it works: once an application
    is uploaded, the service immediately starts analyzing it for known malware, spyware
    and trojans. It also looks for behaviors that indicate an application might be
    misbehaving, and compares it against previously analyzed apps to detect possible red
    flags. We actually run every application on Google’s cloud infrastructure and simulate
    how it will run on an Android device to look for hidden, malicious behavior. We also
    analyze new developer accounts to help prevent malicious and repeat-offending
    developers from coming back.
    

    View Slide

18. Bouncer In A Nutshell Bouncer
    • Dynamic runtime analysis of app (after static analysis)
    • Emulated Android environment
    • Runs for 5 minutes on Google’s infrastructure
    • Allows external network access
    http://jon.oberheide.org/files/summercon12-bouncer.pdf
    

    View Slide

19. Identity Verification Google Play Store
    http://jon.oberheide.org/files/summercon12-bouncer.pdf
    Malicious App
    Developed
    Use New IP
    Submit Credit
    Card Payment
    Receive SMS
    App on Google
    Play
    Pass Security
    Review
    Submit App
    

    View Slide

20. Identity Verification Google Play Store
    http://jon.oberheide.org/files/summercon12-bouncer.pdf
    Malicious App
    Developed
    Use New IP
    Submit Credit
    Card Payment
    Receive SMS
    App on Google
    Play
    Pass Security
    Review
    Submit App
    

    View Slide

21. Identity Verification Google Play Store
    • Google requires minimal identity verification to submit apps
    - Money
    - Prepaid phones
    - EC2 instances
    http://jon.oberheide.org/files/summercon12-bouncer.pdf
    

    View Slide

22. Impossible Tasks Android Security Overview
    

    View Slide

23. Don’t Try This At Home! Impossible Tasks
    • Creating your own secure container
    - Can’t protect against root malware / attacker
    • Checking if a device is rooted
    - Inherently fallible
    - Good attackers don’t leave hints for you to rely on
    • Properly rolling your own crypto to create a magical secure solution
    - I don’t even... what the... why did you... oh no...
    

    View Slide

24. Android Conclusions Android Security Overview
    

    View Slide

25. Security Tour-de-force Android Conclusions
    • OS Security mechanisms are a step in the right direction
    • Exploit mitigations are a nice addition but don’t change much
    • Bouncer isn’t that effective but Google is trying to solve a very hard problem
    • Protect your signing key
    • Don’t store data locally
    • Always use SSL
    • Don’t create your own secure containers
    • Consider devices compromised from the start
    

    View Slide

26. iOS Security
    • The Basics
    • OS Security Mechanisms
    • Exploit Mitigations
    • Marketplace Security
    Mechanisms
    • Conclusions
    

    View Slide

27. The Basics iOS Security Overview
    

    View Slide

28. iOS Security Model The Basics
    The Basics
    • Apps run as the same user, but...
    - Apps must be signed by Apple
    - Apps are given a unique ID and directory by Apple
    • Seatbelt restricts apps from accessing anything else
    - Apps cannot access data from other apps
    - Attack surface of kernel is reduced via Seatbelt
    

    View Slide

29. OS Security Mechanisms iOS Security Overview
    

    View Slide

30. The Keychain OS Security Mechanisms
    • Apps can specify whether keychain items can be migrated onto other devices
    • If one of the -ThisDeviceOnly protection classes are used, the keychain item
    will be encrypted with a key derived from the device key
    • By default, all keychain items are created with kSecAttrAccessibleAlways
    Protection Class Description
    kSecAttrAccessible WhenUnlocked
    Keychain item can only be accessed when
    the device is unlocked
    kSecAttrAccessible AfterFirstUnlock
    Keychain item is protected until the device
    is booted and unlocked
    kSecAttrAccessible Always Keychain item is not protected
    

    View Slide

31. Data Protection API OS Security Mechanisms
    • Introduced in iOS 4
    • Designed to protect data stored in files and keychain items
    • Developers mark protected files and keychain items using constants that
    define their “protection class”
    • Different protection classes are implemented through a key hierarchy where
    each key is derived from other keys or data
    • Other than object instantiation, nothing needs to change to use the DP API*
    *Unless your app relies on accessing attributes while the device is locked and you’ve selected a policy that disallows that
    

    View Slide

32. Data Protection API OS Security Mechanisms
    • The application must set a value for NSFileProtectionKey attribute
    • By default, all files have the protection class NSFileProtectionNone
    Protection Class Description
    NSFileProtection Complete
    The file can only be accessed when the
    device is unlocked
    NSFileProtection CompleteUnlessOpen
    The file must be opened when the device is
    unlocked, but the file can be accessed afterwards,
    even when the device is locked
    NSFileProtection
    CompleteUntilFirstUserAuthentication
    The file is protected until the device is
    unlocked for the first time after boot
    NSFileProtection None No data protection
    

    View Slide

33. Data Protection API OS Security Mechanisms
    • To protect a file:
    [[NSFileManager defaultManager] createFileAtPath:[self filePath]
    contents:[@"sekret string" dataUsingEncoding:NSUTF8StringEncoding]
    attributes:[NSDictionary dictionaryWithObject:NSFileProtectionComplete
    forKey:NSFileProtectionKey]];
    

    View Slide

34. Data Protection API OS Security Mechanisms
    Passcode
    UID Key
    Passcode Key
    Device Key
    NSFP None Key NSFP Complete Key
    

    View Slide

35. Data Protection API OS Security Mechanisms
    UID Key
    Device Key
    NSFP None Key NSFP Complete Key
    

    View Slide

36. Seatbelt OS Security Mechanisms
    • Implemented as a policy module for the TrustedBSD MAC framework
    - TrustedBSD was ported from FreeBSD to the XNU Kernel
    • Seatbelt provides a user-space configurable per-process profile on top of the
    TrustedBSD system call and policy management engine
    • Basically, TrustedBSD provides the hooking, the sandbox provides the logic
    to enforce a configured profile
    

    View Slide

37. Seatbelt OS Security Mechanisms
    • The sandbox has several components:
    - User space library functions for initializing and configuring the sandbox
    (libSystem, libSandbox)
    - Daemon for handling logging from the kernel and storing configurations
    (sandboxd)
    - Kernel extension using the TrustedBSD API for enforcing individual policies
    (Sandbox.kext)
    - Kernel support extension providing regular expression matching for policy
    enforcement (AppleMatch.kext via Sandbox.kext)
    

    View Slide

38. Seatbelt OS Security Mechanisms
    user process
    

    View Slide

39. Seatbelt OS Security Mechanisms
    user process
    libSystem
    

    View Slide

40. Seatbelt OS Security Mechanisms
    user process
    libSystem
    libSandbox
    

    View Slide

41. Seatbelt OS Security Mechanisms
    user process
    libSystem
    libSandbox
    BSD syscalls
    TrustedBSD
    Mach traps
    

    View Slide

42. Seatbelt OS Security Mechanisms
    user process
    libSystem
    libSandbox
    BSD syscalls
    TrustedBSD
    AppleMatch.kext Sandbox.kext
    Mach traps
    

    View Slide

43. Seatbelt OS Security Mechanisms
    user process
    libSystem sandboxd
    libSandbox
    BSD syscalls
    TrustedBSD
    AppleMatch.kext Sandbox.kext
    Mach traps
    

    View Slide

44. Seatbelt OS Security Mechanisms
    user process
    libSystem sandboxd
    libSandbox
    BSD syscalls
    TrustedBSD
    AppleMatch.kext Sandbox.kext
    Mach traps
    Mach Kernel
    

    View Slide

45. Exploit Mitigations iOS Security Overview
    

    View Slide

46. Code Signing Exploit Mitigations
    • The most misunderstood exploit mitigation
    • Introduced in iOS 2.0
    • Only way to run code on iOS devices is for Apple to say it’s OK
    • Forces full ROP payload during exploitation
    • MobileSafari has a special entitlement: dynamic code signing
    • The reason everyone jailbreaks their devices
    

    View Slide

47. Code Signing:
    Provisioning Profiles Exploit Mitigations
    • Developers submit a CSR for a development and distribution certificate
    - These certificates are generated from private keys which are stored locally
    • Apple provides a signed plist file: your provisioning profile
    - Lists certificates, devices* and entitlements
    • When the provisioning profile is installed, it can list additional certificates
    that can sign code which can be executed
    • The MISProvisioningProfileCheckValidity function validates the profile
    - Verifies a plethora of certificate information
    

    View Slide

48. Dynamic Code Signing Exploit Mitigations
    • Introduced in iOS 4.3 to allow JIT compilation of JavaScript for performance
    • Process can make a memory region that is writable and executable
    • Only one such memory region could be made
    • A vulnerability in how the kernel handled JIT (bsd/kern/kern_mman.c) was
    found by Charlie Miller
    • This allowed Charlie to upload an app to the App Store which was able to
    execute arbitrary unsigned code
    

    View Slide

49. Dynamic Code Signing Exploit Mitigations
    • Introduced in iOS 4.3 to allow JIT compilation of JavaScript for performance
    • Process can make a memory region that is writable and executable
    • Only one such memory region could be made
    • A vulnerability in how the kernel handled JIT (bsd/kern/kern_mman.c) was
    found by Charlie Miller
    • This allowed Charlie to upload an app to the App Store which was able to
    execute arbitrary unsigned code
    

    View Slide

50. ASLR - Address Space
    Layout Randomization Exploit Mitigations
    • Introduced in iOS 4.3
    • Randomizes all the libraries that are stored in dyld_shared_cache:
    - the dynamic linker, the stack, the heap
    • Works well with other mitigations to make exploitation more difficult
    • In Xcode, set the following project build settings:
    - “Don’t Create Position Independent Executable” - No
    - “Generate Position-Dependent Code” - No
    

    View Slide

51. Marketplace Security
    Mechanisms iOS Security Overview
    

    View Slide

52. iOS App Store Marketplace Security Mechanisms
    

    View Slide

53. iOS App Store Marketplace Security Mechanisms
    • Apple puts significant effort into identity verification
    - Requires DUNS numbers from corps, drivers licenses from people
    • Apples static/dynamic analysis techniques are extremely secret
    - Can’t say for sure, but it seems to be working
    • In order to submit a malicious iOS app:
    - Create a believable false identity or risk legal action
    - Pass a manual content review for originality
    - Package your sophisticated iOS exploit and send it to Apple
    

    View Slide

54. iOS App Store Marketplace Security Mechanisms
    Malicious App
    Developed
    Unknown Fraud
    Controls & CC#
    Submit App Verify Identity
    App on App Store
    Pass Security
    Review
    Pass Content
    Review
    

    View Slide

55. iOS App Store Marketplace Security Mechanisms
    Malicious App
    Developed
    Unknown Fraud
    Controls & CC#
    Submit App Verify Identity
    App on App Store
    Pass Security
    Review
    Pass Content
    Review
    

    View Slide

56. iOS Conclusions iOS Security Overview
    

    View Slide

57. Security Tour-de-force iOS Conclusions
    • OS Security mechanisms are plentiful and powerful
    • Code signing is extremely effective
    • Don’t jailbreak your iOS device
    • Specify Data Protection API and Keychain item attributes
    • NSLogs and the clipboard are world readable!
    • ASLR is more effective/useful (practically) on iOS than Android
    - More devices with full ASLR
    - Remote exploitation actually happens on iOS
    

    View Slide

58. Greetz
    • iOS HH Authors
    • Jon Oberheide & Duo Security
    • Dan Guido
    • Etsy Security & Mobile
    

    View Slide

59. Questions? mike@arpaia.co
    @mikearpaia
    

    View Slide

60. Sources Android & iOS Security Overview
    • http://nelenkov.blogspot.com/2011/11/using-ics-keychain-api.html
    • http://jon.oberheide.org/files/summercon12-bouncer.pdf
    • http://source.android.com/tech/security/index.html
    • https://blog.duosecurity.com/2012/07/exploit-mitigations-in-android-jelly-bean-4-1/
    • http://developer.android.com/reference/android/security/KeyChain.html
    • http://nelenkov.blogspot.com/2011/11/using-ics-keychain-api.html
    • http://securityevaluators.com/files/papers/apple-sandbox.pdf
    • http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118204123.html
    • http://blog.accuvantlabs.com/blog/bthomas/evasi0n-jailbreaks-userland-component
    • http://www.norebbo.com/
    

    View Slide