Security has been a hot topic on Android for many years, particularly as smartphones take on increasingly significant roles both at home and at work. A single device acts as your main form of communication, contains personal photos and confidential documents, and may even have access to your finances. Google and other companies have made significant investments in time and money to ensure these devices are very hard to break into. However, a vulnerability was recently discovered in some phones that compromises important security measures and opens devices up to various types of attacks. The worst part is that it was created intentionally by a manufacturing partner contracted to build the phones, and the OEMs that designed the phone had no idea.

The company responsible for the issue is Foxconn, a major electronics manufacturer headquartered in New Taipei City, Taiwan. Foxconn became infamous a few years ago due to an inordinately high employee suicide rate that came to attention because the company happens to manufacture most of Apple's handheld devices (i.e. iPhones, iPads, and iPods). Quite a few large and small Android device makers like LG, Sony, and Samsung have also used Foxconn to mass-produce some or all of their phones and tablets.

The vulnerability

The discovery was made by security expert Jon Sawyer – familiar to most under the pseudonym Justin Case or jcase – best known in the Android community for numerous unlocking and rooting tools like Sunshine, WeakSauce, PwnMyMoto, and plenty of others.

Very little is off limits

Dubbed, the vulnerability is found in the bootloader of some devices. By sending a specific command, the device can be restarted in a "Factory Test Mode" with elevated privileges and reduced security. In this mode, SELinux is switched from 'enforcing' to 'disabled' and the adb daemon (the on-device service adb talks to) is automatically run as root and doesn't ask for authorization when unknown computers are attached.

Without the above safeguards, it's possible to do quite a bit to an Android device, regardless of the steps a user has taken to protect it. Lockscreens can be bypassed with an ADB command, the bootloader could be unlocked without wiping user data, and with a little bit of time, the encryption keys could be brute forced. Very little is off limits.

It's worth noting that this exploit is only really useful to somebody that gains physical access to a vulnerable device. This might include governments, law enforcement, forensic data analysts, thieves, con artists, and more. It's not a particularly viable way to spread malware.

Exploitation

Note: These are mostly technical details. If you're not interested in how this works, you may want to skip to the next section. Just know that the steps are trivial for a reasonably competent computer user.

Exploiting this backdoor doesn't require a lot of tools or any specially crafted payloads. In fact, it can be done with either an easily modified build of fastboot or a completely unmodified version of adb (requires the ability to issue adb commands).

... the steps are trivial for a reasonably competent computer user.

As many readers know, the utility most commonly used for working with the bootloader is called fastboot. It's implemented as a command line tool with a relatively short list of capabilities, but it's primary functions are dedicated to properly formatting user commands and passing them through to the bootloader and transmitting partition images over to the device where the data will be flashed to memory. There is a standard set of commands that exists as part of the fastboot spec, like getvar, boot, and the more recently added flashing commands . These commands are hardcoded into the fastboot executable. There is also an affordance for manufacturers to add their own custom commands, but they must always begin with 'oem,' and the command is passed to the bootloader in a different format.

The command to launch factory test mode is called reboot-ftm, but it is somewhat (lazily) hidden. Bootloaders from Foxconn that support this command are programmed to listen for it as if it were a standard protocol command, not an oem command. Since the standard commands are hardcoded in the fastboot executable, it won't recognize the the instruction to launch factory test mode. However, all it takes to work around this is adding a few lines of code to the open source fastboot command and recompiling a custom version.

Once reboot-ftm has been executed, it boots from a special partition named "ftmboot" containing a custom ramdisk and kernel. This takes care of booting the device, but specifically leaves SELinux disabled and elevates adbd to root.

Using adb won't require a custom executable to booth from the ftmboot partition, a user simply has to run 'adb reboot ftm' from the command line. However, this is only an option if debug commands have already been enabled on the device and the computer issuing the command has been authorized.

For more details, check out jcase's blog post about Pork Explosion.

Why does this backdoor exist?

Manufacturers regularly use factory test modes on the hardware they produce. It allows them to run hardware and software diagnostics and can be useful for in-house developers. It's also common practice to either seal them up in ways that are nearly impossible to activate or they are disabled entirely. This is where Foxconn evidently made a mistake – the factory test mode is absurdly easy to access.

There's currently no reason to believe this vulnerability was left in production devices for any malicious intent. The most likely explanation is that somebody either forgot to disable it or actually didn't understand the security implications. Yes, those are terrible reasons... They're just not intentional. Probably.

What devices are affected and what is being done?

At this time, it's not clear how widespread this backdoor actually is. Some companies leave low-level firmware development to their manufacturing partners (Foxconn, in this case) instead of doing the work on their own. Even if Foxconn was involved with firmware for a specific device, the bootloader may have still been done elsewhere. In cases where Foxconn did deliver a bootloader, the clients would likely receive a final binary to use as part of the final firmware package – and they're never the wiser.

Two devices with the backdoor have already been identified by Jon Sawyer: the Nextbit Robin and the InFocus M810. There is good reason to expect many other devices were affected, especially older models and lesser-known brands. Sawyer reported the issue to the manufacturers of both devices and Foxconn. Nextbit released an OTA update earlier this month that disables the backdoor by filling the ftmboot partition with zeros.

The easiest way to tell if a device is affected, or at least was at one time, is to check the list of partitions for ftmboot and ftmdata. Since it's possible some devices use slightly more clever methods to prevent people from accidentally stumbling onto factory test mode, the commands mentioned above may not be enough to activate it. Unfortunately, there's no good advice at this time for those with vulnerable devices, but reporting the issue to the manufacturer and pressuring them for a fix is a good start.

Wrap-Up

Whether or not you feel like Google's efforts to boost security have been sufficient, the real takeaway is that device manufacturers bare a lot of the burden, as well. It's not just on them to ensure their customizations aren't opening potential holes, but they must also be responsible for the firmware that goes on their devices. And when things like this are discovered, OEMs should absolutely be held accountable until a fix is made available.

This incident can also be a good reminder to stick with serious hardware manufacturers rather than cheap knock-off brands, like those that often show up with strangely deep discounts around the gift-giving holidays.