vanhoefm/krackattacks-scriptsScripts to verify WPA2 clients and APs for KRACK key reinstallation vulnerabilities using modified hostapd and monitor-mode frame replay.
This project contains scripts to test if clients or access points (APs) are affected by the KRACK attack against WPA2. For details behind this attack see our website and the research paper.
Remember that our scripts are not attack scripts! You will need the appropriate network credentials in order to test if an access point or client is affected by the KRACK attack.
December 2024: a bug has been fixed in the 7th test ./krack-test-client.py --gtkinit. Before this bugfix, it was mentioned that (the output of) this test was unreliable, but now the output should be trustworthy when following the new instructions. That is, when this test now indicates that the device is vulnerable, it indeed is likely vulnerable.
January 2021: the scripts have been made compatible with Python3 and has been updated to better support newer Linux distributions. If you want to revert to the old version, execute git fetch --tags && git checkout v1 after cloning the repository (and switch back to the latest version using git checkout research).
Our scripts were tested on Kali Linux. To install the required dependencies on Kali, execute:
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw
Now compile our modified hostapd instance and create a python virtual environment. This assure you're using compatible python libraries (those listed in krackattack/requirements.txt):
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh
Then disable hardware encryption for optimal results:
cd krackattack
sudo ./disable-hwcrypto.sh
Note that if needed you can later re-enable hardware encryption using the script sudo ./reenable-hwcrypto.sh. It's recommended to reboot after disabling hardware encryption. We tested our scripts with an Intel Dual Band Wireless-AC 7260 and a TP-Link TL-WN722N v1 on Kali Linux.
Every time before you use the scripts you must disable Wi-Fi in your network manager. Then execute:
sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate
After doing this you can executing the scripts multiple times as long as you don't close the terminal.
If you want to undo the effects of the disable-hwcrypto.sh then delete the file /etc/modprobe.d/nohwcrypt.conf.
First modify hostapd/hostapd.conf and edit the line interface= to specify the Wi-Fi interface that will be used to execute the tests. Note that for all tests, once the script is running, you must let the device being tested connect to the SSID testnetwork using the password abcdefgh. You can change settings of the AP by modifying hostapd/hostapd.conf. In all tests the client must use DHCP to get an IP after connecting to the Wi-Fi network. This is because some tests only start after the client has requested an IP using DHCP!
You should now run the following tests located in the krackattacks/ directory:
./krack-test-client.py --replay-broadcast. This tests whether the client accepts replayed broadcast frames. If the client accepts replayed broadcast frames, this must be patched first. If you do not patch the client, our script will not be able to determine if the group key is being reinstalled (because then the script will always say the group key is being reinstalled).
./krack-test-client.py --group --gtkinit. This tests whether the client installs the group key in the group key handshake with the given receive sequence counter (RSC). See section 6.4 of our follow-up research paper for the details behind this vulnerability.
./krack-test-client.py --group. This tests whether the client reinstalls the group key in the group key handshake. In other words, it tests if the client is vulnerable to CVE-2017-13080. The script tests for reinstallations of the group key by sending broadcast ARP requests to the client using an already used (replayed) packet number (here packet number = nonce = IV). Note that if the client always accepts replayed broadcast frames (see --replay-broadcast), this test might incorrectly conclude the group key is being reinstalled.
./krack-test-client.py. This tests for key reinstallations in the 4-way handshake by repeatedly sending encrypted message 3's to the client. In other words, this tests for CVE-2017-13077 (the vulnerability with the highest impact) and for CVE-2017-13078 . The script monitors traffic sent by the client to see if the pairwise key is being reinstalled. Note that this effectively performs two tests: whether the pairwise key is reinstalled, and whether the group key is reinstalled. Make sure the client requests an IP using DHCP for the group key reinstallation test to start. To assure the client is sending enough unicast frames, you can optionally ping the AP: ping 192.168.100.254.
./krack-test-client.py --tptk. Identical to test 4, except that a forged message 1 is injected before sending the encrypted message 3. This variant of the test is important because some clients (e.g. wpa_supplicant v2.6) are only vulnerable to pairwise key reinstallations in the 4-way handshake when a forged message 1 is injected before sending a retransmitted message 3.
./krack-test-client.py --tptk-rand. Same as the above test, except that the forged message 1 contains a random ANonce.
./krack-test-client.py --gtkinit. This tests whether the client installs the group key in the 4-way handshake with the given receive sequence counter (RSC). This is done by retransmitting Msg3/4 of the 4-way handshake, each time with a new group key and a very high replay counter. We know it is vulnerable if the client under test afterwards accepts broadcast frames with a lower replay counter. Unfortunately, some clients do not accept retransmitted Msg3/4 at all, meaning such clients cannot be tested with this command. Clients that do accept a retransmitted Msg3/4, and therefore can be tested with this command, will reply with a Msg4/4 which can be detected based on the following output:
[09:24:11] 02:20:2a:22:a8:30: received a new message 4
We also recommend executing this test in environments with little background noise and executing it several times.
Some additional remarks:
The most important test is ./krack-test-client, which tests for ordinary key reinstallations in the 4-way handshake.
Perform these tests in a room with little interference. A high amount of packet loss will make this script less reliable!
Optionally you can manually inspect network traffic to confirm the output of the script (some Wi-Fi NICs may interfere with our scripts):
Use an extra Wi-Fi NIC in monitor mode to conform that our script (the AP) sends out frames using the proper packet numbers (IVs). In particular, check whether replayed broadcast frames indeed are sent using an already used packet number (IV).
Use an extra Wi-Fi NIC in monitor mode to check pairwise key reinstalls by monitoring the IVs of frames sent by the client.
Capture traffic on the client to see if the replayed broadcast ARP requests are accepted or not.
If the client can use multiple Wi-Fi radios/NICs, perform the test using several Wi-Fi NICs.
You can add the --debug parameter for more debugging output.
All unrecognized parameters are passed on to hostapd, so you can include something like -dd -K to make hostapd output all debug info.