By: Slade Griffin, Director of Security Assessments
Contextual Security Solutions | August 29, 2019 @ 8:38
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 Istandard. 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.
The hcxtools suite (https://github.com/ZerBea/hcxdumptool) allows for a more prescriptive and focused attack using the same vector but is a more manual process. After installing the tools you can run the command below to begin capturing wireless packets with the appropriate wireless adapter. In this example I am creating a pcap file named “wifitest” and attacking only my lab wireless access point.
Next you want to extract any captured hashes into the appropriate format for either John the Ripper or Hashcat as shown in the next video. In this clip I use hcxpcaptool to dump the hashes to “testhashes.txt” which are formatted for Hashcat.
For the next 2 clips I wanted to display the difference in using a CPU and a GPU for cracking the hashes. In the first clip it would take over 21 days to run this dictionary attack using a CPU compared to 3 minutes using an older GPU.
In the previous video you can see that we were able to crack the password using our dictionary.
Wifite has been updated to include the PMKID attack however there are some limitations to using the automated framework. As you can see in the referenced video, WiFite will only run the PMKID attack for 30 seconds.
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 guest 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 unimitgated 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.