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

iOS and Android Security Mechanisms and Exploit...

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. Who am I? • Mike Arpaia - Software Engineer on

    Etsy’s Security team - Formerly a Security Consultant at iSEC Partners - Slightly opinionated mobile security researcher
  2. Android Security • The Basics • OS Security Mechanisms •

    Exploit Mitigations • Marketplace Security Mechanisms • Impossible Tasks • Conclusions
  3. 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
  4. 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(...)
  5. 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
  6. 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?
  7. 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
  8. 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
  9. 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
  10. 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 +
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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...
  17. 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
  18. iOS Security • The Basics • OS Security Mechanisms •

    Exploit Mitigations • Marketplace Security Mechanisms • Conclusions
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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]];
  24. Data Protection API OS Security Mechanisms Passcode UID Key Passcode

    Key Device Key NSFP None Key NSFP Complete Key
  25. 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
  26. 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)
  27. Seatbelt OS Security Mechanisms user process libSystem libSandbox BSD syscalls

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

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

    syscalls TrustedBSD AppleMatch.kext Sandbox.kext Mach traps Mach Kernel
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. 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
  38. 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
  39. Greetz • iOS HH Authors • Jon Oberheide & Duo

    Security • Dan Guido • Etsy Security & Mobile
  40. 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/