SweynTooth: Bluetooth vulnerabilities expose many BLE devices to attacks
There's no rest for the (bluetooth) wearables
A team of security researchers have discovered numerous vulnerabilities in the Bluetooth Low Energy (BLE) implementations of major vendors.
Bluetooth Low Energy is a wireless communication technology (consisting of a set of standardized protocols) designed to reduce battery usage of mobile and IoT devices.
These group of 12 flaws, dubbed SweynTooth, impact several devices, such as smart homes, wearables, tracking systems, but also medical and logistics products as well.
According to the paper [1]:
As of today, SweynTooth vulnerabilities are found in the BLE SDKs sold by major SoC vendors, such as Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics and Telink Semiconductor. By no means, this list of SoC vendors is exhaustive in terms of being affected by SweynTooth. We have followed responsive disclosure during our discovery, which allowed almost all SoC vendors to publicly release their respective patches already. However, a substantial number of IoT products relying on the affected SoCs for BLE connectivity will still need to independently receive patches from their respective vendors, as long as a firmware update mechanism is supported by the vendor.
The team
Vulnerabilities has been discovered by a team of researcher from Singapore University of Technology and Design: Matheus E. Garbelini, Sudipta Chattopadhyay, and Chundong Wang.
Vulerabilities
Researchers classified the SweynTooth vulnerabilities according to their types and their behaviours on the affected device:
- Crash: Vulnerabilities that can remotely crash a device by triggering hard faults, exploiting incorrect code behaviour or memory corruption.
- Deadlock: Vulnerabilities that affect the availability of the BLE connection without causing a hard fault or memory corruption, requiring to manually restart the device in order to re-establish proper BLE communication.
- Security Bypass: The most critical vulnerability, that allows attackers in radio range to bypass the secure pairing mode of BLE and gain arbitrary read or write access to device’s functions.
Below the summary of findings and the affected vendors:
| Type | Vulnerability | Affected Vendors | CVE |
| Crash | Link Layer Length Overflow | Cypress | CVE-2019-16336 (6.1) |
| NXP | CVE-2019-17519 (6.1) | ||
| Truncated L2CAP | Dialog Semiconductors | CVE-2019-17517 (6.3) | |
| Silent Length Overflow | Dialog Semiconductors | CVE-2019-17518 (6.4) | |
| Public Key Crash | Texas Instruments | CVE-2019-17520 (6.6) | |
| Invalid L2CAP Fragment | Microchip | CVE-2019-19195 (6.8) | |
| Key Size Overflow | Telink Semiconductor | CVE-2019-19196 (6.9) | |
| Deadlock | LLID Deadlock | Cypress | CVE-2019-17061 (6.2) |
| NXP | CVE-2019-17060 (6.2) | ||
| Sequential ATT Deadlock | STMicroelectronics | CVE-2019-19192 (6.7) | |
| Invalid Connection Request | Texas Instruments | CVE-2019-19193 (6.5) | |
| Sec. Bypass | Zero LTK Installation | Telink Semiconductor | CVE-2019-19194 (6.10) |
The Proof of Concept
Researcher also released a python PoC [2] that may causes the crash of several IoT and wearable devices like Fitbit, CubiTag, Eve Energy and August Smart Lock:
SweynTooth uses the Nordic nRF52840 Dongle to send raw link layer packets to and from the vulnerable peripheral. It is necessary to flash the driver firmware to the board before starting the Python 2.7 pr.
[...]
You can run the following commands to install the Python dependencies and to flash the firmware:
python -m pip install nrfutil pyserial nrfutil dfu usb-serial -p COM_PORT -pkg nRF52_driver_firmware.zip
After the requirements are installed, you can run an exploit script by executing the following command:
python Telink_key_size_overflow.py COM7 A4:C1:38:D8:AD:A9
The first argument is the serial port name (generally /dev/ttyACM0 on Linux) and the second is the address of the vulnerable BLE device. You can use any BLE scanner or the nRF Connect App to discover such address.
Security patches?
While most of the affected vendors have already released patches, some SoCs did not receive a patch yet, such as Dialog, Microchip and STMicroelectroncs.
Product vendors (who use the affected SoCs), on the other hand, are being independently contacted by each SoC vendor to inform about the security patches. However, we note that some SoCs did not receive a patch from their vendor yet. This is the case for Dialog, Microchip and STMicroelectroncs. We will be updating this section once vendors release the security patches for the affected SoCs.
We urge action from vendors due to the reliance of the BLE IoT market on such unpatched SoCs. For example, August Home Inc and Eve Systems products rely almost entirely on DA14680, which is still unpatched even after a responsive disclosure period of more than 90 days.
During our contact with Dialog, they have confirmed that a patch is planned in the next SDK release for the affected SoCs. We were also informed that the reason of such delay is due to the affected code being stored in the read-only-memory (ROM) of such SoCs. Thus, the respective vulnerable BLE stack cannot be modified and it requires complex workarounds for publicly releasing a patch.