About two weeks ago (February 11, 2020), a group of Singaporean researchers released a group of vulnerabilities discovered in quite a few BLE vendor SDKs. They named the group of vulnerabilities “SweynTooth“. Here’s their explanation:

The insight behind the name SweynTooth arrives from Sweyn Forkbeard, the son of King Harald Bluetooth (after whom the Bluetooth Technology was originally named). Sweyn revolted against Harald Bluetooth and this forced King Harald to his exile. The exile lead to the death of King Harald shortly. We envision that if SweynTooth style vulnerabilities are not appropriately handled by BLE vendors, then the technology can become a breeding ground for attackers. This may, in turn, lead the Bluetooth technology to be obsolete.

The SweynTooth logo captures a variation of the original Bluetooth logo written in the Runic alphabet. From the Runic alphabet, the “S” of Sweyn and “B” of Bluetooth are combined to design the logo. Moreover, the “S” in the SweynTooth logo visually captures that the arm of “H” is broken in the Bluetooth logo.

Source: https://asset-group.github.io/disclosures/sweyntooth/sweyntooth.pdf

The statement “This may, in turn, lead the Bluetooth technology to be obsolete.” seems a bit too extreme. While this is a group of serious vulnerabilities, it by no means poses a threat to Bluetooth technology itself, but rather may affect adoption and trust of some of the vendors suffering from the vulnerabilities.

The vulnerabilities are specifically in vendor SDKs, and not in the Bluetooth specification itself. However, the researchers do suggest that the BLE certification process, so that’s something to keep in mind when testing your BLE application/product.

The researchers state that the isolation between the Host and Controller defined by the HCI layer adds complexity to the testing of a BLE stack, and is likely the reason for inadequate security testing of BLE stack implementations.

This also means that as BLE developers we need to test our products thoroughly for security vulnerabilities and not rely exclusively on security testing performed by vendors.

Which BLE chipset vendors are affected?

So, which vendors are affected by the vulnerabilities covered in the research paper?

SoCs from seven vendors are listed in the research paper:

  • Texas Instruments
  • NXP
  • Cypress Semiconductor
  • Dialog Semiconductor
  • Microchip
  • STMicroelectronics
  • Telink Semiconductor

UPDATE (Feb 25, 2020): Texas Instruments has already issued a public disclosure regarding these vulnerabilities. They also informed me that “TI has closed on the CVE and notified its customers and has already, or is currently in the process, of providing updated SDKs that will address each CVE that affects TI”.
You can find out more information here: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/882244

Keep in mind that only certain SoCs provided by these vendors and specific SDK versions are affected. Here’s a list of all the affected SoCs, the associated SDK versions, and which SDKs were patched to address the vulnerabilities:

Almost all the vendors have already published patches to address the issues disclosed. However, this still means:

  • The manufacturers have to provide these patches in firmware update releases to their end-customers.
  • Devices that incorporate the affected chipsets need to update their devices with the appropriate patch.
  • It is recommended that device manufacturers perform regression testing and ensure that the security vulnerabilities have been addressed and fixed in the final implementation in their end-product.

The researchers describe one of the sources of the vulnerabilities as “Concrete flaws in the BLE stack certification process” and recommends that vendors and implementers should do their own testing outside of the required certification testing. IMO, this is always sound advice, and not just in the case of discovery of zero-day vulnerabilities such as the ones listed in the paper.

What are the different categories of “SweynTooth” vulnerabilities?

The researchers categorize the vulnerabilities into three types:

  1. Crash: this happens primarily due to a buffer overflow on the target device caused by a remote device over BLE. One example is a buffer overflow caused by the reception of a “malicious” or even invalid BLE packet. If the target device handles the crash by resetting/rebooting, then this would cause temporary interruption to the operation of the device and may potentially cause loss of important data that was not saved in time before the crash.
    This is the least critical of the vulnerability categories and does not require manual interaction from the end-user for recovery.
  2. Deadlock: this occurs due to improper synchronization between the application level and the BLE stack. This causes the application to get stuck in a state that out-of-sync from the BLE stack preventing it from resuming normal operation and causing a “deadlock” situation. Crashes such as those caused by category #1 above but not handled correctly by the firmware have the potential to lead to a deadlock.
    This requires interaction from the end-user to manually restart the device.
  3. Security bypass: this type of vulnerability allows malicious parties to bypass the LE Secure Connections pairing mode allowing them to read/write to BLE characteristics that require security permissions by design.
    This is the most critical of the categories!

Products in the market affected by “SweynTooth”

According to the paper, by doing a Bluetooth Listing search, they found that around 480 product listings use the affected SoCs. The vulnerabilities are, however, implementation-dependent which means that not all these products are affected.

Here’s a list of some of the products tested by the researchers and verified to be affected by at least one of the vulnerabilities:

As you can see, this is just a sampling of affected products, and there are probably many others out there. Also, since the vulnerabilities are in the SDKs of the SoCs mentioned, there will be a wide variety of products affected ranging from minimally critical (such as a key finder tag) to highly critical (such as a medical device)!

In terms of how these vulnerabilities affect the products, it widely varies depending on which vulnerability exists in the SoC used and how the application layer handles certain error cases.

For example, the researchers found that CubiTag (a personal belonging tracker which incorporates a vulnerable TI CC2640R2 SDK) can be forced to crash and go into deadlock mode. The device then will then stop advertising and can not be discovered by the companion mobile app, requiring the user to manually restart it, which requires opening the device with a screwdriver and re-inserting its battery.

Here’s a graph that shows the total number of product listings using the affected SoCs (as of February 8, 2020) listed by SoC:

I’m not a BLE developer, so why should I care?

Think about it. Even if you’re not a BLE developer or manufacturer, there’s some likelihood that you may personally be using a BLE product that is affected by one or more of these vulnerabilities.

So, what should you do? What you can do in reality may be limited, but depending on the criticality of the device in question, this investigation may be worth taking the time to do:

  1. First, think about any BLE connected devices that you use in your daily life. For example, any device that you can directly connect to from your smartphone will likely utilize BLE for its connectivity to the smartphone. Wi-Fi may be implemented instead, but if it’s a device that runs on batteries, it’s most likely a BLE device.
  2. Look up the device online and find out more about its manufacturer. Look for information about how to contact the support team. Reach out to support and mention the “SweynTooth” vulnerabilities and that you need to know whether the device in question is affected by them.
    If the device in question is one of those listed in the paper, then you already know that it is affected, and you can refer the support team to the paper and mention that their product is listed there.
  3. Depending on what you find out from step #2, if the device is vulnerable then request more information on the timeline of when these issues will be addressed.
  4. If the device is affected and the manufacturer has addressed the security issues, you should request more information on the firmware version that includes the fixes. Also, request information on steps you need to take to make sure that your device has the patch(es) applied (including the methodology for updating the device’s firmware).
  5. Finally, spread the word and make your friends and family aware of these critical vulnerabilities!

These steps are generic and apply to any case where vulnerabilities are discovered in IoT devices, not just BLE. Unfortunately, some device manufacturers may be very slow in addressing these issues (depending on the application), and some may even not be aware of these security vulnerabilities!

The best we can do, as end-users, is spread the word and make others aware (including device manufacturers!).

Where do I get more technical information and details?

The “SweynTooth” research paper goes into each of the vulnerability categories and specifics in a lot more detail than in this blog post. If you’d like to learn more then check out the following links:

Take your BLE knowledge to the next level

If you’re interested in staying up-to-date on the latest developments in BLE including newly-discovered security vulnerabilities, how they affect you as a BLE developer, and what actions you need to take to address them, then check out the Bluetooth Developer Academy.

By joining the Bluetooth Developer Academy, you will get access to a growing library of courses and tutorials.

Here’s what one Academy member has to say:

If you’re developing a BLE project, you need two things, a good BLE sniffer and the Bluetooth Developer Academy. I am very happy to be part of this community and look forward to what comes next.

– Christopher Gates, Principal System Security Architect – Velentium

The current courses include:

  • The Basics of Bluetooth Low Energy
  • Analysis of BLE events using a BLE sniffer
  • Long-range mode (Coded PHY) using Bluetooth 5.0
  • Developing nRF52 applications using Visual Studio Code
  • Over the Air Device Firmware Update (OTA DFU) – nRF52 use case
  • Getting Started with Zephyr (including adding custom GATT Services and Characteristics)
  • The Developer’s Guide to what’s new in Bluetooth 5.2
  • SweynTooth: A Summary for BLE Developers
  • Introduction to BLE Security
  • Getting Started with BlueZ development
  • Introduction to BLE Development for iOS
  • …and more courses added each month!

For a full list of courses included, check out the Courses Library here:

Bluetooth Developer Academy Courses Library

The Academy also features a thriving community of Bluetooth experts, developers, and innovators. You’ll get to connect and interact with other experts in the Bluetooth space, learn from others’ experience and knowledge, and share yours.

Also included in the Academy is access to private support from me personally.

In the community, you will find:

  • Discussions around new features such as long-range mode (Bluetooth 5.0) and direction-finding (Bluetooth 5.1).
  • Discussions around the capabilities of different BLE sniffers.
  • Comparisons of BLE support and restrictions in iOS and Android.
  • Various technical questions and answers to these questions.
  • Listing of Bluetooth-related job openings.
  • And many more discussions!

Learn More About the Bluetooth Developer Academy

8 Comments

  1. Avatar Darren Beckwith on March 3, 2020 at

    Nordic released their final update on Sweyntooth vulnerabilities in their SoftDevices here https://devzone.nordicsemi.com/f/nordic-q-a/57990/is-the-sweyntooth-vulnerabilities-addressed-in-nrf-products/

    Good news
    “The investigation is now finished.

    Nordic has determined:
    – nRF51 SoftDevices are NOT affected by these attacks (S110, S120, S130 all versions)
    – nRF52 SoftDevices are NOT affected by these attacks (S112, S113, S132, S140 all versions)”

    • Mohammad Afaneh Mohammad Afaneh on March 1, 2020 at

      Awesome! Thanks for sharing, Darren.

  2. Avatar Christopher Gates on February 27, 2020 at

    Nordic responded that they are not vulnerable nRF51 and nRF52, all versions of the SoftDevices. But what about Zephyr??
    As for utilization in a medical device, Dialog is a popular choice, due to its low current draw, so yeah, you could see this in a single MCU implanted medical device.

  3. Avatar Julian Higginson on February 24, 2020 at

    Thanks for the heads up!

    Considering what I imagined could have been when I first started reading this, I’m finding this report to mostly be good news, and surprised there’s not that much to worry about from such a comprehensive analysis of so many chip makers SDKs.

    Sure, the 6.10 vulnerability with some Telink gear is actually terrible, and I really hope all manufacturers effected can get a fix out to all their devices soon. but apart from that I’d say outside of any kind of life critical system (where I’d not want a BLE SOC to be doing the life critical work, anyway!) most of these vulnerabilities are annoying, at worst.

    Really, its just another great reminder to *always* run watchdogs in your production code and always try to handle every situation that the SDK can throw at you.

    Also, It’s kinda cute how security research reports seem to need their own logos and branding these days.. we are truly living in a marketing run world.

    • Mohammad Afaneh Mohammad Afaneh on February 25, 2020 at

      Julian, great insight! Indeed, most of the vulnerabilities are simply annoying at best (worst).

  4. Avatar Thor on February 24, 2020 at

    Did they list any chips that they tested that were not vulnerable (eg, I didn’t see anything from Nordic, nor did I see the BlueNRG-1 chip… I think they didn’t test the BlueNRG-1 chip, but am wondering if they tested from Nordic or SiLabs)?

    • Mohammad Afaneh Mohammad Afaneh on February 25, 2020 at

      They did not list Nordic or SiLabs at all, which makes me think that the vulnerabilities they discovered do not affect nRF chipsets (I would be surprised if they did not test them at all).

      In terms of testing the BlueNRG-1 chipset, I would think they tested it as well since they tested the newer version (BlueNRG-2).

Leave a Comment