ANDROID SECURITYEMBEDDED SYSTEM PROGRAMMING 2015/2016

PAOLO MONTESEL

BACKGROUNDSecurity is hardAndroid was designed with a multi-layered securityarchitectureAndroid has had many security problems in the past andstill hasGoogle is actively working on itEnd-user actions are also considered in order to mitigateSocial Engineering attacksVendor-speci�c �avours of the OS can introduce new bugsand delay security patches

SECURITY GOALSProtect user dataProtect system resourcesProvide application isolation

OVERVIEW

SECURITY PROGRAMThe entire development lifecycle of Android is subjected to a

rigid security program:

Design Review: Each major feature is reviewed byengineers and security expertsPenetration Testing/Code Review: OS components aresubject to security reviews both from Google and 3rd partyconsultants.Community Review: AOSP code is open and can bereviewed by anyoneIncident Response: Google has a dedicated team in chargeof providing rapid mitigation and minimize risk when a bugis reported.

SECURITY MECHANISMSSecurity at the OS level through the Linux kernelMandatory application sandboxingSecure IPCApplication signingApplication-de�ned, user-granted permissions

BRIEF ANDROID SECURITY HISTORY1.5: ProPolice and buffer/integer over�ow protections2.3: Format String protections, No eXecute (NX) bit3.0: Full Disk Encryption4.0: Address Space Layout Randomization (ASLR), securecredentials storage4.1: Position Independent Executables (PIE) support4.3: SELinux (permissive mode), no more setuid/setgidprograms, hardware-backed secure credentials storage4.4: SELinux (enforcing mode), Certi�cate Pinning5.0: Better Full Disk Encryption, encryption by default,non-PIE support dropped6.0: Runtime permissions, veri�ed boot, Fingerprints

ANDROID SOFTWARESTACK

ANDROID SOFTWARE STACK

KEY CONCEPTSEach layer in the software stack assumes that thecomponents below are properly securedAll code above the Linux Kernel is restricted by theApplication Sandbox (excluding a small amount of Androidcode running as root)Device Hardware: Android is processor-agnostic but takesadvantage of hardware-speci�c security featuresAndroid OS: Built on top of Linux. Device resources are allaccessed through the OSAndroid App Runtime: Both Dalvik and native applicationsrun in the Application Sandbox

APPLICATION SANDBOXKernel-level sandboxEach application has a unique user IDEach application runs on a separate processApps have limited access to the OS by defaultApps cannot interact with each other by defaultNative code as secure as the Dalvik codeTo break out of the Sandbox, an attacker must oftencompromise the Linux Kernel

APPLICATION SANDBOXIf an app requires a permission, it is assigned thecorresponding group IDIf two App's certi�cates match, they can share the sameUID

PERMISSION MODEL

PERMISSION MODELBy default, Apps can access a limited range of systemresourcesCertain APIs are missing on purpose (e.g.: direct SIM-cardmanipulation APIs)Sensitive APIs are protected through a permissionmechanism

Declared in the AndroidManifest.xmlAccepted by the user at install-timeRequested at run-time from Android 6.0 onwards

Special treatment is given to cost-sensitive APIs like SMS

APPLICATION SIGNING

APPLICATION SIGNINGIdenti�es the author of an AppAllows for automatically updating Apps in a secure mannerProves the integrity of the APKIf two APKs' signatures match, they can choose to use thesame UIDSince Android 4.2, Apps are veri�ed by default and the OScan block the installation of harmful APKs

AUTHENTICATION

AUTHENTICATIONAndroid 6.0 introduces a new Hardware Abstraction Layer(HAL) for hardware-based securityUsed by Fingerprint API, Lockscreen, Device Encryptionand Client Certi�catesProtect keys against kernel compromise or physical attacksKeystore: hardware-backed storage for keys, usuallyincluding a Trusted Execution Environment (TEE)Gatekeeper: Components for PIN/pattern/passwordauthenticationFingerprint: Components for �ngerprint authentication

ARCHITECTUREGatekeeper and Fingerprint components interact with theKeystore through the use of Authentication TokensAt �rst boot, a 64-bit User SID (Secure IDenti�er) iscreated from Gatekeeper informationSID identi�es the user and is the token used to access hiscryptographic materialAuthTokens contain the SIDHardware enforces a minimum amount of time betweenauthentication attempts in order to avoid bruteforcingKeys don't leave the TEE

AUTHENTICATION FLOW

FULL DISK ENCRYPTION

FILESYTEM ENCRYPTIONFull FS encryption can be enabled on Android devices sinceAndroid 3.0.Android 5.0 improves FS encryption: faster encryption,encrypt on �rst boot, patterns and encryption withoutpassword, hardware-backed storage of keysUses 128-bit Advanced Encryption Standard (AES) withcipher-block chaining (CBC). 256-bit key is reccomendedfor optimal security

SECURITY THREATS

ANDROID SECURITY THREATSPermission mechanism is too coarseVendors don't support old devices (no security �xes)Privilege escalation using old kernel bugs (that's whatrooting Apps do)APK repacking with malwareApps signed with the same certi�cate can leverage theshared UID to share sensitive dataBugs in the Trusted Execution Environmentimplementations (Qualcomm's had serious security �aws)

CASE STUDY: STAGEFRIGHT

STAGEFRIGHTGroup of bugs in the Stagefright component of AOSPDiscovered by Joshua Drake of the Zimperium security�rmAnnounced on July 27, 2015Allows an attacker to perform remote code execution andprivilege escalation on a deviceAffects all Android versions from Froyo (2.2) to Lollipop(5.1.1): 95% of devices at the timeExploits integer over�ows of libstagefright's MP4 parsingcode

IMPACTBugs are triggered by simply playing an MP4 videoCan be triggered automatically by an MMS thanks toHangout's video pre-loadingRequires no user interactionTotally invisible to the user, as an exploit can erase theMMS through codeRequires an Over-The-Air (OTA) update from the phonemanufacturer to get �xedFirst �xes didn't actually �x the problem

RUNNING PRIVILEGESLuckily, stagefright doesn't run as rootStill, it runs inside the media serverMore privileges than normal Apps: camera, audio, sockets,bluetoothOn some devices, even more: graphic devices, sdcard_r,internal media R/W, adb shell

CONCLUSION

CONCLUSIONAndroid security is a though problem, but it's improvingDevelopers must be careful, especially when using NDKUsers should not install APKs from 3rd parties (e.g.:cracked APKs)Rooting Apps are basically exploiting your OSIf a rooting App can run code as root, any App canKeep your phone updated :)

BIBLIOGRAPHY (1)Android SecurityP. Faruki et al., "Android Security: A Survey of Issues,Malware Penetration, and Defenses"Felt, Adrienne Porter, et al. "A survey of mobile malware inthe wild." Proceedings of the 1st ACM workshop onSecurity and privacy in smartphones and mobile devices.ACM, 2011.

BIBLIOGRAPHY (2)

Stagefright: Scary Code in the Heart of Android, Black HatUSA '15

Vidas, Timothy, Daniel Votipka, and Nicolas Christin. "AllYour Droid Are Belong to Us: A Survey of Current AndroidAttacks." WOOT. 2011.

(slides) (video)Extracting Qualcomm's KeyMaster Keys - BreakingAndroid Full Disk Encryption

THE END