Bill Saltzstein: ‘Sweyntooth’ Demystified

For those of you who have Bluetooth devices in your hospitals and in your daily life (probably all of you), you probably were quite interested by a recent FDA communication regarding the “Sweyntooth” vulnerability. Now that you are aware and perhaps concerned, this blog post will help you evaluate the risk and relative concern that is appropriate for this issue.

The issue was first announced publicly in a paper, Unleashing Mayhem over Bluetooth Low Energy. While the title is somewhat hyperbolic as well as containing one perhaps irresponsible statement (that Bluetooth may become obsolete), the issues are real and the technical content is good.

A couple of quick points:

  • Sweyntooth pertains exclusively to Bluetooth Low Energy (BLE) wireless technology. While that version makes up a large portion of new products, there are still a huge number of Bluetooth classic devices shipping and installed base including almost all audio devices. These devices are not affected.
  • Sweyntooth is caused by a flawed implementation of the software/firmware. It does not result from a fundamental Bluetooth protocol issue or a hardware issue. Basically, many of the implementations failed to ensure that values being transmitted were in bounds (not “illegal values”), so unexpected values “mess up” the software. How that “mess up” presents is a function of the software implementation and position of the values in the protocol.
  • At least one company, not mentioned in the paper, had properly implemented and tested their software for many years. Even though one of their development kits was used to create this issue, their released and approved software that is used in all of its customers’ devices has been immune for all of their products since their first releases. They have a large number of customers in the medical device industry.
  • Almost all of the other Bluetooth suppliers either have fixes for this issue as a software/firmware patch or upgrade. While many products are software upgradeable, not all are set up to be field upgradeable.
  • It is too late for most devices, but it is always a good idea to review devices during the purchasing process to make sure they have appropriate Bluetooth listing. This listing will allow you to track and see what Bluetooth software and chipsets are used in their products, allowing you to quickly verify your risk when issues like this arise. If you didn’t do this, you are in the majority who now have a fairly low-cost lesson about ensuring devices have a Bluetooth listing.

What Does It Take to Make It Happen?

This isn’t something any casual user can do. Below is an outline of what it takes to exploit this vulnerability:

  1. The attacker needs to be within Bluetooth radio range. Note that with good antennas and chipset this can be over 100 feet (line of sight) and less if there are walls between. Most designers work hard to maximize this range, so it isn’t necessarily the case that the attacker and the device are within sight of each other.
  2. The attacker needs experience and development tools provided by the chip suppliers. It doesn’t appear that the Sweyntooth can be implemented using an iOS or Android or any standard computing device since it involves very serious hacking in the lowest level of the Bluetooth low energy protocol, and that level isn’t exposed to programmers in those environments. Although the development tools are widely available and inexpensive, the knowledge and skill to implement these attacks is quite specialized and the software involved is quite tricky. Still, the paper shows how it can be accomplished, effectively giving attackers an overview. While we haven’t seen this “in the wild,” it doesn’t mean that it won’t be.
  3. The attacker would need to identify and target one BLE device. Depending on what/how the device “advertises,” it may be difficult to identify a particular device to target. There is also no way to tell which of the Bluetooth suppliers’ device is used, so little way to know if it will work (or what it will do). Still, a brute force trial/error could be used to mess with devices by a malicious hacker.

What Are The Risks?

While it is fairly unlikely, it is possible for someone who wants to be a malicious attacker to exploit this vulnerability. For Swyentooth, the issues fall into the three major categories, shown below. This by no means a complete hazard analysis, but should provide enough information to understand and assess the risk for your particular devices and circumstances.

Crash. This denial-of-service (DoS) attack is the highest likelihood, since it exists for the greatest number of suppliers (but not necessarily for the greatest number of devices). Most likely this results in a reset of the device or communication subsystem. No data is extracted or injected into the device, but the communication over Bluetooth would be disrupted and might require re-pairing. If well designed, the product will reset by itself and the only loss will be a momentary lapse in its functionality. If poorly implemented, the device itself could lock up requiring a manual power reset.

Deadlock. This is most likely as a result of the previous attack and poorly implemented recovery by the supplier’s firmware stack or device software. This is the case that requires a manual reset (usually battery or power removal to restart). Again, no data is extracted or injected.

Security bypass. This is considered the most unlikely. In the paper and subsequent testing by others, only one supplier has been identified with this exposure. For what is worth, their market penetration (particularly in medical devices) is among the lowest.

If the device maker has only used Bluetooth encryption and authentication, it is possible for the attacker to read and write characteristics (data) from the device. Many devices (the Fitbit is a good example) use additional data protection of their own.

The cybersecurity risk here depends primarily on whether the device has Personal Health Information or if it has critical settings that can be changed over the BLE connection. This needs to be evaluated on a device-by-device basis, but in general most diagnostic wireless sensors to not have or exchange this data. Most devices with critical settings implement additional security/encryption measures separate from those provided by BLE. The device manufacturer must provide this information to assist in the analysis of risk.

What’s the Bottom Line, and What Should Be Done?

I’ve got to leave that up to you to evaluate in your situation. What I can say is that it is unlikely and relatively low risk. This isn’t going to happen casually, and from a strict cybersecurity standpoint the most probable event would be a denial of service that might require a reset of the device. However, the risk for your institution depends strongly on the device.

First check with your medical device supplier(s). Find out if a software update or product exchange to updated devices are available. If they are unaware of this vulnerability, consider changing suppliers and/or ensuring your contracts have clauses in the area of responding to security vulnerabilities.

If you want to dig deeper, you can look for your device on the Bluetooth website and navigate to understand which Bluetooth supplier was used. Then you’re left to understand what data is on the device and what that risk is. The challenge is (as usual) that this is a difficult and time-consuming task even with all the information at hand. Furthermore, this doesn’t provide a security patch for the medical device if a security issue is confirmed.

So, you’re unfortunately left to have the discussion with the medical device supplier. The good news here is that this issue has been pretty widely discussed among the Bluetooth community and medical device suppliers should be able to get you this information relatively quickly, as well as to update you on their plans for upgrades to eliminate this issue entirely. That will put you in the position of making a well-informed decision on whether to stop using the device or find another supplier.

Bill Saltzstein is a consultant with Code Blue Communications, Inc., and a member of the Wireless Strategy Task Force, a former committee of AAMI.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s