We have so many blogs that helps us to learn about the PMF , Still I will try to keep PMF related posts as unique as as possible.
This PMF is enabled by default in the recently introduced WPA3 and OWE and it is very interesting feature introduced by the standard. I will be writing multiple posts about PMF.
What are we going to learn in the multiple PMF related posts ?
- We will learn about the PMF feature.
- We will learn the Keys Generation and MIC Verification for the PMF in the 4-way Handshake, and how is it different from WPA2 without PMF.
- We will create a attack scenario and we will learn about the SA Query Request/SA Query Response Generation and Verification, and when it will be triggered, and what does CCMP programs expects as a input for SA Query Exchange.
- PMF based Broadcast Deauthentication/Disassociation Frame generation and verification by using IGTK, and input data that CCMP program expects.
- PMF based Unicast Deauthentication/Disassociation Frame generation and verification by using TK, and input data that CCMP program expects.
We will discuss few problem scenarios , there will be more attacking scenarios though. We will discuss few popular problem scenarios.
1. Here the STA and AP has the valid connection.
2. An attacker sends the Deauthentication/Disassociation notificaiton to the client with the spoofed MAC Addresses.
3. Here the STA assumes that the Deauthentication/DisAssociation came from the valid AP and terminates the session.
I have used the below python script to trigger the Deauthentication frame, so that the AP will disconnect the already connected client.
Deauthentication Scapy Scriptfrom scapy.all import Dot11,Dot11Beacon,Dot11Elt,RadioTap,sendp,hexdump,RandMAC,Dot11Deauth
clientmac = “0e:e0:ba:ff:c1:d4”
apmac = “0e:e0:ba:f8:14:a0”
pkt = RadioTap() / Dot11(addr1 = clientmac,addr2 = apmac, addr3 = apmac) / Dot11Deauth()
Observe the below sniffer and check that , As soon as Deauthentication is injected, the Connection gets terminated and reconnects again, Observe the below capture.
1. In this scenario the attacker client will make the AP to deauthenticate the already connected station from AP to allow the new session.
2. Client is already connected to the AP
3. Attacker client (Who has valid credential) spoofed the MAC address of already connected client , and then the attacker tries to connect the same AP.
4. Here the connection gets terminated with the genuine Client and AP establishes the connection with the Attacker. Observe the below figure to check the scenario.
Here Observe the Ping check that has been done to verify the test. As soon as the Attacker is connected the Ping gets failed.
So , 802.11w gives the solution for the problems that we have discussed above. The above scenarios are few scenario where the problem occurs.
802.11w (PMF) gives the solution to the problems that we have discussed bove.
- We simply can’t deauthenticate the clients connected to the AP, because the deauthentication and disassociation frames are protected. Both the parties will check the encrypted data + MIC (Unicast Deauthenticaiton/Disassociation), MIC in (Broadcast Deauthenticaiton/Disassociation). They will deauthenticate only for the valid protected Frames.
- Attacker client also can not try to connect to the AP with the spoofed MAC of already connected client because the SA Query Procedure has been enabled in the 802.11w. We will learn about SA Query procedure later in the post.
Protected Management Frames
PMF feature protects the management frames from the spoofed management frames which tries to disrupt the user session. Both the client and AP should support this feature in order to establish a PMF Handshake.
PMF provides protection for unicast, multicast and broadcast management action frames. Below management frames will be protected with the PMF. Management frames that are transmitted after the 4-way handshake will be protected, because the required keys are generated only after 4-way handshake in WPA2-PMF.
Below are the management frames and robust management action frames that are protected in the PMF. We will discuss about the frames that are shown in the red color in the below Figure 5 in the PMF related posts.
Below is the PMF related beacon, PMF is set as required and capable, so the bits are set to 1.
802.11w has introduced a new IGTK Key, which is used to protect broadcast/multicast robust management frames, Example Broadcast Deauthentication/Disassociation frames will be protected by the IGTK.
IGTK provides the integrity of the broadcast or multicast frames by adding the MIC to the frames, 802.11w does this by using the new protocol Broadcast Integrity Protocol (BIP).
The below are the multiple settings that can be set in the AP and Client and the result of the Association.
Observe the below 4-way handshake in PMF based negotiation method.
In the above 4-way Handshake observe that AP sends the IGTK to the Client to protect broadcast/multicast management frames. sending the IGTK has been introduced in 802.11w.
TESTING PMF Scenarios
Scenario 1 – Attacker sending the Fake Association Request to AP
Observe the below figure and check that how the Attacker tries to Attack an AP with the spoofed MAC address.
- AP and STA has a secure PMF Association.
- Now Assume that Attacker has Spoofed the MAC Address of a Connected Station and sends the Association Request to the AP.
- Now the AP gets the Association Request from the spoofed MAC Address , it wants to check whether the Association Request has come from the genuine client or from the Attacker. AP wants to check this because sometimes AP will still have the Valid Association even if the real client gets disconnected.
- Now the AP wants to check whether the real client still exists or it is a Fake Association Request.
- Observe the below capture , I have triggered the Fake Association Request from the some other client with the spoofed MAC Address.
- When the Association Request reached the AP , AP checks that it has a valid association for the MAC. Now AP will send the Association Response with reject (status code 30) saying to come back for association based on the Association Come Back Interval. Observe the below capture to check this.
- Now the SA Query Procedure will be triggered. This SA Query Procedure usually finished within the Association Come back Interval as shown in the Figure 9.
Usually Association Comeback interval will be more than the SAQuery Time out, SA Query timeout will get finished within the Association Come Back interval time. The Timeout settings are vendor dependent.
- Now AP will unicast the SA Query Request (Secure Association Query Request) to the Client and if the client responses with the SA Query Response within the SA Query Timeout, It means that the Client has still connected to the AP. Observe the below SA Query Request/SA Query Response frame exchange.
SA Query Request/Response is a Unicast Frame , this frame consists Total encrypted Data of 12 Bytes (4 Bytes of encrypted DATA and 8 Bytes of MIC). The SA Query frames data will be encrypted using the CCMP and the key will be TK (Temporal Key). Both the AP and client knows how to decrypt and verify, because the both of them have derived the same keys at the 4-way handshake.
Below capture shows , how the SA Query Action Frame looks like.
- Now the AP knows that the Association Request has come from the Fake Client, because the SA Query Exchange is successful.
- When the Fake client sends the Association Request Again after the Association come back interval , Again the same procedure from the step 5 to step 7 will be happening.
Scenario 2 – Real Client Sending Association Request (Not an Attack )
Observe the below scenario, where the client has lost the connectivity, and AP still has the valid Association. See the below figure about the scenario that we are going to discuss now. If the client is not able to send the Deauthentication to the AP before leaving , then the AP still have the valid Association. This maybe client Reboot or removing the power supply to the client or any other reason.
There are multiple ways to replicate the scenario, Below are the few ways to replicate it.
- you can change the drivers code to smoothly exit from the program, by not sending any deauthentication when the program terminates. You can do the code changes in the supplicant code to replicate this.
- Remove the USB Device connected to the laptop.
- AP and STA has Valid Security Association
- Due to Reboot or any other Reason, STA lost the connectivity with AP.
- AP Still has the valid security Association for the client.
- Now the STA has recovered from the failure and Sends the Association Request to the AP.
- AP , Thinks it as a Fake Association Request and sends the Association response with Status Code:30 to come back after some time.
- With in the Association come back time , Now the SA Query Procedure will be triggered.
- AP sends the SA Query to the Client, Client does not give any response because the Client has already lost the connectivity and it can’t give any response because all the generated keys have been lost. Usually multiple SA queries will be done (Usually 5 in supplicant). Here in the capture we see 7 , because 2 SA Queries are re transmitted.
Observe the below capture to check this.
- AP tries Sending SA Query Requests multiple times , and could not receive any response from the client. Because the Client was disconnected already.
- Now when the Association Request comes again after the come back time , AP allows that Connection and then the successful handshake happens.
Scenario 3 – Attacker sending Unprotected Deauthentication
1. Here the STA and AP has the valid security Assciation.
2. Now the Attacker sends the Unprotected Deauthentication Frame to the STA.
3. As the Frame is unprotected the STA will ignore the packet assuming it as a attacking deauthentication frame.
You can simulate this scenario in multiple ways.
- Send the Unprotected Deauth Frame while exiting from the Client, You have to do supplicant code changes to simulate this.
- Inject Spoofed Deauthentication Frame as a Man In the Middle.
Observe the below diagram to check this flow.
Observe the below log to check the error seen in supplicant.
nl80211: Unprot Deauthenticate event
wlxe8de27a994fb: Event UNPROT_DEAUTH (30) received
Unprotected Deauthentication frame dropped: 00:00:4c:24:02:0d -> ff:ff:ff:ff:ff:ff (reason code 1)
This is about PMF, In the next post we will learn about the MIC Verification in WPA2-PMF/WPA3/OWE, and we will learn how it will be different from generating the MIC in WPA2.