Upgrade to Pro — share decks privately, control downloads, hide ads and more …

iOS and Android Security Mechanisms and Exploit Mitigations

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.

Mike Arpaia

March 15, 2013
Tweet

More Decks by Mike Arpaia

Other Decks in Technology

Transcript

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

    View full-size 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 full-size slide

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

    View full-size slide

  4. The Basics Android Security Overview

    View full-size slide

  5. 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 full-size slide

  6. OS Security Mechanisms Android Security Overview

    View full-size slide

  7. 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 full-size slide

  8. 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 full-size slide

  9. 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 full-size slide

  10. Exploit Mitigations Android Security Overview

    View full-size slide

  11. 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 full-size slide

  12. 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 full-size slide

  13. 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 full-size slide

  14. 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 full-size slide

  15. Marketplace Security
    Mechanisms Android Security Overview

    View full-size slide

  16. 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 full-size slide

  17. 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 full-size slide

  18. 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 full-size 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 full-size slide

  20. 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 full-size slide

  21. Impossible Tasks Android Security Overview

    View full-size slide

  22. 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 full-size slide

  23. Android Conclusions Android Security Overview

    View full-size slide

  24. 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 full-size slide

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

    View full-size slide

  26. The Basics iOS Security Overview

    View full-size slide

  27. 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 full-size slide

  28. OS Security Mechanisms iOS Security Overview

    View full-size slide

  29. 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 full-size slide

  30. 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 full-size slide

  31. 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 full-size slide

  32. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  35. 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 full-size slide

  36. 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 full-size slide

  37. Seatbelt OS Security Mechanisms
    user process

    View full-size slide

  38. Seatbelt OS Security Mechanisms
    user process
    libSystem

    View full-size slide

  39. Seatbelt OS Security Mechanisms
    user process
    libSystem
    libSandbox

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  44. Exploit Mitigations iOS Security Overview

    View full-size slide

  45. 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 full-size slide

  46. 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 full-size slide

  47. 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 full-size 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 full-size slide

  49. 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 full-size slide

  50. Marketplace Security
    Mechanisms iOS Security Overview

    View full-size slide

  51. iOS App Store Marketplace Security Mechanisms

    View full-size slide

  52. 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 full-size slide

  53. 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 full-size 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 full-size slide

  55. iOS Conclusions iOS Security Overview

    View full-size slide

  56. 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 full-size slide

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

    View full-size slide

  58. 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 full-size slide