Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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