WPA2 KRACK Attack Exposes Deficiencies in IEEE Standards Processes

Just when you thought it was safe to use wifi again, here we go with another vulnerability in the most popular wifi encryption scheme in use today, WPA2.

If you’ve been in the cybersecurity field for a while, you already know the reason there is a number 2 after WPA (Wi-Fi Protected Access) is that version number 1 had its own set of security flaws (as did the WEP scheme that preceded it… maybe there is a pattern here!).

Some of those had always been a part of WPA2 but were easily avoidable using various best practices—weak passwords, after all, are always going to be a problem regardless of how robust your encryption mechanisms are. And some implementation specific weakness (such as the MS-CHAPv2 weakness) and arcane vulnerabilities (like the Hole196 vulnerability) had been identified in WPA2 over the years it’s been in service, since 2006.

But the whole time, lurking at the heart of the IEEE 802.11i engineering standard that WPA2 was built to comply with, a more serious flaw awaited discovery.

KRACK, short for Key Reinstallation AttaCK, exploits the four-way handshaking protocol used to establish an encryption key for a WPA2 session. The handshake is a clever routine for both radios to establish that they agree on the underlying key to the network without actually exposing that key over the air, keeping it safe from direct attack.

KRACK manipulates the handshake by replaying previously transmitted handshake messages. This tricks the device on the other side of the protocol into reusing a previously used key stream. The attacker can use this knowledge to cryptographically attack the packets sent using the re-used key.

If this sounds complex and esoteric, it is; a successful KRACK attack doesn’t expose your traffic to any more vulnerability than surfing the web in a coffee shop. It allows attacks, theoretically (no known malicious KRACK attacks have surfaced in the wild yet), to compromise a network encryption key and sniff local area network traffic. That’s been a threat for years and there are other time-tested defenses against it.

Because of the general vulnerability of HTTP running across public networks, most web traffic—which is most traffic, period—is already running on another layer of encryption, the HTTPS protocol using robust Transport Layer Security or Secure Sockets Layer encryption.

Organizations, however, might be threatened if they have merged their wireless networks with their secure LAN systems. LAN traffic is rarely encrypted and would be vulnerable to eavesdropping if carried across a wifi network susceptible to KRACK.

A Best-Case Scenario Response to KRACK

Researchers notified CERT and the non-profit Wi-Fi Alliance, the body responsible for certification standards for wifi equipment, well ahead of publicizing the vulnerability, so manufacturers have had a head start on releasing patches to protect their equipment from the attack. Preliminary testing shows that most Apple and Microsoft devices and systems are already safe from KRACK. Android and Linux-based devices have proven more vulnerable.

In many ways, this is the best possible scenario, given the vulnerability. It could, after all, have been discovered by black hat or nation-state hacking groups, all of which would have had a head start on exploiting it. Providing the industry with enough notice to have a few patches in the pipeline by the time the flaw was announced is just about as good as it gets for such incidents.

But personal devices are only the tip of the iceberg and relatively easy to patch. The real threat is to router and access point devices, which most consumers slide under a table and forget about until they break. Few end users have any idea how to patch those devices, or even that they may need to be patched. Corporate IT will be more effective and proactive about upgrading router firmware, but as we’ve seen recently with the Equifax hack, something as basic as software patching is nonetheless outside the realm of competence for some IT units.

The Nightmare of a Snake in the Grass Haunts Security Professionals

The most astounding thing about KRACK might be just how long it took for researchers to discover the vulnerability. WPA2 was adopted in 2006 with the flaw already in place. For nearly ten years, it’s been used as the gold standard for wifi encryption without even a sneaking suspicion of such a widespread problem.

That is, until researchers at Katholieke Universiteit Leuven decided to dive into the WPA2 authentication process. Mathy Vanhoef and Frank Piessens found a flaw that had escaped thousands of other serious security researchers for more than a decade, cracking a process that had been formally proven as secure by a team at Stanford University.

Uncovering the flaw was a prodigious technical feat but for thinking cybersecurity professionals, it raises a troubling question… what other undiscovered flaws underly common, widely implemented standards? Are there other flaws waiting in WPA2, perhaps this time left to black hat researchers to uncover? Or, worse, major undiscovered vulnerabilities in SSL or TLS, issues that could bring the entire modern internet to a screeching halt even without being exploited?

These are thoughts that keep cybersecurity professionals awake at night. The process that lead to the discovery of KRACK is ongoing and remains a vital part of cybersecurity research.

Not All Industry Groups Make Cybersecurity Research Easy

Some security researchers, such as Matthew Green at Johns Hopkins, suggest that KRACK remained undiscovered for so long primarily due to the complexity and secretive nature of the IEEE standards process. Most other modern security and encryption standards are published openly and remain freely available to security researchers, who can comb the documentation for procedural issues without having to first reverse engineer the implementation.

But IEEE standards are available only to paying members (although the group has recently instituted limited sharing of some standards with security researchers through the GET program—on a six month delay). This means they don’t get the intense scrutiny before becoming widespread that more open formulations do. And the specifications leave much to individual implementations… a hole that in this case made devices from some manufacturers open to attack while others were never vulnerable, despite theoretically being written to the same specification.

Although the argument against security through obscurity has been more or less settled for years in the information security community, there persist some individuals for whom the simplistic logic remains compelling.