Internet of things Security

Internet of medical threats? Exploring Bluetooth Low Energy Vulnerabilities in Medical Devices

Internet of medical threats?  Exploring Bluetooth Low Energy Vulnerabilities in Medical Devices
Written by ga_dahmani
Internet of medical threats?  Exploring Bluetooth Low Energy Vulnerabilities in Medical Devices

The Internet of Things (IoT) has brought with it new applications for connected devices. Manufacturers go beyond headphones and keyboards. One of these new use cases stands out in particular: apps that rely less on streaming and instead periodically stream small amounts of data. This is especially true in sensor applications where a remote peripheral transmits information about its environment, such as a thermostat, security sensor, or medical monitoring device. At the same time, an advancement in the Bluetooth standard is making 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 transmission, and image sharing with other smartphones. , among other things.

While many devices using Bluetooth Classic are battery-powered (at least the peripherals), power was never an issue, as the components were designed to easily recharge and replace the battery. It didn’t matter if your computer mouse’s battery only lasted a few days. You can simply plug in a charging cable or change batteries.

A new standard, Bluetooth Low Energy (BLE), has emerged, supporting lower bandwidth rates, ranging from 125 Kb/s to 2 Mb/s, including a new offline mode in addition to the classic connection-oriented mode . The biggest advance in BLE is its energy-saving ability to power devices for much longer. By default, BLE peripherals sleep until they are ready to transmit data. Combined with lower power usage during transmission at lower data rates, the power consumption of BLE devices is typically only 1-5% of devices using Bluetooth Classic. Its power consumption is in the range of 15 to 20 microamps, which means that a standard button cell 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 headsets and thermostats, but that’s only part of the story. Those same attributes also make BLE ideal for connected medical devices, also known as the Internet of Medical Things (IoMT). A glucose monitor, for example, can use BLE to transmit glucose levels to a smartphone for convenient monitoring. In a hospital environment, inexpensive BLE tags attached to devices can make tracking and locating inventory much easier. Additionally, BLE’s support for a large number of connected peripherals 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 monitoring station, for example. With BLE, you can have all your floor ECGs and other patient monitoring devices transmitting telemetry information to a central location. It’s the same idea behind wearable health-related devices like heart monitors and sports watches, all of which transmit pulse information via BLE.

Dispensing with cables, bulky batteries and allowing communication with smartphones is a big step forward. But as with any innovation, there are unavoidable risks. And in the case of medical devices, these risks don’t just cause inconveniences like decreased audio quality or decreased battery life. When it comes to IoMT, device risks can directly jeopardize patient safety.

Cybersecurity in the Internet of Medical Things

For connected medical devices, cyberattacks are a massive threat to patient safety. For example, an attack against a BLE radio interface can interfere with essential performance of an IoMT device, potentially harming or killing a patient. Multiple vulnerabilities like these have already been discovered in Bluetooth-enabled medical devices, leading to widely publicized disclosures, mandatory mitigations, and device recalls. One of the most striking examples is the SweynTooth vulnerabilities which affected a number of BLE IoMT devices. The impact was so severe that the FDA published a security communication to medical device manufacturers, warning them of the dangers that would be posed if one of the vulnerabilities were triggered, which could crash, deadlock, and freeze devices, or even allow an attacker to bypass their security measures.

The most important lesson from SweynTooth (and similar vulnerabilities) was that it made manufacturers aware of previous vulnerabilities in the supply chain. As worrying as the vulnerabilities were, the medical device manufacturers did not write the flawed code. In fact, they didn’t know they existed. They simply obtained a Bluetooth System on Chip (SoC) from a well-known and trusted electronic component manufacturer and included it in their device. The SoCs delivered the vulnerabilities. There simply wasn’t enough security testing done before the product shipped, putting all the systems they’re embedded in at risk.

Discovery of 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 were so many different manufacturers affected? The problem is that the vulnerabilities were hidden in the protocol stacks, making them incredibly difficult to detect and diagnose. While the security community has developed a number of best practices for discovering application-level vulnerabilities, including common tactics and threat library databases that can be checked against software and application libraries, protocol-level vulnerabilities are much more difficult to identify. In fact, there is only one way to properly test for these types of vulnerabilities: a comprehensive testing mechanism known as protocol fuzzing.

In simple terms, protocol fuzzing involves systematically injecting various errors into a communication exchange to confuse the entity at the other end of a connection and put it in an incorrect state. This can involve fairly simple errors, such as sending multiple copies of a packet, or it can involve more sophisticated protocol corruption. Here are some examples:

  • The flags that indicate the start and end of a connection can be set in a single packet.
  • Fields within a packet may be too large or too small.
  • Fields within a package can be set to invalid values.
  • Packages may be delivered out of order.

In many cases, the “handshake”, which occurs at the beginning of a connection to establish security, encryption, and other communication parameters, is an easy target for exploitation. Since the remote device configures itself based on the settings established during the handshake, especially corrupted packets (or sequences of packets) can cause shutdowns or communication 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 tell the device to report incorrect telemetry data, ignore other commands, violate patient privacy rules by reporting data to an unauthorized system, or even deliver a potentially lethal dose of medication.

Protection from protocol-level vulnerabilities in BLE-enabled IoMT devices

Clearly, this type of vulnerability is a serious concern for medical device manufacturers, as reflected by the FDA’s approach in the US and similar regulatory scrutiny around the world. But what is the best way to protect connected devices? For starters, that 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 tasked with quickly distributing warning communications, mitigation strategies, and remedial firmware updates for affected devices to patients and care providers. And, as noted in the example above, even the best-resourced vendors are not immune from delivering vulnerable chipsets.

However, security is a journey, not a destination. That’s why, at a minimum, device manufacturers should insist on corrective updates from chipset vendors prior to product release. And, at the same time, they must also be tasked with conducting extensive protocol fuzzing evaluations of their devices, while including their validation and verification strategies in FDA premarket authorization submissions.

For connected medical #devices, cyber #attacks are a massive threat to patient safety. As BLE connectivity for #IoMT devices becomes more prevalent, fuzzing protocol validation will become even more critical. #cybersecurity #respectdataclick to tweet

As BLE connectivity for IoMT devices becomes more prevalent, fuzzing protocol validation 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 QA teams with little or no cybersecurity experience. And given how long it can take for a chipset vendor to thoroughly reproduce, diagnose, remediate, and validate vulnerabilities, now is the time to begin the process of testing products in the development pipeline. One need only look at SweynTooth to see that the later a vulnerability is found, the more costly the remediation impact will be.

About the author

ga_dahmani

Leave a Comment