I recently wrote a diary on the SANS Internet Storm Center about the impacts, implications and next steps for BrakTooth.
Please click here to read the full diary entry, and this diary entry has been briefly mentioned in the SANS Daily Network Security Podcast (Stormcast) for Wednesday, September 1st, 2021 over here. Alternatively, the full diary is reposted in full below.
In a previous diary entry, I had written about the increasing trend of Bluetooth vulnerabilities being reported in the recent years [1]. Today, the Automated Systems SEcuriTy (ASSET) Research Group from the Singapore University of Technology and Design (SUTD) revealed the BrakTooth family of vulnerabilities in commercial Bluetooth (BT) Classic stacks for various System-on-Chips (SoC) [2]. In this diary, I will be giving a brief background on BrakTooth, highlight affected products and also discuss next steps affected users/vendors could consider.
The name BrakTooth was coined from the Norwegian word “Brak” (translates to crash in English), and “Tooth” (a hat-tip to the Bluetooth protocol). These vulnerabilities were mainly caused due to non-compliance to Bluetooth Core Specifications and their respective communication protocol layers. 13 Bluetooth devices (Bluetooth Classic versions ranging from Bluetooth 3.0 + HS to Bluetooth 5.2) from 11 different vendors were assessed. 16 new vulnerabilities were discovered, and 20 Common Vulnerability Exposures (CVE) Identifiers (IDs) were assigned (along with another 4 CVE IDs pending assignment from Intel and Qualcomm). On top of the vulnerabilities that were discovered, some devices also displayed anomalous behaviour that deviates from the Bluetooth Core Specifications [3]. The summary of vulnerabilities, anomalies, devices and patch status are outlined in Table 1 below.
SoC/Module Vendor | Bluetooth SoC | Firmware/ SDK Version | CVE/Anomaly (A) | Patch Status |
---|---|---|---|---|
Espressif Systems | ESP32 | esp-idf-4.4 | CVE-2021-28135 CVE-2021-28136 CVE-2021-28139 A1: Accepts lower Link Manager Protocol (LMP) length | Available |
Infineon (Cypress) | CYW20735B1 | WICED SDK 2.9.0 | CVE-2021-34145 CVE-2021-34146 CVE-2021-34147 CVE-2021-34148 A2: Accepts higher LMP length A6: Ignore encryption stop | Available* |
Bluetrum Technology | AB5301A | Unspecified (LMP Subver. 3) | CVE-2021-34147 CVE-2021-34148 A1: Accepts lower LMP length A2: Accepts higher LMP length | Available* |
Intel | AX200 | Linux – ibt-12-16.ddc Windows – 22.40.0 | 2 CVE IDs pending A1: Accepts lower LMP length A2: Accepts higher LMP length A5: Invalid response | Patch in progress |
Qualcomm | WCN3990 | crbtfw21.tlv, patch 0x0002 | 1 CVE ID pending A1: Accepts lower LMP length A2: Accepts higher LMP length A4: Ignore Role Switch Reject | Patch in progress |
Zhuhai Jieli Technology | AC6366C | fw-AC63_BT_SDK 0.9.0 | CVE-2021-34143 CVE-2021-34144 A1: Accepts lower LMP length A2: Accepts higher LMP length | Patch in progress |
Zhuhai Jieli Technology | AC6925C | Unspecified (LMP Subver. 12576) | CVE-2021-31611 CVE-2021-31613 A1: Accepts lower LMP length A2: Accepts higher LMP length | Investigation in progress |
Zhuhai Jieli Technology | AC6905X | Unspecified (LMP Subver. 12576) | CVE-2021-31611 CVE-2021-31612 CVE-2021-31613 A1: Accepts lower LMP length A2: Accepts higher LMP length | Investigation in progress |
Actions Technology | ATS281X | Unspecified (LMP Subver. 5200) | CVE-2021-31717 CVE-2021-31785 CVE-2021-31786 A1: Accepts lower LMP length A2: Accepts higher LMP length | Investigation in progress |
Harman International | JX25X | Unspecified (LMP Subver. 5063) | CVE-2021-28155 A1: Accepts lower LMP length A2: Accepts higher LMP length | Pending |
Silabs | WT32i | iWRAP 6.3.0 build 1149 | CVE-2021-31609 A1: Accepts lower LMP length A2: Accepts higher LMP length | Pending |
Qualcomm | CSR8811/ CSR8510 | v9.1.12.14 | 1 CVE ID pending A1: Accepts lower LMP length A2: Accepts higher LMP length | No fix |
Texas Instruments | CC2564C | cc256xc_bt_sp_v1.4 | CVE-2021-34149 A1: Accepts lower LMP length A2: Accepts higher LMP length | No fix |
The various patch statuses are explained as follows:
Available: The vendor has replicated the vulnerability and a patch is available.
Patch in progress: The vendor has successfully replicated the vulnerability and a patch will be available soon.
Investigation in progress: The vendor is currently investigating the security issue and is being assisted by the researchers.
Pending: The vendor hardly communicated with the researchers and the status of their investigation is unclear at best.
No fix: The vendor has successfully replicated the issue, but there is no plan to release a patch.
Utilizing the BrakTooth family of vulnerabilities, the researchers could achieve arbitrary code execution on smart home products that used ESP32 SoC, cause Denial-of-Service (DoS) attacks on laptops and smartphones, and finally induce audio products to freeze up. A preliminary examination of products listed in the Bluetooth listing indicated that over 1400 product listings were affected [4]. However, as the Bluetooth stack is likely to be shared amongst many products, there is a high possibility that many other Bluetooth products are affected by BrakTooth. As of now, the Proof-of-Concept (PoC) code is only made available to any Bluetooth semiconductor or module vendors and embargoed until the end of October 2021 (before the code is made available for the public).
How should everyone handle the usage of Bluetooth devices, especially if the devices used are affected by BrakTooth? As a start, one might want to be more aware of one’s surroundings when using Bluetooth. Since BrakTooth is based on the Bluetooth Classic protocol, an adversary would have to be in the radio range of the target to execute the attacks. As such, secured facilities should have a lower risk as compared to public areas (assuming no insiders within secured facilities). Having said that, this could also be a difficult task if an adversary manages to conceal the equipment well, though that would affect the range of Bluetooth connectivity.
For end users, it is highly recommended to check if the Bluetooth products currently being used are in Table 1. If the patches are available (or if you can contact the vendor for the patch), please apply them immediately. If the patch is in progress or if the vendor is still investigating, perhaps it would be worthwhile to watch out for any anomalous behaviour (such as the inability to reconnect to a Bluetooth connection or audio devices not responding) when Bluetooth is being in use. Turn it off (if possible) when Bluetooth is not actively in use to reduce your attack surface. Keep a close lookout for corresponding patches and update the devices when possible. If the devices used SoC where no fixes are available, it is recommended to stop using them (unless one is prepared to accept the risk of BrakTooth vulnerabilities being exploited). Finally, keep in mind that BrakTooth is not limited only to the devices tested by the researchers as the attacks apply to any Bluetooth Classic implementation. Checking just the Bluetooth chipset is not enough to confirm the existence of BrakTooth. To concretely verify that a Bluetooth device is affected by BrakTooth, users could consider obtaining the BrakTooth PoC (when it is released to public on October 31st) and test the device with it.
Organizations, governments and critical infrastructure may be using affected components as well. If stakeholders are uncertain about the extent of Bluetooth usage and the associated devices, an audit of the devices/components in use should be carried out. Following that, a risk assessment should also be conducted to assess the risk posed by BrakTooth to users or day-to-day operations. Keeping in mind the attack vector, an interim measure could very well be enhanced physical security while affected devices are patched/replaced.
Finally, for Bluetooth SoC or module vendors, it is highly recommended to contact the researchers for the PoC to test products for BrakTooth vulnerabilities [5] now. Although vendors may not be legally obliged to always keep their products secure and updated, increased adoption of Bluetooth for work and health and a rising interest in Bluetooth vulnerability research underscores the importance of such issues for consideration. In addition, as customers and users get increasingly discerning for the need of their privacy and data to be protected, it is in the vendors’ best interests to ensure product security for continued presence in the market.
The full technical details of BrakTooth can be found over here [2], and also available as a downloadable PDF file [6].
References:
[1] https://isc.sans.edu/diary/27460
[2] https://www.braktooth.com
[3] https://www.bluetooth.com/specifications/bluetooth-core-specification
[4] https://launchstudio.bluetooth.com/Listings/Search
[5] https://poc.braktooth.com
[6] https://asset-group.github.io/disclosures/braktooth/braktooth.pdf
One thought