researching android device security with the help of a droid army

Researching Android Device Security with the Help of a Droid Army – Shakacon VI – Joshua J. Drake – © 2014 Accuvant, Inc. All Rights Reserved. © 2014 Accuvant, Inc. All Rights Reserved.

Researching Android Device Security with the Help of a Droid Army

Joshua J. Drake June 24th, 2014

Shakacon VI Honolulu, HI

Researching Android Device Security with the Help of a Droid Army – Shakacon VI – Joshua J. Drake – © 2014 Accuvant, Inc. All Rights Reserved.

Agenda

Introduction

Building a Droid Army

Inside the Visionary

Doing your Bidding

DEMO

Conclusion / Q & A

Presenter

Presentation Notes

Introduction – about me and why I did this work Building a Droid Army – about the hardware design, acquisition, costing, etc Doing your Bidding – the tools, maintenance tasks, required software, conducting security research/testing, with examples Conclusion – key take-aways Q & A


INTRODUCTION Who, Why and What…


• Focused on vulnerability research and exploit development for the past 15 years

• Current affiliations: • Lead Author of Android Hacker’s Handbook • Director of Research Science at Accuvant LABS • Founder of the droidsec research group

• Some might know me from my work at: • Rapid7 Metasploit, VeriSign iDefense Labs

About Joshua J. Drake aka jduck


• I want to help others overcome the biggest

challenge in Android security research…

FRAGMENTATION

aka a very heterogeneous device pool

Motivations


• Device models differ from each other • Hardware, Code changes, Compilation settings

(ARM vs. Thumb), …and more!

• Android development is scattered • Different parties make changes when developing

a particular device for release

(see my previous presentations for details)

Causes of Fragmentation


• Many vulnerabilities only present on a single device model or a subset of device models

• Some bugs are only exploitable on a subset

Effects of Fragmentation I


• Both research and test time is multiplied

• The code behind a given attack surface could be COMPLETELY different

• It’s almost guaranteed to have small differences • Possibly more bugs introduced • Possibly some fixes back-ported

• Physical devices become a REQUIREMENT

Effects of Fragmentation II


Droid Army (noun):

• A collection of always accessible Android devices used to enable large scale security research.

• QUICK DEMO

What is a Droid Army?


• App Developers know this problem well…

• Apkudo (260+) • Inspired me

• Testdroid (258) • AppThwack (231) • Xamarin test cloud (?)

Existing Solutions I


• These can be used for some tasks, but not all.

• Drawbacks • Focused on App testing, not security. • Legality concerns

• Is it ok to root their devices? • “We never root … -AppThwack”

• Is it ok to ex-filtrate data? • Physical proximity requirements • OPSEC fail

• The answer? • Build your own!

Existing Solutions II


BUILDING A DROID ARMY About the hardware design and acquisition…


• Very, very simple/crude: 1. Get a big ass hub 2. Obtain lots of devices 3. Connect everything together

• Initial hardware purchase: • Big ass hub: $75 via Amazon

• Had a few devices, sought more…

Original Design

Presenter

Presentation Notes

The initial design was pretty simple I got a big ass hub, and set out to get some devices…


0 or $

$$

$$

$$$

$$$$$

$$ X

1. Ask around!

2. eBay • Fairly easy to get a good deal • Esp. damaged but functional devices

• bad ESN, cracked screen, etc.

3. Facebook Garage Sales

4. Craig’s List, Swappa.com, etc. • Too pricey IMHO

5. Buy NEW / Off contract • Very pricey (sometimes unavoidable)

NOTE: new prepaid phones are cheap e.g. VZW Moto G - $100 @ BestBuy

Acquiring Devices

Presenter

Presentation Notes

I didn’t know what I was doing at first. This slide is the culmination of over a year of trying to buy Android devices cheap. NOTE: Damaged phones must have working LCD, digitizer, and USB Acquiring Android devices will be, by far, the biggest expense.


The following persons contributed Android devices:

Accuvant LABS Aarika Rosa Brent Cook Charlie Miller Craig Williams EMH Gabriel Friedmann Google James Boyd Jonathan Cran Justin Fisher Kevin Finisterre Matt Molinyawe Rick Flores @thedude13 Tim Strazzere

Other generous AHA! Members Friends, family, and friends of family

THANK YOU!

Presenter

Presentation Notes

I want to take a quick second to thank these people. If you’re in the room, stand up and take a bow. We owe you a round of applause for your help during this research.


Version 0.7 – Sep 2012

Presenter

Presentation Notes

I started out fairly modest using a couple of my own old devices. On top of those, I got a few other devices donated to the cause. Also pictured is the Manhattan Mondo Hub It’s a 28 port hub, but has some issues that we’ll get to in a bit. For one, plugging it in and running “lsusb” showed internally it was just several hubs cascaded


Version 0.8 – Oct 2012

Starting to get serious, as evidenced by the organization!

Presenter

Presentation Notes

In October, I started getting serious. I organized things to make room for plans to buy some more devices from eBay. I also bought a ton of USB cables from Monoprice (YAY MONOPRICE!) A couple of development boards were added to the collection (Origen Quad and Pandaboard)


Version 1.0 – Dec 2012

I really started to realize the benefits!

Presenter

Presentation Notes

This picture shows what I call the 1.0 version. I really started to see the benefits of having a wide range of devices accessible.


Version 2.0 – July 2013

My posse’s getting big and my posse’s getting bigger!!

Presenter

Presentation Notes

At this point all of the ports on the MondoHub were full. I even added another small hub to feed more devices.


DISASTER STRIKES!!

Oh no!

Presenter

Presentation Notes

One of the “Android TV” devices gave up randomly, apparently its flash memory failed. OH NO! The MondoHUB died!! I always had a feeling this was going to happen. I frequently had issues with devices falling off. I’d have to go physically replug them, etc. It turns out the 4A power supply isn’t really enough to cover 28 x 0.5A (LOL?) Maybe that explains the black mk802 rolling over too, heh. In any case, I cobbled some stuff together to get back up and running…


Version 2.7 – Nov 2013

The army is crippled!

Presenter

Presentation Notes

Unfortunately, this setup reduced the max devices from 35 to 19 :-/ I had to take around a dozen devices offline. To make matters worse, devices acquired in the interim couldn’t be used. The new hubs seemed much better overall, so I started working a version 3.0 design to address previous issues…


• How many devices can we *REALLY* have?

• Turns out USB has some limitations! • Max. hub nesting depth – 7 (root hub counts!) • Max. devices (incl. hubs) – 127

Version 3.0 – Issue I

Presenter

Presentation Notes

This issue was something I was noodling on since August. When I added the small hub, I realized I needed to think of a more long term solution as I acquired more devices. I sought out to determine what the real/practical limits of USB were. After some crowd sourcing and reading, I found out the limits and put together a plan.


• Realistic max droidz = 108

• Hit 127 pretty quickly, with only 19 hubs • Several unusable ports :-/

Version 3.0 – USB Design I

Presenter

Presentation Notes

This is what I came up with as an optimal solution. It reaches the max of 127 devices with 19 hubs and lets me use 108 (!!) USB devices! Time to order parts again!!


• Built off recommendations, reports of previous success, and my own experiences

• Thanks Charlie Miller, Sergey Bratus, others!

• Parts list: • 10x D-Link DUB-H7 hubs (Amazon - $26 ea)

• 7 ports, remarkably stable • Software power control!

• 70x Micro-USB cables (Monoprice - $1-2 ea) • Some 1.5 ft, some 3 ft • Some w/ferrite core, some w/o • NOTE: a 6ft cable helps if touching a device is needed

Version 3.0 – USB Design II

Presenter

Presentation Notes

I don’t have 108 devices, so I didn’t go for the full build. I just wanted to get my 42 devices online, so I ordered enough for that. Total cost for this order was around $400.00 NOTE: A 6ft cable can really help if you want to work closely with a device. This is so you can sit at your desk and not have to unplug it from its normal spot.


• Currently topology:

• root -> 7 port hub -> 7 hubs -> droidz • Supports ~ 49 USB devices

• Another issue becomes apparent…

Version 3.0 – USB Design III

Presenter

Presentation Notes

Once the devices arrived, I went with the design shown here. However, I quickly ran into another problem!


Version 2.7 – Issue II

Wall Warts + Power Strip = FAIL

Presenter

Presentation Notes

As you can see, I could only use 3 of 6 outlets on the strip :-/ In December 2013, I did some research looking for a solution to this issue


• Modeled after some Bitcoin miner’s projects • https://bitcointalk.org/index.php?topic=74397.0

• Parts list: 1. An ATX power supply (surplus ) 2. 10x Male Molex connectors

• From FrozenCPU or 3D print ‘em! 3. 40x Molex Pins (FrozenCPU) 4. 10x wired barrels (two options)

1. Butcher power supplies that came with the hubs 2. Order some (DigiKey CP-2191-ND)

• I ordered new and assembled my own. The result…

Version 3.0 – Power Design I

Presenter

Presentation Notes

Ultimately, found out that Bitcoin miners had ran into this issue as well. Their solution was to use an ATX power supply with custom cables. Basically they just put barrel connectors onto the 5V wires coming off the power supply. I had an old 350w power supply lying around. I confirmed it could supply up to 35A on the 5V rail, and went for it. The most tedious part was crimping the molex pins. Still, it only took about 2 hours. This would probably be easier if you have the crimping tool instead of using needle nose pliers + solder like I did, heh.


Version 3.0 – Power Design II

The fancy Molex to Barrel cable

Presenter

Presentation Notes

This is one of the cables after assembly. Next I went ahead and plugged in my ATX power supply and wired everything up.


Version 3.0 – Power Design III

The power cables all wired up.

Presenter

Presentation Notes

Here’s the power setup wired up. To turn the power supply on, you have to short PS_ON to ground on the motherboard connector. This simulates a power switch. Of course you could wire in and use a legit switch instead. If you don’t want to build this yourself, the bitcoin forum OP was selling cables. Not sure if he still is. Certainly not the only solution, just the one I’m currently using.


• More than 108 devices • More USB host adapters – PCI-X slot limits • Use a small ARM box (ODROID?)

• Connect via Ethernet

• Achieves ~Limitless scale !!

• Running out of physical space! • Pondering a vertical solution

• Maybe power phones without batteries?

More Scale Issues

Presenter

Presentation Notes

Duplicate devices can be used to run different firmware versions More host adapters partially solves the USB dilemma, but isn’t tested and has limited utility.�Requires host machine disassembly Will run out of PCI-X slots pretty quickly Exposing connected devices to Ethernet using a small pass-through box should solve it entirely. Not don’t yet, planned for future


Version 3.0 – Dec 2013

The result of the version 3.0 overhaul

Presenter

Presentation Notes

After everything was wired, I started wiring up the devices and setting them out on the table. I took this picture just after making sure everything was live and working.


Version 3.3 – Current

TODAY!

Presenter

Presentation Notes

And here’s what this droid army looks like today.


INSIDE THE VISIONARY About the Android Cluster Toolkit…


• No tools like this existed… …or at least none were available …guess it’s time to build them!

• Features: • Provision new devices quickly/easily • Manage devices by human-friendly names • Handle transient devices (not always connected) • Perform tasks against one or more device

• https://github.com/jduck/android-cluster-toolkit

Android Cluster Toolkit I


• Requirements: ADB binary and Ruby

• Scripts wrap Android Debug Bridge (ADB) • README.md covers details and usage

• Simple but elegant and powerful • 1 device, multiple devices, all devices

• Recommended I: • Minor patch to ADB:

https://gist.github.com/jduck/8849310

Android Cluster Toolkit II

Presenter

Presentation Notes

The tools are ruby scripts that wrap adb, so only two requirements: Ruby and ADB Although simple, these tools are quite powerful The minor patch is for convenience only. It changes the home directory and terminal size when connecting to an ADB shell


• The tools on an Android devices are limited • e.g., some don’t have “grep”

• BusyBox solves this problem

• Best BusyBox binary out there (AFAIK): • Provided by saurik (Jay Freeman) • Only works on devices >= Android 2.3.x • Features:

• More busybox tools (SELinux!!) • Built against bionic (shows users/groups correctly)

http://cache.saurik.com/android/armeabi/busybox

Recommendation II - BusyBox

Presenter

Presentation Notes

Just push to /data/local/tmp, don’t “install” Keeps devices clean!


• Firmware images for devices (“stock roms”) • Restore your devices to factory settings • Extracting offsets, addresses offline

• Source code • AOSP checkout

• Compiler toolchain, etc • Base source for Android devices • Exact code for Nexus devices

• GPL releases • Linux kernel for device kernels

• More info in AHH and slides from previous talks

Supporting Data


DOING YOUR BIDDING Deploying your army for security research… …NOW WITH DEMOS!


• All device interaction!!

• Query for: • “fingerprint” • Linux kernel version • System-on-Chip • ADB user privileges • Root status

Tasks I


• Auditing tasks: • Check for driver (exynos-mem, pvrsrvkm)

• Comparing devices • Processes • File system • init scripts • Key files

• Manifests • /system/etc/permissions/platform.xml

• Plenty more!

Tasks II


• Other tasks: • Install an app • Push files to all devices • Pull files from all devices

• Offline interaction

• Test exploits (CVE-2013-6282)

• Subset interaction!!

Tasks III


• Final demo • Running scripts

• e.g., kernel config – heap selection

• Other tasks (w/o demo): • Send Intents • Fuzzing

• Checking compatibility • Tested “PatchDroid” by Dr. Collin Mulliner

• Testing addJavascriptInterface

Tasks IV


CONCLUSION These are the facts you are looking for.

Presenter

Presentation Notes

Key take-aways from this presentation.


• Various problems appeared over time

• Occasionally disappearing devices • Require intervention, sometimes manual :-/

• Random sounds emanating from cluster • Distracting!

• Li-Ion batteries do not like overcharging! • Swollen, scary, need replacing • Seem to live ~ 2 years

Lessons Learned


• MOAR DEVICES!!@#$%! • Please donate! • http://www.droidsec.org/donate/

• Further automation • privmap, canhazaxs, device diffing, etc • Automated firmware switching, setup

• I’m open to suggestions! • Email me ;-)

Future Directions I

Presenter

Presentation Notes

Duplicate devices can be used to run different firmware versions More host adapters partially solves the USB dilemma, but isn’t tested and has limited utility.�Requires host machine disassembly Will run out of PCI-X slots pretty quickly Exposing connected devices to Ethernet using a small pass-through box should solve it entirely. Not don’t yet, planned for future


• Device differences complicate security research.

• Building and using a Droid Army helps you scale your research!

• Provide quick and easy access to any particular device, version of Android, etc.

• It’s worth the investment!

Conclusions

Presenter

Presentation Notes

Biggest cost is the devices themselves ($0 - $800 ea)


• Use the recommended hardware design!

• Ask around for old/unused devices

• Follow device buying guidelines

• Use / contribute to the tools!

• Join and contribute to droidsec ;-)

Recommendations


Book Giveaway!


Accuvant Headquarters 1125 17th Street, Suite 1700, Denver, CO 80202

800.574.0896 www.accuvant.com

Joshua J. Drake jdrake [at] accuvant.com

jduck on Twitter, IRC, etc.

ASK ME ANYTHING!


BONUS SLIDES These didn’t make the cut…


• Device models differ from each other • Hardware

• SoC, peripherals, CPU features, RAM size, etc.

• Code changes • Made by various ecosystem players

• GOOG, SoCs, OEMs, carriers, third parties, etc. • Android OS / Framework, Linux kernel, etc.

• Compilation settings (ARM vs. Thumb) • …and more!

Causes of Fragmentation (detailed)


• Device databases • devices-orig.rb

• maps device serial numbers to names

• devices.rb • generated from devices-orig.rb by reconfig.rb

• scan.rb • shows you devices that are in ‘adb devices’ but not in

your database

Provisioning New Devices


1. Plug the device in 2. If not running ADB as root:

1. Get USB Vendor:Product 2. Add to udev scripts 3. Replug :-/

3. Run ./scan.rb 4. Add to devices-orig.rb 5. Run ./reconfig.rb 6. Upload busybox 7. Root the device 8. Do some research!

Provisioning a New Node


This stuff is spread allllll over the place :-/ Various places, step-by-step directions Google/OEM download sites Snagging OTA updates community ROM collection sites random searching - "stock roms" etc. See AHH Appendices or my 2013 slide decks

Where do you get firmware/src?


• Fixing problems as they appear (seldom)

• Acquiring more devices is time consuming

• Provisioning new devices • Quick and easy with the toolkit!

• Updating firmware / source code • Also time consuming (slow downloads!) • Sometimes requires re-rooting :-/ • Infrequent updates reduce the workload

Maintenance Tasks

researching android device security with the help of a droid army

Technology