Researchers KRACK Wi-Fi Again, More Efficiently This Time
10.10.2018 securityweek Attack

Researchers who last year discovered security issues in the Wi-Fi Protected Access II (WPA2) protocol that made them vulnerable to an attack known as Key Reinstallation Attack, or KRACK, have just revealed more practical versions of the attacks.

KRACK, Mathy Vanhoef and Frank Piessens explained last year, could provide malicious actors within range of a victim with the ability to access information otherwise believed to be safely encrypted. Residing in the Wi-Fi standard itself, the bugs impact all implementations, including Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others.

Targeting several handshakes in the 802.11 standard, the KRACKs manipulate handshake messages to reinstall an already-in-use key, which results in nonce reuse and replay attacks, Vanhoef and Piessens explained last year.

In a new research paper (PDF) to be presented at the Computer and Communications Security (CCS) conference this month, the researchers detail improved KRACK variants and show how the countermeasures deployed last year can be bypassed.

Generalized against the 4-way handshake, the new attacks no longer rely on hard-to-win race conditions and employ a more practical method to obtain a man-in-the-middle (MitM) position.

The researchers also reveal that the Fast Initial Link Setup (FILS) – which is not yet deployed in practice – and Tunneled direct-link setup PeerKey (TPK) handshakes are also vulnerable to key reinstallations and that the Wireless Network Management (WNM) power-save features can be abused to trigger reinstallations of the group key.

“Moreover, we bypass (and improve) the official countermeasure of 802.11. In particular, group key reinstallations were still possible by combining EAPOL-Key and WNM-Sleep frames. We also found implementation-specific flaws that facilitate key reinstallations,” the two researchers note.

Unlike the original attack, which relied on hard-to-win race conditions to trigger the key reinstallation, the new KRACK abuses power-save functionality of 802.11 to make the access point (AP) temporarily buffer a retransmitted message 3. The AP then sends retransmissions of message 3 encrypted under the newly negotiated session key.

“This encrypted message 3 will always be accepted by the client, even if it already installed the PTK. For example, unpatched versions of Android, macOS, and OpenBSD all accept the encrypted retransmitted message 3, and subsequently reinstall the session key,” the paper reads.

A multi-channel MitM position is required to perform a KRACK attack, which now the researchers say can be achieved by forging Channel Switch Announcements (CSAs) to trick clients into switching to the desired (rouge) channel. Previously, special equipment to jam certain channels was being employed, but the new method was successfully tested against Android and Chromium.

The researchers also discovered that it is possible to delay the delivery of message 3 after it has been captured (thus no longer triggering the key reinstallation immediately). Thus, more frames are sent before the attack occurs, meaning increasing the impact. The delay was successfully tested on Linux, Android, iOS, and macOS, and is also possible for encrypted messages.

“Our results show that preventing key reinstallations is harder than initially assumed. We believe the main reason vulnerabilities are still present is because the Wi-Fi standard is large, is continually being expanded with new features, and requires domain-specific knowledge to understand,” the researchers say.

“These obstacles can be overcome by having high-level descriptions (or formal models) of all security-related features of Wi-Fi. Additionally, we believe the Wi-Fi Alliance should not only test products for interoperability, but also fuzz them for vulnerabilities,” they also note.