I’ve always had a love/hate relationship with Bluetooth. And, to be perfectly honest, it leans a bit more toward the “hate” end of the spectrum. As a consumer using various Bluetooth-enabled devices, I’ve experienced the frustration (shared by many, I’m sure) of flaky and unreliable pairing, mysterious behavior, and general lack of user-friendliness. Much of this is the less-than-optimal design of systems using the standard, but a good chunk of the problem likely lies with Bluetooth itself.
Take a deep breath. Bluetooth has been hacked.
OK, well, the truth is, Bluetooth has been hacked again. This is not BT’s first dance with the dark hats. But, the latest vulnerability – the KNOB attack (Key Negotiation of Bluetooth), identified and demonstrated by a group of researchers at the Singapore University of Technology and Design, the CISPA Helmholtz Center for Information Security, and the University of Oxford – is pretty clearly a flaw in the specification itself, rather than in particular vendors’ implementations. The group conducted KNOB attacks on 24 different devices containing 17 different Bluetooth chips, and found 100% vulnerability to the attack. Chips were made by Apple, Broadcom, Chicony, Intel, and Qualcomm. The vulnerability was shared with manufacturers in November 2018, so there has been a bit of a buffer zone between the discovery of the vulnerability and public disclosure so that manufacturers could work on mitigating the problem.
If you designed a system that uses Bluetooth Basic Rate/Enhanced Data Rate
(BR/EDR) configurations for anything important, and you haven’t yet put a solution in place – ya better get crackin’! If you’re a consumer using a Bluetooth device that hasn’t been updated this year, beware! That sketchy dude in the hoodie sitting across from you in the airport gate laughing his head off may be hip to the fact that you’re rocking out to “Dancing Queen” on your earbuds. If you’re a hacker and are pretty excited by the prospect of punking people’s Bluetooth for fun and profit – there are probably much better ways to make a living that don’t require you to be within 30 feet of the person whose device you are attacking with minimal upside.
The KNOB attack works by spoofing the negotiation process for the entropy of encryption keys. Since not all devices use the same version of the standard, a casual conversation was put into place where the two ends of the connection agree on the number of bytes of entropy they can handle. KNOB steps in, does its best impersonation of one of the nodes, and says, “Hey, I have a great idea! How about we use ONE byte of entropy.” Lacking any common sense, both sides agree to one-byte keys, and then brute forcing the encryption key becomes about as tricky as a game of “how many fingers am I holding up?”
The solution is presumably to patch devices to set a higher minimum for the number of bytes that are acceptable. The Bluetooth SIG is recommending a minimum encryption key length of 7 octets for BR/EDR. That should be plenty to foil KNOB, but it doesn’t help all those of us out there with legacy devices that we haven’t updated, or that the supplier has neglected to patch.
Now, before you get in too much of a tizzy about all this, there is no evidence that the hack has ever been exploited maliciously. In the lab, researchers were able to control the target devices and the environment to show the vulnerability. In the wild, however, a number of things would make such an attack very difficult and unlikely. First, an attacking device would have to be purpose built. Second, it would have to be within wireless range of two vulnerable devices at the exact time they are going through the pairing procedure. (If my experience trying to get two perfectly kosher devices to pair successfully under near-ideal conditions is any indicator, we’re already at “winning the lottery” level of difficulty for the hacker.) Next, the attacking device would need to intercept the public key exchange by blocking each transmission, sending an acknowledgment to the sending device, and then inject the malicious packet to the receiving device within a narrow time window.
“Ahem, excuse me, before you put on those bluetooth headphones, mind if I sit down here between you and your phone for a second – I need to play with this weird contraption I’m carrying around. OK, you can go ahead and listen to your music now.”
Once the one-byte ruse has been perpetrated, the attacking device still has to play a fast round of “guess a number between zero and 255” before it hits pay dirt. If either of the two devices has been updated with a fix, the hack won’t work.
Now, you may be wondering what the real consequences are if a hack DID work (as are we). Certainly there are systems out there that transmit important data over Bluetooth. However, due to the short range required for an attack, the difficulty of carrying out an attack, and the minimal amount of data that could be obtained by succeeding, it’s unclear what the motivation would be. There is certainly lower-hanging fruit for black-hatters to spend their precious time pursuing.
But this leaves us with just one more reason to hate Bluetooth. And that’s too bad, because despite its obvious flaws, Bluetooth is better than any of the other solutions we can name in the same space. To paraphrase Winston Churchill: It’s the worst possible solution – except for all the others.
Wow … how many times have I heard that one “no evidence that the hack has ever been exploited maliciously” when just a few days later the script kiddies are shaking down the public for financial data. Pairing events rare??? So the script just jams the 2.4GHz spectrum for about a minute, till the exisiting BT connections time out, then turns the jammer off knowing a pairing event will follow quickly. Worried about public places … your car on the freeway, with the script kiddie beside you. Or from a drone just outside, with a high gain antenna and amplifier (script kiddies seeking financial gains certainly are not going to care about the FCC EIRP max) pointed through your home/office walls. Not worried about what the expected pairing will expose? Consider that the attacker can take over the connection, and possibly negotiate more than your car entertainment system might expose, or exploit another software attack on the device or network stack.
Say the hackers BT device then negotiates keyboard/mouse emulation, then drives your device remotely.
The attack isn’t about pairing events … it’s about link start up events.
The attack targets the link negotiation process (after pairing) … and the attack doesn’t even require following the pairing process. It just needs to be ready for link negotiation (power up cycle or link restart after a disruption). See http://www.usenix.org/system/files/sec19-antonioli.pdf