Attacks on Wi-Fi. KRACK in practice
In the fall of 2017, the world learned about a new threat to the security of Wi-Fi networks. It affects absolutely all devices and software platforms. No matter how complicated and long the password may be, this will not help, because KRACK is a vulnerability of the WPA2 encryption key exchange protocol itself. In this article, we will understand the theory of a bug and try to test it in practice.
On October 16, 2017, information was disclosed about critical WPA2 problems that circumvent protection and, as a result, listen to Wi-Fi traffic transmitted between the access point and the computer.
The complex of vulnerabilities in WPA2, called KRACK (abbreviation for Key Reinstallation Attacks), was discovered by a joint group of researchers from various universities and companies.
Team leader Mati Vanhof said that he managed to find the problems that make up KRACK back in 2016, but he improved his attack for more than a year. The researcher reported vulnerabilities to some manufacturers and representatives of the US-CERT organization in July 2017, and in August shared information about problems with a wide range of vendors.
Equipment manufacturers hastened to release firmware patches that eliminate vulnerabilities, but, as always happens in such cases, there remains a huge number of non-updated devices.
The attack is based on the vulnerability of the four-element handshake WPA2. This handshake is performed when the client wants to connect to a secure Wi-Fi network. The process confirms that both parties (client and access point) have the correct credentials. At the same time, the handshake is used to negotiate a fresh encryption key, which will subsequently be used to protect traffic.
An attacker could launch a man in the middle attack and force network participants to reinstall encryption keys that protect WPA2 traffic. In addition, if the network is configured to use WPA-TKIP or GCMP, an attacker can not only listen on WPA2 traffic, but also inject packets into the victim’s data.
By exploiting this critical error, you can decrypt traffic, make HTTP injections, intercept TCP connections, and much more.
The use of HTTPS can protect against KRACK, but by no means always. The fact is that HTTPS itself cannot be called absolutely secure (for example, there are downgrade connection methods), although it will become an additional layer of encryption.
The method is universal and works against any unpatched devices connected to Wi-Fi. The main condition is that the attacker will have to be in the range of the attacked Wi-Fi network, that is, the attack cannot be carried out remotely.
Vulnerabilities included in KRACK.
CVE-2017-13077: reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
To demonstrate the vulnerability, we need equipment - at least one, or better, several USB Wi-Fi adapters compatible with Kali Linux. My choice fell on the TP-Link N150 Wireless High Gain USB Adapter (TL-WN722N), it has already been tested and is well compatible with my distribution. But you can use any other to your taste.
Why do we even need this “whistle” if the laptop has a Wi-Fi adapter? A separate device for wardriving is recommended not only because it has fewer pickups and it has a stronger antenna, but also for reasons of convenience. With the built-in Wi-Fi adapter, you can simultaneously access the Internet, and this is a pretty important opportunity.
In general, with TP-Link we will raise our fake (or, if you like, test) network and we will perform our experiment in it.
Let's get Wi-Fi up on Kali Linux.
So, download Kali and go to the taskbar (upper right corner of the desktop), raise the Wi-Fi adapter (that is, turn it on) and connect to a pre-prepared network.
We have WPA2-Personal encryption key, and we’ll immediately agree to use a long and strong password. The network to which we will connect is called SKG2.
Install the Krack Attack toolkit.
First, we need to make sure that we have all the necessary dependencies for the Krack Attack toolkit in our system. Run the following command:
sudo apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysf
Since Kali Linux itself does not by default have the tools to play the attack we need, we go to GitHub and download a set of scripts there.
$ git clone https://github.com/vanhoefm/krackattacks-scripts.git
Next, for the purity of the experiment, we need to disable hardware encryption. That is, we will only encrypt the keys with software embedded in Wi-Fi protocols. To do this, go to the directory with Krack Attack:
$ cd krackattacks-script
And there we run the configuration script:
$ sudo ./krackattack/disable-hwcrypto.sh.root
Next, we need to disable Wi-Fi in the Kali network manager, that is, disconnect from the SKG2 network. This will allow you to start your own broadcast in the new WLAN0 network, where we will carry out the attack.
The next step is to create a test Wi-Fi network using TP-Link N150. However, first we need to make sure that our hardware is not blocked. And we will find out using the rfkill utility by typing the following command:
$ sudo rfkill unblock wifi
After the test network is created, we use the krack-test-client.py script. This Python script will check all devices connecting to our Wi-Fi network for the vulnerability of the “Key Reinstall Attack” vulnerability (this is what this method is officially called).
So, create a grid. Compile our modified hostapd instance. If you are not in the know, hostapd is a daemon (service) of a wireless access point in Linux.
$ cd ../hostapd
$ cp defconfig .config
$ make -j 2
Disable hardware encryption for our fake network with the following command (run the same configuration script):
$ cd ../krackattack/
$ sudo ./disable-hwcrypto.sh
In fact, after the script runs, you need to reboot (as the developers of the tool advise). But everything worked for me without reboot. But if something goes wrong, reboot the car.
After rebooting (or without) we execute the command
$ sudo ./krack-test-client.py
This is the same Python script that will allow you to reinstall the keys in a four-way handshake and will automatically create a network. The WPA2-Personal encryption method is used, and the SSID will be testnetwork.
Now we take a laptop with Windows 10 and we cling on it to the testnetwork network. We enter our very complex and long password and make sure that the connection has occurred.
After the laptop with Windows 10 ended up in the test network, in the Kali terminal we receive notifications from the krack-test-client.py script, which tries to scan the connected client (our laptop) for vulnerability and, if it finds it, exploit it.
But the result is still sad. Windows 10, of course, has a patch, which the Client DOESN’T line seems vulnerable to pairwise key reinstallation in the 4-way handshake says.
Let's try a few more options specified by the keys to the script.
$ sudo ./krack-test-client.py --group
$ sudo ./krack-test-client.py --tptk
$ sudo ./krack-test-client.py --tptk-rand
But of course, nothing works. Are we really trying so much in vain?
Not in vain! I easily found a vulnerable device - it turned out to be a phone with Android 7.0, which was last updated in July 2018. Such for sure you can still meet.
Connect the smartphone to testnetwork and see what our script tells us. A few seconds of waiting, and he reports that Android is vulnerable to group reinstallation of keys in a four-way handshake.
We have achieved the result! Then you can open, for example, Wireshark and sniff packets. In general, the experiment showed that KRACK is still a very real problem and the attack works.
How to protect yourself?
It turns out that almost every device on almost any Wi-Fi network can be hacked with KRACK. It sounds scary, but - as is the case with any other attack - this is not the end of the world. Here are a few tips to protect yourself from KRACK:
First, always make sure that the browser’s address bar has a green padlock icon. If HTTPS is used, then KRACK will not allow traffic decryption;
secondly, be sure to put the latest security updates.
And of course, for critical sessions, you may not trust a wireless connection at all. Or use a VPN: with it you will have end-to-end encryption between the client and server.
Will KRACK help WPA3?
On June 27, 2018, the Wi-Fi alliance announced the completion of the development of a new security standard - WPA3. This is both a new security protocol and the name of the corresponding certification program.
The creators of WPA3 tried to eliminate the conceptual flaws that surfaced with the advent of KRACK. Since the key vulnerability was hidden in a four-way handshake, WPA3 added mandatory support for a more reliable connection method - SEA, also known as Dragonfly.
Simultaneous Authentication of Equals (SEA) technology has already been used in mesh networks and is described in the IEEE 802.11s standard. It is based on a Diffie-Hellman key exchange protocol using finite cyclic groups.
SEA refers to PAKE type protocols and provides an interactive method whereby two or more parties establish cryptographic keys based on knowing the password by one or more parties. The resulting session key that each party receives to authenticate the connection is selected based on information from the password, keys, and MAC addresses of both parties. If the key of one of the parties is compromised, this will not result in compromise of the session key. And even after learning the password, the attacker will not be able to decrypt the packets.
Another WPA3 innovation will be support for PMF (Protected Management Frames) for monitoring traffic integrity. But in the future, support for PMF will become mandatory for WPA2.
However, the fact that WPA3 is backward compatible with WPA2 has already sparked criticism from Maty Vanhof, the author of the KRACK attack. He is confident that there is a way around PMF to force the client to disconnect from the network.
The introduction of SEA, although it will complicate the conduct of dictionary attacks, will not exclude them and will only make them longer, and to bypass protection in open networks, the attacker will still be able to deploy his access point and intercept traffic.
In addition, WPA3 must be implemented in the device in hardware, and you cannot add support for it with a simple update. Accordingly, implementation will take many years, and information security researchers are not idle.