Key Negotiation of Bluetooth Attack
knobattack.com
knobattack.com
Here's their plan to fix this: "To remedy the vulnerability, the Bluetooth SIG has updated the Bluetooth Core Specification to recommend a minimum encryption key length of 7 octets for BR/EDR connections"
7 octets, aka... 56 bit.
So it looks like this vulnerability is here to stay. They just raise the bar from "trivially breakable" to "you need a bit of cloudcomputing effort to break a connection".
The rumor is that 7 bytes is the shortest maximum key length of any devices currently in circulation.
7 bytes is still laughably bad, ofc.
Op is correct, this is not a solution.
DES also used 56 bit keys. It was crackable by the NSA the moment it was introduced in 1975. And by the 2000s, anyone could crack it.
Even back then, the choice of 56 bits had nothing to do with speed. Chips were more than capable of handling 128 bit keys even in 1975. It's 2019 and we're still proposing 56 bit key lengths? Wow.
I don't know how much difference that makes (I am not an encryption expert), but it is a fact that affects your comparison to DES.
[1] https://www.usenix.org/system/files/sec19-antonioli.pdf edit: citation
No, the article is about KNOB, which allows the attacker to arbitrarily shorten key length. The proposed solution is to have a minimum 56 bit key length, which is still too short.
Either way, still not a good decision.
You don't even need that, you can crack 56 bits on a home machine.
Keep in mind, DES was 56 bits, and it was brute forced in 56 hours in 1997.
[Edit] Found some relevant information from the Bluetooth.com security notice[1]
> For an attack to be successful, an attacking device would need to be within wireless range of two vulnerable Bluetooth devices that were establishing a BR/EDR connection. If one of the devices did not have the vulnerability, then the attack would not be successful.
[1] https://www.bluetooth.com/security/statement-key-negotiation...
Another option mentioned in the paper is for the OS to check the entropy level and close the connection after each renegotiation. I'm not sure if OSes have actually been updated to do that, but it would work for all kinds of devices even without hardware vendor support.
How many car manufacturers do you think update their vehicles Bluetooth stack?
Mr Robot.
Relevant results are on page 1057. It's crazy to think all of the devices tested were vulnerable up to Bluetooth 5.0, but at least the attacker would need to be within range of broadcast, as another user pointed out
So anyone who lives in a small footprint high-rise or spends ample time on a coffee shop. Yikes!
edit: format
Basically, researchers started naming vulnerabilities when they thought they mattered. 'Shellshock' and 'EternalBlue' are both deserving of names, IMO.
Then researchers started naming everything, many of the vulnerabilities had zero real world impact, were almost entirely theoretical (many crypto vulns), or required chaining of other attacks to actually achieve anything.
The KNoB description says 'is vulnerable to packet injection by an unauthenticated, adjacent attacker that could result in information disclosure and/or escalation of privileges.' which is sounds extremely caveated. They haven't demonstrated an actual attack so my guess is they've overplayed the significance of the vulnerability entirely and this grants the ability to PITM traffic (which really isn't a defensible boundary, anyway).
Most decent hackers I know laugh at named vulnerabilities unless their technical impact actually matters. Dirty COW took the piss entirely, https://dirtycow.ninja, https://www.zazzle.com/collections/white_theme-1195879626504... .
The followup attack targets the "Bluetooth Asynchronous Low Latency Subsystem"
The phone was literally only a couple weeks old. Nothing new had been paired. I changed the name back and figured I would look it up later. The failed file transfer was automatically cleared (just a phone thing) and I wasn't able to find information about it.
I've been to about 10 defcons, and I've never had a device pwned that wasn't a spare device I was playing with.
There was an instance where someone used a wifi pineapple 0day to brick pineapples, which are considered script kiddie tools in many circles.
Generally nobody will waste a valuable 0day at defcon to attack a personal device. If you get popped it's probably because you're running known vulnerable software.
I might be misremembering technologies, but I think in BT the incoming connection can directly execute commands on your device without any kind of identification/authorization.
Has the added benefit of never having to deal with charging batteries or charging.
Maybe I should use an Ethernet cable on my iPhone instead of LTE, that should be convenient.
Encrypt your damn comms.
Keep any electronics out of the room that might have a microphone. Like phones, laptops, or running mechanical hard drives [1].
[0]: https://arxiv.org/abs/1609.09359
[1]: https://spqr.eecs.umich.edu/papers/Kwong-HDDphone-IEEE-SP-20...
See: https://www.theverge.com/2019/7/14/20692471/logitech-mouseja...
I use a wired keyboard, but I also use a wireless mouse! I've been careful at DEFCON not to.
The Bluetooth attack seems similar to car keyfob attacks. Block and replay.
A directional antenna could do the Bluetooth attack from distance.
Counter measures to key logging use one time passwords otp. A password strength also depends on password age.
"The attacking device would need to intercept, manipulate, and retransmit key length negotiation messages between the two devices while also blocking transmissions from both, all within a narrow time window. "
Meanwhile, the two BT devices are going to be transmitting in their normal time slots, so you would need to prevent them from being heard by the peer-- otherwise, the combined transmission (of the attacker and original BT device) will look like noise to the receiver and the attack would fail.
The attack is certainly doable, but in a practical setting would be extremely difficult.
The attacker has to hit the precisely correct time slot. However, there is no penalty for hitting the wrong time slots, so the easy solution is to just sync the timeslot boundaries by listening once and then retransmit on every timeslot.
The attacker has to somehow prevent the listener from hearing the original transmission. If the attacker retransmits at a similar power, as BT devices usually do, the combined transmission will look like noise. However, the attacker doesn't need to care about things like FCC rules or BT standards, and can simply transmit at a power few order of magnitudes greater, so that what the receiver hears is pretty much just the attacker.
Trying to overpower the transmission of the BT peer is certainly the technique to take (although I was hoping not to broadcast that publicly in my original post). You will still have a tough time, however, because you're probably trying to overpower the transmission of two collocated devices (e.g. keyboard+computer) while you are 5-50feet away. In many cases you'll probably end up saturating the receiving antenna. It will be largely a trial-and-error technique, but it will work eventually.
Source to back up that claim? I am not an expert, but have enough experience on the topic to feel justified in feeling that’s wrong.
This attack should be possible from any software-defined radio that's capable of sniffing on and forming BT connections.
Or with a little more difficulty, you could pop open a bluetooth keyboard, put a shield over the antenna, and MitM what it says to its already-paired desktop to implement a keylogger.
These aren't remotely accessible vulnerabilities to internet hackers, but they're the kind of thing that has been done by amateurs in the past in other realms.
If so, this won't lead to RCE on a host mobile unless other exploits are used. There's probably some interesting stuff that can be done against shitty IOT-type devices, but they should be assumed vulnerable anyway...
The hopping sequence is determined pesudorandomly (not sequentially) using the link key, so you can't exactly "hop along" once you find the right channel.
https://courses.cs.washington.edu/courses/cse474/18wi/pdfs/l...
This seems really powerful and dangerous. Probably not that many people who uses laptops and BT keyboards, but many of the iPad keyboard covers uses bluetooth.
I think that this attack only works when the encryption is being negotiated, which is usually when the connection is made (you can do it later, or redo it at any time)