The third installment of the Bluetooth vulnerabilities focuses on denial of service and code execution attacks in BrakTooth
In this third article, the recently published BrakTooth family of vulnerabilities, which mainly affects the Link Manager Protocol, is explained. As a closure, conclusions are drawn for this series of articles on Bluetooth attacks.
1. BrakTooth: Causing Havoc on Bluetooth Link Manager
BrakTooth is the name given to a family of vulnerabilities published by the ASSET Research Group from the Singapore University of Technology and Design (SUTD). The original research was published on August 31, 2021 and the last update was on November 8, 2021, when the proof of concept was published.
The family comprises a total of 16 vulnerabilities and 6 anomalous behaviour which affect the implementation of the Bluetooth Classic (BR/EDR) stack in 13 widely used SoCs (System on Chip) from 11 providers. Most of the vulnerabilities are of the Denial of Service type (DoS) and one of them is an Arbitrary Code Execution (ACE), and all of them can be exploited without pairing or authenticating to the device. 25 CVEs have already been assigned and 2 more are pending from Intel.
The scenario is the same for all of the attacks: the ESP-WROVER-KIT from Espressif Systems (1) with a custom firmware is used connected to a PC (2), from where the attacks are executed, via serial port.
The vulnerabilities, marked from V1 to V16 are classified depending on the impact on the device: crashes and deadlocks. Crashes trigger buffer or heap overflows segmentation faults and other types of fatal errors.
Deadlocks, on the other hand, lead the device to a state in which Bluetooth functionalities are not available. This can be managed by disabling the page scan process, in which a slave device waits for a master device to connect, or by completely disabling Bluetooth by means of an arbitrary code execution.
V1 vulnerability (Feature Pages Execution) is the most relevant of the research, as it exposes an arbitrary code execution in the ESP32 SoC from Espressif Systems, widely used by IoT and wearable devices.
A lack of out-of-bounds check on the Bluetooth library of de SoC when receiving a LMP_feature_response_ext package allows an attacker to overwrite data past the Extended Features Table, to which the data from the package are intended. More precisely, the Extended Features field marks the offset to where data is written, while the Features Page field contains the data to be written.
The research group has discovered that at offset 0x62 there is a table of callback functions that will eventually be called during the operation of the device.
Therefore, an attacker that knows the available functions and their positions on the memory could force a call to any of those functions by overwriting the callback and, for example, erase the NVRAM user data (nvs_flash_erase function), disable Wi-Fi functionality (disable_wifi_agc function) or disable Bluetooth (esp_bt_controller_disable function).
If the attacker knows the memory addresses to functions controlling actuators attached to the GPIO, this vulnerability also allows controlling those devices.
Also, overwriting data on the memory can lead to a firmware crash.
Some DoS vulnerabilities
As an example of the DoS vulnerabilities found in this publication, V15 and V16 are presented, which affect the Intel AX200 and Qualcomm WCN3990 SoCs, found in laptops and smartphones.
V15 (Invalid Timing Accuracy) is produced by a failure to free resources when receiving a modified LMP_timing_cc_response packet, which allows an attacker to exhaust the device resources.
The attack requires sending the malformed packet and reconnecting to the device with a random Bluetooth address repeatedly until the firmware starts becoming unstable and crashes, in the case of WCN3990, or disconnects previously connected devices, in the case of AX200.
V16 (Paging Scan Disable), on the other hand, allows an attacker to disable the page scan process of the slave device by sending a malformed LMP_timing_acc_request and reconnecting with the same address in a loop. By disabling page scan, the device is not able to accept incoming connections until the user reboots the device to reestablish the functionality.
Other devices, such as the Xiaomi MDZ-36-DB loudspeaker, the JBL TUNE500BT headphones, the XY-WRBT module and other have been found to be vulnerable to crashes and deadlocks by sending oversized packets (V5, LMP Auto Rate Overflow), by sending truncated packets (V8, Truncated LMP Accepted), by initiating out-of-order procedures (V9, Invalid Setup Complete) and by flooding the device with packets (V4, Feature Response Flooding).
Current state and PoC
Together with the publishing of the research, a schedule for the publication of the proof of concept was released, setting november 8, 2021 as the deadline. Since that date, the PoC is available from the Matheus Garbelini github repository, part of the research group.
To this date, and with the PoC published, 5 of the companies with products affected by the vulnerabilities have released a patch for every vulnerable device. Five of them have only released part of the patches or are in the process of releasing them.
In addition, oOne of them, Texas Instruments, hasn’t released any patch production plan, although they have confirmed they have been able to reproduce the problems. Other three companies, Samsung, Mediatek and Airoha, have contacted the researchers, as the have products affected by the vulnerabilities, and they have already released the corresponding patches.
For more information on the subject, the original research post, together with the paper and the PoC, is available on the webpage of the ASSET Research Group.
Conclusions and implications of the attacks
The table below summarizes the expected outcome of each of the attacks written in the serie of articles.
|Listening to communications (eavesdropping).
|Hijacking of the communications channel. Man-in-the-middle.
|Arbitrary code execution and denial of service
While it’s true that the Bluetooth attacks presented are real and are currently in force, implementing them is complicated because in many cases it requires deep control over the Bluetooth stack.
In fact, many of the PoCs analyzed have modified parts of the kernel in order to demonstrate the viability of the attacks. On the other hand, the Bluetooth working group (Bluetooth SIG) has been patching most of the vulnerabilities with the new versions of Bluetooth.
Leaving aside the feasibility of the attacks and by way of conclusion, let’s analyze the real impact and implications of the attacks. Regarding attacks that achieve a man-in-the-middle (BIAS, BLURtooth), the implications can be very serious depending on the type of device being breached.
For example, if a Bluetooth keyboard is attacked, credentials of different services could be retrieved, representing a very high security breach. If, on the other hand, a wireless headset is breached, privileged information from a telephone conversation could be obtained. As a third example, if a smartwatch is breached, all communications exchanged between the cell phone and the watch could be accessed (unless they are encrypted and subsequently decrypted on the watch from the application layer).
Regarding KNOB, BLESA and BLURtooth the implications are a bit different (and perhaps less critical depending on the use case). In the case of KNOB, forcing the entropy to 1B allows reconstructing communications in a way analogous to MitM but without interacting with the device. However, KNOB requires a delay to decrypt the key, which is not necessary in the other attacks.
As for BLESA, by spoofing attributes, a device can be forced to perform certain actions or disconnect from the system. For example, the battery level of a system can be spoofed so that the device shuts down or stops communicating to reduce power consumption.
Regarding BLURtooth, in addition to the above mentioned MitM, this attack hijacks the communications channel, which can be very useful to render a device unusable for a certain period of time.
As for Braktooth, in addition to the devices studied, it is estimated that vulnerable SoCs are used by more than 1,400 devices that could suffer the same problems, although aspects such as product design could mitigate them, depending on how they make use of the SoC’s functionalities.
It should also be noted that some of the devices only allow a single simultaneous connection, which would prevent the execution of an attack while another device is connected. On the other hand, despite the release of some of the patches, it is up to the end-product manufacturers to apply them, so it is to be expected to find still vulnerable devices on the market.
Most of the Braktooth vulnerabilities produce a denial of service, which can be exploited by an attacker to, while disabling a legitimate device, impersonate it with a fake one and communicate with the master device. In addition, the V1 vulnerability (Feature Pages Execution) can have unintended consequences, beyond disabling functionality or corrupting memory, due to arbitrary code execution.
Finally, it is important to remember that Bluetooth is a short-range technology, so to perform this type of attack it is necessary to be close to the victim or to compromise a Bluetooth-enabled device close to the system to be breached.
Proximity is a good mechanism for industrial or domestic environments, but we should not be overconfident; we must be very careful about how we use Bluetooth (in what situations we use it, what data is exchanged, whether the data is sensitive, etc.) to avoid any future surprises.
● ASSET Research Group, Singapore University of Technology and Design, BRAKTOOTH: Causing Havoc on Bluetooth Link Manager”, https://asset-group.github.io/disclosures/braktooth/
This article is part of a series of articles about Bluetooth attacks
- Introduction to Bluetooth attacks
- Bluetooth KNOB and BLURtooth, second installment of Bluetooth cyber-attacks
- Attacks to the Bluetooth Link Manager Protocol with BrakTooth