360 Tianma Security Team (PegasusTeam) comments:

The basic principle of this WPA2 “key reloading attack” is to make use of the logic defects in the WPA protocol layer to retransmit the message 3 in the handshake process for many times, thus leading to the replay of random number and replay counter, which provides the attacker with the conditions to use.

There is also a dangerous comment in the protocol “once installed, the encryption key can be erased from memory”. If implemented according to this comment, the key value overwritten by 0 will be retrieved from memory during the key reinstallation attack, resulting in the client installing a secret key with all zero values. Linux and Android devices using WPA_supplicant are severely threatened. On the whole, the vulnerability is less harmful than the WEP vulnerability, but for Linux and Android devices, extra attention should be paid to timely update and repair this vulnerability to prevent sniffing, hijacking and other attacks.

Note that:

This attack cannot crack the WIFI password, and changing the WIFI password does not mitigate such attacks.

The attacks are primarily directed at client devices, and routers may not require installation updates.

The WPA/WPA2 protocol is still secure, and some client implementations need to be changed, which can be fixed through backward compatibility without replacing devices. Install the fix for your device as soon as it is released.

As of 14:00 BST, October 17, 2017, the official POC/EXP of this vulnerability has not been released.

General situation of

Recently, security researcher Mathy Vanhoef discovered a logical flaw in the WPA2 protocol layer, Almost all wi-Fi-enabled devices (including but not limited to Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys) are at risk of sniffing and tampering with transmitted data. The attacker can obtain data information in WiFi network, such as credit card, email, account number, photos, etc., causing great harm.

This type of attack is called Key Reinstallation Attacks. The vulnerability is due to the fact that the 802.11 standard does not define when a negotiated key should be installed in a 4-way handshake (and other handshakes), and an attacker can reset the random number and replay counter used by the encryption protocol by tricking the same key into being installed multiple times.

Figure 1

The CVE numbers related to this vulnerability are as follows:

Cve-2017-13077: Remount pair Encryption key in quad handshake (PTK-TK) CVE-2017-13078: Remount group Key in quad handshake (GTK) CVE-2017-13079: Remount pair Encryption key in quad handshake (PTK-TK) In four handshake reshipment complete set of keys (IGTK CVE - 2017-13080) : in group key handshake reshipment group key (GTK) CVE - 2017-13081: in group key handshake reshipment complete set of keys (IGTK CVE - 2017-13082) : Cve-2017-13084: Remount STK key IN PeerKey handshake CVE-2017-13086: Remount STK key in PeerKey handshake Re-install TDLS PeerKey (TPK) CVE-2017-13087 in TDLS (Tunneled Direct-link Setup) handshake: Cve-2017-13088: Complete Group Key (IGTK) for Wireless Network Management (WNM) Sleep Mode Response Frame

scope

Since the vulnerability exists in the WiFi protocol layer, this means that all clients that support WPA2 will be affected. According to the description, this key reloading attack can be used to:

WPA1 and WPA2 personal and business networks. Ciphers WPA-TKIP, AES-CCMP and GCMP

Although Windows and iOS do not accept retransmission of “message 3” (which does not comply with 802.11 standard) when implementing the “4-way handshake”, they are not affected by key resetting attacks during the 4-way handshake. However, Group Key Handshake and FT Handshake in 802.11r can still be attacked.

Figure 2

Versions 2.4 and 2.5 of wPA_supplicant implement the protocol comment “once installed, the encryption key can be erased from memory,” which causes the client to install the secret key with all zero values. As a result, Linux and Android devices using these versions of WPA_supplicant are at serious risk.

The following is the release timeline of wPA_supplicant:

Figure 2-2

As noted in the addenda, for WPA Supplicant 2.6, it is still possible to attack using John A. Van Boxtel’s method of faking message 1 with the same ANonce used in the original message 1, and then forwarding the retransmitted message 3 to the victim.

A time line

Around July 14, 2017, Mathy Vanhoef — notified the equipment supplier of the tested product. After communication with multiple suppliers, it was found that the vulnerability was common in almost all devices, which was actually a loophole in the protocol rather than an implementation problem.

29 August 2017, Mathy Vanhoef published “[Securely ImplementingNetwork Protocols: Detectingand Preventing Logical Flaws][4] describes the detection method of logic Flaws in network protocols.

On 28 August 2017, CERT/CC issued an extensive notice to suppliers.

On October 6, 2017, the vulnerability official website was launched and details of the vulnerability were disclosed on Paper.

As of now, the use of tools has not been announced.

protective

Update the software version of wireless router, mobile phone, smart hardware using WPA2 wireless authentication client in time. (With patches)

Enterprises and individuals with conditions should properly deploy WIPS (wireless Intrusion Prevention System) to timely monitor the phishing WiFi in legitimate WiFi areas and block the interference so that the malicious WiFi cannot work properly.

Wireless communication connections use VPN to encrypt tunnels and force SSL to avoid information leakage caused by traffic hijacking and manin-the-middle attacks.

Turn off the WiFi function of the mobile phone when not using WiFi, and do not log in accounts and passwords related to payment and property under public WiFi. If you need to log in, pay, switch the mobile phone to the data traffic network.

WPA/WPA2 is secure and you don’t need to change your WiFi password.

Repair situation

Hostapd and WPA_supplicant patches for Linux have been released on 2 October 2017. For details, see W1.fi/Security /20… .

On October 10, 2017, Microsoft released patch KB4041676 for Windows 10 operating system

Apple fixed wireless network security vulnerabilities in the latest beta versions of iOS, macOS, tvOS and watchOS

Details analysis

This attack focuses on the WPA2 protocol’s four-way handshake process, using a new attack technique called Key Reinstallation attack (KRACK). We know that when a client tries to connect to a protected WiFi network, the AP will initiate a four-way handshake to complete mutual authentication.

Figure 3

At the same time, a new encryption key is negotiated during the quad handshake to encrypt subsequent communication data.

Figure 4.

During the four-way handshake, after receiving Message 3 from the AP, the client installs an encryption key to encrypt normal data frames. Because messages can be lost or discarded, if the AP does not receive a response, the AP will retransmit Message3 so that the client may receive message3 multiple times. The client reinstalls the encryption key each time it receives this message, resetting the incremental send packet number Nonce and receive replay counter used by the encryption protocol. By collecting and replaying message3 in the re-send four-way handshake, an attacker can forcibly reset the Nonce, thus successfully attacking the encryption protocol, decrypting the communication packets sent by the client, and intercepting sensitive information.

In addition, the bug appears to have been caused by a single sentence in the WiFi standard. The standard recommends that once installed for the first time, the encryption key can be erased from memory. When the client receives the retransmission of message3 for the quad handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key.

It is worth noting that the attack did not obtain the password for the wifi network, nor the nascent encryption key negotiated during the quad handshake.

Demo Video Analysis

1. First, the test device is connected to the real TestNetWork:

Figure 5

2. Start WireShark and listen for the network adapter that is later set as a phishing hotspot:

Figure 6.

3. Attack Demonstration:

Real AP:

Ssid: testnetwork

MAC: BC: ae: c5:88:8 c: 20

Channel: 6

Target of the target client:

MAC: 90:18:7c:6e:6b:20

Forge the same MAC hotspot (Rouge AP) :

Ssid: testnetwork

MAC: BC: ae: c5:88:8 c: 20

Channel: 1 (different Channel)

Figure 7.

Injecting CSA Beacon Pairs changes the client channel to 1, which forces the client target to communicate with Rouge AP. The pseudo AP sends a Disassociate packet to the target target to Disassociate it.

4. Use the network adapter to establish a forged hotspot of the target AP and force the client to connect to the forged hotspot. The device is reconnected and the WiFI status is being authenticated.

When the target TARge completes the authentication process with the real AP and is ready to initiate the connection, CSA Beacon Pairs are injected to switch the channel to Channel 1 for manin-in attack, and the client state remains at State 2. Then message 3 in the four-way handshake is sent. Implement Key Reinstallation Attack.

Figure 8.

Figure 9.

5. The key reinstallation attack has been successfully executed and the client has been connected to the forged hotspot:

Figure 10.

6. In this fake hot spot, phishing sites are used to obtain user account information:

Figure 11.

7. The account information submitted by users on this phishing website can be obtained by attackers.

Figure 12

Q&A

Q: Should I change my Wi-Fi password?

A: You can use your home WiFi as you like. WPA/WPA2 itself is secure and you don’t need to change your WiFi password.

Q: I am using WPA2-CCMP. Is this still a security risk?

A: There are also security risks. WPA/WPA2, PSK and Enterprise are all at risk.

Q: The four-way handshake is theoretically proven to be safe. How did your attack work?

A: This attack does not contradict previous proof of WPA2 protocol security. Because the default key will only be installed once at the time of proof.

Q: Has anyone actually started to exploit this loophole?

A: We have no POC/EXP code published at this time

Q: Should I use WEP temporarily until my device is patched?

A: No, just use it how you want. WPA/WPA2 itself is safe

Q: How does this attack compare to other attacks against WPA2?

A: This is A WPA2 protocol attack that does not rely on password guessing.

www.4hou.com/wireless/80…