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
- Cypress Semiconductor
- Dialog Semiconductor
- 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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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).
- 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:
- “SweynTooth” website: https://asset-group.github.io/disclosures/sweyntooth/
- “SweynTooth” research paper: https://asset-group.github.io/disclosures/sweyntooth/sweyntooth.pdf
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.