Keep Calm and Wi-Fi On: A Common Sense Approach to an Uncommon Problem

The exploit is called KRACK and details about this vulnerability have been published by the Imec-DistriNet research group of KU Leuven.

The exploit is called KRACK and details about this vulnerability have been published in true White Hat fashion, by the Imec-DistriNet research group of KU Leuven. Mathy Vanhoef has identified as many as ten vulnerabilities in the WPA and WPA2 protocols, which secure all modern protected Wi-Fi networks. These vulnerabilities were academically well-researched and responsibly reported in a manner allowing the industry to proactively prepare updates.

KRACK Vulnerability - Ruckus FAQ

Broadly, the exploit deals with how the WPA/WPA2 protocol handles requests to reinstall the encryption keys used to encode/decode traffic between a wireless client and an AP. The vulnerabilities can be described in two groups. The first set of vulnerabilities may allow the reinstallation of a pairwise transient key, a group key, or an integrity key on either a wireless client or a wireless access point. A transient key is one that is derived as part of the encryption of individual client sessions. It is not the PSK or user credentials and is a temporary key that is different for every client and every session. The second set of vulnerabilities may affect wireless supplicants supporting either the 802.11z (Extensions to Direct-Link Setup) standard or the 802.11v (Wireless Network Management) standard. This could also allow the reinstallation of a pairwise key, group key, or integrity group key. If a compromised key is installed (via a reinstallation procedure) an attacker can theoretically decrypt the transmissions between a client and an AP. Note, however, that each wireless client creates different temporary encryption keys that it uses with an AP. This is not a global attack but rather attacks a specific, targeted device. These vulnerabilities also only deal with the encryption of data using transient keys that are derived as part of the WPA2 protocol for each session. They are not the same as passwords or any other kind of credentials such as certificates.   What does this mean for you?
  1. Don’t panic. No, you do not need to shut down your Wi-Fi network.  The Internet did not suffer the equivalent of an EMP attack.
      1. Vulnerabilities exist on both sides of the 4-way handshake relationship (client and AP) and both sides need to be patched.
      2. Microsoft, Apple, Google, Intel, and other major vendors have been working on fixing these vulnerabilities for a few months now.
      3. Until client vendors provide updates, disabling 802.11r can help mitigate the attack by eliminating one source of vulnerability (Fast BSS Transitions, otherwise known as 802.11r roaming).
      4. Some client types, such as Android 6 are more vulnerable than others.
      5. iOS and Windows are not vulnerable to the first set of exploits because they don’t accept retries of handshake message 3.
  1. The sky isn’t falling. One, the attack must happen on-premises. Two, while the attacker can decrypt client-to-AP traffic, the attacker cannot inject arbitrary traffic into a WPA2-AES session and cannot get any authentication tokens or keys.
      1. To be successful, the attacker would need to be sophisticated, onsite, and armed with specialized hardware and software. To reiterate, there is currently no publicly available code that enables this attack.
      2. All current certificates and Wi-Fi passwords are still secure. This attack does not reveal passwords.
      3. While networks that use TKIP are vulnerable to packets being injected into the stream, AES does not allow for code injection. (TKIP and WEP have been broken for years so if your network is still either this may be a good time to do something about it.)
      4. A MitM (Man-in-the-Middle) attack is required prior to performing this because the 4thEAPOL message (part of the handshake) must be intercepted/prevented in order to allow retries of handshake message 3.  This means that the attacker must spoof the MAC of the AP.
      5. Mesh and PtP links may be vulnerable (Remember: To be successful, the attacker would need to be sophisticated, onsite, and armed with specialized hardware and software. To reiterate, there is currently no publicly available code that enables this attack).
Steps You Can Take Now:
  1. Mitigate the risks caused by a MitM attack. By default, Ruckus has rogue detection enabled and automatically classifies spoofed MACs as a malicious threat, which can generate alarms for admins. Further, admins can enable APs to protect against Man-in-the-Middle attacks by deauth’ing clients connecting to a malicious rogue AP, which is required to carry out this attack.
  2. Eliminate the 802.11r vulnerability. Ruckus disables 802.11r by default on all SSIDs. If it is enabled on your network, consider disabling it until a fix is in place.
  3. Ruckus APs have additional protection against MitM attak for Mesh links - this makes the attacker to be even more sophisticated to hijack the Ruckus Mesh link. Mesh enabled networks that are not using mesh can have that disabled on a per-node basis.
  4. Go to the Ruckus Security Bulletin to learn about Ruckus’ counter-measures and updated patch release information.
The WPA/WPA2 protocol is not fundamentally flawed. This means that exposure is limited and fixable without throwing out WPA2 altogether. Software/firmware patches that address this are already being rolled out. It is important to remember that, while concretely feasible, these attacks require not only access to your network, but a degree of knowledge and sophistication well beyond, say the Equifax hack, for a lot less return. We always recommend that anyone interested in securing their WLAN network should perform regular audits of their security infrastructure and procedures to ensure everything is in compliance with best practices and vendor recommendations.

For some excellent perspective on the impact of the KRACK vulnerability, read this W-Fi vendor neutral blog by noted Wi-Fi analyst, Peter MacKenzie, and this post by Security Architect, Kevin Beaumont.