In this blog post, we will be testing our clients and access points to see if they are vulnerable to the KRACK attack.
KRACK attack, or Key Reinstallation AttaCK, is an attack against the 4-way handshake of the WPA2 protocol. It was discovered by Mathy Vanhoef of imec-DistriNet, KU Leuven. In the attack, the malicious host tricks a victim into reinstalling an already-in-use-key by manipulating and replaying the cryptographic handshake messages. By replaying these messages, the attacker can decrypt, forge and even also inject packets.
When connecting to the network with the client machine, the 4-way handshake works as a negotiation between the client and the network to generate a new encryption key, which will be installed on the client in the message 3 of the 4-way handshake. Once the client has access to the key, encryption of data frames are made possible using an encryption protocol. However, the inherent weakness in the 4-way handshake is the re-transmissions of Message 3’s (in case the message is not received, dropped or lost). In such cases, the AP will re-transmit the Message 3 to the client – the client can also receive multiple Message 3’s. Each time a message is received, it will reinstall the same encryption key and reset the incremental transmit packet number (nonce). The attacker can force these nonce resets to collect and replay the message 3 of the 4-way handshake. By forcing the reuse of nonces, the attacker can break through the encryption protocol and have full freedom to replay, decrypt, forge packets. With this method, the attacker can for example inject malicious data, ransomware or malware into unencrypted HTTP websites that the victim is visiting.
Currently at the time of writing this blog post, Mathy hasn’t revealed the scripts and the methods used in the proof-of-concept video – mainly because the time it takes to create the GitHub repository, and most importantly to give people enough time to update their devices. However, he has released tools in his GitHub, that allow us to check if our devices are vulnerable to the key re-installation attack.
Firstly – plug in the wireless adapter to your client, run apt-get update and clone the repository used to test the vulnerability.
git clone https://github.com/vanhoefm/krackattacks-scripts.git
After that let’s install the required dependencies on Kali with
apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python-scapy python-pycryptodome
Once the required dependencies are installed, turn off hardware encryption by navigating into the krackattack-scripts folder, and running the bash script.
You can check the success of the command by typing systool -vm ath9k_htc and checking that the nohwcrypt has been set on. Keep in mind that for us the ath9k_htc worked because we are using an Atheros chipset. If your chipset is different the command is also different.
After that lets compile our modified Host AP driver instance by navigating into the hostapd folder and issuing the following commands:
cp defconfig .config make -j 2
We also need to disable Wi-Fi in our network manager before running any of the scripts. After Wi-Fi has been disabled with the service network-manager stop, follow up with the sudo rfkill unblock wifi to allow the test script to still use WiFi
Now let’s setup our test WiFi host, that our devices will try to connect to. Navigate into the hostapd folder, and edit the hostapd.conf configuration file. In the configuration file, we specify which interface will be used in the tests, what the SSID or name of the test host will be (in our case yaparperiTEST) and what will be the test networks password. By default it is set at abcdefgh, so we went with that (shown below the hostapd.conf screenshots)
Keep in mind that the client must use DHCP to obtain the IP address after connecting, because some tests start after the client has requested the IP.
Now let’s run the actual script to test the vulnerability of our devices. Fire up the script by navigating into the krackattack folder and run the ./krack-test-client.py script.
Now once the script is running, it will show all nearby client devices a test network that they can connect to with WiFi. Once a device tries to connect to the WiFi and authenticate into it, the script will show whether the client does or doesn’t reinstall the pairwise key in the 4-way handshake, to show that if it’s exploitable with this key reinstall attack.
We also found out that some devices in our test environment didn’t accept replayed broadcast frames. We didn’t find a pattern or any common factors to why some devices automatically accept broadcast frames. Mathy Vanhoef noted that even though most of the devices are vulnerable, Android and Linux based devices are most at risk.
We compiled a list of devices that we had success on the vulnerability test, and devices where we failed to do these tests.