Cisco Blogs
Share

Perspective About the Recent WPA Vulnerabilities (KRACK Attacks)

- October 16, 2017 - 35 Comments

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 (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:

KRACK Attacks 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.

Tags:
Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed and HTML formatting will not appear.

All comments in this blog are held for moderation. Your comment will not display until it has been approved

35 Comments

  1. Here's the CLI commands to enable the rule mentioned: --- rogue ap ssid alarm rogue rule add ap priority 1 classify malicious notify all state alert Internal rogue rule enable Internal rogue rule match any Internal rogue rule condition ap set managed-ssid Internal ---

  2. Will upgrade correct which vulnerability?

  3. I see that the Cisco AnyConnect Secure Mobility Client - Network Access Manager is listed as being vulnerable to CVE-2017-13078 and CVE-2017-13080. How does that impact a remote teleworker scenario, where they'd be using a Remote Access VPN with their Cisco AnyConnect client for everything running over that WPA2-based wireless link?

      Hi David, This does not affect the VPN functionality. Only the wireless supplicant. An attacker cannot exploit this vulnerability over a VPN tunnel. It can only trigger the vulnerability if the attacker is adjacent (within proximity) of the wireless network.

  4. Is there a caveat id number for this, with a pending code fix? Or with respect to the WLC are we just tweaking these settings and calling it good from the controller side?

      Hi, If you are referring to the Cisco "bug IDs", they are listed in the security advisory and I also included them below: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa CSCvf71749 CSCvf71751 CSCvf71754 CSCvf71761 CSCvf96789 CSCvf96814 CSCvf96818 CSCvg10793 CSCvg35287 CSCvg42682 Thanks! Omar

    Based on https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080 Microsoft has already published the fixes for the Windows client OSs in the OS update of 10th October 2017. Do you have information about the mobile platforms?

      For information about client fixes, you will have to refer to each vendor security advisory or support websites. Regards, Omar

  5. "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." In light of this comment: https://www.cs.columbia.edu/~smb/blog/2017-10/2017-10-16a.html Your remark needs to be clarified. The /attacker/ does not need to be adjacent to an affected wireless network. It is only necessary for the attacker to have control of a device which is in physical proximity to an affected wireless network. The attacker could be physically present anywhere in the world, so long as he can get control of a nearby wireless device (even a wireless enabled printer) from which to launch an attack.

    What I Understand from the post , if we disable FT under SSID, it will address the AP related vulnerabilities. Rest 9 vulnerabilities , we have to patch clients. Can you pleas correct me here ?

      Hi Manjit, That is correct. Also we need to keep in mind that 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.

        Hi Manjit, As a follow up, the following document from Meraki provides a good summary of the impact of each vulnerability (see the first table). https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-13082)_FAQ

      • Hi Omar, what does it mean "Similarly, fixing only the client ..." - how can I fix only the client, please? What does it mean, please? Thank you for reply.

          Hi, The client (i.e., wireless supplicant) can be your laptop, mobile device, tablet, IoT device, etc. This means Windows, Apple MAC OS X, Apple iOS, Linux, Android, etc. For information about client fixes, you will have to refer to each vendor security advisory or support websites. Regards, Omar

        Thanks a lot Omar !! It was really helpful to understand the impact.

    I entered this same question as a guest (Terry) What is the down side of Creating a rule to flag rogue APs using “managed SSIDs” as malicious:?

      Hi Terry, The following are some guidelines to manage rogue devices: (these are documented at: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_011011.html ) The containment frames are sent immediately after the authorization and associations are detected. The enhanced containment algorithm provides more effective containment of ad hoc clients. In a dense RF environment, where maximum rogue access points are suspected, the chances of detecting rogue access points by a local mode access point and FlexConnect mode access point in channel 157 or channel 161 are less when compared to other channels. To mitigate this problem, we recommend that you use dedicated monitor mode access points. The local and FlexConnect mode access points are designed to serve associated clients. These access points spend relatively less time performing off-channel scanning: about 50 milliseconds on each channel. If you want to perform high rogue detection, a monitor mode access point must be used. Alternatively, you can reduce the scan intervals from 180 seconds to a lesser value, for example, 120 or 60 seconds, ensuring that the radio goes off-channel more frequently, which improves the chances of rogue detection. However, the access point will still spend about 50 milliseconds on each channel. Rogue detection is disabled by default for OfficeExtend access points because these access points, which are deployed in a home environment, are likely to detect a large number of rogue devices. Client card implementations might mitigate the effectiveness of ad hoc containment. It is possible to classify and report rogue access points through the use of rogue states and user-defined classification rules that enable rogues to automatically move between states. Each controller limits the number of rogue containment to three per radio (or six per radio for access points in the monitor mode). Rogue Location Discovery Protocol (RLDP) detects rogue access points that are configured for open authentication. RLDP detects rogue access points that use a broadcast Basic Service Set Identifier (BSSID), that is, the access point broadcasts its Service Set Identifier in beacons. RLDP detects only those rogue access points that are on the same network. If an access list in the network prevents the sending of RLDP traffic from the rogue access point to the controller, RLDP does not work. RLDP does not work on 5-GHz dynamic frequency selection (DFS) channels. However, RLDP works when the managed access point is in the monitor mode on a DFS channel. If RLDP is enabled on mesh APs, and the APs perform RLDP tasks, the mesh APs are dissociated from the controller. The workaround is to disable RLDP on mesh APs. If RLDP is enabled on nonmonitor APs, client connectivity outages occur when RLDP is in process. If the rogue is manually contained, the rogue entry is retained even after the rogue expires. If the rogue is contained by any other means, such as auto, rule, and AwIPS preventions, the rogue entry is deleted when it expires.

  6. What is the down side to applying the rule to flag rogue APs using “managed SSIDs” as malicious?

      Hi Terry, The following are some guidelines to manage rogue devices: (these are documented at: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_011011.html ) The containment frames are sent immediately after the authorization and associations are detected. The enhanced containment algorithm provides more effective containment of ad hoc clients. In a dense RF environment, where maximum rogue access points are suspected, the chances of detecting rogue access points by a local mode access point and FlexConnect mode access point in channel 157 or channel 161 are less when compared to other channels. To mitigate this problem, we recommend that you use dedicated monitor mode access points. The local and FlexConnect mode access points are designed to serve associated clients. These access points spend relatively less time performing off-channel scanning: about 50 milliseconds on each channel. If you want to perform high rogue detection, a monitor mode access point must be used. Alternatively, you can reduce the scan intervals from 180 seconds to a lesser value, for example, 120 or 60 seconds, ensuring that the radio goes off-channel more frequently, which improves the chances of rogue detection. However, the access point will still spend about 50 milliseconds on each channel. Rogue detection is disabled by default for OfficeExtend access points because these access points, which are deployed in a home environment, are likely to detect a large number of rogue devices. Client card implementations might mitigate the effectiveness of ad hoc containment. It is possible to classify and report rogue access points through the use of rogue states and user-defined classification rules that enable rogues to automatically move between states. Each controller limits the number of rogue containment to three per radio (or six per radio for access points in the monitor mode). Rogue Location Discovery Protocol (RLDP) detects rogue access points that are configured for open authentication. RLDP detects rogue access points that use a broadcast Basic Service Set Identifier (BSSID), that is, the access point broadcasts its Service Set Identifier in beacons. RLDP detects only those rogue access points that are on the same network. If an access list in the network prevents the sending of RLDP traffic from the rogue access point to the controller, RLDP does not work. RLDP does not work on 5-GHz dynamic frequency selection (DFS) channels. However, RLDP works when the managed access point is in the monitor mode on a DFS channel. If RLDP is enabled on mesh APs, and the APs perform RLDP tasks, the mesh APs are dissociated from the controller. The workaround is to disable RLDP on mesh APs. If RLDP is enabled on nonmonitor APs, client connectivity outages occur when RLDP is in process. If the rogue is manually contained, the rogue entry is retained even after the rogue expires. If the rogue is contained by any other means, such as auto, rule, and AwIPS preventions, the rogue entry is deleted when it expires.

  7. What about 5760 and other IOS-XE WLCs. I cant seem to find those in the Cisco Security Advisory. Are they not affected ? I think not.

  8. Wouldn’t the rogue detection kick in, because he sees a rogue AP broadcasting the same SSID. The WLC would have to be kicking his (rogue AP) ass with deauthentication frames being sent to the clients. Cheers

  9. awesome blog!

  10. Is it possible to whitelist AP mac address and only allow those autentication requests?

      Hi Manish, You can certainly whitelist MAC addresses, but in some cases they can also be spoofed.

  11. Does .1X with RADIUS mitigate? I saw in the paper that although normal data frames can be forged EAPOL frames cannot and hence cannot impersonate the client or AP during subsequent handshakes?

      Hi Barry, The researchers confirmed that the attacks can be possible with both WPA-personal and WPA-enterprise (including .1x). They also cover this in their FAQ at: https://www.krackattacks.com/#faq I am copying and pasting here for completeness: Q: I'm using WPA2 with only AES. That's also vulnerable? A: Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP).

      • Omar, thanks - I meant proxied RADIUS (I just wasn't explicit enough), but perhaps it doesn't make any (or enough of a practical) difference. Best Regards, Barry

  12. When will Aironet's status be modified from "TBD" in the advisory?

      As fixes become available for remaining affected products, Cisco will update the security advisory.

  13. Would we gain any protection using 802.1x?

      Hi, The researchers confirmed that the attacks can be possible with both WPA-personal and WPA-enterprise (including .1x). They also cover this in their FAQ at: https://www.krackattacks.com/#faq I am copying and pasting here for completeness: Q: I'm using WPA2 with only AES. That's also vulnerable? A: Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP).

  14. Standing by for patches. Thanks.

  15. We appreciate that Cisco is attentive to fixing this/these vulnerabilities. It would also be helpful to know of the WiFi client-devices with which Cisco has confirmed interoperability after applying the fix to the Cisco infrastructure equipment. We know that Cisco can't test all possible devices. We just want to know which ones Cisco has verified.

    Very useful information, I'll be tweeting this right now. Thank you for the quick and detailed response.

  16. Thanks, very helpful

Share