Thursday, 7 June 2018

unKRACK: Mitigating Future WPA2 Vulnerabilities

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:
  1. 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.
  2. 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.
  3. 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.
Note that the above are all implementation-specific new vulnerabilities, these are not new weaknesses in the WiFi standard.

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.

Monday, 12 March 2018

WPA3: Technical Details and Discussion

Update 20 May 2018: A short description of the DPP protocol was added, and more information is provided about increased key sizes of WPA3.

The Wi-Fi Alliance made a press release where it announced WPA3. Unfortunately, this did not include many technical details. Nevertheless, we'll interpret the press release from a technical perspective. In particular, it mentions WPA3 will include four major new security features:

1. A More Secure Handshake

They explain that WPA3 will "deliver robust protections even when users choose passwords that fall short of typical complexity recommendations". This means that personal networks, in other words ordinary home networks that are protected with a single password, will be required to use the Simultaneous Authentication of Equals (SAE) handshake. Most importantly, this handshake is resistant against offline dictionary attacks. In contrast, personal WPA2 networks that use a weak password are vulnerable to offline dictionary attacks. Since in practice many networks use weak passwords, resistance against this attack is a major improvement.

On top of that, there is a security proof that indicates the design of the new SAE handshake is secure. The proof also confirms that the handshake provides forward secrecy: if an attacker ever learns the password of a network, they cannot use it to decrypt old captured traffic. This is again in contrast to WPA2, where learning the password allows an attacker to decrypt old traffic. So again the SAE handshake of WPA3 offers a major improvement.

Nevertheless, some caution is warranted. If the handshake is not carefully implemented, it is vulnerable to side-channel attacks. Additionally, because the handshake was designed to be a balanced PAKE, the access point (AP) must store the password in plaintext. Put differently, the AP cannot store some derivation of the password, meaning if someone gains access to the AP they can read out the plaintext password. Finally, just because there is a security proof, does not guarantee it is indeed secure. After all, WPA2 also had a security proof, but could still be attacked. Therefore it remains important to verify that the security proof is correct, makes valid assumptions, proves the correct properties, models real implementations, etc.

On a more technical level, the SAE handshake is a variant of the Dragonfly handshake defined in RFC 7664, which in turn is based on the SPEKE handshake. In a Wi-Fi network, the SAE handshake negotiates a fresh Pairwise Master Key (PMK). The resulting PMK is then used in a traditional 4-way handshake to generate session keys. This means the SAE handshake is always followed by a 4-way handshake. Although it may be surprising to learn that the 4-way handshake is still being used, this construction does avoid the weaknesses of the 4-way handshake. That's because the 32-byte PMK that the SAE handshake negotiates cannot be guessed using a dictionary attack, even though it's used in the 4-way handshake. Additionally, forward secrecy is indeed provided because the SAE handshake assures the PMK cannot be recovered if the password becomes known.

You can view the pcap of an example SAE handshake online on cloudshark.

2. Replacement of Wi-Fi Protected Setup (WPS)

The second improvement that WPA3 brings is "simplified, secure configuration and onboarding for devices with limited or no display interface". This refers to the replacement of Wi-Fi Protected Setup (WPS). Note that WPS is considered insecure. More precisely, the replacement of WPS will be the Wi-Fi Device Provisioning Protocol (DPP). This protocol allows you to securely add new devices to a network using a QR code or a password. It also defines methods to add devices using NFC, and using Bluetooth. At its core, DPP relies on public keys to identify and authenticate devices.

The DPP protocol itself consists of three main phases. In the first phase, called bootstrapping, the public key of the new device (i.e. the device being added to the network) is obtained. This can be accomplished by scanning a QR code that encodes the public key, or by exchanging and encrypting the public key wirelessly using the PKEX protocol. As previously suggested, it is also possible to transfer the public key using NFC or Bluetooth. Each method provides different levels of guarantees as to whether the obtained public key indeed belongs to the new device.

In the second phase, called authentication and provisioning, the now trusted public keys are used to establish a (temporary) authenticated connection, over which credentials can be exchanged. The exchanged credentials are not yet the final credentials to connect to the network. Instead, the exchanged credential is a so-called connector. This connector is used in the final phase of the DPP protocol, called the network access phase, to establish the actual networks keys. More precisely, the connect is used to perform a Diffie-Hellman exchange to establish a Pairwise Master Key (PMK). This PMK can then be used to access the network in a normal fashion.

3. Unauthenticated Encryption

The third feature of WPA3 "strengthens user privacy in open networks through individualized data encryption". This refers to unauthenticated encryption for open networks (i.e. for public hotspots). More precisely, I believe WPA3 will require support for Opportunistic Wireless Encryption (OWE). In practice this would mean a passive adversary, which can only sniff/monitor traffic, will not be able to read traffic of clients. Unfortunately, an active adversary can still create a fake AP, trick victims into connecting to this fake AP, and then read all traffic of connected clients.

Remark that the common practice of setting up a WPA2 network, and then publicly sharing the password to customers, does not prevent a passive adversary from decrypting all traffic. That's because an adversary only needs to capture the handshake the client executes when connecting to a WPA2 network, and then combine it with the public password to decrypt all frames between the client and AP. Active attacks against this setup are equally trivial: an adversary can set up a WPA2 network with the same name and password. Clients (e.g. customers) will then connect to the AP of the adversary, again allowing the adversary to intercept and read all traffic.

The advantage of OWE is that passive attacks are prevented. Unfortunately, active attacks still enable an adversary to intercept traffic. Nevertheless, under the motto of RFC 7435 "Some Protection Most of the Time" this still increases security. One shortcoming of OWE is that there is no mechanism to trust an AP on first use. Contrast this with, for example, SSH: the first time you connect to a SSH server, you can trust the public key of the server. This prevents an adversary from intercepting traffic in the future. However, with OWE there is no option to trust a particular AP on first use. So even if you connected to a particular AP previously, an adversary can still set up a fake AP and make you connect to it in the future.

On a technical level, the OWE handshake negotiates a new PMK using a Diffie-Hellman key exchange. This handshake is encapsulated in Information Elements (IEs) in the (re)association request and response frames. The resulting PMK is used in a 4-way handshake, which will negotiate and install frame encryption keys.

4. Increased Session Key Sizes

Finally, the fourth improvement that WPA3 offers is increased key sizes. More specifically, they refer to the Commercial National Security Algorithms (CNSA) suite. This means WPA3 will support AES-GCM with 256-bit keys for encryption, and elliptic curve cryptography based 384-bit curves. Additionally, SHA384 of the SHA2 family will be used, and any employed RSA keys must be at least 3072 bits in size. All combined, this results in 192-bit security, because that's roughly the effective strength of 384-bit elliptic curves and SHA384.

Improvements to WPA2

It's also interesting to note that the Wi-Fi Alliance now mandates support of Protected Management Frames (PMF) as part of its WPA2 certification. This means new WPA2-certified devices are now required to support PMF. This prevents deauthentication attacks where an adversary can forcibly disconnect clients from a Wi-Fi network. On top of that, it seems they will fuzz implementations of WPA2. Or to put it in their words, they will perform "Enhanced validation of vendor security implementations". In particular devices are tested to assure they validate server certificates properly, and that they are patched against the KRACK attack against WPA2.

Monday, 20 February 2017

Windows 10 Lock Screen: Abusing the Network UI for Backdoors (and how to disable it)

This is a short blog post about a peculiar decision that Microsoft made. When you lock your computer on Windows 10, you are still able to connect to wireless networks. It's even possible to connect to new networks. You simply click on the network icon in the bottom right, and then add the wireless network:


So what's the deal with this? Well, it means that anyone can make your device connect to a possibly malicious wireless network. As an attacker you simply have to broadcast a network, wait until it shows up in the network list, and connect to it:


The victim will now automatically connect to the attacker's network whenever it is nearby. This is unwanted behavior. Since the victim automatically connects to it, it can be used to track the victim, and to intercept and manipulate his or her network traffic.


This is not ideal. When I lock my laptop, I don't expect someone to able to change my network configuration! But now someone can add a (possibly unencrypted!) wireless network to my config, and my device will automatically connect to it.

Thankfully, it's possible to disable the network menu at the lock screen. Open the Windows menu and type "Edit group policy" and open this tool. Now go to "Computer Configuration\Administration Templates\System\Logon" and enable "Do not display network selection UI":



And now the network icon is gone in your lock screen. No annoying people can now mess with your network configuration when you lock your device!