BrakTooth is a family of new security vulnerabilities in commercial, closed-source Bluetooth Classic stacks that range from denial of service (DoS) via firmware crashes and deadlocks to arbitrary code execution (ACE) in certain IoT devices.
A team from Singapore has discovered 16 new security vulnerabilities after evaluating 13 Bluetooth devices from 11 vendors, but after browsing through the list of certified Bluetooth devices with impacted processors, they estimate it could impact 1400 devices.
We can see the list of BrakTooth-impacted SoCs include some familiar names like Intel AX200 (found in many laptops and computers through M.2 cards), Espressif Systems ESP32, Texas Instruments CC2564C, Qualcomm CSR8811/CSR8510, Bluetrum AB32VG1 board (based on AB5301A SoC) which I’ve just reviewed, and more…
The good news is that most vendors have either already submitted a patch or working on it.
Espressif, Infineon (previously Cypress), and Bluetrum already have released patchsets for their firmware. It’s really important to update the ESP32 firmware as they were the only vendor subject to arbitrary code execution (ACE). Harman International and Silbas are still shown as pending since the status is unknown.
Qualcomm will work on a fix for WCN3990/8, but not CSR8811/CSR8510, while Texas Instruments will only work on resolving the issues for CC2564C if customers request it as explained below:
The vendor Texas Instruments has successfully replicated the security issue, however, at this stage has no plan for producing a patch. In particular, according to the Texas Instruments PSIRT team, they will consider producing a patch only if demanded by customers.
Our team approached Qualcomm to inquire whether a patch would be available for the affected devices. We were informed that they are working on a fix for WCN3990/8 and that the security issue reported in Qualcomm CSR8811A08 has been fixed since 2011 only for ROM Versions A12 and beyond. However, new products in 2021 are still being listed to use CSR8811A08, which has no plan to be fixed. Moreover, a patch for the issue on CSR8510A10 …. is not possible … due to the lack of ROM patch space.
You may find the full details about the vulnerabilities listed above in the research paper.
A silver lining of those vulnerabilities is that we’ve got a new tool to play with the ESP32 Bluetooth Classic Sniffer. Developed by Matheus Garbelini for bug bounty for three of the BrakTooth vulnerabilities on ESP32, the open-source utility does not interact with the Bluetooth network like passive sniffers, but as an active sniffer, it connects itself to the remote BT device (BR/EDR target) and allows testing the BT protocol down to the Baseband layer while guided by a BT host stack such as blue-kitchen. The ESP32 Bluetooth Classic Sniffer can work on inexpensive boards like ESP32-DOIT or ESP32-DevKitC.
You can see how BrakTooth vulnerabilities can be exploited with a denial-of-service attach using a Bluetooth headset as a test device.
The BrakTooth PoC Tool is available to researchers, Bluetooth semiconductor, module, and OEM vendors only until October 30, 2021, after which it will be made public.
Via ThreatPost and thanks to Zoobab for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
OK vendors are providing fixes, but bluetooth is deployed in a number of places which will never receive updates, or at least not quickly. I’m particularly thinking about cars, which receive updates less than once a year for example. There could be some fun to have there if the BT stack manages to crash the gadget computer inside.
Could this crash a self driving device, that has Bluetooth scenario or crash personal robot.
The infotainment part is normally isolated from the safety-critical systems. So I don’t think it can happen.
Not gonna rule it out but if it’s well engineered the two systems will be completely separate. Crashing an infotainment system shouldn’t stop your brakes working.
Some cars are indeed susceptible to the security vulnerability, and so are planes. From the paper:
Ah excellent! Most likely the trouble to expect is functions like pairing a phone or opening the car by proximity detection that will stop working, maybe only for a while after a watchdog reboots it. Or the internal panel stopping to respond to users’ requests.
Note that the notion of separation is always a bit complicated. Some cars like mine only let you control the air conditioner from the touch panel (it’s a real pity), so you could end up with something blowing cold or hot depending on the last setting before it hung. You can also imagine a device turning the radio on at maximum volume while someone drives. It’s not directly related to accessing the brakes but I’m pretty sure it could have very similar effects when the driver is under total stress trying to figure how to turn that off or where to stop! And the list of such jokes can be long, very long…
Remember the ESP32 bluetooth and wifi stacks are proprietary and closed source, no way to inspect what’s on there, and probably full of bugs.