Kemparaj Praneeth PMF, Protected Deauthentication, Protected Disassociation, Protected Management Frames, SA Query Procedure

Protected Management Frames in – WPA2 (802.11w)/WPA3/OWE

We have so many blogs that helps us to learn about the PMF , But here in these PMF related posts, I have written a detail analysis of management frame verification on AP/Client side that are involved in PMF.

PMF is enabled by default in the recently introduced WPA3 and OWE.

Below are the multiple posts that I have written for PMF, Follow the links to understand the concepts.

  1. We will learn about the PMF feature.
  2. 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. (4-Way-HandShake-WPA3)
  3. We will create an attack scenario and, decrypt SA Query Request/SA Query Response frames Generation and Verification (In Depth SA Query Procedure)
  4. PMF based Broadcast Deauthentication/Disassociation Frame generation and verification by using IGTK, and input data that CCMP program expects. (PMF Broadcast Deauth/Disassoc Verification)
  5. PMF based Unicast Deauthentication/Disassociation Frame generation and verification by using TK, and input data that CCMP program expects. (PMF Unicast Deauth/Disassoc Verification)

Problem Description

We will discuss few of the problem scenarios in this post , and learn how the PMF solves those problems.

Scenario 1

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.

Figure 1 : Attacker sending DeAuthentication/Disassociation to the Client

I have used the below python script to trigger the Deauthentication frame, so that the AP will disconnect the already connected client.

Deauthentication Scapy Script

from scapy.all import Dot11,Dot11Beacon,Dot11Elt,RadioTap,sendp,hexdump,RandMAC,Dot11Deauth
import subprocess
import sys
import random
import os
clientmac = “0e:e0:ba:ff:c1:d4”
apmac = “0e:e0:ba:f8:14:a0”
pkt = RadioTap() / Dot11(addr1 = clientmac,addr2 = apmac, addr3 = apmac) / Dot11Deauth()
sendp(pkt,iface=”wlan2″,count=100000,inter=0.2)

Observe the below sniffer and check that , As soon as Deauthentication is injected, the Connection gets terminated and reconnects again, Observe the below capture.

Figure 2 : Injecting Deauthication- STA Connects again and again after an Attack

Scenario 2

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.

Figure 3 : Attacker sending Association Request with Spoofed MAC Address to the AP

Here Observe the Ping check that has been done to verify the test. As soon as the Attacker is connected the Ping gets failed.

Figure 4 : Ping check as soon as Attacker is connected

So , 802.11w gives the solution for the problems that we have discussed above. The above scenarios are few scenario where the problem occurs.

Solution

802.11w (PMF) gives the solution to the problems that we have discussed above.

  1. We simply can’t deauthenticate the clients connected to the AP, because the deauthentication and disassociation frames are protected now with PMF. 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.
  2. 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. ((In Depth SA Query Procedure)

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.

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 or you go through the links that were shown initially in this post.

Figure 5 : Frames that can be protected with PMF

Below is the PMF related beacon, PMF is set as required and capable, so the bits are set to 1.

Figure 6 : PMF Beacon with PMF required and enabled

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.

Figure 7 : PMF Settings and their Association results

Observe the below 4-way handshake in PMF based negotiation method.

Figure 8 : WPA2-PMF Handshake

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.

This image has an empty alt attribute; its file name is pmf-1.jpg
Figure 9 : Fake Association Request Received by the AP

Steps:

  • 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.
Figure 10 : Fake Association Request from the Client
  • 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.
Figure 11 : Association Reject with Status Code : 30
  • 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.
Figure 12 : SA Query 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.

Figure 13: Protected SA Query Frame
  • 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.

  1. 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.
  2. Remove the USB Device connected to the laptop.
Figure 14 : Association Request from a Genuine Client

Steps:

  • 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.

Figure 15 : AP Sends Multiple SA Queries , Client doesn’t respond to any Query
  • 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.

  1. Send the Unprotected Deauth Frame while exiting from the Client, You have to do supplicant code changes to simulate this.
  2. Inject Spoofed Deauthentication Frame as a Man In the Middle.

Observe the below diagram to check this flow.

Figure 16 : Attacker sending Unproteced Deauth

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.