FEATURE

November 2014 Network Security5

Android scraping: accessing personal data on mobile devices

There are a surprising number of ways to recover data from smartphones. No doubt we’ve all always suspected that those in the upper echelons have special toolkits and certificates that allowed them to access pretty much anything they like during investigations. But there are also tools out there that are available to regular users, hackers and thieves.

What could someone retrieve from a stolen phone? What if an employee won’t give you a PIN to their corporate phone? What is leaking from you or your busi-ness on secondhand phones? We’re going to look at Android smartphones in this article, mostly because there are plenty of different attack vectors. Apple has made great progress with improving the security of iOS software and the iPhone/iPad hardware, though that’s not to say it’s secure. But Android is a popular target because of its open coding.

Cable-based attacksThere are plenty of ‘fixed’ wire-based attack routes to hacking Android, many of which allow the hacker to both gain access and make changes to the security settings of the device. A key tool is Android Debug Bridge (ADB) which is intended primar-ily for Android developers to debug their application code. It’s also used if you want to ‘root’ your device, maybe to install ‘cracked’ apps from dodgy sources or have deeper access to the handset. If you are lucky then you might find ADB enabled. Connect a micro USB cable to the handset

and your PC, then start the ADB server (part of the Android SDK). You can now read the file system on the phone.

A really basic attack might be to navi-gate to /data/system on the phone, find the password.key and gesture.key files and delete them.

Lock the phone, enter anything on the keypad and it should unlock. There is a caveat with this though. Android 4 (Ice Cream Sandwich) introduced the keychain, which encrypts user data. The encryption key is derived from the PIN or gesture, so if you delete those, and the data you’re are interested in is protected by the keychain, then you can’t get it.

ADB PIN crackIn many respects, it’s far better to crack the PIN rather than to delete it as the hacker will then be able to decrypt the

keychain, which might provide access to VPN credentials, wifi pre-shared keys and any other application data protected by the keychain. A four-digit PIN can be cracked by brute force in about 14 hours. The ‘Rubber Ducky’ USB tool can be used, although we’ve written a rather better version that doesn’t require you to stare at the screen for all 14 hours.

If ADB isn’t enabled, there are plenty of other ways. Numerous chipsets are used in Android devices. Several have issues with the firmware update modes, and probably the most well known with secu-rity issues is the Rockchip, which is used in several brand name tablets. A critical flaw exists in that, when in firmware update mode (‘flash mode’), one can’t just write new firmware to the device, one can also read from it. Using rkflashtool makes this very easy indeed. Again, con-nect a cable to the micro USB port on the device, put it in to flash mode (usu-ally hold volume up, push reset button, release volume up) and start the flash tool in your Linux distribution.

Ken Munro, Pen Test Partners Android devices hold a great deal of personal user data. Accessing that data, par-ticularly if the device has been restored to factory settings, should be relatively difficult. But there are numerous ways to exploit the Android operating system – exploits that can be used to trick these devices into surrendering their secrets.

Figure 1: Accessing the password.key file over a USB cable.

Ken Munro

FEATURE

6Network Security November 2014

A read takes two hours or more, depending on the size of the user par-tition. The output should be in an .img file , which is normally a simple Linux filesystem, which you can simply mount and start reading. Depending on the device, you may find that the wifi keys and some user data are in plain-text. The *.key files are hashed with SHA-1 and MD5 which can easily be cracked, particularly if the PIN is only four or six digits long. Just like with the ADB attack, you can now decrypt the filesystem.

AllwinnerThe Allwinner chipset allows the device to boot and run an operating system that is installed on an SD card; this is similar to booting your laptop from a CD. You can exploit this just as you might boot a laptop or desktop from a live Linux distribution on CD and use that to wipe or crack the local admin password. With this Allwinner attack, you boot from the SD card and then mount or image the user data on the device. Again, if a PIN is set and the

Android version supports encryption and the keychain, one needs to crack the PIN to decrypt user data.

SPFlashToolIf you’re working with a MediaTek device, then a fairly similar attack exists using SPflashtool. It’s a bit more involved but as effective as the Rockchip/rkflashtool attack.

UARTThere’s a rather nice attack against, for example, the Nexus 4, 5 and possibly 7 that involves switching the headphone connector into a serial port. Yes, back to the days of RS232! Amazingly, if the device sees a voltage of >2.8V on the headphone socket, it switches it to UART. This allows you to read the hard-ware state of the device, revealing lots of wonderfully useful information.

However, some devices such as the Samsung Galaxy S2 don’t just allow you to read state, they allow you to write to the device too. A handy consequence of this might be, for example, the ability to reset the ‘yellow flag’ that shows if an unsigned image is written to the flash memory.

Attacks requiring a screwdriverIf data extraction using a cable won’t work, it’s time to start disassembling the device. One of the most reliable methods is to look for the JTAG port, present on almost all phones. JTAG is described in Figure 4: The JTAG Port on the Google Nexus 4.

Figure 3: A UART convertor between the phone and a laptop.Figure 2: An ADB-based brute force attack on the PIN, with the PIN cracked. The Android smartphone is now unlocked

FEATURE

November 2014 Network Security7

IEEE 1149.1. It allows us to talk to the chipset at a really low level. It was intend-ed (among many purposes) for debug-ging firmware – for example, allowing developers to iterate one-by-one through clock cycles to find exactly where a bug lies. However, depending on the particu-lar interface, it can also allow us to scrape memory direct from the device.

First, you need to identify the JTAG ports on your phone. If you have an Android phone then they should be fair-ly easy to locate. Google Image Search can help.

Unsurprisingly, hardware manufactur-ers don’t want just anybody talking to their chips through JTAG ports, so they don’t always publish the protocols you need to communicate with the chip. Nor do they always publish which con-tact does what on the JTAG interface. That’s where hardware hacking gets pretty hardcore. Devices such as the JTAGulator can help you here, but that’s going beyond the scope of this article.

When working on a phone, a device similar to a RIFFbox is needed. This is often used by phone unlocking shops and unbricking services which use the JTAG ports to achieve this. It’s essentially a large database of primarily ARM-based JTAG protocols brought together in a handy hardware and software package. A JTAG connector that can be used for the par-ticular phone being scraped is also essen-tial, and this too is usually available from similar sources to the RIFFbox.

For those feeling brave, or if there isn’t a connector available for your device, then you can try microsolder-ing. However, if you’re not very skilled at soldering on to tiny connections, you run the risk of damaging your phone, possibly beyond repair. Micro soldering services are available.

The example we will walk through is with a Google Nexus 4, also known as an LG E960. Strip down the phone a little to expose the JTAG port. There are plenty of teardown guides on the Internet to help you here. In the case of the Nexus 4, it helps to remove the camera. It’s also worth removing the GSM and wifi connectors as soon as you seize a device so there’s no chance of the user attempting a remote wipe. An RF

shielded bag will help too. Then connect the various cables and connectors via the RIFFbox to your PC, clamp the connec-tor in place and start the RIFF software.

You will need to download the ‘LG E960’ resurrector file from within the manager and select this within the JTAG read tab, and finally the ‘eMMC based Fullflash’ plugin. The RIFF box supports communication with single or multi-chained Test Access Port (TAP) control-lers. The automatic detection of the IR register size means that all is needed is

the TAP controller position. Figure 6 shows the two TAP devices detected on connecting to the Nexus 4.

The next step is to start to read the Flash memory. To do this we need to run ‘eMMC based Fullflash’ from the use-ful plugin tab. By clicking on the ‘Load layout from device’, this will populate the partition table as shown in Figure 7.

The two partitions we are interested in are ‘Userdata’ and ‘Metadata’. The Metadata partition contains all of the crypto information needed to brute force

Figure 5: JTAG connector clamped in place on a Nexus 4.

Figure 6: Two TAP devices identified.

FEATURE

8Network Security November 2014

the encryption password, which is also the device unlock PIN. The next step is to right click on both partitions and select ‘Save partition into file’. The Metadata partition is quite small so will finish quickly; however, depending on the ver-sion of Nexus 4 being used, you will have a Userdata partition of around 8GB or 16GB. The throughput from the RIFF box to the manager software is around 150KB/s, so this will take a few hours.

Two Python scripts are then required: one for the brute force, and one to decrypt the UserData partition. The brute force script requires both of the partitions to be given, plus the length of PIN. If you don’t know the PIN length, it’s wise to start with four as this is the most popular.

The decrypt script requires editing so that the cracked PIN and both partitions are entered. Also, the decrypted script will need to output the decrypted data to a file, as the script only decrypts a sample of the data.

Once decrypted, the format of the UserData partition is compressed EXT4 which has the sparse space removed. This needs to be converted into a stand-ard EXT4 format, which then can be mounted. The commands to do this are:

./simg2img userdata.img userdata-unc.imgmount -o loop userdata-unc.img /mnt/unencrypted-android

The simg2img executable can be found within the android developer kit.

Now, mount the image file to the filesystem to read the contents. As we are already armed with the PIN, it is now possible to unlock the device, although it is usually easier to work through the image file than to use the phone itself. After following these simple steps, pretty much all user data that is on the phone is now available to read. Most of the content will be held in a SQLlite data-base.

It is also possible to extract data directly from the flash storage of the device by removing the NAND chip from the motherboard and read it directly through special hardware. This is not easy to do as it requires microsoldering and custom hardware.

Figure 7: Identifying metadata using JTAG.

Figure 8: Brute forcing the PIN.

Figure 9: Plaintext revealed.

FEATURE

November 2014 Network Security9

Wiping dataFaced with this evidence of how easy it is to extract data from an Android handset, many of us will be making a mental note to run a factory reset when we jettison our current devices. However, unlike iOS which does a pretty thorough wipe when the factory reset is run, Android doesn’t always do quite as well. The default factory wipe doesn’t do much more that delete the equivalent of the File Access Table (FAT) and refresh the OS from a recovery partition.

Given the large user data partition size, there is potential for personal details to remain in slack space after the wipe. We have had extensive success recovering personal details from secondhand phones and tablets. Often, they are sold because the screen is broken (in which case run-ning a wipe is hard for a regular user) or they are simply surplus to requirement. Rarely does the factory wipe remove all sensitive data. Unless you can run a third-party tool, or write zeros to the entire user data partition – using dd, for example – don’t sell used Android hardware.

ConclusionIt’s relatively simple, with about $200 of kit, to scrape memory from an Android device and decrypt it, exposing poten-

tially sensitive information. Mobile Device Management (MDM) products have been touted as the solution, but few can prevent these attacks: most simply enforce existing native encryption policy on the handset. A very small number of MDMs work differently though, creat-ing an encryption container independent of the handset operating system cryptog-raphy. Some handset manufacturers have implemented better encryption than native Android. A good example of this is the Samsung S4, though this has been independently compromised through the Sandy framework.

For other Android devices, setting a long PIN can help, as it would take a great deal longer to brute force a PIN that was eight digits or more. And as for

when Android devices reach end-of-life, don’t sell them on unless you can be cer-tain they have been thoroughly wiped of all user data.

About the authorKen Munro is partner and founder of Pen Test Partners, a firm of experienced penetration testers. He regularly blogs on everything from honeypots to hacking cars and also writes for various newspa-pers and industry magazines. A familiar face on the speaker circuit, Munro enjoys courting controversy and speaks widely on computer security, taking great plea-sure in highlighting vulnerabilities in software and hardware. He has worked in the field of information security for over 15 years.

Figure 10: Viewing credentials from the email application.

Forensic investigation of social networking applications

Although social networking applications are mainly used for personal purposes, some organisations actively encourage their employees to use them within the work environment to potentially

improve productivity via enhanced information sharing above and beyond the corporate network.6,7 Social media can provide employees with formal and informal ties to information sources

both within and beyond organisational boundaries.8 However, some organisa-tions might not fully appreciate the potential for misuse that social network-ing applications may provide.9

If organisations do allow employees to use social networking applications within the work environment then it would be prudent to set out guidelines for such in the organisation’s computer usage policy, to ensure that employees are provided with explicit guidance.10,11

Dr Mark Taylor, Dr John Haggerty, David Gresty, Peter Almond, Dr Tom Berry

Social networking applications such as Facebook, LinkedIn, MySpace and Twitter provide facilities including email, blogging, instant messaging and photo sharing for social and commercial exchange.1 There has been a rapid growth in the use of social networking applications by both individuals and organisations.2,3 And an increasing number of organisations use Facebook and Twitter as part of their marketing campaigns.4,5