Internet of medical threats? Exploring Bluetooth Low Energy vulnerabilities in medical devices
The Internet of Things (IoT) has brought new applications for connected devices. Manufacturers go beyond headsets and keyboards. One of these new use cases in particular stands out: applications that rely less on continuous streaming and periodically relay small amounts of data instead. This is especially true in sensor applications where a remote device transmits information about its surroundings, such as a thermostat, security sensor, or medical monitoring device. At the same time, an advance in the Bluetooth standard makes these new applications possible.
A brief history of Bluetooth Classic and Bluetooth Low Energy
Bluetooth feels like it’s been around forever. In fact, the original specification has been around since 1998, and the first hands-free headsets hit the market in 1999. Since then, it’s been used to connect everything from computer mice and keyboards to portable speakers and headphones. . Bluetooth Classic, as it is now called, covers a range of 79 channels and can transmit up to 3 Mb/s up to 50 meters, making it useful for data transmission, audio streaming and data sharing. images with other smartphones, among others.
While many devices using Bluetooth Classic are battery-operated (at least peripherals), power has never been an issue, as the components have been designed for easy battery charging and replacement. It doesn’t matter if your computer mouse battery only lasted a few days. You can simply plug in a charging cable or swap the batteries.
A new standard, Bluetooth Low Energy (BLE), has emerged to support lower bandwidth rates, ranging from 125 Kb/s to 2 Mb/s, including a new connectionless mode in addition to the connection-oriented mode of Classic. The biggest advancement of BLE is its power saving capability to power devices much longer. By default, BLE devices sleep until they are ready to transmit data. Combined with low power consumption during transmission at lower data rates, the power consumption of BLE devices is typically only 1-5% of devices using Bluetooth Classic. Their power consumption is in the range of 15 to 20 microamps, which means that a standard coin cell battery can power most BLE devices for years.
Reshaping the Internet of Medical Things
Reasonable data transfer rates coupled with low power consumption make BLE devices attractive for consumer applications, such as headphones and thermostats, but that’s only part of the story. These same attributes also make BLE ideal for connected medical devices, also known as the Internet of Medical Things (IoMT). A glucometer, for example, can use BLE to transmit glucose levels to a smartphone for convenient monitoring. In a hospital setting, inexpensive BLE beacons attached to devices can make it easier to track and locate inventory. Additionally, BLE’s support for a large number of connected devices makes it even more valuable in a clinical or hospital environment, which may involve hundreds (or thousands) of connected medical devices. Think of a nurse’s supervisory position, for example. With BLE, you can have all floor ECGs and other patient monitoring devices transmit telemetry information to a central location. It’s the same idea behind health-related wearables such as heart rate monitors and fitness watches – all of which relay pulse rate information via BLE.
Doing without cables, bulky batteries and allowing communication with a smartphone is a giant step. But as with any innovation, there are inevitable risks. And in the case of medical devices, these risks don’t just cause inconveniences like decreased audio quality or battery life. When it comes to IoMT, device-related risks can directly compromise patient safety.
Cybersecurity in the Internet of Medical Things
For connected medical devices, cyberattacks pose a massive threat to patient safety. For example, an attack on a BLE air interface could interfere with critical performance of an IoMT device, which could injure or potentially kill a patient. Multiple vulnerabilities like these have already been discovered in Bluetooth-enabled medical devices, resulting in widely publicized disclosures, mandatory mitigations, and device recalls. One of the most impactful examples is the SweynTooth vulnerabilities which affected a number of BLE IoMT devices. The impact was so severe that the FDA issued a safety communication to medical device manufacturers, warning of the dangers imposed if any of the vulnerabilities were triggered – which could crash, stall and freeze devices, or even allow an attacker to circumvent its security measures. .
The biggest lesson from SweynTooth (and other similar vulnerabilities) is that it made manufacturers aware of vulnerabilities further up the supply chain. As worrying as the vulnerabilities are, medical device makers did not write the faulty code. In fact, they were unaware of their existence. They simply sourced a Bluetooth system on a chip (SoC) from a trusted and well-known electronics manufacturer and included it in their device. The SoCs delivered the vulnerabilities. There simply wasn’t enough safety testing done before the products were shipped, which puts any systems they’re included on at risk.
Uncover hidden vulnerabilities with protocol fuzzing
The SweynTooth vulnerabilities affected several experienced manufacturers, including Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics, and Telink Semiconductor. How have so many different manufacturers been affected? The problem is that the vulnerabilities were hidden in the protocol stacks, which made them incredibly difficult to detect and diagnose. While the security community has developed a series of best practices for uncovering application-level vulnerabilities, including common tactics and databases of threat libraries that can be cross-referenced with application software and libraries , protocol-level vulnerabilities are much more difficult to identify. In fact, there is only one way to properly test these types of vulnerabilities: an exhaustive testing mechanism called protocol fuzzing.
Simply put, protocol fuzzing is the process of systematically injecting various errors into a communication exchange to confuse the entity on the other end of a connection into an incorrect state. This can involve fairly simple errors, such as sending multiple copies of a packet, or can result in more sophisticated corruptions of a protocol. Here are some examples:
- Flags indicating the start and end of a connection can be set in a single packet.
- Fields in a packet can be too big or too small.
- Fields in a packet can be set to invalid values.
- Packages can be delivered out of order.
In many cases, the “handshake,” which occurs at the start of a connection to establish security, encryption, and other communication parameters, is an easy target to exploit. Since the remote device configures itself according to the parameters established during the handshake, specially corrupted packets (or sequences of packets) can cause communication breaks or errors, which must be manually reset .
In the worst case, an attacker could target the handshake itself, as documented in CVE-2019-19194. Because the handshake establishes security and encryption parameters, an attacker can bypass controls that would normally restrict certain actions and allow arbitrary control of the system. For IoMT devices in particular, this could have obvious and disastrous impacts. An attacker could instruct the device to report incorrect telemetry data, ignore other commands, violate patient confidentiality by reporting data to an unauthorized system, or even administer a dose of potentially lethal drug.
Securing Protocol-Level Vulnerabilities in BLE-Enabled IoMT Devices
Clearly, this type of vulnerability is a serious concern for medical device manufacturers, as evidenced by the attention of the FDA in the United States and similar regulatory scrutiny around the world. But what is the best way to protect connected devices? For starters, this means implementing validation and verification strategies to identify vulnerabilities in SoC protocol stacks. Manufacturers must serve as the last line of defense. After all, they are the ones who must quickly distribute warning communications, mitigation strategies, and remediation firmware updates for affected devices to patients and healthcare providers. And, as shown in the example above, even the most well-resourced vendors are not immune to shipping vulnerable chipsets.
However, security is a journey, not a destination. That’s why, at a minimum, device manufacturers should insist on patching updates from chipset vendors before the product is released. And, at the same time, they must also take it upon themselves to conduct thorough protocol fuzzing evaluations of their devices – while including their validation and verification strategies in pre-market authorization submissions. the FDA.
As BLE connectivity for IoMT devices becomes more widespread, validation of protocol fuzzing will become even more critical to maintaining patient safety and confidence in advanced technologies. Fortunately, protocol fuzzing toolkits are becoming more widely available and easier to use, even for quality control teams with little or no cybersecurity experience. And given how long it can take for a chipset vendor to thoroughly reproduce, diagnose, patch, and validate vulnerabilities, now is the time to start the product testing process in the development pipeline. Just look to SweynTooth to see that the later a vulnerability is discovered, the more costly the impact of the fix.