Awesome

KRACK: (K)ey (R)einstallation (A)tta(ck)

From the KRACK <a href="https://www.krackattacks.com/">website</a>:

In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol. By manipulating cryptographic handshakes, we can abuse this weakness in practice.

Unless a known patch has been applied, assume that all WPA2-enabled Wi-Fi devices are vulnerable.

Administrators: Remember to <a href="https://github.com/kristate/krackinfo/subscription">watch this page</a> for changes

Go Directly to Vendor Response Matrix

For Android devices please check the Android Response Matrix

日本人の皆さまへ： こちらをご覧ください(日本語)

The Good

• Should a vendor take responsibility, devices are for the most part updatable.
• Access points are only affected, if they implement the standard 802.11r (a.k.a. Fast-BSS Transition).

The Bad

• Many devices do not have an easy way to apply updates.
• A huge burden is placed on the consumer to keep their devices up to date
  • It may not be easy to search for all updates to all devices.
• The attack affects both clients and access points
  • Updating an access point does not keep clients protected!

The Ugly

• Attacks against Android 6.0+ devices are very easy to accomplish.
  • It is advised to disable Wi-Fi and only use 4G for the time being.
• Updates may never come for many IoT devices.

Attacks that can be made

• Adversary can decrypt arbitrary packets.
  • This allows an adversary to obtain the TCP sequence numbers of a connection, and <a href="https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack">hijack TCP connections</a>.
• Adversary can replay broadcast and multicast frames.
• Adversary can both decrypt and inject arbitrary packets. (TKIP or GCMP ONLY)
• Adversary can force the client into using a predictable all-zero encryption key. (ANDROID 6.0+ and LINUX)

Attacks that cannot be made

• Adversary can not recover WPA password.
• Adversary can not inject packets. (AES-CCMP ONLY)

Further information

• Marthy Vanhoef gave an overview presentation including implications at the conference 34c3. A recording of his session is available.
• A set of scripts has been made available which allows to check devices whether they are vulnerable.

CVE List and Device Types Affected

The reinstallation attack is not a single attack, but a group consisting of ten (10) independent security flaws which do have a common underlying approach. The security holes may be exploited indepdently of each other, and thus have to be fixed individually (if a device is affected). As it is common in computer security, each of them got assigned to a Common Vulnerabilities and Exposures (CVE) number, which are aggregated in VU #228519 for better tracking. Based on a statement provided by Zyxel you may group these CVEs based on which communication party is affected:

Access points, which are intended for the consumer market, typically do not implement the standard 802.11r. However, access points for the enterprise market may do so.

Based on the table above, it becomes apparent that the primary effort for correcting the security flaw is to be expected for the Wi-Fi clients. As of writing, there is no possibility known to safeguard Wi-Fi clients by changing the access point's behavior. This implies that patching the Wi-Fi device is the only way to fix the problem for Wi-Fi clients.

Related Reading

• https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/
• https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathread_check_back_often_for_updated/

Vendor Patch Matrix (non-complete)

Vendor Response (complete)