Wi-Fi at risk from KRACK attacks – here’s what to do

News of the week – and it’s still only Monday – is a Bug With An Impressive name (and its own logo!) called the KRACK Attack.

Actually, there are several attacks of a similar sort discussed in the paper that introduced KRACK, so they’re more properly known as the KRACK Attacks.

These KRACK attacks mean that most encrypted Wi-Fi networks are not as secure as you think.

KRACK works against networks using WPA and WPA2 encryption, which these days covers most wireless access points where encryption has been turned on.

An attacker in your midst (at least, within Wi-Fi range) could, in theory, sniff out at least some of the encrypted traffic sent to some of the computers in your organisation.

Even if an attacker can only “bleed off” small amounts of traffic, in dribs and drabs, the end result could be very serious.

(If you remember the Firesheep attack of 2010, just bled a few bytes of data when you connected to Facebook or Twitter was enough to let a crook clone your connection and access your account for as long as you stayed logged in.)

KRACK in a few words

KRACK is short for Key Reinstallation Attack, which is a curious name that probably leaves you as confused as we felt when we heard about it, so here’s our extremely simplified explanation of what happens (please note this explanation covers just one of numerous flavours of similar attack).

At various times during an encrypted wireless connection, you (the client) and the access point (the AP) need to agree on security keys.

To do so, a protocol known as the “four-way handshake” is used, which goes something like this:

1. (AP to client) Let’s agree on a session key. Here’s some one-time random data to help compute it.
2. (Client to AP) OK, here’s some one-time random data from me to use as well.

At this point, both sides can mix together the Wi-Fi network password (the so-called Pre-Shared Key or PSK) and the two random blobs of data to generate a one-time key for this session.

This avoids using the PSK directly in encrypting wireless data, and ensures a unique key for each session.

3. (AP to client) I’m confirming we’ve agreed on enough data to construct a key for this session.
4. (Client to AP) You’re right, we have.

The KRACK Attacks (with numerous variations) use the fact that although this four-way protocol was shown to be mathematically sound, it could be – and in many cases, was – implemented insecurely.

In particular, an attacker with a rogue access point that pretends to have the same network number (MAC address) as the real one can divert message 4 and prevent it reaching the real AP.

During this hiatus in the handshake, the client may already have started communicating with the AP, because the two sides already have a session key they can use, albeit that they haven’t finalised the handshake.

This means that the client will already be churning out cryptographic material, known as the keystream, to encrypt the data it transmits.

To ensure a keystream that never repeats, the client uses the session key plus a nonce, or “number used once”, to encrypt each network frame; the nonce is incremented after each frame so that the keystream is different each time.

As far as we can determine, all the KRACK attacks involve reused keystream material accessed by “rewinding” crypto settings and thus encrypting different data with the same keystream. If you know one set of data you can figure out the other – that’s the best case; some cases are worse than that because you can as good as take over the connection both ways.

Back to the handshake

At some point, the real AP will send another copy of message 3, possibly several times, until the rogue AP finally lets the message get through to the client.

The mathematical certainty in the protocol now meets cryptographic sloppiness in its implementation.

The client finalises the handshake at last, and resets its keystream by “reinstalling” the session key (thus the name of the attack), and resetting the nonce to what it was immediately after stage 2 of the handshake.

This means the keystream starts repeating itself – and re-using the keystream in a network encryption cipher of this sort is a big no-no.

If you know the contents of the network frames that were encrypted the first time, you can recover the keystream used to encrypt them; if you have the keystream from the first bunch of network frames, you can use it to decrypt the frames encrypted the second time when the keystream gets re-used.

Even if attackers are only able to recover a few frames of the data in any session, they still come out ahead.

Gold dust sounds less valuable than a gold ingot – but if you collect enough gold dust, you get to the same value in the end.

What to do

Changing your Wi-Fi password won’t help: this attack doesn’t recover the password (PSK) itself, but instead allows an attacker to decrypt some of the content of some sessions.

Changing routers probably won’t help either, because there are numerous variants of the KRACK Attacks that affect most Wi-Fi software implementations in most operating systems.

Here’s what you can do:

• Until further notice, treat all Wi-Fi networks like coffee shops with open, unencrypted, wireless.
• Stick to HTTPS websites so your web browsing is encrypted even if it travels over an unencrypted connection.
• Consider using a VPN, which means that all your network traffic (not just your web browsing) is encrypted, from your laptop or mobile device to your home or work network, even if it travels over an unencrypted connection along the way.
• Apply KRACK patches for your clients (and access points) as soon as they are available.
• Sophos Customers should read Knowledge Base article 127658.

The precautions that you take in those cases – why not take them all the time?

If you always encrypt everything yourself, in a way that you get to choose and can control, you never have to worry what you might have forgotten about.