Thank you very much for your interest in the Cisco #WirelessTuesday event and thanks to the hundreds of you that migrated with me from what was our #WirelessFriday event! This article is a quick recap of the November 2017 event with the associated questions and panel responses.
I would like to make a public thanks to Stephen Orr, Distinguished SE here at Cisco (LinkedIn, Twitter)! He weighed in on the WPA2 vulnerabilities known as KRACK and Cisco’ (and the industry’s) response. I loved his first piece of advice: #DontPanic. I would also like to thank my panelists Brad Kincaid, Rush Johnson, and Mark Dellavalle.
If you’d like to hear the recording you can access it here.
Links from the Presentation
- To learn more about the WPA2 KRACK vulnerability and Cisco’s response check out this blog article.
- Updated PSIRT Page: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa
- Recommendations from Cisco: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212390-wireless-krack-attack-client-side-workar.html
- Only 1 impacts APs using 802.11r (Fast BSS Transition): CVE-2017-13082. The rest of the vulnerabilities impact the client devices.
- 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.
- Proposals being submitted week of Nov 6th to TGmd
In-Event Questions and Responses
Q. Can or should both Infrastructure MFP and PMF (802.11w) be implemented together?
R. Steven is a fan of “defense in depth” so the recommendation is yes. 802.11w has 2 modes: MFP required and MFP capable. It’s always good to start with MFP capable until you know for sure your clients support it.
Q. Is it still recommended not to run 802.11r with PMF?
R. If you are using patched code you are good to use 802.11r. Know that both the infrastructure and clients need to be updated.
Q. Does the 5760 have a patched image yet?
R. Yes 5760 updates are available. Please work with TAC on specific recommendations.
Q. Are devices like 800-W series routers/ASAs vulnerable as well?
R. For those SoHo devices where roaming is capable, yes, they would be vulnerable.
Q. With MiTM attack this should be more of an impetus to disable lower data rates…? That should at least shrink the cell size the MiTM attach correct?
R. Not necessarily. This may have a negative effect on coverage and roaming.
Q. So, if AP’s/WLC’s are patched, but clients are not, we’re still vulnerable?
R. The clients not patched would be vulnerable.
Q. So, do either of the 2 threat vectors present vulnerabilities if 802.11r or 802.11ai are not enabled?
R. If they are not enabled on the infrastructure side, then the infrastructure is not exposed, however the client, if using vulnerable code, is exposed.
Q. What are we patching on the client side? Our devices do not use a software to access the AP’s. They just use the wireless app on the device
R. The device itself would need an update from the device manufacturer.
Q. When talking about patching the clients. Are you speaking about patching the workstations clients? For example, if you are using the windows wireless clients?
R. Essentially the supplicant on the device must be update…whether that is separate or part of the OS. Each vendor will need to address the vulnerabilities in their own firmware, drivers, supplicants.
Q. Do any of these vulnerabilities change in a flex-connect mode
R. No, your exposure does not change.
Q. Under WLANS, Security (802.11r) FT = Fast Transition or Authentication Key Management = FT 802.1X / FT PSK boxes checked?
R. On the PSIRT website there is a step-by-step guide to help you determine if you are vulnerable.
Q. I also think it’s important to clarify that the attacker needs to be present for this attack, nearby.
R. Great point… “in RF proximity…”
Q. How about the new Apple Cisco partnership, where apples “turn on” 802.11r
R. That is still the recommendation. The patches are available and should be used.
Q. So, on latest code, 802.11r can be “off” but enabling the Apple-Cisco Best Practices will turn it back “on”?
R. Yes, that is true.
Q. Will the WFA test plan be published and available?
R. For now, the test tool/plan it is available only for manufacturers
Q. Did Wi-Fi Alliance provide a time line to remediate for Infrastructure and all client devices?
R. For those devices that claim support for 802.11r or 802.11ai, mandatory test will be in place, likely by the end of 2017.
Q. Is Cisco publishing all client devices that were remediated
R. Best advice is contact each vendor.
Multi-tenant and IoT deployments have a unique problem. Often there are devices that need to talk to each other, like neighbors in a neighborhood, but not be allowed to talk between neighborhoods. It’s a problem that’s been around for a long time, and it’s getting bigger as we do more with “headless” devices.
Check out this video on Cisco Identity PSK. Let me know what you think.