AUTHOR: LILY HAY NEWMANLILY HAY NEWMAN
05.19.19 07:00 AM
BLUETOOTH IS THE invisible glue that binds devices together. Which means that when it has bugs, it affects everything from iPhones and Android devices to scooters and even physical authentication keys used to secure other accounts. The order of magnitude can be stunning: The BlueBorne flaw, first disclosed in September 2017, impacted 5 billion PCs, phones, and IoT units.
As with any computing standard, there’s always the possibility of vulnerabilities in the actual code of the Bluetooth protocol itself, or in its lighter-weight sibling Bluetooth Low Energy. But security researchers say that the big reason Bluetooth bugs come up has more to do with sheer scale of the written standard—development of which is facilitated by the consortium known as the Bluetooth Special Interest Group. Bluetooth offers so many options for deployment that developers don’t necessarily have full mastery of the available choices, which can result in faulty implementations.
“One major reason Bluetooth is involved in so many cases is just how complex this protocol is,” says Ben Seri, one of the researchers who discovered BlueBorne and vice president of research at the embedded device security firm Armis. “When you look at the Bluetooth standard it’s like 3,000 pages long—if you compare that to other wireless protocols like Wi-Fi, for example, Bluetooth is like 10 times longer. The Bluetooth SIG tried to do something very comprehensive that fits to many various needs, but the complexity means it’s really hard to know how you should use it if you’re a manufacturer.”
Long in the tooth
Bluetooth, as you probably know from your portable speaker, wireless keyboard, or toothbrush, allows two proximal devices to connect to each other over the air. The pairing can last however long both devices are in use, as with a fitness tracker and smartphone. Or it can be temporary, a way of setting a device up or authenticating a user. Bluetooth Low Energy is a condensed version of the protocol for devices that have limited computing and power resources.
Fundamentally, both Bluetooth and BLE open up a channel for two devices to communicate—an extremely useful arrangement, but one that also opens the door for dangerous interactions. Without strong cryptographic authentication checks, malicious third parties can use Bluetooth and BLE to connect to a device they shouldn’t have access to, or trick targets into thinking their rogue device is a trusted one.
“The standard often describes a topic in a scattered way,” says Syed Rafiul Hussain, a security engineering researcher at Purdue University. “And it often leaves the complex interactions of the protocol to the manufacturers, which is another source of vulnerability.”
Ken Kolderup, vice president of marketing at the Bluetooth SIG, says that the group is very aware of the challenge and importance of training developers to get a handle on Bluetooth’s massive scope. He says the documentation is so extensive because the protocol doesn’t only define a radio frequency layer for Bluetooth, but also has components at every layer of tech, from hardware up through applications, to guarantee interoperability between Bluetooth devices.
“Bluetooth isn’t just wireless audio streaming anymore. There’s low power data transfer, mesh network; it’s a very broadened scope,” Kolderup adds. “But security is obviously very important. The standard offers operational modes for everything from no security all the way up to 128 AES encryption or ‘secure connections only’ mode. We’ve put into it as much as the community has asked for.”
A recent example, though, helps illustrate how the process can break down. In February, researchers from the security firm McAfee reported Bluetooth Low Energy misconfiguration issues in a smart padlock known as BoxLock. The device had been designed to use a Bluetooth Low Energy configuration called “Just Works Mode,” which lets devices pair without any passwords or other cryptographic protections. As a result, McAfee researchers could connect to any lock, analyze the device’s BLE commands, and discern which gave the unlock order. Further, BoxLock had configured this command to be in read-write mode, so once the attackers knew what to target, they could initiate an unlock. BoxLock has since patched the vulnerabilities.
BoxLock ran into two common Bluetooth issues. It deployed a relatively insecure version of it for a device—a lock—that demands heightened security. And it made life easier for hackers by leaving Bluetooth traffic out in the open.
“The problem is that BoxLock used a very insecure implementation of BLE,” says Steve Povolny, head of advanced threat research at McAfee. “I wouldn’t say that it’s an insecure protocol by any means. Part of this is the fact that Bluetooth has not been as comprehensively studied by the security community as some things, and it’s not as clear to vendors and manufacturers what the potential flaws are.”
Bluetooth has certainly been investigated to a degree, but researchers say that the lack of intense scrutiny historically stems again from just how involved it is to even read the standard, much less understand how it works and all the possible implementations. On the plus side, this has created a sort of security by obscurity, in which attackers have found it easier to develop attacks against other protocols and systems rather than taking the time to work out how to mess with Bluetooth.
“I couldn’t possibly give an informed opinion on the true security of Bluetooth, and I strongly suspect that the protocol designers couldn’t either,” says Matthew Green, a cryptographer at Johns Hopkins University. “That’s because all of the details are buried in hundreds of pages of unreadable specifications. Many device manufacturers have engineered around this by designing their own security as a kind of ‘add on’ layer that they use over Bluetooth. This is probably wise, given what a mess the protocol itself has been.”
But in recent years, the Bluetooth standstill has begun to erode. After high-profile vulnerabilities like BlueBorne, researchers are increasingly focused on raising awareness about Bluetooth implementation and configuration issues. And attackers are starting to consider Bluetooth as a real option for launching attacks. On Monday, for example, the security firm Kaspersky Lab published findings about a Korean-speaking threat actor with potential state ties that has built a Bluetooth scanner into its Windows malware, seemingly to scan for potentially exposed Bluetooth devices.
Locking it down
The Bluetooth SIG says it is considering a next generation of resources for developers, including the possibility of creating a security audit tool that coders can use to check their Bluetooth implementations. And the SIG’s Kolderup says that the consortium encourages scrutiny of the specification and input about potential vulnerabilities and how to improve its overall security. The SIG is also working to do a better job publicizing existing resources on secure Bluetooth implementation, like the National Institute of Standards and Technology’s guide.
“More and more devices are becoming interconnected, and that all of a sudden brings a whole other set of challenges that you need to be aware of when you’re creating a product,” he says. “We encourage people to use the max level of security your product can support. We encourage you to lock it down.”
Researchers emphasize that the risks of Bluetooth security—and potential rewards for malicious hackers—are only growing as Bluetooth spreads from being used largely in consumer settings, like smart home devices and wearables, to being adopted more and more by enterprises and governments for large-scale deployment in corporate offices, hospitals, and industrial control environments.
“Bluetooth is being used for smart keys, for sensitive encryption and authentication,” Armis’ Seri says. “and also just anything from connected medical devices to wireless infrastructure. All kinds of stuff in business environments where this is a way in and it isn’t monitored. It isn’t secured.”
Researchers say that more tools and training resources from the Bluetooth SIG would go a long way toward making Bluetooth implementation more manageable. In the meantime, whenever you’re not using Bluetooth? Just turn it off.