Understanding the KRACK Wi-Fi vulnerability

This post is supported by Penta Security.

By now, you would have heard about the devastating new Wi-Fi vulnerability known as KRACK, or “Key Reinstallation Attacks”. The flaw revolves around a weakness in the specifications of the WPA2 protocol for Wi-Fi communications, and is particularly devastating as it affects all modern Wi-Fi networks.

Vulnerable devices can be subjected to a wide variety of attacks including the theft of sensitive information. Crucially, vulnerable platforms include those that are widely-deployed including those from Android, Linux, Apple, Windows, OpenBSD, as well as devices from Apple, MediaTek and Linksys, among others.

How exactly does KRACK work, and how can IT managers and network administrators guard against it? Will Enterprise Wi-fi networks secured using 802.1X and good Wi-Fi practices offer protection to organizations? We take a closer look.

Understanding KRACK

The flaw was discovered by Mathy Vanhoef, a doctoral researcher in computer security and documented in a research report in May, though details were only publicly released last week. Ironically, Vanhoef was working on a different research paper when procrastination – in the form of excessive poring through source code, saw him chance upon a potential area of interest. He discovered KRACK upon further examination some weeks later.

The details behind KRACK is rather technical, though Vanhoef did an excellent job distilling the explanation in a detailed blog he set up specifically for KRACK here. In a nutshell, there is an apparent oversight in the specifications of the Wi-Fi standard with regards to the 4-way handshake of the WPA2 protocol. The oversight makes it possible to reset key parameters such as the incremental transmit packet number, known as the nonce, and the receive packet number – while using the same encryption key.

While this doesn’t break WPA2 by itself, it adequately weakens the encryption such that an intermediary component of the encryption process (the keystream) could be deduced with the presence of known content being transmitted. According to Vanhoef, finding packets with known content is not a problem in practice, which means that security administrators should be assumed that any packet can be decrypted.

Though executing a successful attack is contingent on multiple factors the Wi-Fi passphrase is left intact by the attack, this development effectively opens the door to a variety of attacks on the underlying data stream. The as the attack doesn’t concern itself with attacking the passphrase as traditional brute force attacks are, it means that even Wi-Fi deployments secured using enterprise encryption are not immune.

The practical impact

US-CERT has known of the bug for some months and informed vendors ahead of the public disclosure to give them time to prepare patches and prevent the vulnerability from being exploited. Indeed, there are ten different CVE IDs assigned to document the vulnerabilities stemming from the protocol weakness. The result is that many vendors such as Microsoft have already used the lead-time to create a patch to fix the flaw. Many vendors have not fixed this though, and work is ongoing to create the requisite patches.

One concern of KRACK is the variety of Wi-Fi-based IoT devices or wireless networked appliances that may be vulnerable. Though they can presumably be fixed over time, this may not be easy depending on the type of device and their locations. Based on past experiences with wide-spread vulnerabilities though, expect many of many such devices may be forgotten and vulnerable to attacks and snooping.

It is worth noting that the complexity of this vulnerability does mean that various ways of fixing it are available. What is not noted in most media reports is that both access point and client devices must be patched to properly resolve the vulnerability. Work being done to create modifications to Wi-Fi access points to prevent attacks against vulnerable client; the client would still be vulnerable if connected to a non-patched AP.

The implications for security

While the reporting on this issue has been relatively clear, some amount of misinformation has crept in. For a start, the inherent complexity of the attack means that the kind of exploits that could be pulled off is evolving. In general, the KRACK vulnerability gives hackers the possibility of injecting or modifying data, depending on whether the underlying traffic stream is protected by additional encryption protocols such as the use of SSL and an encrypted VPN connection.

What can users and businesses do in the meantime? The first to note that switching to WEP is a bad idea, considering that it was already considered broken more than five years ago. This means that a switch over to wired Ethernet may be necessary, in lieu of additional client-side encryption. Ultimately, nothing works better than ensuring that both access points and client devices are properly patched.

This entire episode illustrates the overriding need for multiple layers of security for genuine protection. If anything, it highlights the importance of SSL encryption over the transport layer to prevent snooping when browsing online. For websites yet to implement SSL, the Cloudbric web-based solution offers an easy click-to-enable SSL capability for encrypting the last-mile communication with the client.

Considering similar widespread vulnerabilities, I personally expect KRACK to stay with us for a long time. You can read the full report on KRACK here (pdf).

By | 2017-10-24T13:20:41+00:00 October 24th, 2017|Categories: Blog, The Work Lounge|0 Comments

About the Author:

Leave A Comment