Lezers,
Naar aanleiding van een discussie met Andrew von Nagy (WPA2 KRACK Vulnerability, Getting Information) ben ik samen met Javier Contreras Albesa er achter gekomen dat het mogelijk is om een WPA2 vulnerability workaround te implementeren in een Cisco omgeving:
“All are effectively implementation issues by allowing reuse of keystream material, meaning software patching can fix them! Of the 9 CVE’s related to clients, the most serious of them (7 of the 9, related to the 4-Way Handshake and Group Handshake) can be mitigated with AP / Infrastructure updates as a workaround, but the infrastructure won’t be able to determine if failure is from packet loss issues or attack. A few can’t be mitigated by AP patches (Peer-Key and tunneled direct link setup [TDLS]), which are peer-to-peer related vulnerabilities, but these methods of communication are rare and practically never used in my experience. The long-term fix is definitely client software patching. Patching Wi-Fi drivers can also fix 2 of the 9 client vulnerabilities…. The 1 CVE related to AP / Infrastructure is related to 802.11r Fast Transition – if you have it enabled you should patch ASAP. If not, no big deal. Many, many thanks go to Hemant Chaskar, Mojo Networks, and Pentester Academy!”
AND
“The EAPoL M3 (and M2/M4) include a MIC integrity check as well as a Key Replay Counter (KRC). The attacker cannot simply replay the initial M3 message from the Authenticator (AP) since the KRC will be the same and the client will discard it. The attack relies on the attacker MiTM AP blocking (not forwarding) the M4 frame to the AP, and the AP then retransmitting M3 with an incremented KRC and valid MIC that the client will accept, thus reinstalling the PTK and resetting the Packet Number (PN) used in the keystream generation for individual frame encryption.
So… patched APs can protect clients from these vulnerabilities if they modify their behavior to not retransmit M3.”
Mocht je een Cisco Wlan-controller en Cisco access-points hebben dan kun je dus een WPA2 vulnerability client workaround implementeren. Waarschijnlijk zal Cisco binnenkort met een Cisco Product Security Incident Response Team (PSIRT) wijziging komen om onderstaande te adviseren:
UPDATE PSIRT is zojuist vrijgegeven:
-
Workaround for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080 and CVE-2017-13081
Cisco Technotes: Wireless KRACK attack client side workaround and detection (Updated:October 27, 2017 Document ID:212390)
Er zijn twee mogelijkheden :
- Wijziging van een globale instelling in alle WLAN-releases
- Wijziging van een SSID instelling vanaf software versie 7.6
#1 Global Config:
config advanced eap eapol-key-retries 0
(CLI only option)
De eopol waarde kan worden gevalideerd met:
(5520) >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
Je kan de wijziging per WLAN aanpassen waarmee je een meer granulaire controle toepast. Hierbij kun je een onderscheid maken per SSID. Voordeel hiervan is dat je de verandering goed kan testen per type apparaat, vooral als ze op specifieke wlans zijn gegroepeerd. Deze work-around is beschikbaar vanaf software versie 7.6
#2 Per WLAN Config:
X=WLAN ID
config wlan security eap-params enable X
config wlan security eap-params eapol-key-retries 0 X
De meeste wlan-clients zullen blijven werken maar er zijn twee scenario’s bekend waardoor er een mogelijkheid bestaat dat (oude) clients problemen gaan ervaren:
- “Clients which are slow or may drop initial processing of EAPoL M1. This is seen on some small/slow clients, which may receive the M1, and not be ready to process it after the dot1x authentication phase, or do slower
- Scenarios with bad RF, or WAN connections between AP and WLC, that may cause a packet drop at some point on transmission towards client.
In both, the outcome would be that an EAPoL exchange failure will be reported, and client will be deauthenticated, it will have to restart association/authentication processes
To lower probabilities for this issue, a longer timeout should be used (1000 msec), to give time for slow clients to respond. The default is 1000 msec(!), but could have been set lower by customer on some scenarios.