
Key Negotiation of Bluetooth Attack - Daviey
https://knobattack.com/
======
hannob
What is even more bananas than the mere existence of this attack is the
statement of the bluetooth standardization group:
[https://www.bluetooth.com/security/statement-key-
negotiation...](https://www.bluetooth.com/security/statement-key-negotiation-
of-bluetooth/)

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".

~~~
codesushi42
_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_.

[http://cs-exhibitions.uni-klu.ac.at/index.php?id=263](http://cs-
exhibitions.uni-klu.ac.at/index.php?id=263)

~~~
peteey
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.

~~~
codesushi42
Huh? You simply capture the packets and crack offline.

------
geerlingguy
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.

[1] [https://www.bluetooth.com/security/statement-key-
negotiation...](https://www.bluetooth.com/security/statement-key-negotiation-
of-bluetooth/)

~~~
sp332
According to
[https://www.kb.cert.org/vuls/id/918987/](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.

~~~
grenoire
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.

~~~
sp332
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.

~~~
shawnz
Perhaps there are devices which don't really know how to "negotiate" so much
as just announce what they support using the negotiation protocol

~~~
roblabla
It still shouldn't matter unless they only support horribly insecure entropy
(< 7).

------
ayakura
Direct link to research paper:
[https://www.usenix.org/system/files/sec19-antonioli.pdf](https://www.usenix.org/system/files/sec19-antonioli.pdf)

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

~~~
ryanisnan
_but at least the attacker would need to be within range of broadcast_

So anyone who lives in a small footprint high-rise or spends ample time on a
coffee shop. Yikes!

edit: format

------
stuaxo
This naming is very unfortunate, but hilarious to any Brits.

~~~
weinzierl
Sorry for my ignorance. Can you explain the reference?

~~~
throwaway_391
From the article 'Key Negotiation of Bluetooth'.

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://dirtycow.ninja),
[https://www.zazzle.com/collections/white_theme-1195879626504...](https://www.zazzle.com/collections/white_theme-119587962650451153)
.

------
lost_name
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.

~~~
robbyt
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.

~~~
tuvan
Is people trying to hack the attendees a common occurrence at Defcon?

~~~
zaeirrka
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

~~~
ckwalsh
DefCon sets up its own wifi networks, it doesn't use the hotel's wifi

------
miohtama
Obvious attack target: Bluetooth keyboards for keylogging.

~~~
koolba
Obvious solution: never use wireless input devices.

Has the added benefit of never having to deal with charging batteries or
charging.

~~~
xnyan
Obvious solution, don't use anything that emits electromagnetic radiation:
[https://en.m.wikipedia.org/wiki/Van_Eck_phreaking](https://en.m.wikipedia.org/wiki/Van_Eck_phreaking)

~~~
wincy
Well, time to go back to typing everything on a typewriter.

~~~
vardump
Your data will leak regardless because of typewriter keystroke acoustics [0].
So you better have a soundproof room for that purpose.

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](https://arxiv.org/abs/1609.09359)

[1]: [https://spqr.eecs.umich.edu/papers/Kwong-HDDphone-IEEE-
SP-20...](https://spqr.eecs.umich.edu/papers/Kwong-HDDphone-IEEE-SP-2019.pdf)

~~~
loeg
[https://www.youtube.com/watch?v=DJdT7vsJtxw](https://www.youtube.com/watch?v=DJdT7vsJtxw)

------
gruez
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.

~~~
jwtorres
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
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)

~~~
jwtorres
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.

~~~
Tuna-Fish
You 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
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.

~~~
jsjohnst
> 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.

------
filleokus
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.

~~~
spzb
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.

~~~
capitol_
I presume that you could pull it of with a SDR.

------
mintplant
In case anyone else is wondering: I believe this doesn't affect Bluetooth LE
Secure connections, though the authors don't state that explicitly.

~~~
SwaraLink
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.

~~~
mintplant
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.

------
driverdan
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.

------
peter_retief
Are there any known similar vulnerabilities for OpenThread? I suspect Thread
would be more secure and probably a better choice for meshed networks

------
ktpsns
That especially means: don't use a Bluetooth keyboard. Never.

------
hdasika
probably need to check the update release notes if there is any mention about
fixing this on the devices.

------
wtdata
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?

~~~
ktpsns
That sounds as a funny side project. Hijacking Bluetooth speakers.

------
chromaton
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.

~~~
Fogest
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.

