Uncovering Hidden Threats in Bluetooth Low Energy Medical Devices

In this blog, we'll focus on securing BLE medical devices.

Cybersecurity and 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 the essential performance of an IoMT device — which could harm or potentially kill 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 impactful examples is the SweynTooth vulnerabilities which impacted a number of BLE IoMT devices. The impact was so severe that the FDA published a safety communication to medical device manufacturers, warning of the dangers imposed if one of the vulnerabilities were triggered — which could crash, deadlock, and freeze devices, or even enable an attacker to bypass its security safeguards.

The biggest lesson from SweynTooth (and other vulnerabilities like it) was that it made manufacturers aware of upstream vulnerabilities in the supply chain. As concerning the vulnerabilities, medical device manufacturers didn't write the flawed code. In fact, they were unaware they existed. They simply sourced a Bluetooth System on Chip (SoC) from a trusted, well-known electronic component manufacturer and included it in their device. The SoCs delivered the vulnerabilities. There simply wasn't enough security testing performed prior to product shipment, which puts every system they're included at risk.  

Uncovering hidden vulnerabilites 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 impacted? 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 series of best practices for discovering application-level vulnerabilities — including common tactics and databases of threat libraries that can be crossed-checked with application software and libraries — protocol-level vulnerabilities are much harder to pinpoint. In fact, there’s only one way to adequately test for this kind of vulnerability: an exhaustive testing mechanism known as protocol fuzzing.

In layman's 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 into an incorrect state. This can involve relatively simple errors, such as sending multiple copies of a packet, or more sophisticated protocol corruptions. Here are a few examples:  

The flags indicating the beginning and end of a connection can be set in a single packet.  

Fields within a packet can be too large or too small.  

Fields within a packet can be set to invalid values.  

Packets can 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 is configuring itself based on settings established during the handshake, especially corrupted packets (or packet sequences) can cause shutdowns or communication errors, which need to be manually reset.

In a worst-case scenario, an attacker could target the handshake itself, as documented in CVE-2019-19194. Since the handshake establishes security and encryption parameters, an attacker can bypass the controls which would normally restrict certain actions and enable arbitrary control of the system. For some 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 privacy rules by reporting data to an unauthorized system or even administer a potentially lethal medication dose.

Securing protocol-level vulnerabilites in BLE-enabled IoMT devices

Clearly, this type of vulnerability is a serious concern for medical device manufacturers — as reflected by the FDA's focus in the USA and similar regulatory scrutiny worldwide. But what's the best way to protect connected devices? For starters, that means implementing validation and verification strategies to identify vulnerabilities in SoC protocol stacks. Manufacturers need to serve as the last line of defense. After all, they're on the hook to rapidly distribute warning communications, mitigation strategies, and remediation firmware updates for impacted devices to patients and care providers. And, as noted in the above example, even the most well-resourced suppliers aren't immune from delivering vulnerable chipsets.

However, security is a journey, not a destination. That's why, at minimum, device manufacturers must insist on remedial updates from chipset vendors prior to product release. And, at the same time, they must also take it upon themselves to conduct extensive protocol fuzzing assessments of their devices — while including their validation and verification strategies in FDA pre-market clearance submissions. KEYSIGHT can help with this process; while developing our LOT Security Assessment product, which finds both application- and protocol-layer vulnerabilities, we developed a patented intelligent fuzzing algorithm that can dramatically accelerate the protocol fuzzing process. Driven by an intuitive point-and-click UI, it lets even those without extensive security backgrounds discover hidden vulnerabilities.

As BLE connectivity for IoMT devices becomes more prevalent, protocol fuzzing validation will become even more critical in maintaining patient safety and trust in advancing technologies. Fortunately, protocol fuzzing toolkits are becoming more widely available and easier to use — even for quality control teams who have little to no experience in cybersecurity. And given the time it may take for a chipset vendor to thoroughly reproduce, diagnose, remedy, and validate vulnerabilities, the time to start the process of testing products in the development pipeline is now. One need only look to SweynTooth to see that the later a vulnerability is found, the more costly the impact of remediation.