Krack Attacks – This blogs discusses the recently identified KRACK vulnerabilities and explores the current state of the tools that enable the identification of vulnerable devices. This blogs is a deep dive into the inner workings of the WPA2 handshake and is recommended for advanced readers.
KRACK stands for Key Reinstallation AttaCKs. It’s a tranche of vulnerabilities publicly disclosed in October 2017 by a team from KU Leuven. The attack is the exploitation of a fundamental flaw in the WPA2 handshake, allowing resending of a stage of the handshake in order to overwrite cryptographic data. This chapter will cover the attack at a theoretical level and provide some guidance on the successful identification and exploitation of this vulnerability.
Let’s look at the WPA2 handshake, the standard for which can be found in the IEEE 802.11 standards, accessible here: http://ieeexplore.ieee.org/document/7792308/ . For this explanation we are starting post-association and authentication stage as the vulnerability is not affected by those.
The Pairwise Transient Key (PTK) used for encryption is made up of five attributes:
- A shared secret key known as the Pairwise Master Key (PMK)
- A nonce value created by the access point (ANonce)
- A nonce value created by the user station (SNonce)
- The access point MAC address (APMAC)
- The user station MAC address (STAMAC)
Throughout the process, Message Identification Codes (MIC) are used to provide a level of integrity and security. While these are integral to the process, they are not used in the resulting cryptographic data. Here’s a representation:
At this time, as a result of the initial authentication and association process, both the user station and the access point have the PMK, the access point MAC address, and the user station MAC address. In addition, each stage will have a Key Replay Counter keeping track of the order of packets; this will come into play later:
- Stage 1: The access point transmits the ANonce value to the user station, which provides the user station with everything it needs to generate the PTK. The user station creates the PTK and now holds the key it will use for encryption.
- Stage 2: The user station sends back its own nonce value along with a MIC. The access point now holds everything that it needs to create the PTK. The access point creates the PTK and is in the same state as the user station.
- Stage 3: The access point creates and sends the Group Temporal Key (GTK) to the user, which enables the reading of non-directed traffic such as multicast/broadcast traffic.
- Stage 4: The user station returns an acknowledged statement.
Following the four-stage handshake, the user station can now send encrypted data to the access point and have it accepted. At this point, the negotiation phase is complete and the user station is free to use the network.
Four-Way Handshake Using Krack
Keeping in mind what we just discussed, you may now be surprised to find that this process is vulnerable to attack! However, the issue is not the core concept, but the practical implementation of the standard. As with most technical standards, sacrifices were made to the security of the solution in order to make it user-friendly. In specific, the sacrifice that was made to make the solution usable was making certain stages in the handshake replayable in the event of a missed message.
While this is not a huge issue for most of the process, Stage 3 is replayable and can have a dramatic effect on the security of the overall solution. By placing themselves in a Man-in-the-Middle (MITM) position during the authentication process, an attacker can block the correctly negotiated PTK and install their own in certain circumstances. The Key Replay Counter and associated nonce values are reset when a key is negotiated. So by blocking certain packets, an MITM attacker can predict what counter and nonce values are going to be by forcing a key reinstall. This will enable future attackers to perform malicious actions such as decryption, spoofing, and packet replay.
However, in deference to how the security industry operates, researchers have wisely only released Proof of Concept (PoC) scripts showing that the attack can be performed on client devices, and they have not released full-attack scripts to fully carry out the attacks against established networks. It should be noted, however, that they have announced that Android and Linux distributions are vulnerable to a key reinstall attack that forces the use of an all- zero key, effectively making traffic decryption trivial.
We will now go through using the scripts as distributed through Mathy VanHoef’s GitHub page.
1. First, open a terminal in Kali and type the command as shown in the following screenshot:
2. We will have to install the dependencies that the project relies upon. This will be achieved with the following command:
apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python-scapy python-pycryptodome
Change into the created krackattacks-scripts directory and check the contents. It should look like the following:
In this folder you can see the body of testing scripts and the solution Mathy and the team have put together. Before we can start playing with them, though, we need to compile hostapd in the format that they need.
The script itself provides these instructions on first use. However, I’ve written them here for clarity.
4. Change into the hostapd directory using the commands shown in the following screenshot:
This will have compiled hostapd for use in the KRACK attack PoC scripts. To verify that it’s built correctly, the folder should look like the following:
5. Change into the krackattack directory in the project root directory. It should look like the following screenshot:
The scripts will recommend executing the disable-hwcrypto.sh script upon first use. However, after using an Alfa AWUS051NH and a Kali Linux VM, I found that this script would only crash the VM and the scripts worked regardless. It is a user’s choice whether to carry this step out, but discretion is advised.
There are three other important files in this directory. Firstly, hostapd.conf defines the Wi-Fi details of the network to be generated. The defaults are testnetwork as the SSID and abcdefgh as the passphrase. Feel free to change these to your satisfaction.
Second, the krack-test-client.py script is the script that we will be using to identify vulnerable devices. This is the main focus of this chapter.
Finally, there is the krack-ft-test.py which we will not cover the usage of in this blogs due to its application to niche wireless devices outside of the standard distribution.
Next, we actually get KRACKing.
6. We will need to disable network manager to avoid conflicts using the following commands:
systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
7. We can then execute the krack-test-client.py script with the following command:
You will then see the following screenshot:
8. Now get hold of a test device, any Wi-Fi-enabled device, and connect to the created network with the credentials described earlier or whatever you’ve set it to.
The terminal will fill with text, but the script will helpfully mark any successful attacks in green as shown in the following screenshot:
The script will iterate through the potential attacks and inform the user whether the device tested is vulnerable.
In this Blogs, we’ve gone over the new KRACK attack, covered how the WPA2 handshake works, and saw how to perform a PoC check against a device. The KRACK attack will develop as time goes on and more scripts are released into the wild. Readers should keep up with the community and monitor for new and interesting applications of this research.
If You Want To Know More About Hacking Then Click Here