TTCSIRT-082.012418: TT-CSIRT Advisory – KRACK Security Update
WPA2 Key Reinstallation Attacks (KRACKs)
Date first published: 23/1/2018
1.0 Introduction
TT-CSIRT wishes to advise that weaknesses have been discovered in the Wi-Fi Protected Access 2 (WPA2) protocol used to secure wireless networks. An attacker within range of a victim can exploit these weaknesses using key reinstallation attacks (KRACKs). Attackers can use these exploits to read information transmitted over the air (via Wi-Fi) that was previously assumed to be encrypted.
The vulnerabilities are within the WPA2 standard itself, and not in individual products of implementations. It should be noted that if your device supports Wi-Fi, it is most likely affected.
It is also important to note that the attacks do not recover the password of the Wi-Fi network, but instead exploit a vulnerability in the WPA2 standard itself, allowing an attacker to eavesdrop on a client(s) communication without having a need to know the network password. The attacker also needs to be in range of the Wi-Fi network.
2.0 Impact
• Impacts may include arbitrary packet decryption and injection, TCP connection hijacking, HTTP content injection, or the replay of unicast, broadcast, and multicast frames.
• This vulnerability can be exploited (via KRACKs) to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on. The attack works against all modern protected Wi-Fi networks. Depending on the network configuration (networks using Temporal Key Integrity Protocol – TKIP encryption and/or WPA(v1), or Galois/Counter Mode Protocol GCMP), it is also possible to inject and manipulate data. For example, an attacker might be able to inject ransomware or other malware into websites.
• As stated before, due to the issue being with the protocol implementation vs any specific vendor/product, this issue is considered widespread. The impact is therefore considered high.
• This issue was first reported in October of 2017 and as such, a number of manufacturers/vendors have released fixes for this issue already.
3.0 Affected Product(s)
• Most, if not all, Wi-Fi enabled devices are affected (Routers, Access Points, computers, phones, IoT devices, etc). A number of vendors have already released patches.
• A list of manufacturers affected or possibly affected can be found here, as well as patch release information:
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
4.0 Technical Description
The main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) the attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):
Key Reinstallation Attacks: High Level Description
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.
Key Reinstallation Attacks: Concrete Example Against the 4-Way Handshake
The idea behind a key reinstallation attack can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. An attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.
Associated CVEs
The following CVEs are associated with this exploit:
• CERT case ID: VU#228519
• CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
• CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
• CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
• CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
• CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
• CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
• CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
• CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
• CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
• CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
5.0 Recommendations
For End Users
• End users are advised to update their Wi-Fi enabled devices as soon as possible. Devices requiring update include:
o Computers
o Tablets
o Phones
o Wireless Routers
o IoT devices
o Security cameras
• Please note, a number of manufacturers have already released fixes for this issue and may have been automatically applied to your device if updated as of January 2018.
• Disable Wi-Fi for devices that are not updated and connect with Ethernet where possible. This is especially advised for highly sensitive information networks (such as Payment Card networks).
For System Administrators
• Update all enterprise wireless access points and endpoints as soon as possible.
• Please note, a number of manufacturers have already released fixes for this issue and may have been automatically applied to your device if updated as of January 2018.
• Disable Wi-Fi for devices that are not updated and connect with Ethernet where possible. This is especially advised for highly sensitive information networks (such as Payment Card networks).
• Ensure networks are properly segmented (hardware, VLANs and IP/subnet) to mitigate the effects of a compromised wireless network against the overall organization network.
It is not recommended to disable WPA2 since its protections are still worth the risk of someone attempting to exploit the vulnerabilities outlined here.
Additionally, it is recommended to only browse encrypted websites where possible (denoted by HTTPS in the address bar) since this transport layer encryption is separate from the Wi-Fi encryption and can still afford a level of privacy in your communications.
HTTPS only isn’t a bulletproof way to eliminate the risk associated with this exploit but a combination of the above recommendations should provide adequate mitigation.
For further enquiries, please contact TT-CSIRT through the following channels:
E-mail: contacts@ttcsirt.gov.tt or incidents@ttcsirt.gov.tt
Phone: 1-868-623-5439 (monitored during business hours)
Fax: 1-868-624-5831
Business Hours: Mon – Fri 0:800 AM – 6:00 PM. (GMT-4)
Twitter: http://www.twitter.com/ttcsirt2
Facebook: http://facebook.com/ttcsirt2