One of the more common issues identified during Wireless Network assessments is that organisations often utilise Pre-Shared-Keys (PSKs) for authentication, despite usually having relatively strong configurations for encryption.
PSKs passphrase authentication ideally is only recommended for home networks, and for physically segregated corporate guest wireless networks. The risks associated with using PSKs are that by definition they are a shared secret, and thus can be statically known by one or more users. This can be partly mitigated by regularly changing the passphrases, but this itself would involve administrative input.
All too often during wireless assessments do we see organisations using Pre-Shared-Key authentication for their main corporate wireless networks. More and more IT professionals are becoming security conscious as data breaches occur and securing wireless networks (and of course the connected devices) should be a priority due to the mobile nature of the modern office. Implementing a strong WPA2 802.1x configuration will greatly increase the security of those corporate wireless networks, although there are known weaknesses to be mindful of with certain configurations.
With Pre-Shared-Key authentication both the client (supplicant) and access point (authenticator, also known as ‘AP’) each attempt to prove that they know the PSK without actually disclosing this information. This process is called the 4-way handshake. Both the supplicant and authenticator each compute a Pairwise-Master-Key (PMK) from the PSK passphrase and the AP’s SSID, which is then used as a basis for creating the rest of the key exchange data (further information below).
The weakness within this is that the majority of the information required to compute the plaintext PSK passphrase can be enumerated either through packet sniffing the access point (for example the SSID), or by capturing the traffic of the 4-way handshake itself. Essentially, the Message Integrity Code (MIC) is what is captured during the handshake and is what is used as a comparison during the cracking process to identify the plaintext PSK passphrase.
An attacker would initially need to identify a wireless network that uses PSK authentication. This can easily be performed by using the aircrack-ng suite of tools, specifically the airodump-ng tool. The first step of this process would be for an attacker to start a capable wireless card (or USB wireless adaptor) in monitor mode. This can be performed with the following command (as an example):
airmon-ng start wlan0 ifconfig wlan0 down
Once the device is in monitor mode, the main interface is taken down (as per the second command).
The next step in the process is to identify a target network. Using the airodump-ng tool and only specifying the monitor interface (in this example, mon0) allows the device to hop between wireless channels. This is not ideal for capturing a specific network handshake but is useful to locate the specific channel for the next step:
The results would show several networks, each with varying signal strengths and configurations, but in our example we will use channel 1 with the ‘SureCloud-WiFi’ AP.
Our next step is to target this network. We do that by specifying additional arguments for airodump-ng:
airodump-ng mon0 –w surecloud-wifi-capture –channel 1
This command will capture wireless traffic to the file surecloud-wifi-capture-01.cap and will only focus on channel 1. Additional parameters can be specified, such as the use of –essid to target the network SSID name.
Once a handshake has been captured airodump-ng will note it at the top of the display. The next step following this is to clean up the capture file from any unnecessary packets not relating to the exchange, and to then ideally convert it to a hashcat-capable format for GPU processing. The following commands can be used to do this:
# wpaclean [output file] [input file] wpaclean surecloud-wifi-clean.cap surecloud-wifi-capture-01.cap # aircrack-ng [input file] –J [output file] aircrack-ng surecloud-wifi-clean.cap –J surecloud-wifi-hashcat
Using Hashcat is the most efficient way to perform password attacks such as dictionary attacks. How to use Hashcat is outside the scope of this article, but there are excellent resources available online:
The key exchange handshake process uses several pieces of information, some of which is transferred over the air for the other device to make its necessary computations. This information includes:
The Pairwise-Master-Key is never revealed over the air, but is used in a Pseudo-Random-Function alongside the key data (a concatenation of the Authenticator and Supplicant MAC addresses, and the Authenticator and Supplicant Nonces) to generate the Pairwise-Transient-Key.
As for the Pairwise-Transient-Key this is a 512 bit key, which is used to provide the following sub-keys:
The Key-Confirmation-Key (KCK) is the key that is used for the creation of the Message Integrity Code (MIC), which is what is ultimately used for computing the PSK passphrase by password cracking tools. The MIC key itself is calculated using a HMAC-MD5 algorithm.
From the perspective of an attacker that has captured the handshake, it is extremely difficult to compute the plaintext PSK passphrase, which is evidenced by the length of the process to compute just one MIC key for passphrase comparison. Common dictionary words (or slight variations of) should not be used for any wireless networks as these may be able to be computed within minutes. Regularly changing the passphrases is highly recommended, alongside using strong passphrases that use special characters and are not based on dictionary words – the longer the passphrase the better, up to the maximum 63 characters, but generally we would say a random strong passphrase should meet a 15 character minimum.
Furthermore, there are many resources online that can be used to obtain pre-computed SSID-PSK pairs for the most common wireless SSID names (such as ‘linksys’). These can be used to very quickly compute the actual passphrase used by a vulnerable network, and as such another recommendation is to not use common SSID names for networks as these would not appear in any pre-computed lists.