KRACK – Is it the end of WPA2?

October 16, 2017

By now you have probably heard that some WPA2 vulnerabilities have been discovered and made available to the public by Mathy Vanhoel on www.krackattacks.com.
This article will explain the implication of these vulnerabilities on enterprise WLAN networks.

WHAT ARE THESE VULNERABILITIES

Nine vulnerabilities has be revealed. Eight of them are client related and one of them is AP related.
Let’s begin by explaining the client related vulnerabilities.

When a Wi-Fi network is configured using WPA or WPA2, different group of keys are used between the client device and the access point:

PTK or Pairwise Temporal Key: keys used to protect unicast traffic
GTK or Group Temporal Key: keys used to protect broadcast and multicast traffic
IGTK or Integrity Group Temporal Key: keys used to protect management frames

These keys are generated and installed by the client and the AP during the 4-way handshake. The 4-way handshake is happening right after the WPA2 authentication phase. The authentication phase is when the client is authenticating using a pre-shared key or 802.1X.
Here is what a 4-way handshake looks like:

The vulnerabilities discovered are exploiting the fact that these keys (PTK, GTK, IGTK) can be re-installed by either the client or the AP. The attacks are, therefore, focusing on messages 3 and 4.

The fact of re-installing already-in-use keys will force some variables such as the Packet Number and the Nonce to be reset. This is important because these variables are used to generate the key stream ultimately used to encrypt data. If the keys are re-installed, the same key stream could be used more than once to encrypt data. The attacker will then be able to retrieve the plain text by applying a simple mathematical formula to encrypted packets transmitted using the same encryption key stream.

This means that all WPA2 networks are impacted (WPA2-Personal and WPA2-Enterprise).

This is a high level description of the following CVE:

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-13084: Reinstallation of the STK key in the PeerKey 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.

For more details on each of them, I would encourage you to watch these really thorough videos produced by Mojo Networks and Pentester Academy: http://blog.mojonetworks.com/wpa2-vulnerability.

Now, let’s go over the AP related vulnerability.

These keys (PTK, GTK, IGTK) are also installed by the client and APs during the 802.11r (or FT) handover. This is not done using the EAPOL packets used during the 4-way handshake. Instead, it is done using the 802.11 management packets used when a client roams:

Authentication Request
Authentication Response
Re-Association Request
Re-Association Response

Here is an example of these packet exchanges:

Here the vulnerability is related to the fact that some packets sent by the client (re-association request), can be replayed and resulting in the AP re-installing the keys.

This is a high level description of the following CVE:

CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.

Once again, for more details on each of them, I would encourage you to watch these really thorough videos produced by Mojo Networks and Pentester Academy: http://blog.mojonetworks.com/wpa2-vulnerability.

HOW BAD IS IT?

Unlike what the KRACK attacks website is stating, I don’t believe that these weaknesses are in the Wi-Fi standard itself. I believe they are all implementation issues. This is a good news because it means that they can be fixed by applying patches!

You remember the 8 client related vulnerabilities? Is it easy to exploit them?
Well, a man in the middle (MiTM) attack is required in order for an attacker to be able to take advantage of these vulnerabilities. This involves the attacker creating a fake AP with 2 radio interfaces:

One radio interface to talk to the AP on channel x
One radio interface to talk to the client on channel y

The fake AP will need to spoof the MAC address of the real AP when talking to the client device in order for this attack to succeed.
Moreover, in order to have the victim client device connecting to the fake AP (rather than connecting to the real AP), the attacker would need to place the fake AP close to the victim client device.
These facts increase the complexity of executing such an attack.

Now, how could we fix these vulnerabilities?
The fix would be to have the client NOT re-installing keys if they are already installed. This can be done by updating the implementation of WPA2 on the client device by applying a patch (no hardware change required). This can be tedious if you are supporting a lot of Wi-Fi devices and need to apply patched to all of them. However, it is doable over time.

The issue arise if the vendor do not release any patch to fix this issue. What could you do then, to mitigate KRACK?
In order to mitigate KRACK, you can upgrade the code of your APs and controllers in order to have them mitigating the issue. The AP could stop re-transmitting packets during the 4-way handshake, therefore avoiding the attack to ever take place. The side effect of this mitigation technique could be the generation of false positives. In order to avoid them, you could have the AP de-authenticating the client and forcing the client to go through a full new connection.

Moreover, you could use WIPS (Wireless Intrusion Prevention System) to detect the MiTM attacks and prevent the client devices to connect to these fake APs.

Now, what about the AP related vulnerability (802.11r handover)? Is it easy to exploit it?
It is actually much easier to exploit this vulnerability. No MiTM attack is required. The attacker will be sniffing the packets and replaying them later. This is called a replay attack.

How could we fix this issue?
Since there is no way for the AP to know if the traffic received is traffic coming from a replay attack, the only way to fix is to have the AP NOT re-installing keys if they are already installed.
This can be done by changing the implementation of WPA2 on the controller or AP applying a patch.
Some vendors have already released their patch code and the rest of them will in the coming days.

IS IT THE END OF WPA2?

Following the arguments presented in the previous section, I don’t believe this is the end of WPA2. In the coming days, we will see vendors starting to roll out patches in order to avoid these type of vulnerabilities to be exploited.

Most companies have acknowledged the KRACK vulnerabilities and some of them have already released their patches. See this really good article from Andrew Von Nagy for more details: http://www.revolutionwifi.net/revolutionwifi/2017/10/wpa2-krack-vulnerability-getting-information

Patches will be able to fix most of the devices out there. But now, what about these IoT devices that you will never patch? What about these devices that will never receive patches? 8 out of the 9 vulnerabilities revealed will be able to be exploited against them.

So what is next? Do we need a WPA3?
I believe that, for now, these patches will protect most of the enterprise WLAN networks. However, sooner or later, we will need to provide better security for IoT devices connecting to Wi-Fi networks. Does it mean WPA3? Does it mean that the IEEE will release a new security 802.11 amendment? I guess we will have to wait and see.

To be honest, I am a little worried by the way Mathy Vanhoel concluded his article: