BrakTooth is a collection of flaws affecting commercial Bluetooth stacks on more than 1,400 chipsets used in billions of devices – including smartphones, PCs, toys, internet-of-things (IoT) devices and industrial equipment – that rely on Bluetooth Classic (BT) for communication.
On Thursday, CISA urged manufacturers, vendors and developers to patch or employ workarounds.
The PoC has been made available on the BrakTooth website on GitHub.
As the paper pointed out, all that attackers need to do to pick apart the BrakTooth bugs is an off-the-shelf ESP32 board that can be had for $14.80, (or as low as $4 for an alternative board on AliExpress), custom Link Manager Protocol (LMP) firmware, and a computer to run the PoC tool.
Researchers from the University of Singapore disclosed the initial group of 16 vulnerabilities (now up to 22), collectively dubbed BrakTooth, in a paper published in September. They found the bugs in the closed commercial BT stack used by 1,400+ embedded chip components and detailed a host of attack types they can cause: Mainly denial of service (DoS) via firmware crashes (the term “brak” is actually Norwegian for “crash”). One of the bugs can also lead to arbitrary code execution (ACE).
Since the paper was published, there have been a number of updates, as vendors have scrambled to patch or to figure out whether or not they will in fact patch, and as researchers have uncovered additional vulnerable devices.
(Score: 2) by edIII on Monday November 08 2021, @07:17PM (1 child)
This is why I stopped using Bluetooth years ago. Don't want it on keyboards, mice, speakers, .etc. I have it turned off on my phone at practically all times. I relent *only* when in the car moving because the speakerphone is just too damned useful, but turn it off when I get somewhere. The exploits are too many, the devices with outdated software and few updates, and therefore the level of confidence is about zero. If there was a really high quality speakerphone available for Android phones based on something else, I'm listening. Problem is the built-in one for cars that integrates with the music, car speakers, and steering wheel is also the best audio quality.
Manufacturers have no impetus, via financial negatives or positives, to focus on security first. We see the results.
Other wireless technologies are not immune, but the commercial equipment isn't that bad when combined 802.1x/EAP and RADIUS authentication methods. AFAIK, there is nothing comparable in Bluetooth. Worse is that Bluetooth is also kind of a shit connection. I've lost and had to rebuild far more Bluetooth connections than 2.4ghz wireless.
Bluetooth is just a pile of worthless shit, but it certainly is convenient to use and everywhere isn't it?
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by JoeMerchant on Monday November 08 2021, @07:44PM
Our embedded wireless guy is pretty fresh out of the Navy. I had a debate with him about "roll our own" vs using the Bluetooth stack. While I'm all about the benefits of using established libraries with more functionality built in, more thoroughly tested security, etc. it was obvious 3 years ago when we were making the decision that Bluetooth wasn't / isn't mature enough to avoid issues like in OP. Still, idealism won out (as well as a lust for some particular feature in Bluetooth that was easier than hand coding it to our chipset), and so our product rests on a commercial Bluetooth stack.
Now, every time one of these things gets published, instead of saying "we use a proprietary protocol which was verified and validated internally to fulfill all of our requirements for functionality and security," and fixing whatever bugs we may find on our own schedule and terms, we get to respond to upper management with reports about how our commercial Bluetooth stack is or isn't impacted by the latest bug reports.
Just as a consumer, I find Bluetooth performance to be too spotty for my taste - random dropouts, variable connection times - sometimes quite long, weird glitches... I listen to Bluetooth speakers at my desk maybe 20 hours a week. At that level of testing, I'm noticing glitches that a proprietary protocol might have been able to mask two or three times a week. Our users are only "listening" to the wireless link maybe 3-4 hours a week, but glitches in their audio can potentially have much higher consequences than a little annoyance in a music stream.
🌻🌻 [google.com]