Bluetooth bugs – researchers find 10 “Sweyntooth” security holes – Naked Security

A trio of researchers from Singapore just published a paper detailing a number of security holes they discovered in Bluetooth chips from several different vendors.

The good news is that they disclosed the holes responsibly back in 2019 and waited 90 days – a sort-of industry standard period popularised by Google’s Project Zero team – before releasing the paper.

The bad news is that not all of the affected devices have received patches yet, and even for chips where the vendor has provided new firmware, it’s hard to be sure:

  • Which products out in the market use those chips.
  • Which products that could have been patched have actually received updates.
  • Which products might be affected but don’t support patching at all.

The researchers name seven different Bluetooth chip manufacturers as having buggy chips, though they insist that their list is “By no means […] exhaustive in terms of being affected.”

We assume they’re saying that out of a sense of fairness to the vendors they did name, which just happen to be the major Bluetooth chip makers whose chips appeared in the products they tried.

In other words, they’re not claiming that they tested a long list of chips and found all the other vendors to be safer, or suggesting that by avoiding the named vendors you’ll immediately be more secure.

The researchers also say that they were quickly able to find about 480 different products using the affected Bluetooth chips they’d identified, including fitness trackers, digital locks, remotely controllable plugs and more.

This family of bugs has been dubbed Sweyntooth. (The -W- should be pronounced as a -V- in English.) We’re usually a bit cynical about BWAINs – bugs with an impressive name, as we call them – that go in for dedicated websites, logos and so on for PR purposes. But we did smile at this name – Bluetooth itself is named after Harald Bluetooth, a Danish ruler from the 10th century. Harald was deposed and driven into exile by his own son, Sweyn Forkbeard. Incidentally, Sweyn was the first Danish king of England, and the father of Cnut, who famously proved to his unbelieving followers that he was not omnipotent by showing them that there were forces that even a king could not control, no matter how hard he tried. (Cnut used the tide to prove his point.)

How bad is it?

Fortunately, most of the Sweyntooth bugs aren’t too serious, and all of them require the attacker to be within Bluetooth Low Energy (BLE) range.

Nine of the ten bugs can so far only be exploited to force an affected device either to reboot or to hang; only one can potentially be abused by crooks to access your device without needing you to let them pair with it first.

Because it’s the most serious, we’ll start with the pairing bypass bug, dubbed CVE-2019-19194 and denoted in the researchers’ paper as 6.10 because it’s explained in the tenth section of part 6 in the document.

(Only one vendor’s Bluetooth chip was found vulnerable to this attack – if you are worried, please check the paper for suggestions on what sort of products under which brand names might be affected.)

According to the researchers, the firmware in the affected chip fails to handle the Bluetooth pairing process properly.

In theory, an app that wants to connect to a device is supposed to go through pairing first.

Typically, this can’t be completed without the owner of the device taking a voluntary step, such as pressing a button or acknowledging a prompt, so that you can’t easily pair with a device without some sort of consent.

During the pairing process, a cryptographic dance is done by both sides to agree on a 16-byte LTK, short for “long-term key”.

Each side remembers the LTK associated with the other device, and with that LTK they can connect securely in future.

But to avoid using the LTK itself on every future occasion they connect, they use an SK, short for “session key”, computed from the LTK.

Different every time

To ensure that the SK is different every time, the two devices connecting first agree on 16 random bytes called the “session key diversifier”, or SKD.

It doesn’t matter if an eavesdropper gets the SKD, because it’s converted to the session key independently at each end, using the algorithm:

       SK = aesencrypt(SKD,LTK)   /* Encrypt the 16-byte SKD with the */
                                  /* 16-byte LTK using the AES cipher */

So, to get the right SK, you need to know not only the random data, which can be considered public, but also the LTK, which you can only acquire privately during the original by-consent pairing process.

No pairing, no LTK; no LTK, no session key; no session key, no connection.

But the researchers found they could trick the buggy chip firmware into short-circuiting the pairing process.

They sent a request to start pairing, and waited for the other end to say, “Go ahead”.

But then they skipped straight to making a session connection, without pairing at all, and without getting an LTK.

The other end ought to say, “No! I don’t know you and I don’t have an LTK for you, so go away until you have completed the pairing process.”

Instead, the buggy firmware went ahead with the connection process anyway and calculated the session key like this:

       SK = aesencrypt(SKD,'0000...0000')   /* Encrypt the 16-byte SKD with  */
                                            /* with 16 bytes' worth of zeros */

In other words, by simply pretending to pair but never actually doing so, you effectively “autopair” with a known LTK consisting of all zeros.

Because you “know” the LTK, you can calculate SK, and with SK, you can complete your connection without ever going through the pairing process.

National Cyber Security Consulting App







National Cyber Security Radio (Podcast) is now available for Alexa.  If you don't have an Alexa device, you can download the Alexa App for free for Google and Apple devices.