Attacking wireless networks
This post will be discussing the process by which a Client authenticates to a wireless network, and a common attack that is used to gain un-authorised access to wireless networks. There will be acronyms abound!
When a Client joins a wireless network, it does so by means of a 4-way handshake designed to prove knowledge of the correct password (key) for that network. The key itself is "Pre-Shared", meaning both the Client and the Access Point have knowledge of the key prior to the handshake. The password, referred to as a 'Pre-Shared Key (PSK)', is never transmitted during the communication between the Client and the Access Point (AP).
Before obtaining the password it is first necessary to understand the measures taken to protect it.
The Client and Access Point have knowledge of the Pre-Shared Key prior to the 4-way handshake. To be more specific - the Access Point is configured with the Pre-Shared Key prior to broadcasting the network, and the Client uses what he/she believes to be the correct key when trying to join the network.
For the sake of security, the PSK cannot be transmitted directly over the wireless medium. The PSK is instead used as input to a cryptographic hashing function, PBKDF2-SHA1, which generates a salted hash as its output. This output becomes the Pairwise Master Key (PMK). The PMK is not transmitted over the wireless medium either, but is instead used as input to a third key - the Pairwise Transient Key (PTK).
The Pairwise Transient Key is created during the 4-way handshake. It is generated based on several pieces of information: the Clients MAC address, the AP's MAC address, the Client's nonce, the AP's nonce, and the Pairwise Master Key.
The PTK is divided into a series of 3 separate keys, each with their own purpose. One of the three keys is used to calculate a 'Message Integrity Check (MIC)' that is used in packets 2, 3 and 4 of the 4-way handshake. The other 2 keys are used after the 4-way handshake for various encryption and decryption tasks.
Both the Client and the AP will generate what they believe to be the correct PTK. It is reasonable to assume that, if the AP can verify the MIC sent by the Client during the 4-way handshake, the Client has tried to join the network with the correct PSK.
Alongside this series of key construction is yet another key created and exchanged by the Access Point to the Client known as the Group Temporal Key (GTK). The GTK is used to encrypt/decrypt multicast and broadcast messages, as well as to compute Message Integrity Check's for multicast and broadcast messages. No further consideration of the GTK is required for the purpose of this discussion.
So, with this knowledge in mind, we can examine the 4-way handshake.
Packet 1 (AP to Client): The handshake begins with the AP sending a cryptographic nonce to the Client. At this point, the Client has enough information to construct the PTK.
Packet 2 (Client to AP): The Client then responds with its own cryptographic nonce, as well as a Message Integrity Check.
The AP now constructs its own PTK. Using the PTK, the AP then checks the validity of the Client's Message Integrity Check (which consequently confirms whether the Client is using the correct PSK).
Packet 3 (AP to Client): The AP responds to the Client with the Group Temporal Key and a MIC.
Packet 4 (Client to AP): The Client responds to the AP with an acknowledgement (ACK) and a MIC.
At the completion of the 4-way handshake, the Client is successfully authenticated with the Access Point. If the Client had been using the wrong Pre-Shared Key, the 4-way handshake would not have completed and the Client would not have been given access to the network.
If the Client was to lose connectivity with the AP, the 4-way handshake would need to be completed again from the start. A Client can lose connectivity with an AP for a number of reasons - perhaps the wireless card malfunctions, the Client leaves the AP's wireless network range, or a 3rd party forcibly de-authenticates the Client.
Forcibly de-authenticating the Client, while simultaneously capturing all wireless traffic within range of the attacking station, is the process that will be used to capture the 4-way handshake in this attack. Once the 4-way handshake has been captured an 'offline' password cracking tool, such as Hashcat, can be used to enumerate the WPA2 PSK.
A quick technical note regarding the captured 4-way handshake: As already discussed, the PSK is not communicated during the handshake. To successfully crack the password, the following process is performed:
1) The packet capture file is parsed for essential information - the Client MAC address, the AP MAC address, the Client nonce, the AP nonce, and a copy of the MIC sent by the Client.
2) A nominated PSK (either from a word-list or generated by brute force parameters) is hashed by PBKDF2-SHA1 to create a PMK.
3) The PMK, along with the parsed Client information, is used to create a PTK.
4) The PTK is used to create a MIC, which is then compared to the client MIC captured in the handshake. If the two match than a correct password is reported, otherwise, another password is attempted.
The network topology used in this scenario consists of a wireless router with two connected clients, and an attacking machine that is within range of the wireless router. To perform the necessary work the attacking machine uses an Alfa Networks wireless adapter capable of packet injection (find out more here: https://www.alfa.com.tw/products_show.php?pc=67&ps=241), and the Aircrack-ng suite of software (find out more here: https://www.aircrack-ng.org/).
The attacking machines network adapter is first placed into monitoring mode, allowing it to receive wireless traffic within range.
The airmon-ng command helpfully displays a list of connected wireless adapters, while the airmon-ng check kill command ensures there are no problematic networking processes running on the attacking machine. Airmon-ng start wlan0 places the adapter into its monitoring state.
With the interface in monitor mode, the attacking machine can start sniffing for interesting wireless traffic in the area.
The BSSID list shows Access Points within range, along with their broadcast network name (ESSID) and the strength of their signal (PWR).
The list of devices in the STATION section of this output shows associated and un-associated devices that are within range.
In this instance, the interesting output is on the first line with the ESSID of "1500BYTES".
With the target network now identified, a more refined approach is required in order to capture the wireless handshake.
Monitoring only the target Access Point, it is possible to identify the devices connected directly to it, their range, and whether they are broadcasting probes for any other wireless networks.
It is also worthwhile looking up the MAC addresses listed under the STATION category to determine which manufacturer produced the device so as to determine what it may be (MAC address lookup: https://macvendors.com/)
The Android phone will be targeted for the next phase. We will actively de-authenticate the phone from the network and force it to re-connect, capturing the 4-way handshake in the process. This is hardly a stealthy approach as the DeAuth packets can be seen by other devices that are sniffing wireless traffic within range. The targeted device will also lose connectivity to the wireless network momentarily which may be noticed by the user of the device. In some instances it may be better to leave this monitor running until a new device connects, and the 4-way handshake is passively captured.
With the device de-authenticated from its wireless network, it is forced to re-connect and begin the 4-way handshake again. This process is captured, as noted in the top right corner of the following output. The output helpfully tells us that a WPA handshake has been captured for the BSSID address listed.
With the 4-way handshake captured, it's now possible to open the capture file in Wireshark and take a quick look at the packets. This is not only a good learning opportunity, but a good way to verify the integrity of the captured handshake.
Let's verify that all 4 packets have been captured, and then take a quick peek at the first packet - the nonce sent by the Access Point to the Client.
We're not out of the woods yet. With the WPA handshake capture verified, it is now possible to start cracking the password. Password cracking can be done with either the CPU or the GPU, depending on the resources available on the machine. To see the difference between the two options we will examine the results of a CPU based attack and a GPU based attack, beginning with CPU.
Both tests will be based on a dictionary attack using the RockYou word list, which contains just shy of 14.4 million passwords.
The CPU based password cracking software, Aircrack-ng, is capable of attempting between 3856.54 to 4000 passwords per second on a 6-core AMD CPU (3 physical, 3 virtual cores) for a total time of 42 minutes. It is worth noting that this command was run on a live USB boot of Kali Linux, so the entire CPU was available for use and there were no virtual machine limitations at play. The results of this software will vary depending on the CPU used - more cores means more keys per second.
A suite of software named Hashcat will be used for GPU based password cracking. Hashcat is run on either Windows or Linux. In this instance we will be running Hashcat from a Windows 10 machine, with an Nvidea GeForce 950 GTX. While the hardware is not 'bleeding edge' the results are still quite impressive.
Hashcat was able to complete the entire RockYou word list of 14,344,384 passwords in just under 4 minutes. Just like the CPU password cracking software, the results of Hashcat will vary depending on how many GPU's are available and how powerful they are.
Worth noting is that the password for the 1500BYTES wireless network was not found on this list - so what other password cracking options are still available? The answer is either alternative word lists, or brute forcing.
Without the proper hardware, brute forcing a password can take an unreasonable amount of time. Unfortunately a single Nvidea GeForce 950 GTX will take 31 days and 9 hours to brute force all possible combinations in an 8 character password consisting of only lower case letters.
With the correct hardware it can take only a matter of seconds to brute force 8 character passwords consisting of lower/upper case letters and/or numbers. Adding special symbols would again increase the amount of time taken, but not substantially.
Realistically the only defense against a brute force attack is to increase the length of the password used, while also using upper/lower case letters, numbers, and special symbols.
Word lists are not guaranteed to contain the correct password, but a good word list is significantly more efficient than brute forcing. Word lists are not hard to find or create; a very short amount of time on Google is all it takes to find additional lists, and creating them is as easy as writing possible passwords sequentially in a notepad file.
Word lists that are created based on information found in data breaches are of particular concern as they contain actual passwords being used in the wild. In general, most people reuse passwords across multiple services which makes such a word list more likely to contain correct passwords more often.
Keeping the chances of seeing your password(s) in one of these lists as low as possible is based on two crucial, equally important points: do not reuse passwords, and do not use dictionary words or words constructed via concatenation.
Based on the small snippet of the "EnglishWords466K" list above, it should be relatively clear that any words found in the dictionary (or concatenated words) are easy targets. While the words themselves can be made more complex by using letter substitution with numerals and special symbols, the overall security of the word is still low.
In this example an additional word list is used against the WPA handshake capture for the 1500BYTES network. The word list, constructed of English words with lowercase letters and numerals, contains a modest 466,000 potential passwords.
This time the crack is successful - the password 'pastelsky1' is retrieved. It is now possible to connect to the 1500BYTES network as an authenticated client and start accessing resources available to that network.
Overall, this attack is quite straight forward and can be achieved without any underlying knowledge of the 4-way handshake, password word lists/brute forcing, or even of the software being used to perform the attack with. Understanding the topics and software in this post is advantageous when troubleshooting the attack or, more importantly, when defending against it.
When a Client joins a wireless network, it does so by means of a 4-way handshake designed to prove knowledge of the correct password (key) for that network. The key itself is "Pre-Shared", meaning both the Client and the Access Point have knowledge of the key prior to the handshake. The password, referred to as a 'Pre-Shared Key (PSK)', is never transmitted during the communication between the Client and the Access Point (AP).
So, how then, does one obtain the password to such a network?
Before obtaining the password it is first necessary to understand the measures taken to protect it.
The Client and Access Point have knowledge of the Pre-Shared Key prior to the 4-way handshake. To be more specific - the Access Point is configured with the Pre-Shared Key prior to broadcasting the network, and the Client uses what he/she believes to be the correct key when trying to join the network.
For the sake of security, the PSK cannot be transmitted directly over the wireless medium. The PSK is instead used as input to a cryptographic hashing function, PBKDF2-SHA1, which generates a salted hash as its output. This output becomes the Pairwise Master Key (PMK). The PMK is not transmitted over the wireless medium either, but is instead used as input to a third key - the Pairwise Transient Key (PTK).
The Pairwise Transient Key is created during the 4-way handshake. It is generated based on several pieces of information: the Clients MAC address, the AP's MAC address, the Client's nonce, the AP's nonce, and the Pairwise Master Key.
The PTK is divided into a series of 3 separate keys, each with their own purpose. One of the three keys is used to calculate a 'Message Integrity Check (MIC)' that is used in packets 2, 3 and 4 of the 4-way handshake. The other 2 keys are used after the 4-way handshake for various encryption and decryption tasks.
Both the Client and the AP will generate what they believe to be the correct PTK. It is reasonable to assume that, if the AP can verify the MIC sent by the Client during the 4-way handshake, the Client has tried to join the network with the correct PSK.
Alongside this series of key construction is yet another key created and exchanged by the Access Point to the Client known as the Group Temporal Key (GTK). The GTK is used to encrypt/decrypt multicast and broadcast messages, as well as to compute Message Integrity Check's for multicast and broadcast messages. No further consideration of the GTK is required for the purpose of this discussion.
 | ||
| Information known by the Client and AP before the 4-way handshake. |
So, with this knowledge in mind, we can examine the 4-way handshake.
Packet 1 (AP to Client): The handshake begins with the AP sending a cryptographic nonce to the Client. At this point, the Client has enough information to construct the PTK.
Packet 2 (Client to AP): The Client then responds with its own cryptographic nonce, as well as a Message Integrity Check.
The AP now constructs its own PTK. Using the PTK, the AP then checks the validity of the Client's Message Integrity Check (which consequently confirms whether the Client is using the correct PSK).
Packet 3 (AP to Client): The AP responds to the Client with the Group Temporal Key and a MIC.
Packet 4 (Client to AP): The Client responds to the AP with an acknowledgement (ACK) and a MIC.
 |
| The 4-way handshake |
At the completion of the 4-way handshake, the Client is successfully authenticated with the Access Point. If the Client had been using the wrong Pre-Shared Key, the 4-way handshake would not have completed and the Client would not have been given access to the network.
If the Client was to lose connectivity with the AP, the 4-way handshake would need to be completed again from the start. A Client can lose connectivity with an AP for a number of reasons - perhaps the wireless card malfunctions, the Client leaves the AP's wireless network range, or a 3rd party forcibly de-authenticates the Client.
Forcibly de-authenticating the Client, while simultaneously capturing all wireless traffic within range of the attacking station, is the process that will be used to capture the 4-way handshake in this attack. Once the 4-way handshake has been captured an 'offline' password cracking tool, such as Hashcat, can be used to enumerate the WPA2 PSK.
A quick technical note regarding the captured 4-way handshake: As already discussed, the PSK is not communicated during the handshake. To successfully crack the password, the following process is performed:
1) The packet capture file is parsed for essential information - the Client MAC address, the AP MAC address, the Client nonce, the AP nonce, and a copy of the MIC sent by the Client.
2) A nominated PSK (either from a word-list or generated by brute force parameters) is hashed by PBKDF2-SHA1 to create a PMK.
3) The PMK, along with the parsed Client information, is used to create a PTK.
4) The PTK is used to create a MIC, which is then compared to the client MIC captured in the handshake. If the two match than a correct password is reported, otherwise, another password is attempted.
The network topology used in this scenario consists of a wireless router with two connected clients, and an attacking machine that is within range of the wireless router. To perform the necessary work the attacking machine uses an Alfa Networks wireless adapter capable of packet injection (find out more here: https://www.alfa.com.tw/products_show.php?pc=67&ps=241), and the Aircrack-ng suite of software (find out more here: https://www.aircrack-ng.org/).
The attacking machines network adapter is first placed into monitoring mode, allowing it to receive wireless traffic within range.
The airmon-ng command helpfully displays a list of connected wireless adapters, while the airmon-ng check kill command ensures there are no problematic networking processes running on the attacking machine. Airmon-ng start wlan0 places the adapter into its monitoring state.
 |
| Placing a wireless adapter into monitoring mode. |
With the interface in monitor mode, the attacking machine can start sniffing for interesting wireless traffic in the area.
The BSSID list shows Access Points within range, along with their broadcast network name (ESSID) and the strength of their signal (PWR).
The list of devices in the STATION section of this output shows associated and un-associated devices that are within range.
In this instance, the interesting output is on the first line with the ESSID of "1500BYTES".
 |
| There's a lot of wi-fi around here... |
With the target network now identified, a more refined approach is required in order to capture the wireless handshake.
Monitoring only the target Access Point, it is possible to identify the devices connected directly to it, their range, and whether they are broadcasting probes for any other wireless networks.
It is also worthwhile looking up the MAC addresses listed under the STATION category to determine which manufacturer produced the device so as to determine what it may be (MAC address lookup: https://macvendors.com/)
 |
| Monitoring the 1500BYTES wireless network, and its two connected clients. |
The Android phone will be targeted for the next phase. We will actively de-authenticate the phone from the network and force it to re-connect, capturing the 4-way handshake in the process. This is hardly a stealthy approach as the DeAuth packets can be seen by other devices that are sniffing wireless traffic within range. The targeted device will also lose connectivity to the wireless network momentarily which may be noticed by the user of the device. In some instances it may be better to leave this monitor running until a new device connects, and the 4-way handshake is passively captured.
 |
| DeAuth packets being sent to the target Access Point |
With the device de-authenticated from its wireless network, it is forced to re-connect and begin the 4-way handshake again. This process is captured, as noted in the top right corner of the following output. The output helpfully tells us that a WPA handshake has been captured for the BSSID address listed.
 |
| WPA handshake captured |
With the 4-way handshake captured, it's now possible to open the capture file in Wireshark and take a quick look at the packets. This is not only a good learning opportunity, but a good way to verify the integrity of the captured handshake.
Let's verify that all 4 packets have been captured, and then take a quick peek at the first packet - the nonce sent by the Access Point to the Client.
 |
| Messages 1 through 4 of the 4-way handshake |
 |
| Highlighted: the Access Point nonce sent to the client in packet 1. |
We're not out of the woods yet. With the WPA handshake capture verified, it is now possible to start cracking the password. Password cracking can be done with either the CPU or the GPU, depending on the resources available on the machine. To see the difference between the two options we will examine the results of a CPU based attack and a GPU based attack, beginning with CPU.
Both tests will be based on a dictionary attack using the RockYou word list, which contains just shy of 14.4 million passwords.
 |
| That's 14,344,392 passwords to be precise! |
The CPU based password cracking software, Aircrack-ng, is capable of attempting between 3856.54 to 4000 passwords per second on a 6-core AMD CPU (3 physical, 3 virtual cores) for a total time of 42 minutes. It is worth noting that this command was run on a live USB boot of Kali Linux, so the entire CPU was available for use and there were no virtual machine limitations at play. The results of this software will vary depending on the CPU used - more cores means more keys per second.
 |
| CPU password cracking with Aircrack-ng |
A suite of software named Hashcat will be used for GPU based password cracking. Hashcat is run on either Windows or Linux. In this instance we will be running Hashcat from a Windows 10 machine, with an Nvidea GeForce 950 GTX. While the hardware is not 'bleeding edge' the results are still quite impressive.
Hashcat was able to complete the entire RockYou word list of 14,344,384 passwords in just under 4 minutes. Just like the CPU password cracking software, the results of Hashcat will vary depending on how many GPU's are available and how powerful they are.
Worth noting is that the password for the 1500BYTES wireless network was not found on this list - so what other password cracking options are still available? The answer is either alternative word lists, or brute forcing.
 |
| GPU password cracking with Hashcat |
Without the proper hardware, brute forcing a password can take an unreasonable amount of time. Unfortunately a single Nvidea GeForce 950 GTX will take 31 days and 9 hours to brute force all possible combinations in an 8 character password consisting of only lower case letters.
With the correct hardware it can take only a matter of seconds to brute force 8 character passwords consisting of lower/upper case letters and/or numbers. Adding special symbols would again increase the amount of time taken, but not substantially.
Realistically the only defense against a brute force attack is to increase the length of the password used, while also using upper/lower case letters, numbers, and special symbols.
 |
| Brute forcing an 8 character password with a GTX 950 |
Word lists are not guaranteed to contain the correct password, but a good word list is significantly more efficient than brute forcing. Word lists are not hard to find or create; a very short amount of time on Google is all it takes to find additional lists, and creating them is as easy as writing possible passwords sequentially in a notepad file.
Word lists that are created based on information found in data breaches are of particular concern as they contain actual passwords being used in the wild. In general, most people reuse passwords across multiple services which makes such a word list more likely to contain correct passwords more often.
Keeping the chances of seeing your password(s) in one of these lists as low as possible is based on two crucial, equally important points: do not reuse passwords, and do not use dictionary words or words constructed via concatenation.
 |
| Lower case English word list example |
Based on the small snippet of the "EnglishWords466K" list above, it should be relatively clear that any words found in the dictionary (or concatenated words) are easy targets. While the words themselves can be made more complex by using letter substitution with numerals and special symbols, the overall security of the word is still low.
In this example an additional word list is used against the WPA handshake capture for the 1500BYTES network. The word list, constructed of English words with lowercase letters and numerals, contains a modest 466,000 potential passwords.
This time the crack is successful - the password 'pastelsky1' is retrieved. It is now possible to connect to the 1500BYTES network as an authenticated client and start accessing resources available to that network.
 |
| Success |
Overall, this attack is quite straight forward and can be achieved without any underlying knowledge of the 4-way handshake, password word lists/brute forcing, or even of the software being used to perform the attack with. Understanding the topics and software in this post is advantageous when troubleshooting the attack or, more importantly, when defending against it.
Comments
Post a Comment