Jul 30, 2019 by Alexandre | 6046 views
It is very important to set up strong security on your Wi-Fi AP to avoid someone connects on your local network and intercept all (or a part) of the traffic.
In 1999, the WEP (Wired Equivalent Privacy) was introduced. It was deprecated in 2004 after some researchers discovered flaws in the design of the protocol. Currently, it is really easy to crack a WEP password. With the right tools, it requires only a few minutes.
The Wi-Fi Alliance defined the WPA (Wi-Fi Protected Access) in the response of weakness found in WEP. WPA became available in 2003 and WPA2 (a little improvement of WPA) in 2004.
In 2018, the Alliance announced WPA3 as a replacement of WPA2. But currently, the WPA2 is the most used protocol to secure Wi-Fi AP.
WPA and WPA2 are very similar from an authentication perspective. We will use the global term "WPA" and point the difference between the two when it is necessary.
WPA can be used in two different modes:
This article is about the WPA-PSK mode. This protocol uses a single pass-phrase (PSK) for authentication to the network, shared among all devices and the AP. The PSK is between 8 and 63 characters in length. Because of this unique PSK, if an attacker can find it, he can access and expose all client devices on the network.
From this PSK, each device derives, and store, a Pairwise Master Key (PMK) until the PSK or the SSID (access point's name) change.
When a client tries to connect to an authenticator, a protocol called 4-ways handshake is initialized to generate a Pairwise Transient Key (PTK). This key is used to encrypt data between a client and the AP and change at least as every 65,535 packets. It is an important improvement compared to WEP.
The following sections will describe more precisely the PMK generation, the 4-way handshake and the PTK generation.
First, all devices derive the Pairwise Master Key (PMK) from the PSK.
The PMK is computed by using to PBKDF2 (Password-Based Key Derivation Function 2) that is a key derivation function. This kind of functions is used to reduce vulnerabilities to brute force attacks because of the high computational cost.
DK = PBKDF2(PRF, password, Salt, c, len)
The WPA protocol generates the PMK as  :
PMK = PBKDF2(HMAC-SHA1, PSK, SSID, 4096, 256)
The following figure represents the previous equation.
The PMK is composed of the first 256 bits of the result of the computation. This step is performed once by all clients and the AP and the result is stored until the pass-phrase or the SSID change.
The 4-way handshake provides mutual authentication based on the shared secret key PMK and negotiates a fresh session key PTK. The PTK is derived from the PMK, two nonces, the MAC addresses of both the client and the authenticator. This 64 bytes PTK is split into:
During the handshake, every message is defined using the EAPOL frames. The following figure is the layout of an EAPOL frame.
Most of these fields are important during the handshake, but we are specifically interested by the key nonce and key MIC fields in order to crack the pass-phrase. For more information about the EAPOL frame, see  and 
The following figure represents a 4-way handshake. The figure is willingly simplified for better comprehension. There is no mention of the Group Transient Key (GTK) for example.
The different steps are:
The Authenticator generates a nonce (random number) called ANonce (for Authenticator Nonce)
The Authenticator sends the ANonce to the client. The message has no Message Integrity Code (MIC)
The client generates the SNonce (Supplicant Nonce)
The client derives the PTK with
PTK = PRF(PMK || ANonce || SNonce || AMAC || SMAC)
The supplicant sends a message with the SNonce and a MIC for an integrity check. The MIC is computed by using to the KCK (the 16 first bytes of the PTK) by using the Michael algorithm . It is important to note that the SNonce is not encrypted.
The Authenticator derives the PTK with the received SNonce.
The Authenticator verifies the Message Integrity Check.
The Authenticator sends a message to the Supplicants (it can contain some encrypted data thanks to KEK) with a MIC.
The Supplicant checks the MIC.
The Supplicant installs the PTK.
The Supplicant sends a message (it is a kind of confirmation message) with a MIC.
The Authenticator checks the MIC.
The Authenticator installs the PTK.
After these steps, all messages are encrypted using the TK.
At least as every 65.535 packets, the PTK is refreshed, but if the Supplicant and the Authenticator are already communicating, they use the current PTK to exchange data for the new PTK.
Sniff a 4-way handshake is enough to build an offline attack and try to find the passphrase (PSK).
An attacker observes a client connection and obtains:
For each PSK guess, the attacker computes the PMK' and the PTK'. It uses his PTK' to compute a MIC' for packet 2, 3 or 4 of the handshake. If the computed MIC' is equal to the MIC of the packets, the PSK guess is correct.
The following figure describes the process to crack the password.
Several tools can be used to perform this attack. The suite of tools Aircrack-ng provides all elements necessary to crack a password (airodump-ng for capturing packets, aircrack-ng to perform a dictionary attack, airdecap-ng to decrypt packets).
To perform the attack, we used another tool: bettercap . This tool, written by evilsocket   in Golang. It is a rewriting of the famous ettercap command-line tool. Bettercap has a lot of features like WI-Fi network scanning, BLE devices scanning, ARP-DNS-DHCpv6 spoofing, network sniffer, port scanner, REST API,... Bettercap provides also an easy web interface.
The first step is to set your Wi-Fi interface in monitor mode to be able to scan all channels. A lot of built-in Wi-Fi cards support monitor mode.
To set up our Wi-Fi interface in monitor mode, we used airmon-ng. First, identify the name of your Wi-Fi interface with
The result should look like the following figure.
The command to set the interface in monitor mode is:
airmon-ng wlp4s0 start
Of course, replace wlp4s0 by the name of your interface. The name of your interface will change the previous command. For this example, the name will be wlp4s0mon.
sudo bettercap -iface wlp4s0mon
bettercap is launched to be used with wlp4s0mon interface. You should see something like the following figure.
The following commands run a scan of all Wi-Fi channels and display the result in a table.
# Start channel hooping on all supporting frequencies >> wifi.recon on # Every second, clear view and present an updated list of Wi-Fi Access Points >> set ticker.commands 'clear; wifi.show' >> ticker on
The result should be like the following figure
In this example, we tried to find the password for the SSID Linksys01845. The channel used is the 11 and there are 2 clients connected on it. To avoid jumping to other frequencies and potentially losing useful packets, we will scan only the channel 11.
>> wifi.recon.channel 11
Capturing a 4-way handshake requires a client to connect to the network. Waiting for that can take a lot of time. To avoid this waste of time, we can use a de-authentication attack.
The protocol 802.11 (Wi-Fi) provides a mechanism to, originally, de-authenticate any rogue client on a network. The Access Point sends a frame to the client and it will close the connexion. The problem is, de-authentication frames are not encrypted. It is easy to forge fake frames by spoofing the origin MAC address (AP MAC address).
Bettercap is able to forge fake de-authentication frames and broadcast them to all clients on a network. Thanks to this, all clients will close their connexions and they will initiate a fresh 4-way handshake.
To perform a de-authentication attack, the command, in bettercap, (replace 58:xx:xx:xx:xx:xx by the MAC address of the target AP):
>> wifi.deauth 58:xx:xx:xx:xx:xx
Once the clients will reconnect, bettercap will capture the need EAPOL frames of the handshake and store it in a pcap file.
Different tools are available to crack the handshake. It is possible to do that with aircrack-ng, Pyrit project or hashcat. We used hashcat  (a tool to recover many different types of hashes) because it is very well documented, very powerful, supports a lot of different hardware and uses multi-threads.
Hashcat works only with .hccapx file. To convert pcap file to hccapx file we can use an online converter or hashcat-utils locally.
/path/to/cap2hccapx /home/alex/bettercap-wifi-handshake.pcap bettercap-wifi-handshake.hccapx
We are now ready to run hashcat and try to crack the password.
/path/to/hashcat -m2500 -a3 -w3 bettercap-wifi-handshake.hccapx ?l?l?l?l?l?l?l?l
The previous example of command has 4 important parameters:
Concretely, with this command, we try all 8-lowercase letters combinations.
Another way the crack a 4-way handshake is a dictionary attack. The idea is to try the passwords the most used in the world. The following command performs a dictionary attack:
/path/to/hashcat -m2500 -a0 -w3 bettercap-wifi-handshake.hccapx rockyou.txt
The file rockyou.txt is a famous file that contains around 15 million leaked passwords.
It is also possible to use a dictionary file in combination with a rules file. For example, classical rules are to replace the E by a 3 or A by a 4.
Theoretically, it is possible to crack any WPA/WPA2 protection. But because of the high computational cost of the hashes, it is not feasible for password longer than 12 or 15 characters.
A few years ago, the Proximus Internet box (B-Box) used 8 capital-letters length passwords. With the current classical hardware, it takes around 20 days to complete a brute-force attack. The new routers of Belgian Internet provider (Proximus, Telenet, VOO, ...) use a 12 characters password (digits and lowercase letters). A brute-force attack would take several years and the interest of founding the password would be null.
To illustrate the necessary time to crack a WPA password, we performed a performance analysis. We ran hashcat on three kinds of hardware and we tried to crack different types of password with brute-force and dictionary attacks.
The hardwares are:
The attacks we performed:
The results are synthesized in the following table
|Nvidia GTX 960M||96 cores Intel Xeon||Google Cloud 4 Nvidia Tesla T4|
|8-digits brute-force attack||+/-30 minutes||+/- 19 minutes||+/- 80 seconds|
|10-digits brute-force attack||+/- 2 days||+/- 30 hours||+/- 140 minutes|
|8-lowercase letters brute-force attack||+/- 40 days||+/- 28 days||+/- 2 days|
|12-characters (digits + lowercase) brute-force attack||+/- 160 years||+/- 100 years||+/- 7 years|
|Dictionary attack (rockyou + basic rules)||+/- 20 minutes||+/- 13 minutes||+/- 30 seconds|
|Dictionary attack (rockyou + OneRuleToRuleThemAll rules)||+/- 140 days||+/- 95 days||+/- 6 days|
We can note that GPUs are better than CPUs for computing hashes. We note also that for password with more than 12 characters, brute-force attacks are not very interesting even with very good hardware.
A dictionary attack is, of course, faster but the attack could be failed if the password is a random one. Combining a dictionary attack with a rules file increase the probability to find the password. The file OneRuleToRuleThemAll is designed to be better than other rules files. This rules file was tested, with rockyou.txt, on the Lifeboat leak: 68.36% of the passwords were recovered!
It could be interesting to estimate the price of this attack. A Google Cloud server with 4 Nvidia Tesla T4 cost only 2.72$/hour. A dictionary attack with OneRuleToRuleThemAll cost only around 400$. It is expensive for a single person but it is cheap for an organization, government, company,...
We can now answer the question: is it possible to crack any personal WPA/WPA2 password? Theoretically, yes, any WPA/WPA2 system is vulnerable to this attack. Practically, it is not always possible to recover the password in a reasonable time.... currently! Maybe in a few years, the hardware will be able to crack a 50 characters password in few hours...
To protect your network, use a random password with, at least, 12 or even 15 characters. It is also a good idea to change the password sometimes to render inefficient an off-line attack.
 IEEE Std 802.11i. 2004. Amendment 6: Medium Access Control (MAC) Security Enhancements; pp 77-84
 IEEE Std 802.11i. 2004. Amendment 6: Medium Access Control (MAC) Security Enhancements; pp 45, 48, 49.