Mathy Vanhoef and Frank Piessens at KU Leuven disclosed KRACK yesterday — Key Reinstallation Attacks against WPA2 (krackattacks.com paper and USENIX Security 2017 paper). The flaw is in the four-way handshake of the WPA2 key-establishment protocol, used by essentially every wireless network deployed since 2004 to derive the per-session encryption keys between client and access point. The attack convinces the client to reinstall an in-use key, which resets the cryptographic nonce counter, which in turn allows the attacker to replay, decrypt, and (against some clients) inject packets into the WPA2-protected wireless session.
The technical specifics are interesting in their own right. The four-way handshake is a well-studied protocol — the academic cryptographic community has analysed it for years and produced formal proofs of its security against various attack models. The KRACK attack works against assumptions in those proofs that, as Vanhoef shows, do not hold against an active attacker who can replay the third message of the handshake. The vulnerability exists in the specification — every implementation that follows the specification correctly is vulnerable — and the fix is to modify implementations to refuse re-installation of an already-installed key. The protocol can stay; the implementations need to change. The CVEs (CVE-2017-13077 through CVE-2017-13088) cover specific implementation paths, and patches are being issued by Microsoft, Apple, the various Linux distributions, and the major access-point and router vendors over the next few weeks.
The deployment-population concern is the same as for every infrastructure-grade vulnerability. Microsoft Windows clients are being patched on the regular cycle. Apple iOS and macOS will follow shortly. Most modern Android devices will get patched through the regular Android security-update cadence — the population that does not receive timely Android updates remains a concern, as it has been for every Android disclosure since Stagefright. Embedded wireless clients in IoT devices, in industrial-control systems, in older mobile phones, and in various consumer-grade equipment are not going to be patched at all in many cases. The patching-coverage problem is the operational story.
The practical impact is more limited than the press coverage will suggest. The attack requires the attacker to be in wireless range of the target — physical proximity is necessary, this is not a remote internet-based attack. The decrypted traffic is wireless-frame-level traffic, which means TLS-protected content (which is most sensitive content in 2017) remains protected by the TLS layer. The attack is most damaging against unencrypted protocols (HTTP, plain DNS) carried over WPA2-protected wireless, and against protocols whose endpoints are improperly configured for TLS (for example, cleartext API traffic between an IoT device and its cloud back-end, or HTTPS sessions that allow downgrade). For the customer organisations whose corporate wireless networks I have spent today reviewing, the practical exposure is limited to the contexts where wireless-layer protection is the only line of defence.
Operationally, the action items this week are straightforward. Patch wireless-client OS where vendor patches are available; expedited patching cycle for the next four weeks across the customer fleet. Patch wireless infrastructure (access points and controllers) where vendor firmware updates address the corresponding CVEs on the access-point side. For consumer-grade or end-of-life equipment that will not be patched, the realistic mitigation is enterprise-grade controls: WPA2-Enterprise with proper certificate authentication and traffic monitoring, segmentation of any IoT devices using legacy wireless onto restricted VLANs with no access to sensitive systems, and HTTPS-everywhere posture so that the wireless layer is not the only protective layer.
For the customer briefings, the strategic conversation is about wireless infrastructure planning. Several customers have substantial wireless estates that are operationally important and have not been part of the systematic vulnerability-management programme in the same way as the wired-network estate. KRACK is the catalysing event for those customers to bring wireless infrastructure into the same operational framework — patch cadence, asset inventory, configuration auditing, segmentation review. The Browne Jacobson estate is being assessed this week; the manufacturer's larger campus wireless deployment is on a longer schedule because of the practical complexity of campus-wide patching during business hours.
The wider strategic point is one I keep coming back to in the year's writing. The protocols and implementations that secure the modern internet are the work of decades, and the assumptions they rest on are sometimes weaker than the formal proofs of their security would suggest. KRACK is a relatively benign case — a finding that produces specific patches against specific implementations and a manageable cleanup. The broader question of what other infrastructure-grade protocols have similar latent flaws is one that the academic cryptographic community continues to investigate, and one that the operational community has, in 2017, become more aware of than was the case ten years ago. The investments in formal verification, in protocol simplification (TLS 1.3 in particular, the IETF work on which is now in late stages), and in implementation audit are paying off, slowly. KRACK is a reminder of why those investments need to continue.