YAWA – Yet Another WPA Attack – an analysis

Some clever guys found out a way to crack WPA. The attack and the needed tools are described here:

https://hashcat.net/forum/thread-7717.html

First of all, this attack is so obvious, I cannot believe nobody found it earlier (including me 🙂 ). It’s based on PMKID (Pairwise Master Key Identifier) caching and the attack utilize one problem of PMKID caching: the WLAN password is actually transported over the air in a hashed way. Therefore, it’s attackable using brute-force attacks. And that’s what it is: An offline brute-force attack against the WPA(2) passphrase.

I split this article in three sections:

1.) A (hopefully simple) FAQ like section, to answer the most common questions

2.) Technical details regarding PMK caching methods

3.) An analysis of the attack tools and the used examples in the new attack description

FAQ

Q: What is a PMKID caching and why is it used?

The intent of PMKID caching is to efficiently roam between multiple access points using EAP as authentication (WPA2 ENTERPRISE) to prevent that during a roaming event a full EAP authentication is performed. Otherwise, roaming might take some time depending on the used EAP method (e.g. EAP-TLS, PEAP), which has an impact on time sensitive applications like voice.

Q: What are the methods, which utilize PMK caching?

Typically all fast roaming technologies make use of PMK caching, including

• 802.11i extension PMK Caching (WPA2 only)
• PKC (Proactive Key Caching) / OKC (Opportunistic Key caching)
• 802.11r: 4-way handshake with new AP before roaming

Q: Which WLAN authentication methods are vulnerable?

Only WPA and WPA2 PERSONAL (pre-shared key) are vulnerable. Because it’s an attack against the WPA key management (which is nearly the same for WPA1 and WPA2), the used ciphers are not relevant (AES, TKIP).

WPA2 ENTERPRISE (802.1X) is typically not vulnerable, although PMKID caching is the main use case for this application. This is because the PMK is dynamic for each client at the time of associaton. Furthermore, compared to WPA2 PERSONAL, the PMK is not the key which enables the user to access the WLAN in WPA2 ENTERPRISE.

Q: Wait! So WPA2 PERSONAL is vulnerable, WPA2 ENTERPRISE is not. But you said PMKID caching is used by WPA2 ENTERPRISE (which is not vulnerable). Is PMKID caching also used in WPA2 PERSONAL WLANs?

You can argue whether it makes sense to utilize PMKID caching for WPA2 PERSONAL SSIDs. If using the classic methods like PKC/OKC or PMK caching, there is no functional advantage to utilize PMKID caching. For 802.11r (FT) in WPA2 PERSONAL WLANs, the number of needed messages for key exchange are reduced from four (4 way handshake) to two (big deal).

Q: So what you say is, that PMKID caching does not make sense in WPA2 PERSONAL networks?

yes!

Q: Is PMKID caching enabled in WPA2 PERSONAL networks?

Well, it depends. If 802.11r is enabled, then yes. But this is typically a manual configuration option. Typically this is not available for consumer equipment.

OKC, PMK caching etc. is sometimes enabled by default, depending on the WLAN vendor. For example Cisco has OKC enabled by default and Aruba PMK caching.

I tested it with a WLAN configured for WPA2 PERSONAL on a Cisco WLC (8.3 train). The PMKID is included in the first message of the 4-way handshake. However, a consumer grade device like AVM Fritz!Box does not include the PMKID in the first message of the 4-way handshake.

However, if you feel better, you could disable any PMK caching technology from your WPA2 PERSONAL networks to overcome the vulnerability (if it is possible).

Q: Is WPA2 broken / safe any more?

It’s not worse than before in my opinion. Offline brute-force attacks are possible nearly since the beginning of WPA2 PERSONAL by capturing the 4-way handshake of a legitimate WLAN client the the cell. With the new attack you don’t need any client in the cell if PMK caching is enabled.

However, the WLAN vendors which send the PMKID in the first message of the 4-way handhake should consider to remove the PMKID in WPA2 PSK configured WLANs (non-802.11r). This way the exploit is fully mitigated without the discussion whether an additional exploit for the same weakness is a relevant issue.

Technical details

PMKID caching is used to support fast roaming across radio cells in the same SSID. The goal is, that for a roaming event, no 802.1X authentication must be performed.

In an EAP-TLS authentication for example, approximately 20 packets are exchanged between the client and the authentication server infrastructure. The number of packets and the amount of data heavily depends on the certificate content. During the authentication process, no user data is allowed. So user data is delayed or discarded by the client / AP. Measurements show, that for EAP-TLS, the complete process takes approximately 300ms[1]. This time is too high to maintain a good voice quality during roaming. Other traffic (e.g. TCP traffic) is not heavily impacted by this behavior.
[1] Measurement in a low latency network (LAN) / lab environment without load

Multiple methods utilize PMKID caching to support fast roaming, for example:

• 802.11i extension PMK Caching (WPA2 only)
• PKC (Proactive Key Caching) / OKC (Opportunistic Key caching)
• 802.11r: 4-way handshake with new AP before roaming

A good overview of the different methods is provided by Cisco (including lots of technical deep dive):

802.11 WLAN Roaming and Fast-Secure Roaming on CUWN

A very detailed article focussing on 802.11r is: 802.11r BSS Fast Transition Deployment Guide

Long story short: Each of the described methods has advanteges and drawbacks. The most sophisticated and standardized method is 802.11r (aka “Fast Transition”).

As already outlined in the “FAQ” above, PMKID caching only makes sense in combination with WPA2 ENTERPRISE (802.1X) WLANs. With pre-shared keys, there is no functinal benefit, except when using 802.11r. With 802.11r in combination with PSK SSIDs, the number of needed frames for a roaming event is reduced from six (association frames, 4-way handshake) to two (association frames only, containing the PMKID).

To mitigate the new exploit, there are several options:

Ignore it

Acutally this is a valid option, because it’s a new exploit for an old weakness: WPA2 PERSONAL is attackable by offline brute-force attacks (big deal). The only difference is, that you don’t need a client in the cell to perform the attack.

Check it

Check if your equipment is sending PMKIDs in the 4-way handshake for an WPA2 PERSONAL (PSK) without 802.11r. If yes, tell your vendor that it doesn’t make sense and that you want a fix. If you are an 802.11r user in combination with PSK, reflect if this is really necessary 🙂

Fix it

If the options above are no option for you, there’s another way: Disable WPA2 PERSONAL in your network completely and rely on WPA2 ENTERPRISE using a secure EAP method (e.g. EAP-TLS, PEAP, EAP-TTLS). 🙂

Attack analysis

Coming soon