In my last video blog on KRACK attack, I explained the technical details of workings and countermeasures for 9 out of 10 CVEs. The one I did not discuss in detail was CVE-2017-13088. At the time there wasn't enough information available on it and though it looked like the twin of CVE-2017-13087, due to differences between how group keys are distributed in MFP mode versus non-MFP mode, it required separate consideration. After receiving more details from the researcher (@vanhoefm), I am prepared to share information about CVE-2017-13088 and the appropriate countermeasures.
CVE-2017-13088, pertains to IGTK transport when a client wakes up from WNM sleep mode. IGTK comes into play with MFP (802.11w). When MFP is enabled, both GTK and IGTK are piggybacked on WNM Sleep Mode Response and a group key handshake is not performed to distribute them. When MFP is disabled, there is no IGTK, and GTK is distributed using standard group key handshake that follows WNM Sleep Mode Response. The CVEs pertaining to abuse of standard group key handshake are 13080 (GTK refresh in non-sleep mode), 13081 (IGTK refresh in non-sleep mode) and non-MFP part of 13087 (GTK refresh after sleep mode).
Working of CVE-2017-13088
I reached out to @vanhoefm for clarification on 13088 and he sent me the information which helps to understand how this CVE works. It works as follows:
- MFP client wakes up from sleep mode and sends Sleep Mode Request to AP with wakeup indication.
- AP sends Sleep Mode Response with IGTK piggybacked. Let us say currently running packet number for IGTK is x.
- Adversary blocks this Sleep Mode Response from AP. Note the difference from group key handshake attacks in which adversary blocks group key message 2/2 from client.
- AP sends some frames protected with IGTK that is currently in use and which the client has cached before going into sleep mode. The client receives IGTK protected frame with packet number x+1, x+2 etc.
- Adversary releases Sleep Mode Response to client, which results in reinstallation of same IGTK and resetting of packet counter at client to x. This now allows replay of IGTK protected frames with packet numbers x+1, x+2 etc.
Note that MFP part of 13087 is abused in the same way as described above by blocking Sleep Mode Response, rather than blocking second message of group key handshake.
Now that it is understood how 13088 works, we can discuss countermeasures. Of course, the fix is on the client side so that it does not reinstall the same IGTK and GTK upon waking up from sleep mode. The current patch to hostapd supplicant compares new IGTK and GTK with currently installed ones and if they are found to be identical, it does not reinstall them. This addresses IGTK and GTK reinstallation issue for 13080, 13081, 13087 and 13088 with one fix. It also addresses IGTK and GTK reinstallation issue inside EAPOL for 13078 and 13079.
However, AP side mitigation differs for 13088. Recall, AP side mitigation is useful when clients cannot be patched or until clients are patched. The mitigation relies on discouraging clients from entering sleep mode. One way this could be done is by advertising in beacons that WNM sleep mode is not supported on the AP. This is done by setting WNM-Sleep Mode (bit 17 of extended capabilities IE) to 0. If some clients ignore this advertisement and still attempt to enter sleep mode by sending a Sleep Mode Request, the AP can send Sleep Mode Response with 'deny' status. Such measures will prevent the client from going into sleep mode and avoid 13088 as well as MFP part of 13087.
And finally, practical exploit using this vulnerability requires MAC spoofing AP as Man-in-the-Middle. MAC spoofing APs can be detected and contained using WIPS.
If you're interested in more technical details on KRACK, please see my previous KRACK blog from 10/16 or catch the podcast that will be recording with Clear to Send next week. I will continue to keep you up to date as new information arises.