Shulou(Shulou.com)06/01 Report--

This article shows you how to use Python to understand the WPA four-way handshake process, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Environmental preparation

Before officially starting the analysis, prepare the software and analysis objects.

System environment

The operating system used this time is Windows10 1909, part of which requires Linux to use the Kali installed by the virtual machine.

In the code part, the interpreter version is Python 2.7.

The packet analysis tool uses the classic Wireshark.

Data preparation

Because different encryption methods and parameters have a great influence on the handshake packet, the analysis object uses the WPA packet officially given by Wireshark.

The package can be downloaded from the https://wiki.wireshark.org/HowToDecrypt802.11 page:

Manually capture the handshake bag

As an additional note, if you want to capture the device's WPA handshake package yourself, you need additional software and set the network card to Monitor Mode. Let's give a brief introduction.

Windows platform: to capture 802.11 management frames on the Windows platform, you need to use Microsoft's official software Microsoft Network Monitor. It is also relatively easy to install and use, and there are quite a number of tutorials online, such as "crawling 802.11 Management Pack under windows". It is important to note that after the software opens Monitor Mode in scan Settings (Scanning Options), the window cannot be closed, otherwise it will exit:

Linux platform: under the Linux platform, we can use the familiar aircrack-ng suite to set the Monitor Mode of the network card, and use Wireshrak to obtain and view data. Here, take Kali as an example. Other Linux systems can install related packages on their own.

The command to set the listening mode is:

Root@kali:~# airmon-ng start wlan0

Where wlan0 is the name of the network card. If the following occurs:

Root@kali:~# airmon-ng start wlan0

Found 2 processes that could cause trouble.

If airodump-ng, aireplay-ng or airtun-ng stops working after

A short period of time, you may want to run 'airmon-ng check kill'

PID Name

1959 NetworkManager

1989 wpa_supplicant

PHY Interface Driver Chipset

Phy0 wlan0 rt2800usb Ralink Technology, Corp. RT2870/RT3070

(mac80211 monitor mode vif enabled for [phy0] wlan0 on [phy0] wlan0mon)

(mac80211 station mode vif disabled for [phy0] wlan0)

Indicates that the Nic is occupied, and you need to use the airmon-ng check kill command to end the occupation process:

Root@kali:~# airmon-ng check kill

Killing these processes:

PID Name

1989 wpa_supplicant

Root@kali:~# airmon-ng start wlan0

PHY Interface Driver Chipset

Phy0 wlan0mon rt2800usb Ralink Technology, Corp. RT2870/RT3070

Here the name of the network card will become wlan0mon, which needs to be noted.

However, after direct setting, sometimes only part of the packet can be caught, such as only the data on the AP side, and the data packets on the device side are lost because the channel is not specified. At this point, you need to use the airodump-ng tool to view the channel of the target AP:

Root@kali:~# airodump-ng wlan0mon

In the information shown in the first line of the figure above, CH represents the channel. If we want to capture the AP with a four-way handshake, we need to fix the channel monitored by the Nic to 11:

Root@kali:~# airmon-ng start wlan0mon 11

PHY Interface Driver Chipset

Phy0 wlan0mon rt2800usb Ralink Technology, Corp. RT2870/RT3070

(mac80211 monitor mode already enabled for [phy0] wlan0mon on [phy0] 11)

See the prompt in parentheses on the last line of the command line, indicating that it has been set to fixed listening channel 11.

Open wireshark at this time, select the network card wlan0mon to capture.

WPA four-way handshake

In the previous article, "A brief introduction to Wi-Fi attacks", we have briefly explained the handshake process of WPA, and summed up that the four-way handshake of WPA has been completed:

1) Verification of Wi-Fi password

2) calculation of encrypted passwords for subsequent communications (note that this is "calculation", not "transmission")

In the process of handshake, some process products will be generated, such as the key of encrypting handshake data, integrity check data and so on. The overview view of key calculation is as follows:

A simple schematic diagram of a four-way handshake:

Next, we will introduce the calculation process of each step step by step.

Preparation before handshake: calculating PMK

PMK (Pairwise Master Key) is a very core key in the whole WPA authentication process, which is calculated from Wi-Fi 's SSID and Pre-Shared-Key (that is, Wi-Fi password). Its algorithm is called Password-Based Key Derivation Function 2 (PBKDF2), which uses HMAC-SHA1 and SSID as salt value for hashing.

In the default Python environment, the pbkdf2 library needs to be installed to support this algorithm, which can be installed using the pip install pbkdf2 command.

= (,). ()

In addition, you can use the wpa_passphrase tool in the Linux system to calculate the PMK with the command:

Pentest@DESKTOP-2AE07FJ:~$ wpa_passphrase Coherer Induction

It can be seen here that the calculated values are consistent.

First handshake: pass ANonce,STA to calculate PTK

During the first handshake of WPA, the AP sends the ANonce to STA:

In this packet, in addition to ANonce, the header contains the MAC addresses of both parties. At this time, STA generates SNonce locally, which satisfies all the conditions of PTK calculation, so the calculation of PTK is carried out.

Because SNonce is in the packet of the second handshake, the demonstration of this part of the calculation will take place in the next section.

Second handshake: pass SNonce,AP to calculate PTK

On the second handshake, STA sends SNonce to AP:

The calculation of PTK (Pairwise Transient Key) requires the PRF512 algorithm, which is implemented with reference to the algorithm given in the article "Understanding WPA/WPA2 Hash (MIC) Cracking Process In Python":

(,): = (): =. (,) () + =. () [:]

The ANonce, SNonce and MAC addresses extracted from the first two handshakes are spliced together as part of the calculation of PTK:

= () = (,)

PRF512 requires three parameters, PMK,PKE and the key_data calculated above. Where PKE is a fixed string, PMK has calculated in the previous article:

= (,). ()

At this point, AP and STA have each calculated the PTK (normally the content of the PTK calculated by both sides is the same).

The composition of PTK

In the previous step, the calculated PTK is a string of 512bit (64 bytes). This is because the WPA in the official sample package provided by Wireshark we downloaded uses TKIP encryption. If it is CCMP encryption, the algorithm here will be different, because the calculated PTK should be 384bit.

Taking TKIP encryption as an example, the string of 512bit can be divided into three parts: KCK, KEK, and TK.

KCK (Key Confirmation Key): MIC used to calculate WPA EAPOL key messages (integrity verification)

KEK (Key Encryption Key): used to encrypt additional data sent to the client (in the key data field)

TK (Temporal Key): for subsequent communication data encryption

In TKIP encryption mode, PTK has a total of 512bit, in which the order is: KCK (128bit), KEK (128bit), TK (256bit)

In CCMP encryption mode, PTK has a total of 384bit, in which the order is: KCK (128bit), KEK (128bit), TK (128bit)

As calculated in the previous section, the PTK, divided by length, should be:

KCK = b1cd792716762903f723424cd7d16511

KEK = 82a644133bfa4e0b75d96d2308358433

TK = 15798d511beae0028313c8ab32f12c7ecb71c893482669daaf0e9223fe1c0aed

Verify MIC

Comparing the first handshake with the second handshake, you will find that the WPA Key MIC field has changed from the original all zero to a string of characters in the packet:

MIC (Message Integrity Code): the message integrity code verifies that the data has been tampered with and that the PSK is correct (because the MIC is calculated by PTK and the PTK is generated by PSK).

The calculation of MIC is the result of HMAC operation with KCK as the key (Key) and the whole 802.1X message as the message body (Message), which is a total of 128bit.

By the way, the offline cracking of the password of WPA also uses PSK to generate PMK, and calculates the KCK according to the handshake packet, regenerates it into MIC, and compares the MIC in the original packet to determine whether the password is correct.

When we verify manually, we need to extract the entire message (here take the second handshake as an example), find the WPA Key MIC field, replace this part with 0, and then calculate it.

This part of the code is as follows:

=. (). ([:],.). () [:]

At this point, most of the calculation and verification tasks have been completed.

Third handshake: pass encrypted GTK,STA installation TK

In the third handshake, AP sends data to STA, where the MIC part is consistent with the above calculation. After the STA receives the data, verifying that the MIC is passed means that the AP is valid and the PMK of both sides is consistent.

At the same time, the encrypted GTK is included in this packet. GTK (Group Temporal Key) is used to encrypt broadcast and multicast data. The key for GTK encryption is KEK, and its decryption and use are not detailed here.

When STA receives the third handshake packet and verifies that the MIC is passed, the calculated TK (the last segment of the PTK) is installed into the system as the subsequent communication encryption key.

Fourth handshake: AP install TK

The last handshake is only the confirmation message sent by STA to AP, indicating that the key has been installed, and the key installation will also be carried out on the AP side. At this point, the key installation of both parties is completed, and the subsequent communication will be carried out according to the key in the previous step.

Key reinstallation attack KRACK Attack

The above briefly combs the process of WPA's four-way handshake, omitting some parts of it. Because I mainly want to help understand the KRACK vulnerability, I focus on the key installation part of the third handshake and the key source of the installation.

Principle

With regard to this vulnerability, those who are interested can refer to the "KRACK Attacks Analysis report on WPA2 key reinstallation attacks". I feel that this article explains this vulnerability in more detail. To sum up, this loophole is:

Among them, versions 2.4 and 2.5 of wpa_supplicant implement the protocol comments that "once installed, the encryption key can be cleared from memory", which will cause the client to install a secret key with all zero values. Therefore, Linux and Android devices that use these wpa_supplicant versions will be seriously threatened.

This vulnerability exploits wpa_supplicant 's handling of TK during the third handshake to achieve the purpose of attack. Because the TK is generated from the data in the first and second handshake packages, STA saves the key in local memory. When the packet of the third handshake is received, STA installs the key and clears it from memory ("once installed, the encryption key can be cleared from memory"), so when the handshake package is received again, the program loads this part of the cleared memory again, causing the reinstalled key to be all zero.

Utilization

Since no direct use of EXP/POC has been found, there is a detection tool on Github: https://github.com/vanhoefm/krackattacks-scripts, and a demonstration of this vulnerability is available on its website https://www.krackattacks.com.

From the point of view of the principle and demonstration, the KRACK vulnerability needs to build a Rogue AP as a middleman to forward handshake data frames. When the third handshake packet is sent, playback is performed.

Because the third handshake is received several times, STA attempts to install the all-zero key and uses the key to encrypt subsequent traffic packets. Rogue AP's communication key is set to 0 in advance so that it can communicate with STA normally.

At present, there is no time to practice this vulnerability, only to analyze the exploit method of the vulnerability in principle, the vulnerability is more like the traditional Evil Twin attack method, but the Evil Twin needs to know the password of the target AP to let the user's device connect smoothly; with KRACK Attack, the attacker can realize the man-in-the-middle attack without knowing the password of the target AP and monitor the traffic of the victim.

Summary

In the four-way handshake of WPA, the first two times are in the exchange of information about computing PTK (ANonce, SNonce), AP verifies the STA identity (using MIC) and calculates the PTK; third handshake STA verifies the identity of AP, transmits encrypted GTK, and installs the calculated TK; the fourth handshake confirms that the key installation is complete.

Attached: complete Python code for calculating MIC

, (,): = (,): =. (,) () + =. () [:] = (,). . (), [:]. () =. () =. ([:],.). () [:], the above is how to understand the WPA four-way handshake process with the help of Python. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.