In the past few months, I've been working on new results regarding the KRACK attack against WPA2. This includes improved (and more practical) exploitation techniques, and a method to mitigate future attacks against WPA2. I hope to present both topics in more detail at either my HITB Singapore talk if accepted (so please for vote it), or in a more detailed future blog post. In the meantime this post briefly introduces both topics.
Improved Exploitation Techniques
A few implementation-specific improvements of the KRACK attack have already been discussed in my OPCDE presentation. Other new research on improved attack techniques is being finalized, and I hope to release these new attack techniques in the near future. The implementation-specific attack improvements that were already discussed in my OPCDE talk are:
Preventing Multi-Channel Man-in-the-Middle Attacks
Traditional attacks against protected WiFi networks only require an attacker to sniff and (optionally) inject packets. For example, WEP can be broken by passively sniffing packets, and dictionary attacks against WPA2 merely require a passive capture of the 4-way handshake. In other words, these attacks don't require a man-in-the-middle (MitM) position between the client and AP. In contrast, most recent attacks against WPA2 require a MitM position. For example, several KRACK attacks against WPA2 handshakes require the ability to block packets. Similarly, certain attacks against (WPA-)TKIP require a MitM position, as do other attacks against the 4-way handshake and encryption algorithms of WPA2.
In all these attacks, the MitM position is established using a multi-channel technique. In this technique, the adversary clones the AP on a different channel, and tricks the client (victim) into connecting to the AP on this rogue channel. The adversary then forward frames between both channels so the client and AP can communicate. This enables the adversary to reliably delay, block, or modify (encrypted) frames sent between the client and AP.
Together with Broadcom and Intel, we designed an extension to the WiFi standard to prevent such multi-channel MitM attacks. This makes exploiting future weaknesses in protected WiFi networks harder, to practically infeasible. The idea behind our defense is to cryptographically authenticate the parameters that define the operating channel. This enables two communicating WiFi devices to detect when they are operating on different channels, and hence to detect when they are under attack.
We're doing a lot of work to get this extension deployed in practice. First, we have an academic paper discussing the high-level design of our extension. Second, we are submitting our proposal for inclusion in the official WiFi standard. So far the general WiFi industry appears receptive of our mechanism, so I have good hopes that this will be included in the standard. Third, we have a working proof-of-concept where the 4-way handshake validates the current operating channel using our extension. We plan to improve this code so it will be included in wpa_supplicant and hostapd, meaning all Linux and Android devices will support this in the near future (and hopefully other vendors will implement this soon too).
To summarize, our technique to prevent multi-channel MitM attacks is a bit like stack canaries: it makes attacks harder, though not impossible. And we hope that just like with stack canaries, it will soon become a common method to harden and protect WiFi networks.
Improved Exploitation Techniques
A few implementation-specific improvements of the KRACK attack have already been discussed in my OPCDE presentation. Other new research on improved attack techniques is being finalized, and I hope to release these new attack techniques in the near future. The implementation-specific attack improvements that were already discussed in my OPCDE talk are:
- Attacking Access Points (APs). In the original attack against the 4-way handshake, we generated retransmitted message 3's to attack the client. This affected nearly all clients, because the WiFi standard mandates that retransmitted message 3's must be processed. In contrast, the standard says that retransmitted message 4's should be ignored. But of course APs may be buggy, and process retransmitted message 4's anyway. And indeed, we discovered one driver that accepts retransmitted message 4's, and reinstalls the session key while processing them. This means the 100+ different routers and APs using this chipset/driver are all likely vulnerable.
- SNonce and ANonce reuse. We also discovered that macOS reused the (normally random) SNonce during a rekey handshake. Similarly, hostapd was reusing the ANonce during a rekey. This means that if an unpatched macOS was connected to an unpatched hostapd AP, rekeys caused the reinstallation of the current session key! As a result, it becomes possible to decrypt old captured traffic captured between a macOS and hostapd AP.
- Group key installation issues. We also noticed that many devices accept replayed broadcast traffic. To attack these devices, there is no need to trigger a reinstallation of the group key, the adversary can simply replay broadcast packets. Additionally, some devices improperly initialize the receive replay counter when installing the group key, which can again be abused to replay broadcast frames.
Preventing Multi-Channel Man-in-the-Middle Attacks
Traditional attacks against protected WiFi networks only require an attacker to sniff and (optionally) inject packets. For example, WEP can be broken by passively sniffing packets, and dictionary attacks against WPA2 merely require a passive capture of the 4-way handshake. In other words, these attacks don't require a man-in-the-middle (MitM) position between the client and AP. In contrast, most recent attacks against WPA2 require a MitM position. For example, several KRACK attacks against WPA2 handshakes require the ability to block packets. Similarly, certain attacks against (WPA-)TKIP require a MitM position, as do other attacks against the 4-way handshake and encryption algorithms of WPA2.
In all these attacks, the MitM position is established using a multi-channel technique. In this technique, the adversary clones the AP on a different channel, and tricks the client (victim) into connecting to the AP on this rogue channel. The adversary then forward frames between both channels so the client and AP can communicate. This enables the adversary to reliably delay, block, or modify (encrypted) frames sent between the client and AP.
Together with Broadcom and Intel, we designed an extension to the WiFi standard to prevent such multi-channel MitM attacks. This makes exploiting future weaknesses in protected WiFi networks harder, to practically infeasible. The idea behind our defense is to cryptographically authenticate the parameters that define the operating channel. This enables two communicating WiFi devices to detect when they are operating on different channels, and hence to detect when they are under attack.
We're doing a lot of work to get this extension deployed in practice. First, we have an academic paper discussing the high-level design of our extension. Second, we are submitting our proposal for inclusion in the official WiFi standard. So far the general WiFi industry appears receptive of our mechanism, so I have good hopes that this will be included in the standard. Third, we have a working proof-of-concept where the 4-way handshake validates the current operating channel using our extension. We plan to improve this code so it will be included in wpa_supplicant and hostapd, meaning all Linux and Android devices will support this in the near future (and hopefully other vendors will implement this soon too).
To summarize, our technique to prevent multi-channel MitM attacks is a bit like stack canaries: it makes attacks harder, though not impossible. And we hope that just like with stack canaries, it will soon become a common method to harden and protect WiFi networks.