Some notes on the KRACK attack

This is my interpretation of the KRACK attacks paper that describes a way of decrypting encrypted WiFi traffic with an active attack.

tl;dr: Wow. Everyone needs to be afraid. (Well, worried -- not panicked.) It means in practice, attackers can decrypt a lot of wifi traffic, with varying levels of difficulty depending on your precise network setup. My post last July about the DEF CON network being safe was in error.

Details

This is not a crypto bug but a protocol bug (a pretty obvious and trivial protocol bug).

When a client connects to the network, the access-point will at some point send a random "key" data to use for encryption. Because this packet may be lost in transmission, it can be repeated many times.

What the hacker does is just repeatedly sends this packet, potentially hours later. Each time it does so, it resets the "keystream" back to the starting conditions. The obvious patch that device vendors will make is to only accept the first such packet it receives, ignore all the duplicates.

At this point, the protocol bug becomes a crypto bug. We know how to break crypto when we have two keystreams from the same starting position. It's not always reliable, but reliable enough that people need to be afraid.

Android, though, is the biggest danger. Rather than simply replaying the packet, a packet with key data of all zeroes can be sent. This allows attackers to setup a fake WiFi access-point and man-in-the-middle all traffic.

In a related case, the access-point/base-station can sometimes also be attacked, affecting the stream sent to the client.

Not only is sniffing possible, but in some limited cases, injection. This allows the traditional attack of adding bad code to the end of HTML pages in order to trick users into installing a virus.

This is an active attack, not a passive attack, so in theory, it's detectable.

Who is vulnerable?

Everyone, pretty much.

The hacker only needs to be within range of your WiFi. Your neighbor's teenage kid is going to be downloading and running the tool in order to eavesdrop on your packets.

The hacker doesn't need to be logged into your network.

It affects all WPA1/WPA2, the personal one with passwords that we use in home, and the enterprise version with certificates we use in enterprises.

It can't defeat SSL/TLS or VPNs. Thus, if you feel your laptop is safe surfing the public WiFi at airports, then your laptop is still safe from this attack. With Android, it does allow running tools like sslstrip, which can fool many users.

Your home network is vulnerable. Many devices will be using SSL/TLS, so are fine, like your Amazon echo, which you can continue to use without worrying about this attack. Other devices, like your Phillips lightbulbs, may not be so protected.

How can I defend myself?

Patch.

More to the point, measure your current vendors by how long it takes them to patch. Throw away gear by those vendors that took a long time to patch and replace it with vendors that took a short time.

High-end access-points that contains "WIPS" (WiFi Intrusion Prevention Systems) features should be able to detect this and block vulnerable clients from connecting to the network (once the vendor upgrades the systems, of course). Even low-end access-points, like the $30 ones you get for home, can easily be updated to prevent packet sequence numbers from going back to the start (i.e. from the keystream resetting back to the start).

At some point, you'll need to run the attack against yourself, to make sure all your devices are secure. Since you'll be constantly allowing random phones to connect to your network, you'll need to check their vulnerability status before connecting them. You'll need to continue doing this for several years.

Of course, if you are using SSL/TLS for everything, then your danger is mitigated. This is yet another reason why you should be using SSL/TLS for internal communications.

Most security vendors will add things to their products/services to defend you. While valuable in some cases, it's not a defense. The defense is patching the devices you know about, and preventing vulnerable devices from attaching to your network.

If I remember correctly, DEF CON uses Aruba. Aruba contains WIPS functionality, which means by the time DEF CON roles around again next year, they should have the feature to deny vulnerable devices from connecting, and specifically to detect an attack in progress and prevent further communication.

However, for an attacker near an Android device using a low-powered WiFi, it's likely they will be able to conduct man-in-the-middle without any WIPS preventing them.