Thursday, May 5, 2022

Mitigating WiFi deauth attack with Protected Management Frames in Unifi (aka 802.11w Management Frame Protection MFP)

by Steve Endow

Note:  In case the title didn't make it obvious, this post has nothing to do with Business Central.  I wanted to document my learning because I found very little reliable or current information on mitigating WiFi deauth attacks, as of May 2022.  If I got anything wrong or if you find a good resource covering this topic, please post a comment and let me know.


When I'm not trying to learn Business Central, I like to learn about computer security.  I'm not a computer security expert by any means, just someone who finds it interesting as a side hobby.

While learning about password cracking several months ago, I learned about Kali Linux, an amazing distribution that includes lots of different computer and network security tools pre-installed.

In order to learn how to use Kali Linux and the security tools it includes, I decided to try to learn how to crack my WiFi password.  It seemed like a fun exercise, and it was.  But it just happened to teach me something entirely unexpected.

While following the instructions in this "Hacking Wi-Fi" guide (which had some minor omissions--I recommend using this version instead), I was quite surprised when I read this step:

"...disconnect the clients connected to the target network..."

Wait, what?

As I reviewed the instructions, I realized that it was instructing me to disconnect the clients on the target network in order to force them to re-authenticate, thus forcing the re-transmission of the encrypted WPA PSK passphrase.

This is a brilliant technique.  But wait a minute--how in the world do you disconnect all of the clients from a WiFi network without even being connected to the network?

It turns out that anyone can just broadcast a packet telling one or more, or all!, devices on the WiFi network to disconnect.  This is called a "deauthentication" attack.

WiFi Deauth Attack Using aireplay-ng

While this is just one step in the process of trying to hack a WiFi password, it happens to also be a pretty significant security vulnerability that could allow anyone to perform a denial of service attack on a WiFi network.  Imagine someone sitting in the parking lot of an office park performing a WiFi denial of service attack against dozens of nearby companies using only a laptop.  There are even dedicated devices, smaller than a pack of gum, that can be left somewhere with a USB battery bank to perform the attack for days without any human intervention.

From what I have read, there is virtually nothing you can do to block or prevent such an attack.  Any teenager with a laptop or Raspberry Pi can broadcast the deauth packets.  This was a known vulnerability of the WiFi standard, so around 2009, a new standard called 802.11w was drafted--called the "Protected Management Frames" standard.

802.11w proposed that a few types of "management frames" be encrypted to mitigate deauthentication attacks (and perhaps a few other attacks).

Here is a summary from 2009:

https://www.cwnp.com/wireless-lan-security-and-ieee-802-11w/

This standard was apparently eventually implemented through a WiFi feature called "Management Frame Protection" (MFP) or "Protected Management Frames" (PMF), depending on the vendor name for the feature.  My understanding is that it implements RFC 4493, which is AES "cipher based message authentication code", or CMAC, on the WiFi management frames.  I can't tell which standard covers its implementation, but I've read that this is all rolled into the 802.11ac standard.  (I have not attempted to research that yet, so if anyone has a link to a clear explanation as to which standard mandates it, please post a comment below.)

PMF (or MFP) essentially allows authorized WiFi devices to validate management packets.  Devices that are connected to the WiFi network are able to authenticate management commands, and ignore commands that do not have a valid AES CMAC value.

An attacker can still attempt to send deauth codes to the devices on the WiFi network, but since they won't have a valid CMAC, they can easily be ignored.


I'm writing this post because I found very little information about PMF / MFP.  The few notes that I found were quite old.  One post claimed that MFP was a Cisco feature.  Other old posts claimed that MFP was not supported by most devices as of 2017, including all Apple devices.

I use Ubiquiti Unifi gear for my wireless network, so I looked into whether Unifi had support for PMF.  Once again, I found VERY little information, other than the fact that Unifi does support "Protected Management Frames".  I happened to find this 2017 video by Tom Lawrence of Lawrence Systems where he discusses the feature, but indicates that it has very limited support.  He notes that only third generation Unifi APs support PMF, and he explains that his Samsung mobile phone didn't support PMF at that time. 

I purchased my Ubiquiti Unifi network gear in September 2017, so I didn't think it would support PMF.  I have the UAP-AC-PRO, the UAP-AC-M, and the UAP-AC-IW access points, all of which appear to be "2nd gen" Unifi devices, and thus not supported as of 2017, according to Tom.

With my expectations very low, I searched for the Protected Management Frames feature in my Unifi configuration page.  The feature is buried under each Wifi Network in Advanced -> Security, and the setting is disabled by default.

Ubiquiti Unifi Protected Management Frames (PMF) Feature

One nice thing about the feature is that it is per WiFi network.  So I was able to set PMF to Required on my Guest network and then see which devices could connect.  To my surprise, not only does it appear that my 2017 Unifi access points do support the PMF feature, but also, most of my devices connected fine with PMF set to Required.

These three devices connected properly with PMF Required:

    iPhone 13 Pro (2022)

    iPhone 11 Pro (2019)

    Lenovo X1 Carbon with Kali Linux (2017)


I then tried a very old 2013 Gen 1 iPad Air.  Even though the specs claim that this model supports 802.11ac, it was unable to connect to my Guest network when PMF was set to Required.

I then set PMF to Optional, and the Gen 1 iPad Air was able to connect successfully.  So Optional seems like a good choice if you have to support relatively old devices.  

I was very pleased with these results.  If a laptop from 2017 works fine with PMF, I'm happy with that, and don't mind if 6+ year old devices cannot connect if I choose to use PMF Required.

So now that I had learned about Unifi PMF, confirmed that my 2nd Gen Unifi access points do support PMF, and confirmed that most of my devices support PMF Required, I was ready to re-test the deauth attack.

With Unifi PMF set to Required, I re-ran the deauth attack, and my devices did NOT disconnect.  I tried it multiple times, and I was unable to disconnect my iPhone 13 or iPhone 11.

I didn't try running the deauth attack with PMF Optional to see if my 2013 iPad Air would be disconnected.  I assumed that it would still be vulnerable to a deauth, since it would not be using PMF, but I didn't bother to confirm that.

So to summarize:

--It appears that Unifi Protected Management Frames (PMF) does prevent / mitigate deauth attacks
--My 2nd generation Unifi access points do support PMF
--My old 2017 laptop worked fine with PMF, as did my newer iPhones 
--Internet speed tests (using iOS SpeedTest app) showed no difference with PMF enabled


There are probably several things I don't know about PMF, such as any downsides, limitations, or subtle performance impacts of the feature.  

If you have any information that I missed, please post a comment below and let me know.

Steve Endow is a Microsoft MVP in Los Angeles.  He works with Dynamics 365 Business Central and related technologies.

You can also find him on Twitter and YouTube, or through these links:  links.steveendow.com

No comments:

Post a Comment

All comments must be reviewed and approved before being published. Your comment will not appear immediately.

How many digits can a Business Central Amount field actually support?

 by Steve Endow (If anyone has a technical explanation for the discrepancy between the Docs and the BC behavior, let me know!) On Sunday nig...