Bluetooth-Related Flaws Threaten Dozens of Medical Devices
Credit to Author: Lily Hay Newman| Date: Thu, 20 Feb 2020 12:00:00 +0000
Hundreds of smart devices—including pacemakers—are exposed thanks to a series of vulnerabilities in the Bluetooth Low Energy protocol.
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.
"We were quite surprised to find these kinds of really bad issues."
Sudipta Chattopadhyay, Singapore University of Technology and Design
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.
"Imagine the time it takes for a single pacemaker to get an update and the kind of process to update it in the field," says Ben Seri, who has found similar chip-level BLE implementation issues and is vice president of research at the embedded device security firm Armis. "It’s not something that happens quickly or easily. For all of these affected devices, they either won't be patched at all or will require huge effort to be updated."
The researchers emphasize that even more products than the hundreds they've already identified are likely vulnerable, because it's difficult to know where manufacturers have used impacted SoCs. Now that the SweynTooth findings are public, it's possible that more vulnerable SoCs will come to light as well as the Singapore University of Technology and Design group and other researchers around the world continue investigating.
"The FDA is assessing the SweynTooth Bluetooth Low Energy chipset vulnerabilities," an agency spokesperson told WIRED. "The FDA continues to assess new information concerning emergent cybersecurity vulnerabilities and will keep the public informed if significant new information becomes available."
The vulnerabilities are difficult to exploit in practice, and expose different devices to different degrees. But they underscore just how critical chip-level security is, especially when those chips are broadly outsourced—not to mention how long it takes to fix these problems when they arise in IoT.