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

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

Agenda 

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

The Basics Android Security Overview 

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 

OS Security Mechanisms Android Security Overview 

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(...) 

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 

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? 

Exploit Mitigations Android Security Overview 

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 

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 

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 

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 + 

Marketplace Security Mechanisms Android Security Overview 

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. 

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 

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 

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 

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 

Impossible Tasks Android Security Overview 

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... 

Android Conclusions Android Security Overview 

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 

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

The Basics iOS Security Overview 

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 

OS Security Mechanisms iOS Security Overview 

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 

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 

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 

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]]; 

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

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

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 

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) 

Seatbelt OS Security Mechanisms user process 

Seatbelt OS Security Mechanisms user process libSystem 

Seatbelt OS Security Mechanisms user process libSystem libSandbox 

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

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

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

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

Exploit Mitigations iOS Security Overview 

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 

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 

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 

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 

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 

Marketplace Security Mechanisms iOS Security Overview 

iOS App Store Marketplace Security Mechanisms 

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 

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 

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 

iOS Conclusions iOS Security Overview 

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 

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

Questions? [email protected] @mikearpaia 

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/