WPA2 KRACK: Kobo official response?

[PeterT]

See https://github.com/kobolabs/hostap/c...2b3345ed8e52d3
https://github.com/kobolabs/hostap/c...cc3809bf2fd69d
https://github.com/kobolabs/hostap/c...a7f788645fa919

and probably others

[roebeet]

Originally Posted by DNSB

Not quite sure what you mean by the router being in a client mode unless you are referring to an AP being used in bridge mode. The KRACK vulnerability hijacks the 4 way handshake and appears to require that both sides allow recycling transmit and receive packet numbers (aka nonces) by the man in the middle. So the client/station/whatever and the AP/master must both be vulnerable for this to work as described in the original paper to allow eavesdropping on a wireless session. With the vulnerability on one side only, the results are not as useful to an attacker (not my opinion, I'm quoting from a Palo Alto engineer who has a heck of a lot more experience with network security than I).

To quote from the krackattacks.com website:

Currently, all vulnerable devices should be patched. In other words, patching the AP will not prevent attacks against vulnerable clients. Similarly, patching all clients will not prevent attacks against vulnerable access points. Note that only access points that support the Fast BSS Transition handshake (802.11r) can be vulnerable.

That said, it is possible to modify the access point such that vulnerable clients (when connected to this AP) cannot be attacked. However, these modifications are different from the normal security patches that are being released for vulnerable access points! So unless your access point vendor explicitly mentions that their patches prevent attacks against clients, you must also patch clients.

The first paragraph is why we have disabled Fast BSS Transitions on our corporate network.

Correct, I had meant bridged mode. Bad wording on my part.

I've heard back and forth about whether both sides need to be patched or just one (like the router). So I'm assuming the client should be patched, especially Linux-based devices using the 2.4 / 2.5 wpa_supplicant which again I'm not sure how susceptible the Kobo's actually are.

[roebeet]

Originally Posted by PeterT

See https://github.com/kobolabs/hostap/c...2b3345ed8e52d3
https://github.com/kobolabs/hostap/c...cc3809bf2fd69d
https://github.com/kobolabs/hostap/c...a7f788645fa919

and probably others

Thanks. Looks like the first link in particular is notable.

[Robik]

Originally Posted by eenk

The bug affects wpa_supplicant and hostap. The latter most probably isn't used on the Kobo eink readers, but the former is for connecting to wireless LANs. However, the attack mentioned does not in a compromise of the WPA2 passphrase, but instead a single session can be read. For a ebook reader I would guess that its WLAN is off most of the time, and only sporadically switched on for syncing. At least as a temporary user measure this shouldn't be a burden on users. And even if a session gets compromised at the data link level, I fail to see what damage could be done? A firmware download is rare, and then the attacker doesn't get any valuable information I would think. Sending a hacked firmware inband doesn't seem to be really possible, but I might be wrong here. Seeing reading statistics also doesn't strike me as too dangerous unless in those cases where someone doesn't want even Kobo to see them. So the danger of Krack on ebook readers doesn't strike me as even low.

Connections to kobo.com -> https. You can't see nothing.
You can see only http connections from web browser.

[JSWolf]

Will this changes shown on github be in the next version firmware?

[PeterT]

I can't speak for Kobo but.... if they've published the source changes what do YOU think?

[DNSB]

Originally Posted by PeterT

I can't speak for Kobo but.... if they've published the source changes what do YOU think?

Why does Doug and the Slugs' third album pop into my head?

[PeterT]

Love it!

Spoiler:

https://en.wikipedia.org/wiki/Music_...rd_of_Thinking