BrakTooth: Impacts, Implications and Next Steps, (Tue, Aug 31st)

This post was originally published on this site

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.

Table 1: Patch Status, Vulnerabilities and SDK/Firmware Version of Affected Devices (*Contact vendor to acquire patch)
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-34150
CVE-2021-31610

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

———–
Yee Ching Tok, ISC Handler
Personal Site
Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.