Bluetooth is used in everything from speakers to implanted pacemakers, which means that Bluetooth-related vulnerabilities can affect a dizzying array of devices. In the latest instance, a newly discovered round of 12 Bluetooth bugs potentially exposes more than 480 devices to attack, including fitness trackers, smart locks, and dozens of medical tools and implants.
Researchers from Singapore University of Technology and Design began developing techniques for analyzing Wi-Fi security in January 2019, and later realized they could apply those same methods to assess Bluetooth as well. By September they had found their first bug in certain implementations of Bluetooth Low Energy, the version of the protocol designed for devices with limited resources and power. Within weeks, they had found 11 more.
Collectively dubbed “SweynTooth,” the flaws exist not in BLE itself, but in the BLE software development kits that come with seven “system on a chip” products—microchips that integrate all of a computer’s components in one place. IoT manufacturers often turn to off-the-shelf SoCs to develop new products quickly. That also means, though, that SoC implementation flaws can propagate across a wide variety of devices.
The SweynTooth bugs can’t be exploited over the internet, but a hacker within radio range could launch attacks to crash targeted devices entirely, disable their BLE connection until a restart, or in some cases even bypass BLE’s secure pairing mode to take them over. In addition to all manner of smart home and enterprise devices, the list includes pacemakers, blood glucose monitors, and more.
As problematic as the vulnerabilities could be in smart home devices or office equipment, the stakes are clearly higher in the medical context. The researchers did not develop proof of concept attacks against any of the potentially vulnerable medical devices, but the relevant SoCs contain bugs that could be used to crash the communication functions or the whole device. Manufacturers will need to individually test each of their products that rely on a vulnerable SoC to determine which attacks would be feasible in practice and what patches are necessary. And the researchers note that it’s important for manufacturers to consider how an attacker could chain the SweynTooth vulnerabilities with other possible remote access attacks to cause even greater harm.
Any device that wants to advertise Bluetooth as a feature and use the Bluetooth logo goes through a certification process to ensure interoperability across devices. In this case, though, the SoC manufacturers missed some basic security red flags.
“We were quite surprised to find these kinds of really bad issues in prominent vendors,” says Sudipta Chattopadhyay, an embedded systems researcher who oversaw the work. “We developed a system that found these bugs automatically. With a little bit more security testing they could have found it as well.”
The Bluetooth Special Interest Group, which oversees development of the Bluetooth and BLE standards, did not a return a request from WIRED for comment about the findings. Bluetooth and BLE implementation issues are common, though, partly because the Bluetooth and BLE standards are massive and complex.
“Some of the vendors we contacted originally the engineers said, ‘well, the reason you’re getting these issues is that you’re putting in values that are not expected, not within the specification,” Chattopadhyay says. “But you can’t only be testing for a benign environment. We’re talking about an attacker here. He doesn’t care about what’s expected.”
The researchers notified seven SoC makers about the vulnerabilities. Texas Instruments, NXP, Cypress, and Telink Semiconductor have all released patches already. Dialog Semiconductors has released updates for one of its SoC models, but has more coming for other models in a few weeks. STMicroelectronics recently confirmed the researchers’ findings but has not developed patches yet, and Microchip does not currently seem to have patches in the works. Even when the SoCs release updates to their BLE software development kits to plug the holes, though, the challenge is that each individual manufacturer that uses any of the seven affected SoCs still needs to take those patches, adapt them to their particular products, and convince customers to install them.
