This article will explain the implication of these vulnerabilities on enterprise WLAN networks.
What are these vulnerabilities
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 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.
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:
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?
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
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.
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?
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:
- The KRACK attacks website: https://www.krackattacks.com/
- The detailed research paper: https://papers.mathyvanhoef.com/ccs2017.pdf
- The series of videos from Mojo Networks: http://blog.mojonetworks.com/wpa2-vulnerability
- The great summary from Andrew Von Nagy: http://www.revolutionwifi.net/revolutionwifi/2017/10/wpa2-krack-vulnerability-getting-information
- A security point of view from WiFiTraining.com: https://wifitraining.com/blog/wpa2-vulnerability-krack-know/
- A great summary from Alex Hudson: https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/
- Cisco's security advisory message: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa
- Aruba's security advisory message: http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt
written by François Vergès