The Real Deal of Android Device Security: The Third Party
3 likes856 views
The document discusses Android device security issues related to third parties. It summarizes a tool called X-Ray that was used to detect privilege escalation vulnerabilities on Android devices. Over 60% of Android devices were found to be vulnerable. It then describes another tool called PatchDroid that aims to patch these vulnerabilities by leveraging the vulnerabilities to gain root access and deploy the patches. PatchDroid works by patching processes in memory at runtime to avoid modifying system files or partitions.
The Real Deal of Android Device Security: The Third Party
- 1. The Real Deal of Android Device Security: The Third Party Collin Mulliner and Jon Oberheide CanSecWest 2014
- 2. Mulliner and Oberheide, CSW 2014 Introductions ● Collin Mulliner ● Jon Oberheide
- 3. Mulliner and Oberheide, CSW 2014 #Cats4Fun
- 4. Mulliner and Oberheide, CSW 2014 Thanks, Mudge!
- 5. Mulliner and Oberheide, CSW 2014 Thanks, Mudge!
- 6. Mulliner and Oberheide, CSW 2014 Android
- 7. Mulliner and Oberheide, CSW 2014 Android Most popular smartphone platform about 1 billion devices today
- 8. Mulliner and Oberheide, CSW 2014 This dude is in trouble
- 9. Mulliner and Oberheide, CSW 2014 Lets patch him up!
- 10. Mulliner and Oberheide, CSW 2014 WTF are we doing here people ● Anti-malware ○ 99.9%* of Android malware is bullshit toll fraud ● MDM ○ “Manage” your way out of an insecure platform ○ HEY I CAN SEE ALL MY VULNERABLE DEVICES, YAY! ● Other features of mobile “security” products ○ Find my phone (G does it), backup (G does it), …? * I just made this up, kinda
- 11. Mulliner and Oberheide, CSW 2014 How about... ● Maybe we try to fix the underlying issues? ○ “Enumerating badness” always doomed to fail ○ Naw, that’s crazy talk! ● Underlying issues (in our not-so-humble opinion) ○ Lack of platform integrity ○ Privilege escalation vulns, large attack surface ○ Huge windows of vuln due to slow/non-existing patching practices
- 12. Mulliner and Oberheide, CSW 2014 Our research ● Investigated Android vulns and solutions ○ Vulns in native and managed code ○ More than privesc! ● Let’s show what can be done ○ Mostly PoC, but deployed to 100k’s of real-world devices ○ If we can do this on the cheap, maybe Big Corp can do it for reals ● “Defensive” talk, booooooooo vs.
- 13. Mulliner and Oberheide, CSW 2014 A tale of three projects ● Vulns exist ○ X-Ray ● How to get rid of them ○ PatchDroid ● How to brick a lot of people’s phones ;-) ○ ReKey
- 14. Mulliner and Oberheide, CSW 2014 Ideal mobile ecosystem...HA! ● In a perfect world… ● AOSP: Google ships a secure base platform. ● OEM: Samsung and third-party suppliers don’t introduce vulns in their handsets and customizations. ● Carrier: T-Mobile rolls out rapid OTA updates to keep users up to date and patched.
- 15. Mulliner and Oberheide, CSW 2014 Real-world mobile ecosystem ● In the real world… ● AOSP: Android improving mitigations, but slowly. ● OEM: Customizations by device OEMs are a primary source of vulnerabilities. ● Carrier: Updates are not made available for months and sometimes even years.
- 16. Mulliner and Oberheide, CSW 2014 Real-world mobile ecosystem ● In the real world… ● AOSP: Android improving mitigations, but slowly. ● OEM: Customizations by device OEMs are a primary source of vulnerabilities. ● Carrier: Updates are not made available for months and sometimes even years. All software has vulns, mobile or otherwise. Failing to deliver patches is the real issue.
- 17. Mulliner and Oberheide, CSW 2014 Disclosure & patching process Researcher Google OEM Carrier Third-party providers Public Attackers days weeks months months days days
- 18. Mulliner and Oberheide, CSW 2014 Challenges in patching ● Why is mobile patching challenging? ● Complicated software supply chain ● Testing, testing, testing ● Risk of bricking devices ● Inverted economic incentives ● Want to patch your device's vulnerabilities? ● Loadset controlled by carrier ● Can't patch the device (unless rooted)
- 19. Mulliner and Oberheide, CSW 2014 What the carriers say "Patches must be integrated and tested for different platforms to ensure the best possible user experience. Therefore, distribution varies by manufacturer and device." - AT&T
- 20. Mulliner and Oberheide, CSW 2014 What the carriers say "Patches must be integrated and tested for different platforms to ensure the best possible user experience. Therefore, distribution varies by manufacturer and device." - AT&T
- 21. Mulliner and Oberheide, CSW 2014 Privilege escalation vulnerabilities ● Android security model ● Permissions framework, “sandboxing” (Linux uid/gid) ● Compromise of browser (or other app) != full control of device ● Privilege escalation vulnerabilities ● Unprivileged code execution → Privileged code execution ● Publicly released to allow users to jailbreak their devices ● Public exploits reused by mobile malware to root victim's devices ● Ooooh, fancy mobile privesc, right???
- 22. Mulliner and Oberheide, CSW 2014 Quick trivia ● What's wrong with the following code? ● Assuming a uid/euid=0 process dropping privileges... /* Code intended to run with elevated privileges */ do_stuff_as_privileged(); /* Drop privileges to unprivileged user */ setuid(uid); /* Code intended to run with lower privileges */ do_stuff_as_unprivileged();
- 23. Mulliner and Oberheide, CSW 2014 Zimperlich vulnerability ● Return value not checked! setuid(2) can fail: ● Android's zygote does fail if setuid does: ● Fork until limit, when setuid fails, app runs as uid 0! EAGAIN The uid does not match the current uid and uid brings process over its RLIMIT_NPROC resource limit. err = setuid(uid); if (err < 0) { LOGW("cannot setuid(%d): %s", uid, strerror(errno)); }
- 24. Mulliner and Oberheide, CSW 2014 A sampling of privesc vulns ● ASHMEM: Android kernel mods, no mprotect check ● Exploid: no netlink source check, inherited from udev ● Exynos: third-party device driver, kmem read/write ● Gingerbreak: no netlink source check, GOT overwrite ● Levitator: My_First_Kernel_Module.ko, kmem read/write ● Mempodroid: inherited from upstream Linux kernel ● RageAgainstTheCage: no setuid retval check ● Wunderbar: inherited from upstream Linux kernel ● Zimperlich: no setuid retval check ● ZergRush: UAF in libsysutils
- 25. Mulliner and Oberheide, CSW 2014 X-Ray for Android http://xray.io ● How can we measure this problem? ● X-Ray for Android ● DARPA CFT funded ● Performing _actual_ vuln assessment on mobile ● Detects most common privescs ● Works without any special privileges or permissions
- 26. Mulliner and Oberheide, CSW 2014 X-Ray Service Static probes ● Static probes ● Can identify vulnerabilities using static analysis ● Send up vulnerable component (eg. binary, library) to service ● Disassemble and look for patched/vulnerable code paths libdvm.so result Analyze!
- 27. Mulliner and Oberheide, CSW 2014 Static probe example: Zimperlich
- 28. Mulliner and Oberheide, CSW 2014 Ok, what does it _really_ look like? ● l33t static analysis...aka ghetto objdump/python/grep ● Do we need to be that smart or perfect? Thankfully, no.
- 29. Mulliner and Oberheide, CSW 2014 Dynamic probes (aka psuedo-exploits) ● Dynamic probes ● Not all vulnerabilities are in software components we can access ● Example: kernel vulns, kernel image not accessible by X-Ray ● Probe locally for vulnerability presence! ● Basically sad, neutered, wacky half exploits :-( halp! liblevitator_v1.so Execute! result X-Ray Service
- 30. Mulliner and Oberheide, CSW 2014 Dynamic probe example: Levitator
- 31. Mulliner and Oberheide, CSW 2014 Dynamic probe example: Exploid
- 32. Mulliner and Oberheide, CSW 2014 Probe manifests in JSON { "id": "webkit", "type": "static", "name": "WebKit (inactive)", "query_url": "/xray/webkit/query", "probe_url": "/xray/webkit/probe", "static_payload": "/system/lib/libwebcore.so" } { "id": "exynos", "type": "dynamic", "name": "Exynos", "result_url": "/xray/exynos/result", "dynamic_slot": "06", "dynamic_payload_armeabi": "/xray/static/exynos/armeabi/libexynos_v1.so", "dynamic_signature_armeabi": "vrX...", "dynamic_payload_armeabi-v7a": "/xray/static/exynos/armeabi-v7a/libexynos_v1.so", "dynamic_signature_armeabi-v7a": "mbe...", "dynamic_payload_mips": "/xray/static/exynos/mips/libexynos_v1.so", "dynamic_signature_mips": "F33...", "dynamic_payload_x86": "/xray/static/exynos/x86/libexynos_v1.so", "dynamic_signature_x86": "Lu7..." }, Static probe: Dynamic probe:
- 33. Mulliner and Oberheide, CSW 2014 X-Ray distribution ● Not in Google Play*, but free for download at http://xray.io ● Results collected by us (and Five Eyes) from users who ran the X-Ray app on their Android device: 74,405 devices 4,312 models 190 countries * don’t ask
- 34. Mulliner and Oberheide, CSW 2014 Aside: Android exploitation challenges ● Android fragmentation is _real_ ○ Not for app dev, but for exploit dev ● X-Ray’s binary dataset ○ 3,124 unique libsysutils.so ○ 5,936 unique libdvm.so ○ 5,303 unique vold ● If only there was a way to collect all those binaries...
- 35. Mulliner and Oberheide, CSW 2014 Scary numbers ● 6 months after the X-Ray release… ● Percent of the global Android population that are vulnerable to a privilege escalation detected by X-Ray... 60.6% vulnerable
- 36. Mulliner and Oberheide, CSW 2014 Methodology ● How to extrapolate out to global Android population? ● Selection bias? ● Google provides stats on Android versions → ● If we saw 98.8% of 2.2 devices were vulnerable, and 2.2 makes up 15.5% of Android globally, that contributes 15.3% to the total % of vulnerable Android devices.
- 37. Mulliner and Oberheide, CSW 2014 Death of an Android vuln
- 38. Mulliner and Oberheide, CSW 2014 Changes over time 60.6% vulnerable 41.2% vulnerable Early 2013Late 2012 13.4% vulnerable Early 2014 Looks like OK progress, but... Only measuring those original 8 ancient privesc vulns from X-Ray 1.0, not any new ones!
- 39. Mulliner and Oberheide, CSW 2014 OEM vendor fuckups ● Versions that shouldn’t be patched, but are! ● Version 2.3.2, but not vuln to gingerbreak ● Backports without version bumps ● Versions that should be patched, but aren’t! ● Version 4.1, but still vuln to mempodroid ● Incomplete patching, regressions ● OEM vendors relying on public exploits to do vuln assessment
- 40. Mulliner and Oberheide, CSW 2014 Failed exploit != patched ● SORRY. I WRITE CRAPPY EXPLOITS. ● OEM vendor inquiry:
- 41. Mulliner and Oberheide, CSW 2014 Database of vulnerable models “The vulnerability affects Android devices with the PowerVR SGX chipset which includes popular models like the Nexus S and Galaxy S series. The vulnerability was patched in the Android 2.3.6 OTA update.” It’s like PRISM...for Android! mysql> SELECT COUNT(DISTINCT(model)) FROM results WHERE probe='levitator' AND result='vulnerable'; +------------------------+ | COUNT(DISTINCT(model)) | +------------------------+ | 136 | +------------------------+ mysql> SELECT DISTINCT(model) FROM results WHERE probe='levitator' AND result='vulnerable' AND model LIKE '%Kindle%'; +-------------+ | model | +-------------+ | Kindle Fire | +-------------+ OOPS!
- 42. Mulliner and Oberheide, CSW 2014 XRAY Overview TOP SECRET//COMINT//REL TO USA, FVEY//20230108 ➢ (S//SI//REL) Covert platform for mobile TAO implants ○ Highly successful (~75,000 active implants worldwide) ➢ (S//SI) Metadata selector types ○ Device ID, manufacturer, model, version, carrier, country, IP address, vulnerability state ➢ (S//SI) Integrates with POOPCHUTE and BLAMEVUPEN ○ Palm Pilot support in development XRAY Project Results
- 43. Mulliner and Oberheide, CSW 2014 Lessons learned from X-Ray ● Man, OEMs and carriers sure suck at patching. ● If only there was some way to patch these vulns ourselves! ● BRING OUT THE GERMAN!
- 44. Mulliner and Oberheide, CSW 2014 Use Bug to Gain Root to Patch Bug
- 45. Mulliner and Oberheide, CSW 2014 Use Bug to Gain Root to Patch Bug Introducing PatchDroid
- 46. Mulliner and Oberheide, CSW 2014 Use Bug to Gain Root to Patch Bug Introducing PatchDroid ...but we actually have users root their devices
- 47. Mulliner and Oberheide, CSW 2014 Challenges ● No access to source code ○ AOSP != code running on devices ○ modifications by OEMs ● Can’t modify system files and/or partitions ○ patched binaries might brick device ○ cannot replace signed partitions or files on them ● Scalability and testing ○ too many different devices and OS versions ○ patches need to be decoupled form source code
- 48. Mulliner and Oberheide, CSW 2014 PatchDroid ● Third-party security patches for Android ○ includes: attack detection and warning mechanism ● Independent of device and Android version ○ support for Dalvik bytecode and native code
- 49. Mulliner and Oberheide, CSW 2014 PatchDroid cont. ● Scalable ○ only develop patch once, patch any device ○ test patches in the field ● Practical ○ almost no overhead (user won’t notice any) ○ we don’t need source code ■ not everything of Android is open source
- 50. Mulliner and Oberheide, CSW 2014 PatchDroid - The System ● In-memory patching at runtime ○ need to patch processes at startup ■ before process executes vulnerable code ■ monitor system for new processes ○ no need to modify system files or system partitions ■ important!
- 51. Mulliner and Oberheide, CSW 2014 PatchDroid - The System cont. ● Patches as independent code ○ self-contained shared library ○ patching via function hooking ○ no access to original source code required ○ scale across different OS versions
- 52. Mulliner and Oberheide, CSW 2014 Overview ● PatchDroid system architecture ● Patches in our system ○ creating a patch ● Technical insights ● ReKey! ○ a public release of PatchDroid ● Demo
- 53. Mulliner and Oberheide, CSW 2014 Architecture
- 54. Mulliner and Oberheide, CSW 2014 Architecture
- 55. Mulliner and Oberheide, CSW 2014 Architecture
- 56. Mulliner and Oberheide, CSW 2014 Architecture
- 57. Mulliner and Oberheide, CSW 2014 Architecture
- 58. Mulliner and Oberheide, CSW 2014 Architecture
- 59. Mulliner and Oberheide, CSW 2014 Architecture
- 60. Mulliner and Oberheide, CSW 2014 Anatomy of a Patch ● Replacement for vulnerable function ○ equivalent code without vulnerability ○ wrapper that adds input/output sanitization ● Install ○ hook vulnerable function ■ keep original function usable, we will need it later ● Communication link ○ read config parameters ○ write log messages, report attacks
- 61. Mulliner and Oberheide, CSW 2014 Lifetime of a Patch ● Deployment ○ trace target process ○ setup communication ○ inject patch library
- 62. Mulliner and Oberheide, CSW 2014 Lifetime of a Patch ● Installation ○ connect communication ○ hook function(s)
- 63. Mulliner and Oberheide, CSW 2014 Lifetime of a Patch ● Fixed function is called ○ log (and report attack) ○ collect telemetry ○ (call original function)
- 64. Mulliner and Oberheide, CSW 2014 Lifetime of a Patch ● Patch failure ○ detected using telemetry ○ failing patch is removed ● This is tricky ○ works only to certain extend ○ but enables some kind of field testing
- 65. Mulliner and Oberheide, CSW 2014 Creating a Patch ● Extract patch from source, transform to PatchDroid patch ○ apply patch strategy best suited for vulnerability ○ sources: e.g., AOSP, Cyanogen, etc... ● Develop custom patch ○ vulnerability known, but no patch available
- 66. Mulliner and Oberheide, CSW 2014 Patching Strategies ● replace ● proxy ● add return value check
- 67. Mulliner and Oberheide, CSW 2014 Source Patch -> PatchDroid Patch ● Missing return value check ○ mEntries.put() returns != null,key is already used ○ dup key == multiple zip entries with same name
- 68. Mulliner and Oberheide, CSW 2014 Transform ● Hook: java.lang.LinkedHashMap.put() ○ call orig method and check return value ○ throw exception if result != null ● LinkedHashMap is used outside of ZipFile ○ need to only patch behavior in ZipFile code ● Hook: java.util.ZipFile.readCentralDir() ○ install hook for LinkedHashMap ○ call original readCentralDir() ○ unhook LinkedHashMap
- 69. Mulliner and Oberheide, CSW 2014 PatchDroid - Implementation ● patchd: the patch daemon ○ monitor system for newly created process ○ inject patches into process ○ monitor patched process ● PatchDroid App ○ UI ○ Helper Service ○ Attack Notification
- 70. Mulliner and Oberheide, CSW 2014 PatchDroid - Implementation ● patchd: the patch daemon ○ monitor system for newly created process ○ inject patches into process ○ monitor patched process ● PatchDroid App ○ UI ○ Helper Service ○ Attack Notification
- 71. Mulliner and Oberheide, CSW 2014 Hooking Techniques ● Native patches based on ADBI ○ framework for hooking native code on Android ○ http://github.com/crmulliner/adbi/ ● Dalvik patches based on DDI ○ framework for hooking Dalvik methods ○ http://github.com/crmulliner/ddi/
- 72. Mulliner and Oberheide, CSW 2014 Insights ● patchd uses ptrace() for monitoring and injection ○ most target processes run as root ○ patchd -> requires root ● PatchDroid app lives in /data/data/… ○ no need to modify ‘/system’ file system ■ often signed and checked by bootloader ○ can be installed/removed like any other app ■ we don’t want to brick devices
- 73. Mulliner and Oberheide, CSW 2014 Patches ● Native Target Process ○ Zimperlich zygote ○ GingerBreak vold ○ ZergRush vold ● Dalvik ○ Local SMS Spoofing system_server ○ MasterKey system_server
- 74. Mulliner and Oberheide, CSW 2014 Patches ● Native Target Process ○ Zimperlich zygote ○ GingerBreak vold ○ ZergRush vold ● Dalvik ○ Local SMS Spoofing system_server ○ MasterKey system_server
- 75. Mulliner and Oberheide, CSW 2014 MasterKey Bug ● Discovered by the guys from BlueBox ● Bug in handling of APK files ○ APK can be modified without breaking its signature ● Can be used for privilege escalation (root device) ○ modify APK signed with platform/oem key ○ that APK roots any device from given OEM!
- 76. Mulliner and Oberheide, CSW 2014 MasterKey Bug cont. ● Actually multiple bugs ● Bugs in Java code (Dalvik bytecode) ○ first priv esc vuln due to bug in Dalvik bytecode ● Bug present in AOSP until version 4.3 ○ Affected almost all Android devices at that time
- 77. Mulliner and Oberheide, CSW 2014 Patching MasterKey Bug(s) ● Patching Strategies ○ Add missing return value check ○ Add input/output sanitisation (thru proxy function) ● Fast turnaround ○ 3 hours for initial version, coding + testing
- 78. Mulliner and Oberheide, CSW 2014 ReKey ● Special version of PatchDroid ○ Patches for MasterKey only! ● Released on July 16th 2013 ○ Available Google Play! ● ReKey your device ○ http://rekey.io
- 79. Mulliner and Oberheide, CSW 2014 PatchDroid / ReKey - Demo
- 80. Mulliner and Oberheide, CSW 2014 Data & Stats ● Google Play ● ReKey opt-in
- 81. Mulliner and Oberheide, CSW 2014 ReKey Stats - installs remember: we require a pre-rooted device
- 82. Mulliner and Oberheide, CSW 2014 ReKey Stats - Android versions
- 83. Mulliner and Oberheide, CSW 2014 ReKey Stats - Devices
- 84. Mulliner and Oberheide, CSW 2014 ReKey opt-in data ● 7k logs ● 942 unique device models ● Android versions ○ 1.5.1 to 4.4.2
- 85. Mulliner and Oberheide, CSW 2014 Lessons Learned “My ZTE Score M, is badly hacked and your software detected it, after I found obvious examples (all of which I video- taped). Help please if possible? Thank you.” STAHP.
- 86. Mulliner and Oberheide, CSW 2014 Conclusions ● Android security is fucked ● More public pressure on the responsible parties ● Top-down from Google ● Bottom-up from users and companies ● Open up platform security to third-parties? ● Allow enterprises, third-parties to offload patching responsibility ● Better platform security in general, less vulns to patch
- 87. Mulliner and Oberheide, CSW 2014 What’s Next? ● PatchDroid / ReKey ○ basically working but still a PoC ● Add patches for vendor specific bugs!? ○ that’s a lot of bugs ● Open Source it? ○ X-Ray probes are woefully out of date ○ Exynos, Webkit, MasterKey, etc ○ Interest in open source version for community development and new probes?
- 88. Mulliner and Oberheide, CSW 2014 Q & A http://x-ray.io http://rekey.io http://patchdroid.com detailed academic paper twitter: @collinrm @jonoberheide
- 89. Mulliner and Oberheide, CSW 2014 Thanks & Greetz ● mudge ○ DARPA $$$ ● Joshua ‘jduck’ Drake ○ heavy PatchDroid testing ● Greetz ○ zach, ben, van Hauser, i0nic, AHH crew
- 90. Mulliner and Oberheide, CSW 2014 Alternative ‘Hotpatching’ Tools ● Xposed framework ○ made for modding Android without reflashing FW ○ replaces zygote ● Cydia Substrate ○ mode for modding Android without reflashing FW ○ complex