On October 16^th,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 (WPA) and the Wi-Fi Protected Access II (WPA2) protocols. 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: https://www.krackattacks.com

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:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa

It is important to note both affected access points and the associated clients must be patched in order to fully remediate this issue. Installing the patches only in infrastructure wireless devices will not be sufficient in order to address all of the vulnerabilities. Similarly, fixing only the client will address nine (9) of the ten (10) vulnerabilities; however, it will not fix the vulnerability documented at CVE-2017-13082.

 

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://www.icasi.org/wi-fi-protected-access-wpa-vulnerabilities

Vulnerability Details and Additional Information

The following Common Vulnerability and Exposure (CVE) identifiers have been assigned to each of these vulnerabilities:

• • CVE-2017-13077
    • Reinstallation of the pairwise key in the Four-way handshake.
    • 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.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 Basic Service Set Identification (BSSID) 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:

 

1. Faking an infrastructure AP (rogue 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).
2. 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.

EAPoL Attack Protections

The following applies to vulnerabilities described in CVE-2017-13077 through CVE-2017-13081. Wireless clients can be protected relatively easy using Cisco Wireless LAN Controllers (WLCs).

In order to successfully exploit these vulnerabilities the attacker needs at least one additional EAPoL retry generated by the authenticator during the WPA 4-way handshake , or during the broadcast key rotation. Blocking the retries will prevent exploitation of the Pairwise Transient Key (PTK)/Group-wise Transient Key (GTK) vulnerabilities.

Configuration

There are two mechanisms available to achieve this configuration:

• Global: available in all releases
• Per WLAN: available  from Cisco WLC 7.6 to latest

The global option is the easiest to implement from the two options. All Cisco WLC versions support this option. When configuring .

Per WLAN configuration setting allows a more granular control, with the possibility to limit which SSID gets impacted, so the changes could be applied per device types, etc, if they are grouped on specific wlans. This is available from version 7.6

For example, it could be applied to a generic 802.1x WLAN, but not into a voice specific WLAN, where it may have a larger impact

 

Global configuration:

config advanced eap eapol-key-retries 0

(CLI only option)

The value can be validated with:

(2500-1-ipv6) >show advanced eap
EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000
EAPOL-Key Max Retries............................ 0
EAP-Broadcast Key Interval....................... 3600

Per WLAN configuration:

X=WLAN ID

config wlan security eap-params enable X
config wlan security eap-params eapol-key-retries 0 X

How to Identify if a Client is Deleted Due to Zero Retransmissions:

Client would be deleted due to max EAPoL retries reached, and deauthenticated. The retransmit count is 1, as the initial frame is counted

 *Dot1x_NW_MsgTask_6: Oct 19 12:44:13.524: 28:34:a2:82:41:f6 Sending EAPOL-Key Message to mobile 28:34:a2:82:41:f6
 state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
..
*osapiBsnTimer: Oct 19 12:44:14.042: 28:34:a2:82:41:f6 802.1x 'timeoutEvt' Timer expired for station 28:34:a2:82:41:f6 and for message = M3
*Dot1x_NW_MsgTask_6: Oct 19 12:44:14.042: 28:34:a2:82:41:f6 Retransmit failure for EAPOL-Key M3 to mobile 28:34:a2:82:41:f6, retransmit count 1, mscb deauth count 0
..
*Dot1x_NW_MsgTask_6: Oct 19 12:44:14.043: 28:34:a2:82:41:f6 Sent Deauthenticate to mobile on BSSID 58:ac:78:89:b4:19 slot 1(caller 1x_ptsm.c:602)

Rogue Detection

Several of the attack techniques for the vulnerabilities against the client PMK/GTK encryption, need to “present” a fake AP with the same SSID as the infrastructure AP, but operating on a different channel. This can be easily detected and the network administrator can take physical actions based on it, as it is a visible activity.

There are 2 ways proposed so far to do the EAPoL attacks :

• Faking infrastructure AP,  in other words, acting as rogue AP, using same mac  address, of a real AP, but on a different channel. Easy to do for the attacker but visible
• Injecting frames into a valid connection, forcing the client to react. This is a lot less visible, but detectable under some conditions, it may need very careful timing to be successful

The combination of AP impersonation features and rogue detection can detect if a “fake ap” is being placed in the network.

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.

Cisco Mobility Services (CMS) and Cisco Connected Mobile Experiences (CMX)

Cisco Mobility Services (CMS) coupled with Cisco Connected Mobile Experiences (CMX) software allows for detection of KRACK.

With Cisco Connected Mobile Experiences (CMX) 10.4 (coming out November 2017) or MSE 8.0MR5 with PI 2.2 and later, the location of the Rogue AP will be shown to the network administrator.

This is done by leveraging Cisco CMX location algorithms coupled with the RSSI strength signal. The result will help pinpoint any rouge AP’s and thus help discover possible KRACK atttacks.

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.

No workarounds have been identified for any of these vulnerabilities, with the exception of a workaround for CVE-2017-13082.

AP impersonation

On default configuration, the infrastructure can detect if the attack tool is using one of our AP mac addresses. This is reported as an SNMP trap  and would be indication that the attack is taking place.

Impersonation of AP with Base Radio MAC bc:16:65:13:a0:40 using source address of bc:16:65:13:a0:40 has been detected by the AP with MAC Address: bc:16:65:13:a0:40 on its 802.11b/g radio whose slot ID is 0

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.