KRACK in Practice: How the Wi‑Fi WPA2 Key Reinstallation Attack Works

How it works

The attack is based on a vulnerability in the WPA2 four-way handshake. This handshake runs when a client tries to join a protected Wi‑Fi network. During the process, both sides—the client and the access point—prove they have valid credentials. At the same time, the handshake negotiates a fresh encryption key that will be used to protect the traffic.

An attacker can launch a man-in-the-middle attack and force network clients to reinstall the encryption keys that protect WPA2 traffic. Moreover, if the network is configured to use WPA-TKIP or GCMP, the attacker can not only eavesdrop on WPA2 traffic but also inject packets into the victim’s data.

By exploiting this critical vulnerability, an attacker can decrypt traffic, perform HTTP injection attacks, hijack TCP connections, and more.

Using HTTPS can help protect against KRACK, but not always. HTTPS itself isn’t completely secure—for example, there are connection downgrade techniques—even though it does provide an additional layer of encryption.

The method is universal and works against any unpatched devices connected to Wi‑Fi. The key requirement is that the attacker must be within range of the target Wi‑Fi network; the attack cannot be carried out remotely.

Exploitation

To demonstrate the vulnerability, we’ll need hardware—at least one, preferably several USB Wi‑Fi adapters compatible with Kali Linux. I went with the TP‑Link N150 Wireless High Gain USB Adapter (TL‑WN722N); it’s already tested and works well with my distro. But you can use any other model you prefer.

Why do we even need that “dongle” if the laptop already has Wi‑Fi? A separate device for wardriving is recommended not only because it’s less prone to interference and has a stronger antenna, but also for convenience. You can use the built‑in Wi‑Fi adapter to stay online at the same time, which is a pretty important advantage.

So, using a TP-Link, we’ll bring up our own fake (or, if you prefer, test) network and run our experiment in it.

Enabling Wi‑Fi on Kali Linux

Boot into Kali, go to the taskbar (top-right corner of the desktop), bring up the Wi‑Fi adapter (i.e., enable it), and connect to the preconfigured network.

We’re using WPA2-Personal for Wi‑Fi security, and let’s agree up front to use a long, strong passphrase. The network we’ll be connecting to is named SKG2.

Installing the KRACK Attack toolkit

First, we need to make sure all the required dependencies for the KRACK Attack toolkit are installed on our system. Run the following command:

Since Kali Linux doesn’t include the tools to reproduce this attack by default, we head to GitHub and download a set of scripts.

Next, to keep the experiment clean, we need to disable hardware encryption. In other words, we’ll encrypt keys only using the software mechanisms built into the Wi‑Fi protocols. To do this, navigate to the Krack Attack directory:

From there, run the configuration script:

Next, disable Wi‑Fi in Kali’s Network Manager—i.e., disconnect from the SKG2 network. This will let us bring up our own broadcast on the wlan0 interface, which we’ll use to carry out the attack.

Next, we’ll create a test Wi‑Fi network using a TP‑Link N150. But first, we need to make sure the hardware isn’t blocked. We’ll check this with the rfkill utility by running the following command:

After setting up the test network, we use the krack-test-client.py script. This Python tool checks every device that connects to our Wi‑Fi network for susceptibility to the “key reinstallation attack” (the official name of the method).

So, let’s set up the network. We’ll compile our modified build of hostapd. If you’re not familiar, hostapd is the daemon/service that runs a wireless access point on Linux.

Let’s disable hardware encryption for our rogue network with the following command (we’ll run the same configuration script):

Strictly speaking, the tool’s developers recommend rebooting once the script finishes. In my case everything worked without a reboot, but if anything goes wrong, just reboot the machine.

After a reboot (or without one), run the command.

This Python script resets the keys during the 4-way handshake and automatically brings up the network. It uses WPA2-Personal, with the SSID set to testnetwork.

Attack

Now grab a Windows 10 laptop and connect it to the testnetwork network. Enter the very long, complex password and verify that the connection is established.

After the Windows 10 laptop joined the test network, the Kali terminal started showing alerts from the script krack-test-client.py, which attempts to scan the connected client (our laptop) for the vulnerability and, if found, exploit it.

But the results so far are disappointing. Windows 10, of course, has a patch, as indicated by the line: “Client DOESN’T seem vulnerable to pairwise key reinstallation in the 4-way handshake.”

Let’s try a few more variations controlled by the script’s command-line flags.

But of course, nothing works. Did we really put in all that effort for nothing?

Sure enough, I easily found a vulnerable device of my own—a phone running Android 7.0 that last received an update in July 2018. You can definitely still find these in the wild.

Connect the smartphone to testnetwork and see what our script reports. After a few seconds, it says Android is vulnerable to a group key reinstallation during the four-way handshake.

We did it! From here, you can fire up Wireshark and start sniffing packets. Overall, the experiment showed that KRACK is still a very real problem, and the attack works.

How to protect yourself?

It turns out that almost any device on almost any Wi‑Fi network can be compromised using KRACK. That sounds scary, but—as with any other attack—it’s not the end of the world. Here are a couple of tips to protect yourself against KRACK:

• First, make sure the site is using HTTPS (look for the padlock in the address bar). With HTTPS, KRACK can’t decrypt your traffic.
• Second, always install the latest security updates.

And of course, for sensitive sessions you can skip wireless entirely. Or use a VPN—it gives you end-to-end encryption between the client and the server.

On June 27, 2018, the Wi‑Fi Alliance announced it had finalized the new WPA3 security standard. WPA3 is both a new security protocol and the name of the corresponding certification program.

The designers of WPA3 set out to fix the architectural flaws exposed by KRACK. Since the core weakness was in the four-way handshake, WPA3 mandates a more robust authentication and key exchange method—SAE (Simultaneous Authentication of Equals), also known as Dragonfly.

The SAE (Simultaneous Authentication of Equals) mechanism has already been used in mesh networks and is specified in the IEEE 802.11s standard. It is based on the Diffie–Hellman key exchange using finite cyclic groups.

SEA belongs to the PAKE family of protocols and provides an interactive method by which two or more parties establish cryptographic keys based on a password known to one or more of them. The resulting session key that each side uses to authenticate the connection is derived from the password, the keys, and both parties’ MAC addresses. If one party’s key is compromised, it does not compromise the session key. And even if an attacker learns the password, they still won’t be able to decrypt the packets.

Another WPA3 enhancement is support for PMF (Protected Management Frames), which safeguards the integrity of management traffic. In the future, PMF support will also become mandatory for WPA2.

However, the fact that WPA3 is backward-compatible with WPA2 has already drawn criticism from Mathy Vanhoef, the researcher behind the KRACK attack. He believes there will be a way to bypass Protected Management Frames (PMF) to forcibly disconnect a client from the network.

While adopting SAE will make dictionary attacks harder, it won’t eliminate them—only prolong them—and in open networks an attacker can still set up their own access point to bypass protections and intercept traffic.

What’s more, WPA3 requires hardware support; you can’t just add it with a firmware update. As a result, widespread adoption will take years—and infosec researchers aren’t standing still.