Six major Android vulnerabilities found, but will they shake MNOs’ apathy?

Security researchers from the University of California at Santa Barbara have discovered six major vulnerabilities in Android smartphone bootloaders. Found in chipsets from Huawei, MediaTek, Nvidia and Qualcomm, the vulnerabilities could be used to attack and overhaul a device. Five of the six vulnerabilities were zero-days, meaning they have been present since they originally shipped.

These flaws completely undermine the Chain of Trust (CoT) in the devices, but are unlikely to shake MNOs out of their habitual apathy about device security.

Called BootStomp, the researcher’s tool found ways to exploit the flawed bootloader, which will apparently let them execute malicious code and perform denial-of-service (DoS) attacks, and even brick the device remotely. BootStomp’s tools primarily involved dynamic symbolic execution and static analysis, to find potential problem areas to target in the bootloader firmware.

But will the MNOs really care about the new vulnerabilities? To carry out an attack using the exploits is quite tricky to do remotely, and while stealing passwords and credentials would certainly be traumatic for a consumer, it isn’t going to hurt the carrier’s bottom line. This isn’t something like Heartbleed or a DDoS attack, which can hamper and offline an MNO’s operations, so it’s hard to see the researchers’ work doing anything to change the current dynamic of carrier apathy towards device security.

The bootloaders in question concern the Huawei P8 ALE-L23 (which uses a HiSilicon chipset), the Sony Xperia XA (a MediaTek chipset), and the Nexus 9 (an Nvidia Tegra chipset). Perhaps more concerning were findings on two versions of Qualcomm’s MSM chipset and Little Kernel (LK) bootloader, given that Qualcomm has around a 60% share of the market. In some of the attacks, the bootloaders were operating at a higher privilege than they should have been allowed, which let the researchers interfere with ARM’s TrustZone – a theoretically secure enclave for handling encryption keys and the like.

The report notes that “ideally, [the bootloader] is an uncircumventable, rigid process, removing any possibility of compromise, even when attackers can achieve arbitrary code execution on the high level OS (Android or iOS). However, hardware vendors are given a great amount of discretion when implementing these bootloaders, leading to variations in both the security properties they enforce and the size of the attack surface available.”

From reading the paper, it seems that the Android ecosystem’s diversity of choice is mostly to blame for the vulnerabilities. With so many options, it is inevitable that errors will be introduced into the hardware and code at some point – which a tool like BootStomp can then capitalize upon. Apple’s far smaller catalog of devices means that it is not as vulnerable to these types of problem.

At some point, it could pay for carriers to invest in their own penetration testing divisions, to thoroughly test the devices they are adding to their networks. That process would essentially be due diligence, and can easily be justified by the customer experience improvements that are brought to the table, by preventing those customers suffering from hacks and exploits on their phones.

But carriers are no longer the only source for handsets. Increasingly, many have opted for pushing SIM-only contracts, as consumers have become more comfortable for buying their own devices and paying the MNO only for connectivity. Handset sales and leasing are still a big part of the equation for many carriers, but the idea of security due diligence would have been more appealing in a closed ecosystem – where they would have had complete control over a limited number of handsets available.

This is no longer the case, and the cost of testing every single potential handset would be prohibitive. However, given that only a few models make up a big proportion of the total number of devices on a network, it would still be a workable approach – but modeling the return on this investment would be tricky, and many CFOs are not going to see the merit in it.

In addition, these types of attacks are not really risks for the network infrastructure – meaning that operational security or uptime aren’t incentives for the MNO to tackle the problem in-house. Compelling the handset vendors to adhere to better standards of security is all well and good on paper, but often these devices require recalls to flash new firmware to them in secure environments.

The bootloader is one of the first pieces of software to load on a device, and as the name suggests, it guides the system on where to load files from – both for startup and for file retrieval.

Part of this process involves validating the origin and security of files, and bootloaders are designed to reject things that are not trusted as part of an operating environment. Once the device posts (Power-on Self-Tests), the bootloader loads up all the OS systems, moving them into the RAM memory from the persistent flash.

The bootloader is a bit like a doorman for the device’s flash storage – only letting the correct people through the door, and guiding people to their destinations. It also prevents a user doing things like deleting storage partitions that might brick the device, should they be overwritten.

These bootloaders are typically locked down via encryption, so that you can only start software that is trusted and verified by the security key chains deployed by the vendor. For users that want to root their phones, usually to install different operating systems, part of the process involves unlocking the bootloader or replacing it with another – which can open them up to malicious software getting through the door.