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".
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".
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.
Bluetooth physically requires some time to pass between communication. 2^56 seconds is 2 billion years. I doubt you can try more than 100 times a second.
7 octets is the minimum set by the SIG, not a mandatory length to support for all devices. For devices that transfer sensitive information (phones, keyboards, etc.), a larger key length can be enforced. This would be enforced by the application written by the product designer, not the BT chipset vendor nor the BT SIG.
My guess is they're trying to support legacy hardware that might not have the crunching power to do 128/256 with the tight timing constraints on channel hopping?
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.
No, they are not proposing 56 bit key lengths. I understand the key is always 128 bits. They are saying that the entropy should be minimum of 56 bits. In fact the entropy is always 128 bits but this negotiation reduces it because 'some' governments didn't want other governments to have stronger encryption. See [1] page 1050, figure 2.
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.
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.
What isn't clear is if you have a device like a laptop, phone, or tablet, and it _is_ updated post-late-2018... will that protect you from the vulnerability even if you're using an older Bluetooth device (e.g. keyboard, headset, etc.) that isn't going to ever get an update?
[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.
According to https://www.kb.cert.org/vuls/id/918987/ either side can propose a new amount of entropy and the other side can accept or reject it. An updated controller firmware on either side could reject the connection.
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.
A rejected connection means a bricked device, on the other hand. Sure, newer drivers could protect me against attacks, but simultaneously prevent me from using my BT headphones.
Hopefully this would only be an issue during an attack. Not sure why your headphones would be legitimately negotiating encryption but then only supporting <7 bytes of entropy.
That's not difficult then, order one of these https://www.raspberrypi.org/products/raspberry-pi-zero-w/ , get a battery pack and fix to some unsuspecting CEO or other juicy corporate targets vehicle. Saves trailing the vehicles and thus raising suspicion.
How many car manufacturers do you think update their vehicles Bluetooth stack?
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
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).
Kind of a tangent, but I was traveling in Portugal last year, and one day as I was headed to a train station I felt my phone buzz. I picked it up and it had a failed Bluetooth file transfer. In the settings, the device name had changed from the default to what looked like a base64 string, if I remember correctly. Unfortunately I didn't think to screenshot anything.
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.
A similar thing happened to my phone while I was at Defcon several years ago. After that I put my phone on airplane mode. Then when I got home, I reset all my passwords, and wiped the phone.
Can be, the Wall of Sheep mentioned here is from the traffic on the DefCon network. General practice is to make sure at least your bluetooth and wifi are turned off. Realistically, no one is going to use a 0-day to hack into your personal phone.
That's for unencrypted credentials captured going across the wire by the ops team. That's to highlight insecure comms not hack people.
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.
No its more of an urban legend. I'm sure there's some hijinks going on but I doubt the hotels would tolerate any kind of large scale malicious activity especially with all the unrelated people staying at the hotel
I concur. While I bring a "burner" phone and laptop, it's more so I have a scratch system I can play / experiement on than any real fear that a sensibly configured device is going to get pwned. I used my real phone and laptop during Defcon 27 last week, too. I do have bluetooth off, and I made sure I had no filesharing enabled, and the latest patches, etc.)
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.
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.
Never trusted wireless keyboards always uses cable connected devices. Although those could still be tapped by a usb sniffer but it’s more safe than wireless.
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.
Sadly, many BLE keyboards on the market today are still not using the LE Secure Connections feature during pairing. The LE legacy pairing algorithm does not use Elliptic Curve Diffie-Hellman Key Exchange, and is easily susceptible to having the encryption cracked via passive eavesdropping.
I don't know of any because I haven't tested too many, but LE Secure Connections has been around since the Bluetooth 4.2 spec, which was adopted in 2014. The feature is supported by most single-mode BLE chipsets / stacks that have been released since then. I'd be surprised if there were none that supported it, though I don't know for sure.
How easy is this attack to pull off? Doesn't bluetooth use spread spectrum? If so, you'd need to somehow predict the frequencies that will be used, which is non-trivial because it's generated from the link key.
I don’t think the price point is quite that low yet, is it? I have a couple I bought for $250 that can do that, but I’m not aware of a readily available radio that can receive 80MHz+ at that price point. If you can point me to it, I’ll probably buy a couple immediately.
I own most of the commonly available SDRs, and I’m also not aware of any that can do that wide of a range at $100 price point. Like you, I’d be happy to be proven wrong (albeit my wallet won’t be).
This is not a trivial attack. Within the short key negotiation phase, the attacker must simultaneously prevent the two devices from hearing each other, and be transmitting in their place at the exact frequency hop and interval.
"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. "
That quote is from the Bluetooth standardisation group’s response. They are clearly trying to downplay the seriousness with their choice of language here. “All within a narrow time window” is, generally speaking, something computers are capable of handling. I have no idea from that statement how easy/tricky this attack is. Also, is it really necessary to block transmissions, or can the attacker just “get lucky” and have his transmissions received first? (Honest question, I have no idea)
For BT, it's not a matter of transmitting first (for Wifi it would be), but rather transmitting in the exact time slot that the two devices are expecting each other to transmit. This is tightly timed in BT devices (tens of microseconds)--they are only listening on tiny intervals and only expected to transmit on tiny intervals. It would sound like periodic chirping if you were able to hear it with your ears.
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.
There certainly is a penalty for missing time slots (especially if you're trying to overpower the other transmitter). There are two reasons for this: (1) the victim device will have hit the time slot and the pairing process will move into the next stage and (2) packet counters will prevent you from using the same packet in the wrong slot.
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.
The way you're describing this makes it sound like an extremely difficult process. In some ways, it is. However, every BT device that exists is currently capable of doing this frequency tracking and tight timing. It's merely a matter of starting to transmit slightly earlier and significantly louder than a normal BT transmit after sniffing the start of the connection.
This attack should be possible from any software-defined radio that's capable of sniffing on and forming BT connections.
Quoting my response to Tuna-Fish:
"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."
And if you do manage, it's granting the ability to intercept/modify traffic, right?
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...
That's true for use cases like phones and headsets where the physical device can't reasonably be tampered with. But this sounds like something you could trivially squish on top of an unattended reader device a-la credit card skimmers.
If one side of the communication is a fixed device subject to simple tampering (e.g. "put your phone here for access") then you can MitM the connection is much the same way as was done with ATM skimmers.
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.
Agree that it would be significantly easier if you had physical access either of the devices. However, with physical access there are probably even easier attack vectors (e.g. in the case of a keyboard, why not just capture the key presses directly instead of trying to capture it as it's going over BT?).
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.
I thought the hopping sequence and clock was adopted from the master during the paging process, as the slave joins the network, before the link negotiation process even begins.
Haven't worked my way all through the paper yet. But is it correct that an attacker can perform this attack to something like a keyboard that has been previously paired and everything? What kind of user "interaction" would be required? Will the OS re-pair the device and (possibly) notify the user?
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.
Not a Bluetooth expert and I might have misunderstood the paper but it seemed like it can be done any time two devices initiate a new connection (not when they're paired but anytime they start communicating). AFAIU, it's a firmware level hack so not something you can do with standard Bluetooth functionality. You need to be able to get a custom firmware into the Bluetooth chipset to carry off an attack.
Good question. Can the attacker force an existing paired device to re-negotiate the pairing process, or is this attack only viable against devices that have not yet paired?
I think an attacker can disrupt already existing connections causing them to reconnect but if they try to re-pair then operator interaction would be required.
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)
That is correct. The vulnerability note clearly states that this only impacts "Bluetooth BR/EDR Core v5.1 and earlier". "BR/EDR" is the technical term for Classic Bluetooth; in other words not Bluetooth Low Energy.
The authors state that it impacts BR/EDR, but not exclusively so. If the standards shared enough aspects of their key negotiation protocols, then both could potentially be impacted. After scanning through the paper and the relevant details of the LE Secure pairing process, that does not appear to be the case, fortunately.
Was this known previously or was there another entropy attack? I remember reading about this or a similar attack a while ago but don't remember if the details matched.
Does this mean we will finally be able to easily and quickly, hack that pesky people forcing us all to listen to their Bluetooth speakers (invariably with bad music) on public transports?
Recently there was an update to my Android on my Samsung Galaxy S8 that makes it HARDER to see if Bluetooth is turned on. I like to leave it off whenever I'm not using it to try to reduce the attack surface.
Not sure this is really the same thing. However in my case I like it harder because I use bluetooth multiple times a day with my phone and it's annoying having a persistent icon showing me it's on despite not caring.
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".