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
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
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.
