Luke Potter, head of cybersecurity at SureCloud, examines the KRACK vulnerability and provides steps for guarding against it
This week, several vulnerabilities in the WPA and WPA2 protocols that would enable an attacker to decrypt wireless network packets, and even inject into the network traffic on the wireless network directly, were publically disclosed. This would mean that in some cases, an attacker could potentially intercept and manipulate requests to sensitive websites with an aim to capture the credentials.
The ultimate impact of this vulnerability being successfully exploited would allow an attacker the ability to decrypt WPA/WPA2 wireless traffic. This would mean that any cleartext network traffic could be viewed as if the attacker were on the same network as the victim. However, this does not necessarily mean that traffic encrypted through a VPN (Virtual Private Network) or secured with HTTPS would be directly affected.
The proof of concept video that was released alongside the disclosure demonstrated an example where a victim visiting ‘match.com’ was targeted with an additional exploitation layer using ‘SSLStrip’, whereby the victim was downgraded on to a plaintext HTTP connection. This is of course a very real scenario that could happen – even though the control of security over third-party webservers is not possible.
Understanding KRACK
That flaw identified by researchers is within a specific part of the WPA/WPA2 protocol that is broadcast during the initial connection to a wireless access point. When a client is authenticating to a wireless network, the Access Point (AP) and client, exchange a 4-way handshake that mutually assures that each device has the appropriate secret key, and then establish an encrypted channel for further communications. The Pairwise Transient Key (PTK), sometimes called the “Session Key”, breaks down into the following parts:
- Key Confirmation Key
- Key Encryption Key
- Temporal Key
- Message Integrity Code (MIC) Authenticator Transmit Key
- Message Integrity Code (MIC) Authenticator Receive Key
Each of these keys has a difference usage within the WPA protocol, but the main one that is affected is the “Temporal Key”, which is the key-part that is used to encrypt the Wi-Fi traffic, or to be more specific, the non-broadcast Wi-Fi traffic. The Group Temporal Key (GTK) is used in a similar way to encrypt broadcast and multicast traffic. There are also other handshakes too; while the GTK is initially transferred during the first 4-way handshake as described above, it is independent of the PTK and is updated with a separate handshake.
To be able to leverage these vulnerabilities to attack a client device, an attacker would need to be present during the 4-way handshake, which is only performed when first connecting to the wireless network’s access point. However, an attacker can force this by sending de-authentication packets to the client device, which will effectively and forcibly disconnect the client from the wireless network, resulting in the client and access point performing another 4-way handshake. This technique is typically used when attempting to capture the handshake for wireless network attacks against PSK networks.
When an attacker is present during the 4-way handshake, it is possible to replay message 3, which is where the GTK is transmitted. This causes the PTK to be “installed” again (or “reinstalled”), which means while the same PTK is used, various associated counters and nonce values that have already been used are re-used again. These values being used a second time means the keystream is reused when encrypting network traffic. If a message that reuses this keystream has known content, such as the predictable words found in HTTP headers, then it becomes trivial to derive the keystream. This keystream can then be used to decrypt messages with the same nonce. If there is not a source of predictable underlying content, the decryption becomes harder, for example if the target is exclusively using a VPN. But if the target is using a VPN, successful exploitation would still not defeat the protections of the VPN.
With Android 6.0 and WPA Supplicant 2.6, an additional bug can be triggered where the Temporal Key within the PTK (the part used to encrypt the network traffic) is set to all zeros, thus rendering the entire stream trivial to intercept or inject into. This also requires forging message 1 within the 4-way handshake, as well as retransmitting message 3.
Rapid response
While the potential threat posed by KRACK is clearly disturbing, it was reassuring to see a quick response from many vendors. For instance, certain vendors were aware of this vulnerability as early as the 14th July 2017, after being directly tested as part of this research. The extent of which vendors were notified is unknown, but a broad notification was sent to vendors by CERT/CC on the 28th August 2017. As such, there are several vendors that have already released security patches for this vulnerability, with some silently releasing the security updates prior to this public disclosure.
In a positive step, Microsoft and various Linux distributions have claimed to have released updates for their operating systems. Google are expected to release Android patches in the immediate days and weeks following the public disclosure, whilst other vendors will need checking with directly. Unfortunately, there will likely be a large range of IoT (Internet of Things) devices, legacy mobile phones, and other unsupported devices that will never be patched.
Mitigating the risk
In addition to ensuring that all relevant vendor patches are applied there are other steps that businesses can take to mitigate against this vulnerability. First we would highly recommend ensuring that any client devices are using a secure VPN to connect through wireless networks until security updates are available and can be deployed to these devices.
Second, for organisations or individuals offering websites and applications, mobile apps, etc. we would recommend reviewing the current configuration of these services and ensuring that cleartext protocols and downgrade attacks are not possible. Providing secure services is an aid in mitigation for these attacks. Finally it is highly advisable to perform an authenticated vulnerability scan once all vendor patches have been made publicly available.
While this is no doubt the most critical vulnerability found within the WPA/WPA2 protocol, with the vulnerabilities affecting every computer or wireless-enabled device across the world, security patches are being released quickly by many vendors. One of the mitigating factors for this particular flaw is that Windows and iOS devices are slightly less affected in comparison to Android, Linux, MacOS, and OpenBSD. With Windows being one of the lesser affected systems, the fact the attack works on WPA2 Enterprise is made somewhat less dangerous. In conclusion, blue teams and individuals should look to patch as soon as possible as the exploit tools will likely be available in the next few days or weeks.
[su_box title=”About Luke Potter” style=”noise” box_color=”#336588″][short_info id=’102737′ desc=”true” all=”false”][/su_box]
