Current State of Android "Physical" Security

Android Partition Layout

The android partition layout is differs from device to device, but there are some main components that can be found on every device.

On most devices / is actually a ramdisk that is created at every boot. So don't try to persist anything there. The contents of the ramdisk are loaded from the "boot" partition, where also the kernel lies. /system: contains the core OS, all the system binaries, configuration, the android framework etc. The apps and all the data that apps produce are stored in /data/. Another interesting partition is the recovery image partition. This partition contains a kernel and a ramdisk similar to the "boot" partition, but is not intended to boot the full system, but provide only basic functionality for recovering devices or updating the devices firmware. Flashing a new recovery image is usally one of the first steps when using a custom ROM. The there usually is a partition for the cache, which is used by the android JVM implementation (the dalvik VM). Finally we have the storage where the user has direct access. For example the SD card or internal memory. Those are usually acessible via /sdcard, /mnt/storage or something similar.

Boot Process

HTC/Qualcomm devices usually boot in the following manner. Don't forget that we have two "main" processors inside a typical phone. One that performs all the stuff related to the telephone network (called baseband processor) and one that processes all the applications and the actual OS (also called the applications processor).

1. The baseband processor starts and loads the primary boot loader (PBL)
2. The PBL loads the secondary boot load (SBL)
3. The application processor boots the HBOOT bootloader
4. HBOOT loads the kernel or recovery image

Other devices boot in a similar manner, although they use their custom bootloader(s) and everything is called a little different.

To achieve security during the boot process the bootloader verify the next step before continuing. So in this case the PBL verifies the signature of the SBL. The SBL verifies and loads the baseband code and the HBOOT bootloader. HBOOT the verifies and loads the kernel/recovery. This way no untrusted code can be booted.

For development this isn't really practical, so one can usually unlock the bootloader, so that untrusted kernels or recoveries can be booted. This is cool because we can use this to install custom ROMs. Most app processor bootloaders implement the fastboot protocol, so that it can be controlled over USB. fastboot is also the tool that ships with the android sdk and can be used to boot other kernels, recoveries, flash images to partitions and also unlock the phones bootloader. The later can be achieved by using:

fastboot oem unlock

What this does is disable signature checking of the kernel/recovery image but most devices also perform a factory reset (aka. formatting the /data/ partition) when the bootloader is unlocked. Note that not all devices have bootloader that can be that easily unlocked or relocked.

HTC S-ON/S-OFF

You can think of this as a more complete device lockdown. Additionally to a locked bootloader, the /system, kernel and recovery partition are hardware-write-protected. So even if we gain root on the phone, we cannot modify the system beyond a reboot. To gain S-OFF one can use an exploit or go the offical HTC way, where you need to submit a token and flash a signed blob, so that HTC can confirm that you know that the warranty is now voided. This makes the system, kernel and recovery partition writable and you are free to flash your own images.

Smudge Patterns

In 2010, pretty soon after Android started booming, the first attack against the unlock pattern was presented [2]. The problem is that we leave smudge on the display after inputting the unlock pattern. If we input our pattern a few times we can see the line of smudge on the display and only have to guess the direction in which the pattern is input. And that's not hard to bruteforce ;)

The paper that presented the attack describes several possibilities using a camera and some image manipulation to make the pattern more visible [2].

Face unlock method introduced in Android 4 is another insecure method for unlocking the phone. It can be easily tricked by showing a picture of the owner (accessible via your favorite social network) to the phone. So if you are truely paranoid use a PIN or a password to protect your phone. But what if an attacker does actually manage to unlock your phone? I will discuss that in the next section.

Installing Malware

the first thing that comes to my mind is: install some malware:

adb install com.example.AngryBirdsStarTrek.apk

Using adb we can also access many parts of the system, although we are still restricted. We can give our malware all kinds of permissions to gain access to a lot of personal data. Unfortunately we don't have unlimited permissions, because the really awesome permissions are the system or systemOrSignature level permissions, which are only available to system apps or apps signed by the system vendor.

But that said we can get access to most personal data, such as contacts texts, phone calls etc.

We can also use our installed app to disable the "keyguard" lock, effectively bypassing any PIN, password, unlock pattern or face unlock. This is as simple as the following code (which might not be accurate anymore but I'm currently too lazy to check again ;)

KeyguardManager keyguardManager = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
KeyguardLock mkeyguardLock = keyguardManager.newKeyguardLock("unlock");
mkeyguardLock.disableKeyguard();

Oh shit. So now we have nearly unrestricted access to the phone. But what to do now?

Intercepting Login Credentials

While we do have access to the phone we probably can't access any credentials stored by the installed apps. What if we need to give the phone back soon and going through all the email directly on the phone probably isn't practical. What we do now is go back a level deeper and start watching the network traffic produced by the android phone. This means we launch a classic man-in-the-middle attack. Since we have access to the phone we can easily connect to our own hostile wifi. Unfortunately we can't see all the login credentials, since most apps transmit the data via https or TLS. But wait we can just add our own CA certificate in the android trust store and look at all this confidential data :) I like to use the mitmproxy [5] tool for such purposes, but you could also use Burp or OWASP ZAP. Unfortunately not all apps seem to support the proxy setting in Android.

Stuff you can intercept are mostly auth tokens [6], which can give you the power to take over accounts. But sometimes you get lucky and directly spot a password. The following image shows the mitmproxy tool while intercepting an authentication request. The "Token" parameter is the token which is used to authenticate the device.

Google had a very serious bug, where you could even bypass the two-factor authentication once you had access to an applicaiton specific password, such as the android's login token, which you can observe with a mitm proxy [7]. This was fixed by google.

So this is already pretty serious, but there is another feature of Google's Android: the Backup & reset feature. This feature enables a backup of system settings, application data and wifi passwords to the google cloud. If we use the google authentication token we sniffed to log into the google account on another rooted phone, we can get all the stuff backed up to google in plaintext. I'd say: "All your wifi password are belong to us!".

Escalate to root

So this is already pretty serious now, but we still do not have root, so we can't install the really juicy malware and give the phone back. Well we could also use one of the countless root exploits for Android. Nearly every phone and Android version is vulnerable to some kind of root exploit. Because phone vendors can't keep up with patching or leave devices intentionally vulnerable, the likelyhood that a device with adb enabled is vulnerable is pretty high.

Bruteforcing the Encryption Key

Android encryption forces you to set a password or PIN to unlock your device. Unfortunately the same password is used for unlocking the phone for everyday use and for decrypting the device. This means that you will probably use a very weak password. Who has the time and the nerve to input a 16 character password for quickly reading a text message.

Unfortunately the disk encryption for Android is tailored for low-power low-performance devices. Android uses dmcrypt for performing the actual crypto. The information needed to decrypt the phone is saved in the last 16 kB of the encrypted partition. The encryption key is actually just a bunch of random bytes read from /dev/urandom. This key is then encrypted using the users password. Because user passwords are usually pretty low entropy and don't have the right length for an encryption key, a technique called "key stretching" [9] is used. Like almost everyone else the standardized PBKDF2 function is used to stretch the key. PBKDF2 stand for Password Based Key Derivation Function 2 and uses repeated hashing and salting to derive an actual encryption key [10]. This technique is not only useful to derive good encryption keys with various lengths from a master key, but also offers protection against brute-force attacks. PBKDF2 is a parameterized function that takes the number of iterations as parameter. The higher the iteration count the more work has to be done before the actual key can be tested.

Unfortunately the iteration count is hardcoded to 2000 on Android, which is in fact pretty low. For example the LUKS/dmcrypt setup on my Fedora box uses about 160000 iterations for PBKDF2. While this may not be possible on an Android device, an iteration count of 2000 is definitely too small. Additionally PBKDF2 is also pretty fast on GPUs.

Can you guess where this is going? Yes bruteforcing the password/PIN used to encrypt the device is absolutely feasible. It has actually been done with the hashcat bruteforcing tool [11]. So we see Android encryption isn't actually that secure.

Recovering the Encryption Key from Memory

Another attack against encrypted Android phones is called: FROST [12] [13]. As you might have guessed this is a form of cold boot attacks against Android phones. The researchers discovered that the contents of the RAM can be preserved across a device reboot by cooling it down. They showed that it is sufficient to cool the whole device, so it is not even needed to directly access the memory chips. They also wrote a recovery image and kernel module to search and dump any disk encryption keys that still reside in the memory of the Android device.

Not only encryption keys but also other possibly sensitive data such as pictures, documents or password to services can be retrieved using this cold boot attack.

Fortunately to boot into FROST or something similar, the phone needs to have an unlocked bootloader. As I wrote at the beginning unlocking should wipe all user data, which restricts FROST to recovering data from memory.