WPA2 Key Reinstallation AttaCK or KRACK attack

Recently, Mathy Vanhoef of imec-DistriNet, KU Leuven, discovered a serious weakness in WPA2 known as the Key Reinstallation AttaCK (or KRACK) attack. Their overview, Key Reinstallation Attacks: Breaking WPA2 by forcing nonce reuse, and research paper (Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, co-authored by Frank Piessens) have created quite a stir in our industry because the press touts that it “breaks Wi-Fi”.

There have been numerous articles written about this vulnerability, and we won’t rehash them here. However, we want to take a moment to talk about how this relates to Kali Linux, from a defensive, testing, and detection standpoint.

Is Kali Linux Vulnerable?

From a defensive standpoint, if you’re keeping up with your Kali Linux rolling updates (via a simple “apt update && apt upgrade), you’re already patched against this vulnerability thanks to patches in wpasupplicant and hostapd (both at 2.4-1.1). To be entirely clear: an updated version of Kali Linux is not vulnerable to this attack. You are keeping your Kali Linux system up-to-date, aren’t you?

How do I test for the Vulnerability?

With your Kali system updated, there are also some steps you can take to test for this vulnerability on your access points. Mathy Vanhoef recently released a script that can be run from Kali Linux to test whether or not your access point (AP) is affected by CVE-2017-13082 or specifically the Key Reinstall in FT Handshake vulnerability found in 802.11r devices. The script requires that you authenticate to the access point, but bear in mind that it may incorrectly flag an AP as vulnerable due to “benign retransmissions of data frames”.

How can I Detect Attacks?

Dragorn, the author of the amazing Kismet, has released lots of great information on the subject on his blog, including excellent info about detecting KRACK attacks using Kismet. He explains that the git-master version of Kismet is, “introducing alerts to attempt to detect a Krack-style attack”.

These alerts track spoofed access points, multichannel access points, zero-length keys, zero nonce in a handshake, and nonce retransmission, all factors that could point to a KRACK attack in progress.

Dragorn warns that since Kismet hops channels, it could miss handshake packets and therefore miss the attack. In addition, he says that false positives are still possible despite Kismet’s packet de-duplication and that once real proof-of-concept code is released for KRACK, the logic of these alerts may need to be adjusted.

Dragorn also explains that, “it looks like you can still trip the kismet nonce detection w/ a packet flagged in the frame control as a retransmit” but despite these drawbacks, Kismet is still a decent system for detection of this and other Wi-Fi protocol attacks.

To install the git-master version of Kismet on Kali Linux, follow these steps

First, tell networkmanager to ignore the Wi-Fi device by adding these lines:

[keyfile]
unmanaged-devices=interface-name:wlan0

to

/etc/NetworkManager/NetworkManager.conf

Then, restart NetworkManager:

root@kali:~# systemctl restart NetworkManager

Next, install updates and the git-master version of Kismet:

root@kali:~# apt update
root@kali:~# apt upgrade
root@kali:~# git clone https://www.kismetwireless.net/git/kismet.git
root@kali:~# apt install build-essential libmicrohttpd-dev libnl-3-dev libnl-genl-3-dev libcap-dev libpcap-dev libncurses5-dev libnm-dev libdw-dev libsqlite3-dev
root@kali:~# cd kismet
root@kali:~# ./configure
root@kali:~# make
root@kali:~# make suidinstall
root@kali:~# /usr/local/bin/kismet_capture_tools/kismet_cap_linux_wifi --list
root@kali:~# kismet -c wlan0

Next you can browse to http://localhost:2501 to view the Kismet interface and any alerts. Be sure to log in with the credentials found in

~/.kismet/kismet_httpd.conf

to get full functionality. You can also build and run the capture tools on separate machines, allowing you to monitor from several endpoints and view the alerts on a single centralized server.

Overall, this vulnerability is not the end of the world. As , this vulnerability encourages this shocking approach: “Patch your stuff. Use 2FA. Use HTTPS.” We couldn’t agree more.

We also encourage you to consider the defensive, testing, and detection perspectives of any new vulnerability to help you become more aware of the finer details of the vulnerability, gain insight about it, and become part of the solution.

Thanks to Offensive Security and Kali team member Steev for the technical resources used in this article.