Bluetooth flaw (a single character unlocks encryption) forces Bluetooth specification change

[Arlen George Holder]

Bluetooth apparently had a hole that a bus could drive through...
"A serious Bluetooth security flaw has been acknowledged by Bluetooth SIG,
the official body in charge of standards for the wireless communications
technology.

It is sufficiently dangerous that the official Bluetooth specification has
been changed.

The vulnerability would make it far easier for an attacker to brute-force a
pairing with your devicesĄK"

o Key Negotiation of Bluetooth
<https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth/>

o Bluetooth vulnerability could expose device data to hackers
<https://www.theverge.com/2019/8/16/20808597/bluetooth-device-flaw-hackers-vulnerability-data-encryption-cybersecurity-knob>

o Major Bluetooth security flaw exposes devices to hackers
<https://mobilesyrup.com/2019/08/16/major-bluetooth-security-flaw-exposes-devices-to-hackers/>

o Serious Bluetooth flaw finally acknowledged by Apple
<https://9to5mac.com/2019/08/16/bluetooth-security-flaw/>

o Critical KNOB exploit penetrates gaping Bluetooth vulnerability
<https://thenextweb.com/security/2019/08/16/critical-knob-exploit-penetrates-gaping-bluetooth-vulnerability/>

o Serious Bluetooth flaw leaves devices open to attack
<https://www.engadget.com/2019/08/16/bluetooth-flaw-knob-attack/>

o KNOB Attack Weakens Bluetooth Encryption
<https://www.tomshardware.com/news/bluetooth-knob-attack,40178.html>

o Critical Bluetooth security bug discovered
<https://www.digitaltrends.com/mobile/bluetooth-security-flaw-knob-attack/>

o Critical Bluetooth flaw opens millions of devices to eavesdropping attacks
<https://www.helpnetsecurity.com/2019/08/16/bluetooth-cve-2019-9506/>

o Bluetooth security flaw has a silly name but serious consequences
<https://www.slashgear.com/bluetooth-security-flaw-has-a-silly-name-but-serious-consequences-16587472/>

o Bluetooth flaw leaves everyone vulnerable to terrifying KNOB attack
<https://www.trustedreviews.com/news/bluetooth-flaw-leaves-everyone-vulnerable-to-a-massive-knob-attack-3931162>

o Bluetooth BR/EDR supported devices are vulnerable to key negotiation attacks
<https://www.kb.cert.org/vuls/id/918987/>

[Keith Nuttle]

On 8/16/2019 5:32 PM, Arlen George Holder wrote:
> Bluetooth apparently had a hole that a bus could drive through...
> "A serious Bluetooth security flaw has been acknowledged by Bluetooth SIG,
> the official body in charge of standards for the wireless communications
> technology.
>
> It is sufficiently dangerous that the official Bluetooth specification has
> been changed.
>
> The vulnerability would make it far easier for an attacker to brute-force a

> pairing with your devices�K"

>
> o Key Negotiation of Bluetooth
> <https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth/>
>
> o Bluetooth vulnerability could expose device data to hackers
> <https://www.theverge.com/2019/8/16/20808597/bluetooth-device-flaw-hackers-vulnerability-data-encryption-cybersecurity-knob>
>
> o Major Bluetooth security flaw exposes devices to hackers
> <https://mobilesyrup.com/2019/08/16/major-bluetooth-security-flaw-exposes-devices-to-hackers/>
>
> o Serious Bluetooth flaw finally acknowledged by Apple
> <https://9to5mac.com/2019/08/16/bluetooth-security-flaw/>
>
> o Critical KNOB exploit penetrates gaping Bluetooth vulnerability
> <https://thenextweb.com/security/2019/08/16/critical-knob-exploit-penetrates-gaping-bluetooth-vulnerability/>
>
> o Serious Bluetooth flaw leaves devices open to attack
> <https://www.engadget.com/2019/08/16/bluetooth-flaw-knob-attack/>
>
> o KNOB Attack Weakens Bluetooth Encryption
> <https://www.tomshardware.com/news/bluetooth-knob-attack,40178.html>
>
> o Critical Bluetooth security bug discovered
> <https://www.digitaltrends.com/mobile/bluetooth-security-flaw-knob-attack/>
>
> o Critical Bluetooth flaw opens millions of devices to eavesdropping attacks
> <https://www.helpnetsecurity.com/2019/08/16/bluetooth-cve-2019-9506/>
>
> o Bluetooth security flaw has a silly name but serious consequences
> <https://www.slashgear.com/bluetooth-security-flaw-has-a-silly-name-but-serious-consequences-16587472/>
>
> o Bluetooth flaw leaves everyone vulnerable to terrifying KNOB attack
> <https://www.trustedreviews.com/news/bluetooth-flaw-leaves-everyone-vulnerable-to-a-massive-knob-attack-3931162>
>
> o Bluetooth BR/EDR supported devices are vulnerable to key negotiation attacks
> <https://www.kb.cert.org/vuls/id/918987/>
>

That is the reason you always turn off your computer when you are not
using it, turn off bluetooth when you are not using it, and turn off
WIFI when you are not using it.


A unit that is turned off can not be hacked.

--
Judge your ancestors by how well they met their standards not yours.
They did not know your standards, so could not try to meet them.

[Arlen George Holder]

On Fri, 16 Aug 2019 18:05:32 -0400, Keith Nuttle wrote:

> A unit that is turned off can not be hacked.

I'm with you on turning off anything you're not using,
where, if I understand this flaw, essentially a single character in some
situations, entirely defeats the encryption.

The attacker needs to be in the middle though, at the time of the
negotiations between two devices.

The good news is that TESTING for this vulnerability will be ADDED to the
Bluetooth device testing suite.

The bad news is that there are some companies who spend millions highly
marketing the mere _illusion_ of security, whose products (as it always
turns out) are just as vulnerable as all the rest - but the poor hapless
users who are fed such bullshit literally _believe_ that their products are
safer than other products (which I find simply sad for them to be fooled so
easily).

The main defense is to own an adult brain that realizes all common consumer
devices suffer from the same vulnerabilities in the aggregate.

Here are the main two articles, I think:
<https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth/>
<https://www.kb.cert.org/vuls/id/918987/>

[William Unruh]

On 2019-08-16, Arlen George Holder <arlinggeo...@nospam.net> wrote:
> On Fri, 16 Aug 2019 18:05:32 -0400, Keith Nuttle wrote:
>
>> A unit that is turned off can not be hacked.
>
> I'm with you on turning off anything you're not using,
> where, if I understand this flaw, essentially a single character in some
> situations, entirely defeats the encryption.
>
> The attacker needs to be in the middle though, at the time of the
> negotiations between two devices.
>
> The good news is that TESTING for this vulnerability will be ADDED to the
> Bluetooth device testing suite.
>
> The bad news is that there are some companies who spend millions highly
> marketing the mere _illusion_ of security, whose products (as it always
> turns out) are just as vulnerable as all the rest - but the poor hapless
> users who are fed such bullshit literally _believe_ that their products are
> safer than other products (which I find simply sad for them to be fooled so
> easily).
>
> The main defense is to own an adult brain that realizes all common consumer
> devices suffer from the same vulnerabilities in the aggregate.

That is not a defense for the vulnerability.

>
> Here are the main two articles, I think:
><https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth/>
><https://www.kb.cert.org/vuls/id/918987/>

From the first:
"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. 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. If the
attacking device was successful in shortening the encryption key length
used, it would then need to execute a brute force attack to crack the
encryption key. In addition, the attacking device would need to repeat
the attack each time encryption gets enabled since the encryption key
size negotiation takes place each time."


There is no "single character vulnerability. It might be possible for
the attacker to tell the two devices to use a single character password,
and then do an exhaustive search for which single character they decided
on.

[Arlen George Holder]

On Sat, 17 Aug 2019 00:00:35 -0000 (UTC), William Unruh wrote:

> There is no "single character vulnerability. It might be possible for
> the attacker to tell the two devices to use a single character password,
> and then do an exhaustive search for which single character they decided
> on.

The news only broke today, so we'll learn more as time goes on...
where, the sad thing seems to be that the suggested workaround, in fact,
is, AFAICT, to simply lengthen the number of characters from a single
character (in some cases) such that the intruders' negotiation will time
out instead - whereas - with the single character flaw - the timeout period
isn't exceeded (AFAICT).

[M. L.]

> "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. 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. If the
> attacking device was successful in shortening the encryption key length
> used, it would then need to execute a brute force attack to crack the
> encryption key. In addition, the attacking device would need to repeat
> the attack each time encryption gets enabled since the encryption key
> size negotiation takes place each time."

Sounds like the vulnerability is mostly academic.

[William Unruh]

Again, there is no single character vulnerability. There is a password
length vulnerability. Anyone who used a single character as their
password is a complete idiot, and (I hope) noone would do that. However
this bug allows a MITM to persuade the two vulnerable bluetooth devices
to use a single character as a password, which the MITM can then decrypt
by trying all 256 possibilities (exhaustive search).

So, problems for the attacker. He must be within range of both of the
devices while they are negotiating the bluetooth connection. Both devices
must have their bluetooth software be a buggy version. And the MITM must
be quick enough to get in on the negotiation at the beginning.

[Mayayana]

"M. L." <m...@privacy.invalid> wrote

| Sounds like the vulnerability is mostly academic.
|

Not at all. That's what people always think until it happns.
Who imagined that your ATM could give away your bank account
savings by someone inserting a thin skimmer card into the
bank card slot?

This attack may be academic for the average home or
small office user, where bluetooth is not common. But on
phones this could be a big problem. For instance, in Starbucks,
where the wireless service could be used to capture your
phone talking to their cash register. And this :

https://www.nytimes.com/interactive/2019/06/14/opinion/bluetooth-wireless-tracking-privacy.html

That article explains how retail stores are now tracking
location of customers in great detail, so they can study what
products you look at. The location data is collected using small
bluetooth beacons distributed throughout the store. All you
need is a spyware app on your phone (which most of them
seem to be) and you end up with repeated bluetooth connections.
These particular beacons may not need to actually negotiate a
connection. The article describes them as broadcasters.
But that's just one possible scenario, which most of us never
would have imagined possible. It's likely that bluetooth tracking
will be ubiquitous soon, done by commercial but also gov't
entities. So why enable bluetooth on your phone? So it can
talk to your watch or your earplugs? So you can wave your
phone at cash registers to pay? If you want to be able to
do such silly things then you *will* be taking a risk. If not
with security then with privacy. If not with this bug then
with the next.

I half expect that one of these days I'll be picked up on
a surveillance camera and cops will stop me for walking without
a cellphone, because I showed up on the camera but the
corresponding bluetooth beacons never sent my ID, movement
history, sexual preferences, favorite color, and last purchase
details to the authorities.

That makes phones the next security problem. Computers
are mostly only being attacked these days by ransomware
aimed at commercial entities. Increasingly, people are shopping
and banking by waving their cellphone. Bluetooth. Spyware apps.
Malware. All happening on a profoundly insecure little device
that holds everything that used to be in your desk... plus a lot
more.

That creates an extensive threat potential. And as usual, no
one will take it seriously because everyone wants convenience.

[Richard Kettlewell]

William Unruh <un...@invalid.ca> writes:
> Again, there is no single character vulnerability. There is a password
> length vulnerability. Anyone who used a single character as their
> password is a complete idiot, and (I hope) noone would do that. However
> this bug allows a MITM to persuade the two vulnerable bluetooth devices
> to use a single character as a password, which the MITM can then decrypt
> by trying all 256 possibilities (exhaustive search).

It’s a key, not a password, and (in the non-legacy case) it’s 128 bits
long. The vulnerability is that the attacker can cause it to have only 8
bits of entropy, i.e. only 256 possible (128-bit) values.

--
https://www.greenend.org.uk/rjk/

[Gene Wirchenko]

On Fri, 16 Aug 2019 18:05:32 -0400, Keith Nuttle

<Keith_...@sbcglobal.net> wrote:

[snip]

>That is the reason you always turn off your computer when you are not
>using it, turn off bluetooth when you are not using it, and turn off
>WIFI when you are not using it.

>A unit that is turned off can not be hacked.

Do not be so sure.

When I was freelancing, one client had a desktop system that
could be configured so that when shut off, an incoming call to the
modem would cause the system to start up.

Sincerely,

Gene Wirchenko

[Wildman]

That is called wake on lan. Turn it off.

--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!

[Joe Beanfish]

On Sun, 18 Aug 2019 23:17:53 -0500, Wildman wrote:

> On Sun, 18 Aug 2019 20:20:07 -0700, Gene Wirchenko wrote:
>
>> On Fri, 16 Aug 2019 18:05:32 -0400, Keith Nuttle
>> <Keith_...@sbcglobal.net> wrote:
>>
>> [snip]
>>
>>>That is the reason you always turn off your computer when you are not
>>>using it, turn off bluetooth when you are not using it, and turn off
>>>WIFI when you are not using it.
>>
>>>A unit that is turned off can not be hacked.
>>
>> Do not be so sure.
>>
>> When I was freelancing, one client had a desktop system that
>> could be configured so that when shut off, an incoming call to the
>> modem would cause the system to start up.
>>
>> Sincerely,
>>
>> Gene Wirchenko
>
> That is called wake on lan. Turn it off.

"modem" would be wake-on-ring (WOR). Wake-on-lan (WOL) would be on
ethernet.

[Wildman]

OK, I got the name wrong. The fix if the same... turn it off.

[Frank Slootweg]

Indeed, "turned off" is a relative term.

My previous laptop (Vista era) completely drained its battery when
left in shutdown during our extended (weeks) absence.

It turned out it was a Media Center version which had a little remote
control device and - apparently - even when in shutdown, the laptop still
'listened' to the remote control and a press of a button on the RC would
(completely) start up the laptop. (So next time, we removed the
battery.)

[Anssi Saari]

Frank Slootweg <th...@ddress.is.invalid> writes:

> Indeed, "turned off" is a relative term.
>
> My previous laptop (Vista era) completely drained its battery when
> left in shutdown during our extended (weeks) absence.

I had a similar experience with an old work laptop (Thinkpad T series
from around 2010). In it, USB ports were powered even if it was off so
you could charge stuff off the laptop. There was a config setting to
disable that in bios setup though.