
Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic - oherrala
https://www.eset.com/int/kr00k/
======
skunkworker
An interesting attack on WPA2 on unpatched devices.

This reminds me of the WPS reaver attack, which is a complete facepalm from an
implementation perspective. Only 11,000 possible combinations, and trying 1
key every other second would net you the WPA password in < ~5 hours.

"In 2011, a security researcher named Stefan Viehböck discovered a flaw in
this implementation. The concept he introduced was based on the following
facts:

Out of the 8 digits of the PIN, the last digit is a checksum, which leaves 7
digits to guess. The PIN is validated by dividing it into 2 halves. So first
half leaves 10^4 = 10,000 guesses & 2nd half leaves 10^3 = 1000 guesses. So a
total of 11000 guesses only, where it should be 10^8 = 100000000 guesses."

[1] [https://kalilinuxtutorials.com/reaver-
pixewps/](https://kalilinuxtutorials.com/reaver-pixewps/)

~~~
bjornsing
Yea makes you wonder about the bozos at Wi-Fi Alliance who designed that
shit... How can you make a blunder like that?

~~~
semi-extrinsic
All the way back to WEP, it's been clear that the WiFi people are much more
interested in the radio-technical aspects than safety.

~~~
vlan0
>WiFi people are much more interested in the radio-technical aspects than
safety.

History shows us we should expect folks to build the thing then improve later.

------
jascii
Less sensationalist and more informative link:
[https://nvd.nist.gov/vuln/detail/CVE-2019-15126](https://nvd.nist.gov/vuln/detail/CVE-2019-15126)
(CVSS Severity Base Score: 3.1 Low)

Eh yeah, you shouldn't use WPA2 as your sole defence against data
exfiltration. Nice way to drive traffic to your website though..

~~~
tptacek
Not that I think this an especially scary vulnerability, but I wouldn't use
CVSS scores as a basis for evaluating any kind of bug. CVSS is a ouija metric
without any real merit.

The underlying work here is good and interesting. If companies are going to
hype bugs, let it be for stuff like this!

~~~
jascii
> CVSS is a ouija metric without any real merit.

Tell that to the hard working folks that define the standard, I'm sure they'll
appreciate it..

Like any such metric, CVSS is far from perfect, however, in the real world you
are sometimes called upon to express things in a quantitative manner even if
they are better expressed in a qualitative manner, for instance when you need
to justify security spending in a corporate environment, or in the context of
compliance reporting. Do you know of a better tool/standard?

> If companies are going to hype bugs, let it be for stuff like this!

That's a bit like crying wolf though, isn't it? It desensitises people to
actual issues and takes focus and funds away from them. This kind of fear
based marketing might be useful if your goal is to suck a naive client dry for
a year or so, if you are actually trying to make the world a safer place it
does more harm then good.

~~~
tptacek
Steve Christey? I have. Many times. He's fine with it. (I assume he disagrees!
He's wrong!) Sorry, you'll have to find someone else to take vicarious offense
for.

CVSS doesn't work, for the reasons I gave, and have given other times on HN;
the search bar will help you if you want to dig in.

~~~
jascii
> CVSS doesn't work, for the reasons I gave

You didn't give any reasons. If you want to have a civil discourse, at least
_try_ to justify your opinions.

------
titzer
What I gathered from my quick scan of their PDF:

An attacker can trigger a dissociation between the device and the access
point. The dissociation causes the device to zero its temporary encryption key
called the TK (transient key), which is the key used to encrypt traffic
between the device and the access point. Unfortunately, some data frames still
on the device could then be encrypted with this zero key and sent anyway.
Because the key is known to be zero, the attacker can decrypt these few data
frames (a couple of kilobytes) trivially. Since the attacker can trigger this
at will, they can leak an unbounded amount of data.

It's essentially a race condition in hardware between clearing keys and
finishing sending off the last few packets inside the transmission buffer.
Nasty!

This is going to require you to patch your firmware.

~~~
dfox
The fact that attacker can cause dissociation is separate vulnerability slash
wifi design decision. Detecting active attackers doing exactly that is in fact
(literal) text book example of what statistical IDS does. The question of what
exactly you are going to do if you detect such an attacker is unfortunately
another matter.

Edit to add: this vulnerability essentially upgrades a class of well-known DoS
attacks against WiFi networks to potential data exfiltration. On the other
hand I feel like that intentionally exploiting this combination for data
exfiltration by actively causing disassociations is not exactly practical
attack, because you are going to cause significant disruption to operation of
the network, ie. the target users are just going to give up and complain that
the network is broken.

------
heavyset_go
Is there a proof of concept out there yet? Also, does this require a firmware
patch, or can it be mitigated via software?

edit: I can't reply to the comment below about iOS updates because the comment
is dead, but I just would like to interject that iOS and macOS updates can,
and sometimes do, contain firmware updates for hardware. The release notes for
the macOS update that contains the fix doesn't specify if the fix is in
firmware or software, but I suspect it is in the former.

~~~
lxgr
Since the bug is apparently in FullMAC devices, it would be a firmware fix in
most cases (unless someone is running a FullMAC device as SoftMAC for whatever
reason).

Also, the boundaries between firmware, hardware and (driver) software are
pretty murky as far as Wi-Fi drivers are concerned: I remember reading that
many FullMAC devices contain their own firmware in a ROM and have some room in
on-chip RAM for patches (but not an entirely new firmware image!). These
patches can be uploaded at device initialisation time and are contained in the
device driver.

This is similar conceptually to microcode, both in that such updates are not
persistent (i.e. have to be applied again after every boot) and optional
(compared to a mandatory firmware blob upload, you won't notice if your driver
is outdated or simply not installing updates for a known vulnerability).

~~~
heavyset_go
Thanks for your detailed post.

> _Also, the boundaries between firmware, hardware and (driver) software are
> pretty murky as far as Wi-Fi drivers are concerned_

Yeah, this is why I ask if it can be fixed via software. I've been utterly
surprised at the amount of bugs that exist in firmware but can be mitigated on
the seemingly software-side of things.

I have a device that used the brcmfmac driver on Linux until today, and am
hoping I won't have to shelve it forever.

~~~
jascii
> I have a device that used the brcmfmac driver on Linux until today, and am
> hoping I won't have to shelve it forever.

No need to shelve the device, just don't treat WiFi as a "trusted zone" and
use better encryption on top of WPA2. You should anyway, and this
vulnerability is just another _small_ reason why. What this vulnerability does
-- as I understand it -- is, when a device dissociates with the network, send
the rest of the tx buffer with a zero'd out encryption key. And thus leaks a
small amount of data. Not good, however if you apply common best practices to
your network I wouldn't lose any sleep over it.

------
mjevans
The next time I update (wifi) routers I'm responsible for, I think I'm going
to go fully Internet Only DMZ, and Wireguard 'VPN' for entry to the LAN.

~~~
josteink
That sounds nice on paper, but will make common things like accessing Plex-
servers from apps on the set-top box, Chromecasting and what not a royal pain
in the ass.

~~~
heavyset_go
I thought this would be the case, but I have most of my WiFi-enabled devices
using WireGuard, and don't have a problem accessing my self-hosted services,
nor with casting. This is the case even with phones using WireGuard. I can
cast, use Jellyfin, and cast from Jellyfin just fine. edit: I should mention
that I don't have an internet-only DMZ, just WireGuard for the LAN.

~~~
apfsx
I can't get any casting to work when my phone is connected with WireGuard. I
have exclude private IP's on for the one I'm connected to. It'll show for
instance in the YouTube app but not actually be able to cast. Disabling VPN
and retrying works immediately.

~~~
e12e
While I'm exited about wireguard - you might want to have a look at zerotier -
it works perfectly as a mesh LAN. Must admit I haven't tried casting - the
only thing I "cast" is youtube - which is just via regular LAN/internet.

------
raybb
Related Wikipedia article:
[https://en.wikipedia.org/wiki/Kr00k](https://en.wikipedia.org/wiki/Kr00k)

