Saltar a la navegación Saltar al contenido principal Ir al pie de página

PMKID Attacks: Debunking the 802.11r Myth

Analyzing the actual vulnerabilities behind PMKID-based attacks on Wi-Fi networks

Introduction

This article addresses common misconceptions surrounding PMKID-based attacks while offering technical insights into their mechanics and effective countermeasures. The PMKID-based attack, first disclosed in 2018 by the Hashcat team, introduced a novel method of compromising WPA2-protected Wi-Fi networks. Unlike traditional techniques, this approach does not require capturing a full 4-way handshake, instead leveraging a design flaw in the Pairwise Master Key Identifier (PMKID). Over time, a prevalent misconception has emerged, suggesting that the attack is feasible only on networks with 802.11r Fast Transition (FT) enabled. However, the actual vulnerability arises from the way an access point handles PMKID requests rather than the specific presence of 802.11r. This article provides a detailed explanation of the attack's mechanics and refutes the claim that it is exclusive to 802.11r-enabled networks.

PMKID Attack Overview

The PMKID-based attack exploits a weakness in the WPA2 authentication process, specifically in the handling of the Robust Security Network (RSN) handshake. During authentication, the Pairwise Master Key (PMK) is used as the foundation for secure communication. Instead of intercepting a complete 4-way handshake, it is possible to retrieve the PMKID directly from the access point by initiating an RSN request. The PMKID is subsequently used in offline brute-force attacks to recover the Pre-Shared Key (PSK) of the network.

Technical Details and Calculations

The PMKID is calculated during the RSN handshake using the following formula: PMKID = HMAC-SHA1(PMK, "PMK Name" + MAC_AP + MAC_Client) Each element of the formula plays a critical role:

  • PMK: The Pairwise Master Key, which is derived from the PSK and the SSID using the PBKDF2 function.
  • "PMK Name": A fixed, standardized string used in the HMAC function to ensure compatibility across devices.
  • MAC_AP: The MAC address of the access point.
  • MAC_Client: The MAC address of the client attempting to connect

Once calculated, the PMKID is included in the first frame of the 4-way handshake. By capturing this PMKID, an attacker can perform offline brute-force attacks to guess the PSK. For each guessed PSK, the PMK is recalculated, and the resulting PMKID is compared to the captured value. A match confirms the correct PSK.

Debunking the 802.11r Myth

The notion that PMKID attacks are restricted to networks with 802.11r enabled stems from a misunderstanding of the underlying vulnerability. While 802.11r does make networks more susceptible due to its streamlined handshake process, the attack itself is not contingent on its use. The key factor lies in whether the access point responds to PMKID requests during the RSN handshake. Networks without 802.11r can still be vulnerable if improperly configured or if older firmware is in use. Many providers have long been implementing the firmware of their access points and routers in a way that made them vulnerable to this issue. Even today (six years after the vulnerability was discovered), it is still possible to find some vulnerable access points.

Why 802.11r Networks May Appear More Vulnerable

Access points with 802.11r enabled are often more prone to PMKID attacks due to the way Fast Transition (FT) facilitates seamless roaming. This feature simplifies and accelerates the authentication process, sometimes exposing the PMKID more readily. However, the vulnerability is not exclusive to 802.11r networks. The decisive factor is how the access point implements and manages RSN requests, which can vary based on configuration and vendor-specific practices.

Proof of Concept (PoC)

To demonstrate the feasibility of a PMKID-based attack on networks without 802.11r, a Proof of Concept (PoC) can be implemented. The PoC will involve setting up a custom access point using hostapd. Since recent versions of hostapd include patches that mitigate PMKID vulnerabilities, the source code must be modified to intentionally reintroduce this flaw. After compiling the modified version, the resulting access point will allow PMKID requests, even without 802.11r enabled.

  • Clone the hostapd source code repository:
 git clone git://w1.fi/hostap.git 
cd hostap

  • Download a configuration file for building hostapd. This example uses a pre-prepared file from one of my GitHub repositories:
 curl -o hostapd/.config 'https://raw.githubusercontent.com/OscarAkaElvis/PMKID_PoC/refs/heads/main/.config'

  • There is no need to modify anything in this file we have downloaded. However, it is worth noting that this file contains the configuration optionCONFIG_IEEE80211R=n, which means the 802.11r feature will be disabled.
  • Next, modify the source code to reintroduce the PMKID vulnerability intentionally. Open the file `src/ap/wpa_auth.c` and locate lines 2753-2757 (based on the latest version as of this writing - 13/12/2024). If you try this PoC, it is highly likely that the line numbers have changed since hostapd is an active project. Therefore, it is more convenient to directly checkout the commit from this moment if you want to avoid searching through the code for the lines of interest.
 git checkout fe56cf124ce828cf9129a4b25a430a6961aedf05

  • In those line numbers, we will find a conditional with the following source:
2753 if (sm->wpa == WPA_VERSION_WPA2 && 
2754 (wpa_key_mgmt_wpa_ieee8021x(sm->wpa_key_mgmt) || 
2755 (sm->wpa_key_mgmt == WPA_KEY_MGMT_OWE && sm->pmksa) || 
2756 wpa_key_mgmt_sae(sm->wpa_key_mgmt)) && 
2757 sm->wpa_key_mgmt != WPA_KEY_MGMT_OSEN) {
  • We can verify this by displaying those lines along with some additional context:
awk 'NR>=2748 && NR<=2762 {print NR ": " $0}'

  • Modify it to simplify it to a single condition as follows, and then save the changes and exit:
2753 if (sm->wpa == WPA_VERSION_WPA2) {
  • Alternatively, instead of modifying the file manually, you can make the modification using a `sed` command, and then we can verify the change:
sed -i '2753,2757c\ if (sm->wpa == WPA_VERSION_WPA2) {' src/ap/wpa_auth.c && awk 'NR>=2748 && NR<=2762 {print NR ": " $0}' src/ap/wpa_auth.c

  • Build the hostapd binary with the modified configuration and source code:
make -C hostapd

.......snipped.......

  • This creates a hostapd version with 802.11r disabled and the PMKID vulnerability reintroduced. Next, create a standard WPA2 hostapd configuration file (hostapd.conf) in the root directory of the cloned repository, We will assume your wireless adapter is wlan0, and the file will contain the following content:
interface=wlan0 
ssid=vulnPMKID 
driver=nl80211 
hw_mode=g 
bssid=00:11:22:33:44:55 
channel=1 
logger_syslog=0 
wpa=2 
wpa_passphrase=Wh4teverPassw0rd 
wpa_key_mgmt=WPA-PSK 
rsn_pairwise=CCMP
  • We can check the content of the file to ensure it is correct:
cat hostapd.conf

  • Launch the access point using the created configuration file. Bear in mind that the compiled binary is not in the current directory:
./hostapd/hostapd -K hostapd.conf

  • At this point, you will have a functional access point vulnerable to PMKID attacks, even with 802.11r disabled. This setup serves as a controlled demonstration that PMKID-based vulnerabilities are not exclusive to 802.11r networks, debunking a common misconception
  • Now we can try obtaining the PMKID using a tool like hcxdumptool or airgeddon, which automates the capture process (using hcxdumptool behind the scenes). It is important to note that, unlike when 802.11r is active, network traffic is required to obtain the PMKID. This traffic can be generated in any way, such as attempting to authenticate with the network, even if the attempt fails. Therefore, while the capture process is running, it will suffice to attempt a failed authentication using any Wi-Fi-enabled mobile phone.
  • So, we launch the PMKID capture using airgeddon tool, selecting the vulnerable network as the target and increasing the timeout to ensure successful results:

 

  • While the attack is underway, we attempt to authenticate with the vulnerable network using a mobile phone as the client, without even entering the correct password. We repeat the process several times to ensure sufficient traffic is generated to capture a PMKID:

  • We start receiving these messages in the access point window because the password we are entering is incorrect. However, we are still generating traffic in the process:

  • Finally, we successfully obtain the PMKID saving it to a safe location. The tool will initially save the PMKID in TXT format to be used by Hashcat, but it will later also prompt us to save it in CAP format, to which we will respond "yes":

  • We now check the content of the file to verify if the PMKID has been successfully captured, thereby finalizing the proof of concept that demonstrates the PMKID can be obtained from an access point without 802.11r:

Conclusion

In conclusion, while it has been demonstrated that the PMKID attack is not exclusively tied to the presence of 802.11r, the absence of this feature significantly impacts the practicality and efficiency of the attack. When 802.11r is not enabled, obtaining the PMKID becomes more challenging as it requires the presence of traffic, and thus, connected clients to generate it. This dependency on client activity reduces the inherent advantage of the PMKID attack (its ability to operate without requiring active clients). Therefore, while the attack remains feasible in networks without 802.11r, its effectiveness is notably diminished in such scenarios. The PMKID-based attack represents a threat to WPA2-protected networks by circumventing traditional handshake capture methods. Although networks with 802.11r enabled may facilitate quicker PMKID retrieval, the vulnerability itself is not exclusive to such configurations. Instead, it depends on how the access point handles PMKID requests during the RSN handshake. By addressing configuration issues and implementing best practices, organizations can effectively mitigate this risk and protect their wireless networks.

Mitigation and Best Practices

Effective mitigation strategies against PMKID-based attacks emphasize the importance of proper access point configuration and robust security measures. These include:

  1. Regularly updating firmware and software to address known vulnerabilities.
  2. Implementing strong, unpredictable PSKs to resist brute-force attempts.
  3. Considering the adoption of WPA3, which replaces PSK-based authentication with Simultaneous Authentication of Equals (SAE).
  4. Disabling unused protocols, such as 802.11r, unless strictly required for operational purposes.
  5. Conducting periodic security audits to identify and rectify misconfigurations.

About the Author

My name is Óscar Alfonso Díaz, I am a cybersecurity researcher passionate about the field of cybersecurity, with a particular focus on 802.11 wireless technology. Among my personal projects are the creation of the widely used wireless security auditing tool airgeddon, collaboration with the Wi-Fi security certification program Certified WifiChallenge Professional (CWP), and participation in the development of the red team tool Evil-WinRM

References, tools and sources:

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

https://netgab.net/web/2018/08/08/yawa-yet-another-wpa-attack-an-analysis/

https://www.cwnp.com/uploads/802-11_rsn_ft.pdf

https://github.com/v1s1t0r1sh3r3/airgeddon

https://github.com/ZerBea/hcxbtdumptool

https://w1.fi/