Wi-Fi has been hacked

[ToxicBunny]

Aruba wrote a very nice document detailing the issue and their response.



http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007_FAQ_Rev-1.pdf

Which perfectly explains a work around...

 

[Gnome]

Ok looks like the AP vulnerability they are talking about is for APs that support 802.11r (Fast Roaming, where clients are handed off between APs).

 

[Swa]

Are you blind?

Its the STANDARD that has the issue, not the spec.

You don't seem to comprehendo. The spec describes the standard and it's not sufficiently detailed to resist the attack. It's like code injection into a database. Programmers are supposed to foresee it but where it's not prescribed they usually don't. Doesn't mean that PHP or SQL is flawed and needs to be fixed.

It is unclear to me why a AP would need to be patched.

Perhaps someone can explain what exactly you would "patch" on the AP.

I've read the attack and I realize the author knows the vulnerability better than I do, but I couldn't see a way it could be used against an AP.

(And before someone brings up that an "AP" can be a client, let me be clear, not an AP hardware device connecting to other devices as a client. I'm talking about an actual wifi access point providing connectivity. Any client connectivity from a hardware device makes it a client, regardless of what you call it when you sell it)

It doesn't apply to an access point unless it also serves as a repeater. Even then it only makes that part of the connection unsecure and not the clients connecting to it. Patching an access point however can prevent it occurring from the client side so I'd suggest it when one becomes available.

 

[SauRoNZA]

Now this is value added .

I was going to ask how this affected me. With having a router, connected to an ADSL line, feeding only my my TV and console etc at home. Any concerns over this?

Of course you’d want to patch stuff when the patches come out.

But unless you are being very specifically targeted I wouldn’t stress too much.

No need to be paranoid and switch your WiFi off or something crazy like that.

Tv’s and Consoles are closed devices anyway and at least the console traffic is pretty well encrypted already.

 

[Valerion]

You don't seem to comprehendo. The spec describes the standard and it's not sufficiently detailed to resist the attack. It's like code injection into a database. Programmers are supposed to foresee it but where it's not prescribed they usually don't. Doesn't mean that PHP or SQL is flawed and needs to be fixed.


It doesn't apply to an access point unless it also serves as a repeater. Even then it only makes that part of the connection unsecure and not the clients connecting to it. Patching an access point however can prevent it occurring from the client side so I'd suggest it when one becomes available.

You're missing the 802.11r case for APs. And yes, it may be enabled in the background on consumer hardware, those usually don't have very good interfaces for advanced settings.

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access. Go ahead and google for the IETF TLS or IPSec specifications — you’ll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.

The IEEE has been making a few small steps to ease this problem, but they’re hyper-timid incrementalist bull****. There’s an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they’ve been public for six months — coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.

This whole process is dumb and — in this specific case — probably just cost industry tens of millions of dollars. It should stop.

The second problem is that the IEEE standards are poorly specified. As the KRACK paper points out, there is no formal description of the 802.11i handshake state machine. This means that implementers have to implement their code using scraps of pseudocode scattered around the standards document. It happens that this pseudocode leads to the broken implementation that enables KRACK. So that’s bad too.

And of course, the final problem is implementers. One of the truly terrible things about KRACK is that implementers of the WPA supplicant (particularly on Linux) managed to somehow make Lemon Pledge out of lemons. On Android 6 in particular, replaying message #3 actually sets an all-zero key. There’s an internal logic behind why this happens, but Oy Vey. Someone actually needs to look at this stuff.

https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/

Poorly specified standards open themselves to this sort of thing. Specify ALL the constraints you are assuming applies. Then you can blame the implementers. If the standard just leave it vague you blame the standard. And if you have a certification process for the standard, and the vulnerable hardware passes, you are doubly guilty.

I am waiting for the next one, that no workaround may work for. That will be fun to watch. Proprietary closed standards deeply embedded in hardware is problematic.

 

[Valerion]

Which perfectly explains a work around...

Sorry, I was actually trying to agree with you, thought I posted more in there.

 

[Gnome]

Patching an access point however can prevent it occurring from the client side so I'd suggest it when one becomes available.

No.

In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value.

When the client connects to the AP a key is sent by the AP to the client.

The attacker captures that key and replays that key to the client.
The specification has to allow this because packets can get lost during transmission.
Thus it is not an error to receive the same packet multiple times.

By replying that packet you end with the nonce inevitable being the same for more than one message (contents are different between the messages).
Because the nonce is used multiple times and TCP packets have a predetermined format you can apply a known plaintext attack to recover the nonce used for encryption
If two different messages are encoded with the same key and nonce most of the packet will look the same, but some of it will be different, allowing the nonce to be factored.

The is no way an AP can prevent this attack. No amount of patching or anything will stop this from the AP side.

There is no value in patching the AP unless you it is itself a client or uses 802.11r which is vulnerable to the same attack.

 

[ToxicBunny]

Sorry, I was actually trying to agree with you, thought I posted more in there.

I think all of us who have a clue know that it’s a workaround... was just trying to educate Swa on that fact

 

[Swa]

No.



When the client connects to the AP a key is sent by the AP to the client.

The attacker captures that key and replays that key to the client.
The specification has to allow this because packets can get lost during transmission.
Thus it is not an error to receive the same packet multiple times.

By replying that packet you end with the nonce inevitable being the same for more than one message (contents are different between the messages).
Because the nonce is used multiple times and TCP packets have a predetermined format you can apply a known plaintext attack to recover the nonce used for encryption
If two different messages are encoded with the same key and nonce most of the packet will look the same, but some of it will be different, allowing the nonce to be factored.

The is no way an AP can prevent this attack. No amount of patching or anything will stop this from the AP side.

There is no value in patching the AP unless you it is itself a client or uses 802.11r which is vulnerable to the same attack.

That's not what the attack details. Replaying the 3rd step installs a zero key. That's not what should happen. Unless I'm misunderstanding something here and there are different attacks here.

I think all of us who have a clue know that it’s a workaround... was just trying to educate Swa on that fact

Yes a "workaround" to just make it work like it is supposed to. I think the correct terminology you're looking for is patch.

 

[Gnome]

That's not what the attack details. Replaying the 3rd step installs a zero key. That's not what should happen. Unless I'm misunderstanding something here and there are different attacks here.

Android and Linux clients using wpa_supplicant install a 0 key after receiving the same handshake packet.

Apparently there was a badly worded part of the specification that suggested zeroing out the key in that scenario.