KRACK What?!

Hours after hitting the web, the vulnerability in WPA2 known as “KRACK” is causing major waves and making people panic.

It is still unclear how far and how quickly attackers will take this. But rest assured as the vulnerability becomes better known and more exploitation software and scripts are written for it – it's going to go like wildfire!

So, what is “KRACK”? What does the vulnerability entail? Should we throw all our Wi-Fi devices in the Bin and rewind the world back 30 years?

The short answer is No, and the long answer is: You’ve been warned…

What is KRACK?

Without venturing too deeply into how WPA2 handshakes work, in its simplest form when a wireless device (a client, like your mobile phone) connects to an AP (Access Point, the thing that runs your Wi-Fi network) the following happens between the two to ensure security…

The AP sends a nonce (a value used only once) to the client. It does this using the key that is derived from the PSK (Pre-shared key – the “password” you typed into the AP at setup)

The client takes that value and creates a Pairwise Transient Key (PTK) along with the authentication code and a new nonce value it generates. It sends this back to the AP.

If all is well, the AP responds with a Message Integrity Code (MIC) and a Group Temporal Key (GTK) to the client.

If all is well, the client responds with an ACK (all ok/acknowledgment), and the client is now connected.

Due to the fact that at any time, a client could be temporarily disconnected, or out of range, etc – the WPA2 protocol allows the packet with the key to be re-sent subsequent handshakes to re-establish the connection.

It is at this function of the WPA2 protocol that KRACK’s exploitation exists.

Note that at MESSAGE 3 above – the client installs the key it receives from the AP. To support the possibility that packets of data may have dropped, or were lost – the AP has the ability to re-transmit MESSAGE 3, and herein lies the problem.

Every-time the Client receives “MESSAGE 3” of the handshake, it re-installs the key it was given and resets its incremental packet transmit number (or IV) to 0 (this is used as part of blocking potential replay attacks).

Now think about this – If I can collect and replay these “MESSAGE 3″‘s what happens? I can force the Client to keep on re-inserting a key and resetting its transmit number to 0. So we force the client to always use an increment packet number (or Initialization Vector) of 0. The encryption key the client will use for the next packet send will be the same encryption key already used and with nonce values already used in the past! Now we have got the client to encrypt the data with something we know and can control.

The result is that the WPA2 Encryption process will use the same stream of computed random characters when encrypting packets.

So…

What can someone do with this attack?

They can potentially decrypt data in transit (through the air) by having forced the encryption process into a direction they control and/or have decryption of.

They can also inject packets and/or modify TCP/IP packets with the correct attack vectors and tools in place.

This applies to WPA2 Pre-Shared Key (PSK) and Enterprise-based WPA2 Authentication.

What can someone NOT do with this attack?

They cannot obtain the password of the WPA2 network (the older, well-known methods of obtaining password keys can still be used).

They cannot recover new encryption keys created between the legitimate AP and its client.

How do I mitigate against this?

We have to wait for patches. The problem is many IoT device manufacturers are barely patching their unstable devices, let alone patching this!

The result is many devices will be unpatched and in-use that will remain vulnerable.

For mainstream systems, and software/hardware vendors who put effort into user support – we can expect patches to start coming through to fix this vulnerability urgently.

Another method of mitigation, especially within corporate environments, is to make sure you use (proper) SSL security for critical internal data traffic. This way even if the WPA2 encryption is breached, the data is still going over secure SSL channels.*