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
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
3. Agenda
4. Android Security • The Basics • OS Security Mechanisms • Exploit Mitigations • Marketplace Security Mechanisms • Impossible Tasks • Conclusions
5. The Basics Android Security Overview
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
7. OS Security Mechanisms Android Security Overview
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(...)
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
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?
11. Exploit Mitigations Android Security Overview
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
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
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
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 +
16. Marketplace Security Mechanisms Android Security Overview
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.
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
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
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
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
22. Impossible Tasks Android Security Overview
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...
24. Android Conclusions Android Security Overview
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
26. iOS Security • The Basics • OS Security Mechanisms • Exploit Mitigations • Marketplace Security Mechanisms • Conclusions
27. The Basics iOS Security Overview
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
29. OS Security Mechanisms iOS Security Overview
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
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
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
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]];
34. Data Protection API OS Security Mechanisms Passcode UID Key Passcode Key Device Key NSFP None Key NSFP Complete Key
35. Data Protection API OS Security Mechanisms UID Key Device Key NSFP None Key NSFP Complete Key
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
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)
38. Seatbelt OS Security Mechanisms user process
39. Seatbelt OS Security Mechanisms user process libSystem
40. Seatbelt OS Security Mechanisms user process libSystem libSandbox
41. Seatbelt OS Security Mechanisms user process libSystem libSandbox BSD syscalls TrustedBSD Mach traps
42. Seatbelt OS Security Mechanisms user process libSystem libSandbox BSD syscalls TrustedBSD AppleMatch.kext Sandbox.kext Mach traps
43. Seatbelt OS Security Mechanisms user process libSystem sandboxd libSandbox BSD syscalls TrustedBSD AppleMatch.kext Sandbox.kext Mach traps
44. Seatbelt OS Security Mechanisms user process libSystem sandboxd libSandbox BSD syscalls TrustedBSD AppleMatch.kext Sandbox.kext Mach traps Mach Kernel
45. Exploit Mitigations iOS Security Overview
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
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
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
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
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
51. Marketplace Security Mechanisms iOS Security Overview
52. iOS App Store Marketplace Security Mechanisms
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
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
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
56. iOS Conclusions iOS Security Overview
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
58. Greetz • iOS HH Authors • Jon Oberheide & Duo Security • Dan Guido • Etsy Security & Mobile
59. Questions? mike@arpaia.co @mikearpaia
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/