KRACK—Key Reinstallation Attack damages nearly all Wi-Fi security Done

Document by pair Belgian researchers added more light on the vulnerabilities detected in the Wi-Fi Protected Access II (WPA2) implementations on most, if not all, broadcast networking devices that use the protocol. Named “KRACK” (Key Reinstallation AttaCK), the attack “abuses design or implementation flaws in cryptographic protocols to reinstall an already-in-use key,” wrote Mathy Vanhoef and Frank Piessens of the Katholieke Universiteit Leuven in the paper, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 released today.
The report came after wide disclosure of the problems, as Ars reported Sunday night. The research is built upon previous explorations of weaknesses in WPA2’s component protocols, and some of the attacks mentioned in the paper were previously acknowledged to be theoretically possible. Still, the journalists have applied these vulnerabilities into proof-of-concept code, “and found that every Wi-Fi device is vulnerable to some variant of our attacks. Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.”
While Windows and iOS devices are safe to one flavor of the attack, they are susceptible to others. And all major operating systems are vulnerable to at shortest one form of the KRACK attack. Including in addendum posted instantly, the researchers recorded that information is worse than they appeared at the time the document was written:

Although this paper is made public now, it was already submitted for review on 19 May 2017. After this, only minor changes were made. As a result, the findings in the paper are already several months old. we have noticed easier techniques to take out our key reinstallation attack against the 4-way handshake. With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of communication 3 of the 4-way handshake. In special, this suggests that beating macOS and OpenBSD is significantly easier than presented in the paper.
Wi-Fi networks typically use shared keys (usually based on AES encryption) to protect network traffic. The code is distributed via a group of cryptographic “handshakes” that verify the identity of network clients. The attack style documented by Vanhoef and Piessens targets those cryptographic handshakes: the four-way handshake used to initially pass a shared key to the client or the PeerKey Handshake used in peer-to-peer network communications; the group code refresh handshake practiced by the network to change the key when a client leaves the network; and the Fast Basic Service Set (BSS) Transition (FT) handshake used to allow clients to roam around a network with multiple access points.
 Windows and Apple IOS devices do not vulnerable to the four-way handshake attack, all are vulnerable to the combination key handshake charge and the Fast BSS attack. Android 6.0,
Chromium and Android Wear 2.0 devices are particularly vulnerable to four-way handshake attacks—an attack actually causes the protocol to reinstall a predictable, all-zero key, making it trivial to decrypt the network’s traffic. The equivalent is sure of another Linux implementations that work report 2.4 and 2.5 of wpa_supplicant, the Wi-Fi client commonly used on Linux (wpa_supplicant’s most recent version is 2.6).
“This vulnerability appears to be caused by a remark in the 802.11 standard that suggests clearing parts of the session key from memory once it has been installed,” Vanhoef and Piessens explained. “As a result, currently 31.2 percent of Android devices are vulnerable to this exceptionally devastating variant of our attack.”
In an addendum to this article posted by the writers today, Vanhoef and Piessens developed on their issues, expanding the difficulty to all current Linux distributions:
Linux’s wpa_supplicant v2.6 is also vulnerable to the installation of an all-zero encryption key in the 4-way handshake. This was discovered by John A. Van Boxtel. all Android versions larger than 6.0 are also affected by the attack, and hence can be tricked into installing an all-zero encryption key. The new attack works by injecting a forged message 1, with the same ANonce as used in the original message 1, before forwarding the retransmitted message 3 to the victim.the attacker can force a targeted device to re-install an already-in-use shared key, downgrading the key.

Depending on the type of handshake being used between the nodes on the Wi-Fi network, the attack can do varying levels of damage:

    • Connections performing AES and the Counter with CBC-MAC Protocol ((AES)-CCMP), an attacker can decrypt network packets, making it possible to read their contents and to inject malicious content into TCP packet streams. Without that key itself stir be cut or shaped, so the attacker can’t forge a solution and join the network—instead, they have to use a “cloned” access point that uses the same MAC address as the access point of the targeted network, on a different Wi-Fi channel.
    • WPA2 operations applying the Temporal Key Integrity Protocol (TKIP), this Message Integrity Code key can be recovered by the attacker. This supports them to replay taken packages to the system; they can also forge and transmit new packets to the targeted client acting as the passage point.
    • For methods that handle the Galois Mode Protocol (GCMP), the crime is the unfortunate: “It is possible to replay and decrypt packets,” Vanhoef and Piessens wrote. “Additionally, it is tolerable to improve the authentication key, which in GCMP is used to protect both communication directions as consumer or access point, therefore, unlike with TKIP, an opponent can advance packages in both ways.” That means that the attacker can really join the system and represent to be a client or the access point, depending on the type of access they want. “Given that GCMP is expected to be adopted at a high rate in the next few years under the WiGig name, this is a worrying situation,” the researchers noted.

    Leave a Reply

    Your email address will not be published. Required fields are marked *