Vulnerabilities - SweynTooth is Just the Beginning

Written by Nick Lesniewski-Laas, Director of Electrical Engineering
image description
There are billions of Bluetooth devices out in the world, with billions more sold each year. It seems that all new electronic devices, including many of the medical devices that we at Sunrise Labs design, have Bluetooth connectivity. Because it is so ubiquitous, many of our customers think of Bluetooth as a commodity, a simple component that can be plugged into a design and expected to just work.

Unfortunately, this view of Bluetooth as a commodity leads to many suboptimal implementations. This approach often relies entirely on the plug-and-play tools and libraries provided by the Bluetooth component manufacturers, which are great tools to get up and running quickly but do not address the specific product needs. Bluetooth implementations must be optimized for the product-specific workflow; also, robustness of the Bluetooth interface requires deep systems engineering analysis and knowledge of the inner-workings of Bluetooth.

Recently, a set of BLE vulnerabilities, collectively known as SweynTooth[1], brought attention to some straightforward attack vectors exposed in many of the software stacks provided by the Bluetooth component manufacturers. The SweynTooth attacks affect a broad range of Bluetooth Low Energy devices, including many consumer devices and some medical devices. The publicity around SweynTooth attracted the attention of the FDA, resulting in a press release[2] and a safety communication[3]. The FDA will likely monitor this situation closely.

Most of the SweynTooth attacks are trivial, exploiting simple bounds-checking operations such as when a link layer packet contains more data than is expected. In terms of attack vectors, this is probably just the tip of the iceberg. The manufacturer-supplied software stacks are large, complex, and closed source, so there are likely to be many exploits waiting to be exploited; however, these manufacturer-supplied software stacks are only a small part of the problem. The application code provided by the implementer, the team designing the device itself, is a much bigger problem. Bluetooth stacks unload many aspects of data management to the application layer, often with nuance that is beyond the application developer's understanding of the Bluetooth standard.

Bluetooth is complicated, making it a likely target for more sophisticated attacks in the future. The core standard is over 3000 pages of requirements, suggestions, and exposition[4]. In addition to the core standard, Bluetooth also includes hundreds of pages of test protocols for qualifying devices as Bluetooth compliant; however, the tests are not exhaustive and most of the tests are limited to ‘happy-path’ workflows. The behavior of Bluetooth devices when presented with unexpected situations is often undefined. This puts the burden of safely handling undefined behaviors directly on the shoulders of the stack developers and the application developers. The lesson to learn from SweynTooth is that stack developers, and application developers, need to take this responsibility seriously to avoid introducing gaping security holes in their devices.

SweynTooth, named after the scandinavian king who exiled his father, Harald Bluetooth, leading to Bluetooth’s death, is aptly named. It is a warning that these glaring security holes in Bluetooth implementations may result in a loss of confidence in Bluetooth as a dependable solution for wireless communication. Industry push-back against Bluetooth adoption could ultimately limit the growth of potentially transformative industries, such as medical body area networks.

Sunrise Labs has extensive experience implementing Bluetooth, and many other communications protocols, into a broad range of medical devices, including small wearables, floor-standing chemical processing machines, and even portable life-support devices. Over the next few months, Sunrise will release a series of blog posts addressing some of the challenges to Bluetooth development and identifying some of the common pitfalls that we see.

Read the blog: 'Nordic’s New Bluetooth Security Vulnerability', the next in the “Bluetooth is not a Commodity” Series
__________________________________________________
    [1]    M. E. Garbelini, S. Chattopadhyay, and C. Wang, “Unleashing Mayhem over Bluetooth Low Energy,” ASSET Research Group: SweynTooth, 2020. [Online]. Available: https://asset-group.github.io/disclosures/sweyntooth/
    [2]    “FDA Informs Patients, Providers and Manufacturers About Potential Cybersecurity Vulnerabilities in Certain Medical Devices with Bluetooth Low Energy,” 03-Mar-2020. [Online]. Available: https://www.fda.gov/news-events/press- announcements/fda-informs-patients-providers-and-manufacturers-about-potential-cybersecurity-vulnerabilities
    [3]    “SweynTooth Cybersecurity Vulnerabilities May Affect Certain Medical Devices: FDA Safety Communication,” 03-Mar-2020. [Online]. Available: https://www.fda.gov/medical-devices/safety-communications/sweyntooth-cybersecurity-vulnerabilities-may-affect-certain-medical-devices-fda-safety-communication
    [4]    “At the core of everything Bluetooth,” Core Specifications | Bluetooth® Technology Website, 2020. [Online]. Available: https://www.bluetooth.com/specifications/bluetooth-core-specification/