7 ms·
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 t
by jwtorres 7y ago
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. "
- benpbenp 7y agoThat 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)
- jwtorres 7y agoFor 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.
- Tuna-Fish 7y agoYou are not thinking like an attacker. 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.
- jwtorres 7y agoThere 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.
- jsjohnst 7y ago> packet counters will prevent you from using the same packet in the wrong slot. 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.
- timerol 7y agoThe 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.
- jwtorres 7y agoQuoting 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."
- ajross 7y agoThat'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.
- jwtorres 7y agoNot sure I understand what you mean.
- ajross 7y agoIf 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.
- jwtorres 7y agoAgree 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?).
- throwamay1241 7y agoAnd 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...