Case Study 1: KRACK — When Every Wi-Fi Device in the World Was Vulnerable

Background

On October 16, 2017, security researcher Mathy Vanhoef of KU Leuven (Belgium) publicly disclosed a set of vulnerabilities collectively known as KRACK (Key Reinstallation Attacks) that affected the WPA2 protocol -- the wireless security standard protecting virtually every Wi-Fi network in the world. The disclosure sent shockwaves through the cybersecurity community and beyond: if WPA2 was broken, the security of billions of wireless connections was in question.

What made KRACK exceptional was not that it exploited a bug in a specific vendor's implementation. The vulnerability existed in the IEEE 802.11i standard itself -- the specification that defines how WPA2 works. This meant that every correctly implemented WPA2 client was vulnerable. The flaw was not in the code; it was in the design.

The Discovery

Mathy Vanhoef discovered the KRACK vulnerabilities while working on a formal analysis of the WPA2 four-way handshake as part of his doctoral research. His approach was methodical: rather than searching for implementation bugs, he examined whether the protocol's security properties held under all possible message sequences, including adversarial ones.

The key insight was deceptively simple. The four-way handshake is designed to handle message loss: if the access point does not receive message 4 (the client's acknowledgment), it retransmits message 3. The WPA2 specification states that upon receiving a retransmitted message 3, the client should reinstall the pairwise transient key (PTK). The specification did not address the cryptographic consequence of this reinstallation: it reset the nonce (packet counter) used for encryption.

In AES-CCM (used by WPA2-CCMP), the nonce serves as a counter that ensures each packet is encrypted with a unique keystream. Resetting this counter to zero causes the same keystream to be used for new packets as was used for previous packets. When two packets are encrypted with the same keystream, the encryption can be broken through a simple XOR operation:

Ciphertext1 XOR Ciphertext2 = Plaintext1 XOR Plaintext2

If one of the plaintexts is known (or partially known, as many network packets have predictable headers), the other can be recovered.

Technical Details

The Four-Way Handshake Vulnerability

The attack required the attacker to be positioned as a man-in-the-middle between the client and the access point. Vanhoef achieved this through a channel-based MitM:

  1. Clone the AP on a different channel: Create a rogue AP that impersonates the legitimate AP but operates on a different channel
  2. Force the client to the rogue AP: Use CSA (Channel Switch Announcement) beacons to direct the client to the rogue AP's channel
  3. Relay messages selectively: Forward handshake messages between the client and the real AP, but strategically delay or block message 4 to trigger retransmission of message 3
  4. Capture repeated keystreams: When the client reinstalls the key and resets its nonce, the same keystream is generated, enabling decryption

Severity Variations Across Platforms

The severity of KRACK varied significantly across platforms:

Linux and Android 6.0+ (Critical): The wpa_supplicant v2.4+ (used by Linux and Android) had an additional bug: upon key reinstallation, it installed an all-zero encryption key rather than reinstalling the real key. This meant that all traffic from the client could be trivially decrypted without any cryptanalysis -- the attacker simply decrypted with the known all-zero key.

Windows and iOS (Moderate): Microsoft's and Apple's implementations did not strictly follow the specification regarding message 3 retransmission handling. Windows did not accept retransmitted message 3 in certain states, and iOS had similar protections. However, the group key handshake vulnerability still affected these platforms.

macOS (Moderate-High): Apple's macOS implementation was vulnerable to the standard KRACK attack but not the all-zero key variant.

IoT and Embedded Devices (Variable): Many IoT devices, embedded systems, and older routers used vulnerable implementations and had limited or no update mechanisms.

CVE Assignments

KRACK affected multiple components of the WPA2 handshake, each assigned a separate CVE:

  • CVE-2017-13077: Reinstallation of the PTK-TK in the four-way handshake
  • CVE-2017-13078: Reinstallation of the GTK in the four-way handshake
  • CVE-2017-13079: Reinstallation of the IGTK in the four-way handshake
  • CVE-2017-13080: Reinstallation of the GTK in the group key handshake
  • CVE-2017-13081: Reinstallation of the IGTK in the group key handshake
  • CVE-2017-13082: Accepting a retransmitted FT Reassociation Request
  • CVE-2017-13084: Reinstallation of the STK in the PeerKey handshake
  • CVE-2017-13086: Reinstallation of the TDLS PeerKey in the TDLS handshake
  • CVE-2017-13087: Reinstallation of the GTK during TDLS handshake
  • CVE-2017-13088: Reinstallation of the IGTK during TDLS handshake

Impact Assessment

Scale of Vulnerability

The scope of KRACK was unprecedented in wireless security:

  • Billions of devices affected: Every Wi-Fi device using WPA2 was potentially vulnerable
  • Universal protocol flaw: The vulnerability existed in the protocol specification, not in vendor implementations (though implementation choices affected severity)
  • No password compromise: KRACK did not reveal the Wi-Fi password; it allowed decryption of traffic and, in some cases, injection of malicious packets
  • Proximity required: The attack required the attacker to be within Wi-Fi range of the target, limiting remote exploitation
  • Active attack: KRACK required active intervention (MitM positioning), not merely passive eavesdropping

Real-World Exploitability

While KRACK was a genuine and serious vulnerability, several factors moderated its real-world impact:

  1. Physical proximity requirement: The attacker needed to be within Wi-Fi range, which limited the attack to targeted operations rather than mass exploitation
  2. Application-layer encryption: Traffic protected by HTTPS, VPNs, or other application-layer encryption remained secure even if WPA2 was compromised
  3. Complexity: The channel-based MitM setup required specialized equipment and expertise
  4. Rapid patching: Major vendors released patches within weeks of disclosure (though IoT devices remained vulnerable for much longer)

What KRACK Could Not Do

It is important to clarify what KRACK did NOT enable:

  • It did not reveal the WPA2 passphrase
  • It did not allow permanent decryption of all past traffic (no forward secrecy violation for non-reinstalled sessions)
  • It did not allow remote exploitation (physical proximity was required)
  • It did not compromise traffic protected by higher-layer encryption (HTTPS, TLS, SSH)

The Disclosure Process

Vanhoef's disclosure process became a case study in responsible vulnerability disclosure:

  1. July 2017: Vanhoef notified CERT/CC and major vendors (Microsoft, Apple, Google, Linux, OpenBSD) under embargo
  2. August 2017: Notifications extended to additional vendors and the Wi-Fi Alliance
  3. October 16, 2017: Coordinated public disclosure with academic paper, website (krackattacks.com), and proof-of-concept code
  4. Patch coordination: Major vendors released patches on or near the disclosure date, having had months to prepare

The disclosure was widely praised for its thoroughness: Vanhoef provided clear documentation, a dedicated website with FAQs, proof-of-concept demonstrations, and open-source testing tools.

Remediation and Industry Response

Vendor Patches

Major vendors responded quickly: - Microsoft: Patched in October 2017 security update (before public disclosure) - Apple: Patched in iOS 11.1 and macOS High Sierra 10.13.1 - Google: Patched in Android November 2017 security update (though device-level rollout took months) - Linux: wpa_supplicant patched immediately, but distribution rollout varied - Router manufacturers: Major brands released firmware updates, but many consumers never applied them

IoT Challenge

The most significant long-term impact was on IoT devices: - Many IoT devices had no update mechanism - Some manufacturers went out of business before patches could be released - Industrial and medical devices often required lengthy certification processes before patches could be deployed - Legacy devices were effectively permanently vulnerable

Protocol Changes

KRACK directly influenced the development of WPA3: - WPA3 mandates Protected Management Frames (802.11w), making the MitM positioning more difficult - WPA3's SAE handshake is designed differently, though separate key reinstallation analysis was performed - The Wi-Fi Alliance implemented additional testing requirements for key installation behavior

Lessons for Ethical Hackers

  1. Protocol analysis is a valid attack surface: KRACK was found through formal analysis of the protocol specification, not through fuzzing or reverse engineering. Protocol-level thinking can reveal vulnerabilities that implementation-level testing misses.

  2. Test the handshake, not just the encryption: Wireless security testing should include verification that key installation and handshake behavior are correct, not just that encryption is enabled.

  3. Defense-in-depth justification: KRACK demonstrated why relying on a single security layer (wireless encryption) is insufficient. Penetration test reports should recommend application-layer encryption as a complement to wireless security.

  4. Patch verification is essential: During wireless assessments, verify that access points and clients are patched against KRACK. The krack-test-tool (available on GitHub) can test for remaining vulnerabilities.

  5. IoT devices may remain permanently vulnerable: When assessing environments with IoT devices, assume that some devices may still be vulnerable to KRACK and evaluate the risk accordingly.

Lessons for Defenders

Blue Team Perspective: KRACK reinforced several critical defensive principles:

  • Patch management for wireless infrastructure: Wireless access points, controllers, and client devices must be included in patch management programs. Firmware updates for network infrastructure are often neglected compared to server and workstation patches.
  • Application-layer encryption as defense-in-depth: HTTPS, VPNs, and other application-layer encryption protected data even when WPA2 was compromised. This is the strongest argument for universal HTTPS adoption.
  • IoT device lifecycle management: Organizations must have processes for tracking, updating, and retiring IoT devices. Devices that cannot receive security updates should be isolated on dedicated network segments.
  • Network monitoring for MitM indicators: The channel-based MitM required for KRACK has detectable characteristics. Wireless IDS systems can monitor for unexpected channel changes and AP impersonation.
  • WPA3 adoption planning: Begin planning and implementing WPA3 migration, prioritizing environments with sensitive data or high-security requirements.

Discussion Questions

  1. Why did Vanhoef describe KRACK as a "protocol-level vulnerability" rather than an "implementation bug"? What are the implications of this distinction for other security protocols?

  2. Why were Linux and Android 6.0+ disproportionately affected compared to Windows and iOS? What implementation decision caused the all-zero key installation?

  3. How did application-layer encryption (HTTPS) limit the practical impact of KRACK? Does this mean wireless encryption is unnecessary?

  4. What challenges did IoT devices present for KRACK remediation? How should organizations manage the security lifecycle of devices that may not receive updates?

  5. Evaluate Vanhoef's disclosure process. What elements made it effective, and what might you have done differently?

References

  • Vanhoef, M. and Piessens, F. (2017). "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2." ACM Conference on Computer and Communications Security (CCS).
  • Vanhoef, M. (2017). "KRACK Attacks: Breaking WPA2." krackattacks.com.
  • CERT/CC (2017). "Vulnerability Note VU#228519: Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated."
  • Wi-Fi Alliance (2017). "Wi-Fi Alliance security update." Official response to KRACK disclosure.
  • US-CERT (2017). "Alert TA17-318A: KRACK Wi-Fi Vulnerability." Alert and guidance.