Wireless Network Vulnerability - KRACK Attack


This morning, a paper was published outlining several flaws in the WPA2 encryption protocol for Wireless Networking.  The methods, dubbed KRAck (Key Reinstallation Attack) affect nearly every device that uses WiFi, at both the access point and client level. The WPA2 protocol is ubiquitous in wireless networking. The vulnerabilities described here are in the standard itself as opposed to individual implementations thereof; as such, any correct implementation is likely affected.  

From the discoverer's website (https://www.krackattacks.com):

"The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. To prevent the attack, users must update affected products as soon as security updates become available. Note that if your device supports Wi-Fi, it is most likely affected. During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks. For more information about specific products, consult the database of CERT/CC, or contact your vendor."

What does this vulnerability mean?

  • There is no risk of access to networks by those not physically present.
  • It is highly unlikely that any raw data is protected solely by the encryption that WPA2 provides.
  • Accessing secure websites such as those beginning with "https" is still secure.
  • Attackers are not able to recover existing WPA2 passwords, so there's no need to change any currently existing passwords.
  • If you're using WPA2 with AES, attackers may be able to decrypt normal traffic, but nothing else.  If you're using TKIP, however, you're significantly more vulnerable, as attackers are potentially able to forge and inject malicious data.

What should I do?

  • If you're unsure about what form of wireless encryption you're using, please contact us! (For our Meraki users, you're using WPA2 with AES, so good job!)
  • Update access point firmware as soon as fixes are released (Again, for our Meraki users, when Cisco releases the fix, your networks will be automatically updated that night.)
  • As software updates continuing security patches are released, we will begin pushing them out for our contract clients, as the client side is significantly more vulnerable than the access points, particularly on mobile devices.
  • For the Android users out there, stay alert for software updates and install them immediately. If you're running an older version of Android (before 7), then it may not be a bad idea to consider upgrading to something new, as you may not receive any updates to protect your phone (depends on the manufacturer).  While we definitely recommend the iPhone to anyone (and can help you make the swap, including all your data and apps), if you must stick with Android, I'd recommend going with a Google-branded device (like the Pixel), as those have the best chance of receiving future versions of Android.


Now for the fellow nerds out there, a bit more detail for the discoverer's website on the vulnerability itself: 

"In our opinion, the most widespread and practically impactful attack is the key reinstallation attack against the 4-way handshake. We base this judgement on two observations. First, during our own research we found that most clients were affected by it. Second, adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies. Decryption of packets is possible because a key reinstallation attack causes the transmit nonces (sometimes also called packet numbers or initialization vectors) to be reset to zero. As a result, the same encryption key is used with nonce values that have already been used in the past. In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted).In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.

The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to obtain the TCP sequence numbers of a connection, and hijack TCP connections. As a result, even though WPA2 is used, the adversary can now perform one of the most common attacks against open Wi-Fi networks: injecting malicious data into unencrypted HTTP connections. For example, an attacker can abuse this to inject ransomware or malware into websites that the victim is visiting.

If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic.Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets. Moreover, because GCMP uses the same authentication key in both communication directions, and this key can be recovered if nonces are reused, it is especially affected. Note that support for GCMP is currently being rolled out under the name Wireless Gigabit (WiGig), and is expected to be adopted at a high rate over the next few years.

The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked. Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent by the client. When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent towards the client. Finally, most of our attacks also allow the replay of unicast, broadcast, and multicast frames. For further details, see Section 6 of our research paper.

Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake.

Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key. Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack." 


Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Write a comment