Perspective About the Recent WPA Vulnerabilities
Perspective About the Recent WPA Vulnerabilities
On October 16th,Mathy Vanhoef and Frank Piessens, from the University of Leuven, published a paper disclosing a series of vulnerabilities that affect the Wi-Fi Protected Access II (WPA2) protocol. These are protocol-level vulnerabilities that affect wireless vendors providing infrastructure devices and wireless clients, which follow the WPA and WPA2 specifications. These vulnerabilities were also referred to as “KRACK” (Key Reinstallation AttaCK) and details were published at: http://ift.tt/2kR33OH
What Cisco Products are Affected?
The Cisco Product Security Incident Response Team (PSIRT) has disclosed the impact of these vulnerabilities in Cisco products at the following Cisco Security Advisory:
http://ift.tt/2ymGF5g
Industry Coordination
Mathy Vanhoef originally reported these vulnerabilities to the Cisco PSIRT and we engaged the Industry Consortium for Advancement of Security on the Internet (ICASI) via the Unified Security Incident Response Plan (USIRP).
The USIRP enables Product Security Incident Response Teams (PSIRTs) from ICASI member companies to collaborate quickly and effectively to resolve complex, multi-stakeholder Internet security issues. These issues include: vulnerabilities in commonly-used software; incidents – urgent or emergent – that affect multiple ICASI member organizations; and ongoing or long-term problems that warrant a strategic response.
Cisco also worked with the researchers, CERT coordination center, the Wi-Fi Alliance, and several other industry peers during the investigation of these vulnerabilities.
ICASI has published a summary of the industry coordination and collaboration at the following link: http://ift.tt/2gIwGgM
Vulnerability Details and Additional Information
The following Common Vulnerability and Exposure (CVE) identifiers have been assigned to each of these vulnerabilities:
- CVE-2017-13077
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used pairwise key.
- An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.
- CVE-2017-13078
- Reinstallation of the group key in the Four-way handshake.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used group key.
- An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.
- CVE-2017-13079
- Reinstallation of the integrity group key in the Four-way handshake.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used integrity group key.
- An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.
- CVE-2017-13080
- Reinstallation of the group key in the Group Key handshake.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used group key.
- An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.
- CVE-2017-13081
- Reinstallation of the integrity group key in the Group Key handshake.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used integrity group key.
- An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.
- CVE-2017-13082
- Accepting a retransmitted Fast BSS Transition Re-association Request and reinstalling the pairwise key while processing it.
- The vulnerability could allow an unauthenticated, adjacent attacker to force an authenticator to reinstall a previously used pairwise key.
- An attacker could exploit this vulnerability by passively eavesdropping on an FT handshake, and then replaying the re-association request from the supplicant to the authenticator.
- CVE-2017-13084
- Reinstallation of the Station-to-station link (STSL) Transient Key (STK) in the PeerKey handshake.
- The vulnerability could allow an unauthenticated, adjacent attacker to force an STSL to reinstall a previously used STK.
- An attacker could exploit this vulnerability by establishing a man-in-the-middle position between the stations and retransmitting previously used messages exchanges between stations.
- CVE-2017-13086
- Reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant that is compliant with the 802.11z standard, to reinstall a previously used TPK key.
- An attacker could exploit this vulnerability by passively eavesdropping on a TDLS handshake and retransmitting previously used message exchanges between supplicant and authenticator.
- CVE-2017-13087
- Reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant that is compliant with the 802.11v standard, to reinstall a previously used group key.
- An attacker could exploit this vulnerability by passively eavesdropping and retransmitting previously used WNM Sleep Mode Response frames.
- CVE-2017-13088
- Reinstallation of the integrity group key (IGTK) when processing a WNM Sleep Mode Response frame.
- The vulnerability could allow an unauthenticated, adjacent attacker to force a supplicant that is compliant with the 802.11v standard, to reinstall a previously used integrity group key.
- An attacker could exploit this vulnerability by passively eavesdropping and retransmitting previously used WNM Sleep Mode Response frames.
Impact Categories
The aforementioned vulnerabilities can be grouped into two categories:
- those that affect wireless endpoints acting as a “supplicant”
- those that affect wireless infrastructure devices acting as “authenticators”
Exploitation
Exploitation of these vulnerabilities depend on the specific device configuration. Successful exploitation could allow unauthenticated attackers the reinstallation of a previously used encryption or integrity key (either by the client or the access point, depending on the specific vulnerability).
Once a previously used key has successfully being reinstalled (by exploiting the disclosed vulnerabilities), an attacker may proceed to capture traffic using the reinstalled key and attempt to decrypt such traffic. In addition, the attacker may attempt to forge or replay previously seen traffic.
An attacker can perform these activities by manipulating retransmissions of handshake messages.
Additional details on example attack scenarios can be found on the published paper and at the KRACK Attack website.
In all cases, an attacker will need to be adjacent to the access point, wireless router, repeater, or the client under attack. In other words, the attacker must be able to reach the affected
wireless network.
A Way to Detect the Attacks
Several of the attacks disclosed for attacker to “present” the same Service Set Identifier (SSID) as the real access point (AP), but instead operating on a different channel. An SSID is the primary name associated with wireless local area network (WLAN) including enterprise networks, home networks, public hotspots, and more.
Client devices use this name to identify and join wireless networks.This can be detected by Cisco enterprise wireless access points and customer can take actions based on notifications from the Wireless LAN Controllers (WLCs).
There are two fundamental ways that the KRACK attacks can be executed against WLANs:
- Faking an infrastructure AP: this includes creating same MAC address, but different channel. This is fairly easy to do; however, the attack is “very visible” (i.e., it can be easily detected).
- Injecting frames into a valid connection, forcing the client to react: this attack can be a little harder to detect; however, it can still be detected by looking for null key attacks, or Initialization Vector (IV) reuse. The wireless infrastructure devices (APs, WLCs, etc.) to detect data frames sent with its own mac address on currently operating channel. Wireless SMEs are looking into this.
Complete the following steps in a Wireless LAN Controller (WLC):
Step 1. Make sure rogue detection is enabled
Step 2. Create a rule to flag rogue APs using “managed SSIDs” as malicious:
Step 3. Navigate to Wireless > 802.11a/n/ac > RRM > General and ensure that Channel List is set to “All Channels” under the Noise/Interference/Rogue/Clean Air Monitoring Channels section.
These recommendations have been part of wireless best practices and are documented at the Rogue Management and Detection best practice document.
Workarounds
The IEEE 802.11r or fast BSS transition (FT) — also called “fast roaming” – could be disabled in a wireless infrastructure device to mitigate some of these vulnerabilities. Unfortunately, disabling FT will introduce performance issues in busy environments.
The FT key hierarchy is designed to allow clients to make fast BSS transitions between access points (APs) without requiring re-authentication at every AP. Modern WLAN devices support FT and typically it is enabled by default. When FT is enabled, the initial handshake allows the wireless client and APs to calculate the Pairwise Transient Key (PTK) in advance. These PTK keys are applied to the client and the AP after the client does the re-association request or response exchange with new target AP. Disabling FT could cause instability and performance issues in wireless networks and why it is not considered as a workaround in most environments.
Remediation
Cisco has started providing fixes for affected products, and will continue publishing software fixes for additional affected products, as they becomes available. The details about all affected products and available fixes can be found at the Cisco Security Advisory.
Tags:from Cisco Blog » Security http://ift.tt/2zdjMOB