PMKID Wireless Vulnerability Proof of Concept

by | Mar 5, 2020 | Uncategorized

Print PDF

Submit your email address to access the PDF of this post.

  • This field is for validation purposes and should be left unchanged.

What are you talking about?

The PMK caching vulnerability was discovered in 2018 and has now been incorporated into most wireless auditing and testing techniques that we perform. So, what is this new thing? The technical aspect resides in the IEEE 802.11 I[1] standard. Here is the relevant definition from the referenced Wikipedia page:

“After the PSK or 802.1X authentication, a shared secret key is generated, called the Pairwise Master Key (PMK). The PMK is derived from a password that is put through PBKDF2-SHA1 as the cryptographic hash function. In a pre-shared-key network, the PMK is actually the PSK. If an 802.1X EAP exchange was carried out, the PMK is derived from the EAP parameters provided by the authentication server.”

For the sake of our attention spans I will sum up that this new vulnerability no longer requires client to AP interaction or the 4-way handshake in order to capture the hashed value of your pre-shared key. My hope is that the last sentence makes you pause and want to disable this immediately across your wireless infrastructure. Executing the attack can be done with different tools which are shown in the videos below.

Wifite has been updated to include the PMKID attack however there are some limitations to using the automated framework. The hcxtools suite[1] allows for a more prescriptive and focused attack using the same vector but is a more manual process.


As you can see in both videos, a client is not needed in order to obtain the cached pre-shared key from several of the networks within range of my office.

Why does this matter?

Depending on your network architecture and the business case for wireless in your environment this answer can vary widely. If you only have a guet wireless network that you keep outside your perimeter hardware then the risk would be low as a compromise would only risk those devices and information attached to that  network and hopefully you do not allow your corporate devices to access this hostile network. If you have a corporate wireless network that allows unmitigated access to internal assets just like being on the wired network, the risk is much higher. If your wireless network allows access to HIPAA or PCI data, you may also now be non-compliant provided your auditor knows to verify things like this.

What should you be doing? First off, determine whether this vulnerability is present in your environment. This can be accomplished by your own personnel or a third party. If this vulnerability is present, work with your wireless vendor to determine how to disable this feature. Depending on your use cases and environment you may also want to disable this feature in multiple stages to ensure as little impact as possible for your user base. Lastly, if compliance auditing is involved, determine whether your current auditors are capable of verifying this sort of testing and network segmentation at the technical level prior to your next audit so that your compliance mandates can be maintained.