BlueBorne is Bluetooth’s Stagefright moment

When Armis researchers demonstrated BlueBorne, an attack that takes advantage of vulnerabilities in the Bluetooth protocol, it was downright frightening how easily an attacker could take remote control over the device. 

View all files saved on the device? Sure—and it’s a snap to encrypt those files as part of a ransomware attack. Turn on the camera? Not a problem—and the device can eavesdrop on meetings and monitor conversations without anyone else knowing. Install malware? Done with a click and no one the wiser.

But what scared me even more was the fact that BlueBorne was just the tip of the iceberg when it comes to Bluetooth-based attacks.

Researchers at internet of things security company Armis found eight vulnerabilities in the Bluetooth implementations for Android, Microsoft Windows, Linux, and iOS, which means nearly all Bluetooth-capable devices are affected. The list of vulnerable devices goes beyond just smartphones, tablets, and laptops: think about TVs, watches, entertainment gear, childrens’ toys, and even automative and home automation systems.

Anything that has Bluetooth. Armis researchers estimated that over 5.3 billion devices are at risk.

“The BlueBorne attack vector requires no user interaction, is compatible to all software versions, and does not require any preconditions or configurations aside of the Bluetooth being active,” Armis researchers wrote.

Dangers of always on, always listening

BlueBorne takes advantage of the fact that Bluetooth-enabled devices are always listening for other devices they can connect to. While devices typically have to be manually paired to form that initial wireless connection, once paired those devices reconnect automatically whenever they are near each other. BlueBorne exploits the vulnerabilities in a way that it can establish the Bluetooth connection with devices nearby without having to go through the pairing process. Unless someone happens to be looking at the list of Bluetooth devices, it’s unlikely these connections will ever be discovered.

“BlueBorne is different from past Bluetooth-based exploits, which relied on weaknesses in the protocol that no longer exist, or authentication-based issues related to idiotic PIN codes,” said Nadir Izrael, CTO and co-founder of Armis. “It [BlueBorne] requires nothing from the user.”

I have heard this before: Malware that executes code and hops from device to device is a worm. BlueBorne lays the groundwork for an IoT worm that spreads over Bluetooth.

There are many ways the vulnerabilities can be weaponized. Imagine going to a sporting event and knowing that every Bluetooth-enabled device in the stadium is vulnerable to an attack launched from a single device. An attacker can walk into a building carrying a device pre-loaded with malware and infect a device in the lobby just by standing near it. Everyone walking in and out of that lobby carrying a vulnerable device can be infected, and as those devices move around the building, the potential grows for more infections, until the malware is firmly lodged in the corporate network. Because of the fact that all the malicious activity happened over Bluetooth, no one would even be aware of the malware spread until they start investigating what went wrong.

“The automatic connectivity of Bluetooth, combined with the fact that nearly all devices have Bluetooth enabled by default, make these vulnerabilities all the more serious and pervasive,” they said. “Once a device is infected with malware, it can then easily broadcast the malware to other Bluetooth-enable devices in its vicinity, either inside an office or in more public locations.”

Another possible scenario is to launch a man-in-the-middle attack by turning the device into a Bluetooth Pineapple, capable of sniffing traffic sent between devices or spoofing a legitimate device to hijack the connection and redirect traffic. Attackers can look at nearby Bluetooth devices and specifically target devices by using commonly available tools to identify the MAC addresses.

“By probing the device, the attacker can determine which operating system his victim is using, and adjust his exploit accordingly. The attacker will then exploit a vulnerability in the implementation of the Bluetooth protocol in the relevant platform and gain the access he needs to act on his malicious objective,” researchers wrote.

Bluetooth typically has high-level privileges on devices because it is intertwined with many system-level processes. Compromising Bluetooth inevitably means that malware executes with those same elevated privileges, in some cases, even as root.

Bluetooth’s Stagefright moment

BlueBorne may be to Bluetooth what Stagefright was to Android. When Zimperium researchers uncovered the Stagefright vulnerability in Android, where a malformed video sent via text message could be used to execute malicious code on the device, it spurred other researchers to look more carefully at the mediaserver component (and the libstagefright library) that processes video and other multimedia files for other—related—vulnerabilities. For more than a year, Google released fixes for mediaserver every single month as part of its monthly security update. Most of the vulnerabilities were tangential to the original Stagefright flaw, but were located in similar sections of the code and were found because of the increased scrutiny.

That’s what we need for Bluetooth. Ben Seri, head of the research team at Armis Labs, said that it hadn’t been that difficult to find the set of vulnerabilities they’d grouped as BlueBorne, noting that hunting for zero-day vulnerabilities is not part of their typical job activities. Anyone “oriented towards looking for remote code execution vulnerabilities” would have been able to find the flaws, Seri said.

Seri and Izrael were worried about the number of other vulnerabilities lurking in Bluetooth that no one knows about because no one has really paid a lot of attention to the inner workings of the protocol.

“Armis believes many more vulnerabilities await discovery in the various platforms using Bluetooth,” the researchers wrote. “These vulnerabilities are fully operational, and can be successfully exploited, as demonstrated in our research.”

There are also other, custom, implementations of Bluetooth beyond what the major players are doing. “If we found them in major stacks, we expect to find them in custom implementations,” Seri said.

Most devices can’t be patched

Google and Microsoft released updates fixing the vulnerabilities in their September security updates for Android and Windows, and major Linux distributions are coordinating their own fixes. Microsoft said Windows Phones are not impacted, and Apple had changed how it implemented Bluetooth in iOS 10, providentially closing the vulnerability by the time Armis reported the issue. Only pre-iOS 10 versions remain at risk, which Armis estimates at about 130 million devices.

The eight vulnerabilities are as follows:

• Linux kernel RCE vulnerability – CVE-2017-1000251
• Linux Bluetooth stack (BlueZ) information leak vulnerability – CVE-2017-1000250
• Android information leak vulnerability – CVE-2017-0785
• Android RCE vulnerabilities CVE-2017-0781 & CVE-2017-0782
• The Bluetooth Pineapple in Android – Logical Flaw CVE-2017-0783
• The Bluetooth Pineapple in Windows – Logical Flaw CVE-2017-8628
• Apple Low Energy Audio Protocol RCE vulnerability – CVE Pending

However, that ignores the fact that a siginificant number of those devices will never receive patches or be updated. For example, Armis estimates that only 45 percent of Android devices—approximately 960 million—can be updated, which leaves 1.1 billion Android devices currently in use worldwide vulnerable. There are also plenty of devices that run some flavor of Linux, but don’t have a way to be patched—or the update process is too cumbersome for average users to even attempt. 

Armis recommends keeping Bluetooth disabled on devices until absolutely necessary, and then turning it off when done. Once the device has been updated with the patch closing the flaw, it would be safe to turn Bluetooth back on and leave it on, but it seems to me that it’s good security practice to keep it off when not in use. Why increase the attack surface when you don’t need to?

I can’t decide which prospect worries me more: a BlueBorne botnet à la Mirai or a BlueBorne worm. Either way, before we make even more things that are Bluetooth-capable, can we make it harder for devices to connect to each other without actual user permission?