Thursday 12 December 2019

IEEE 802.11w: Securing your WiFi from Deauth Attack Part 1 - The Right Stuff (Updated 2019-12-31)

The Right Stuff by Tom Wolfe

"No bucks, no Bucks Rogers" - Gus Grissom, The Right Stuff


One of the guilty pleasures of Linux is aircrack-ng,  software tools to -cough- test WiFi security. In the good old days with WEP WiFi passwords you can get a WiFi password within 2 minutes. It was so convenient it was much quicker than getting the password the legal way from your company sysadmin. Back in the day, the best hotspots are for Top Management, people who don't browse or torrent, dictate their emails and think that typing is for secretaries.


aircrack-ng on Kali Linux


IEEE 802.11 is the standard for WiFi networks. Amongst other things it specifies Management Frames, ie data packets sent by both the client and the Access Point to 'manage' or maintain communications with each other, for example, logging in, authentication and when one party wishes to terminate the connection, 'deauthenticate'.

With WPA (in particular WPA2), cracking WiFi hotspots became much much harder, but if the password is weak (most passwords are weak) you can speed things up by getting aircrack-ng to issue 'deauthenticate' Management Frames in your victim's name (ie MAC address). This causes the target to re-issue authentication frames. The more frames you sniff out, the quicker you will crack it.



Now if you do nothing but issue deauth frames, say with a bash script, you effectively jam WiFi for the luckless target, and if you target the AP MAC address you jam the whole hotspot if you are close enough. Normally you did it for a purpose, like persuading the legal users to quit using their WiFi so you can, -cough-  check-in your flight online. People who deauth used to have a higher purpose ... besides it is easy to spot the pasty-faced user on the Linux laptop with an out-sized WiFi antenna.

ESP8266 deauth jammer

But with the advent of Espressif's ESP8266  you can now buy or build a cheap portable deauth jammer that will fit inside your pocket, and now all you have to do is walk up to a hotspot to jam it. And since many security cameras these days are WiFi, an intruder can disable them by just driving up to your gate.

Now having made quite a few ESP8266-based IoT devices, it is time to secure my WiFi from deauth attacks: IEEE 802.11w-2009. With 802.11w, the Management Frame is encrypted and becomes a Protected Management Frame (PMF). This means a WiFi outsider now cannot deauthenticate you with impunity.

IEEE 802.11w stops deauth attack by encrypting the 'deauthenticate' command

Now you would think you can buy a new reasonably-priced IEEE 802.11w-2009 router for home use. After all the standard is 10 years old. And you would be wrong. It is common enough in Big Iron like Cisco or Aruba (one of dear old Hewlett Packard's random name changes) but it is not common in say, a D-Link or TP-Link. OpenWrt is a shining exception, as easy as checking an option in its base distribution. But OpenWrt often only runs on the more expensive models, and then there is the problem of compatibility with WiFi client devices.

The usual culprit would be production cost. As Gus Grissom said, "No bucks, no Buck Rogers". It turned out it is probably a compatibility issue, specifically of encryption, a missing cipher. IEEE 802.11w uses CCMP-128, SHA-256 and AES128-CMAC encryption for Management Frame protection.

To tell if your hardware has The Right Stuff, you need to execute the Linux command 'iw phy', shown here for a no-name WiFi USB dongle based on the Realtek RTL8812BU:

# iw phy
Wiphy phy8
        max # scan SSIDs: 9
        max scan IEs length: 2304 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CMAC (00-0f-ac:6)

And listed under the 'Supported Ciphers' the bare minimum you need is CCMP-128 (note OUI 00-0f-ac:4) and CMAC (OUI 00-0f-ac:6). There is a helpful write-up here. Compare this to the output for the delicious Qualcomm AR9565 from my Acer Aspire E1 laptop:

$iw phy                                                
Wiphy phy0
        max # scan SSIDs: 4
        max scan IEs length: 2257 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports RSN-IBSS.
        Device supports AP-side u-APSD.
        Device supports T-DLS.
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CCMP-256 (00-0f-ac:10)
                * GCMP-128 (00-0f-ac:8)
                * GCMP-256 (00-0f-ac:9)
                * CMAC (00-0f-ac:6)
                * CMAC-256 (00-0f-ac:13)
                * GMAC-128 (00-0f-ac:11)
                * GMAC-256 (00-0f-ac:12)

CCMP-256 and in particular GCMP-256 looks really good. Now your mileage may vary with 'iw phy', as some device drivers are known not to be listed. I had best results with a late model Raspberry Pi (3 or 4) running the latest Rasbian (ie Debian).

You can do an online search for compatibility with this link.

From my very limited survey here in Seremban Malaysia only a minority of WiFi devices on the market supports this. And since some device drivers do not come up in 'iw phy' (in particular deliciously cheap Realteks), in the end I had to take my Linux laptop to my friendly local computer shop and test all 5 WiFi USB dongles models he had. None passed the test; in the end an ancient TP-Link TL-822N v1.1 proved up to the task.

TP-Link TL-W822N. Note only v1 worked, and possibly v2. v3 & v4 have Ralink chips

So did the Samsung Galaxy Note 5, with default setings:

Samsung Galaxy Note 5 will work as IEEE 802.11w client


A very pleasant surprise was the Raspberry Pi 3 Model B Plus' BCM4345:

        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CMAC (00-0f-ac:6)

Unfortunately the results were spotty. Upgrades to Rasbian caused it to stop working, but subsequent updates should fix this, so watch this space for updates.

And since I meant to link my deauth-proof routers to outdoor antennae I took a chance on the RTL8812BU generic USB dongles, from a hint here

Generic no-name RTL8812BU USB dongle also worked, but only as AP and not client/STA
This proved to be the toughest to use, as even my up-to-the-minute Rasbian (Buster) did not come with the device driver for it. The dongles came with driver source code, but cilynx (Randy C Wills) has a much better version here. cilynx's instructions (in README.md) worked very well for my Raspberry Pi 3 B+; I just needed to add in the Makefile

EXTRA_CFLAGS += -Wno-error=date-time

And change 'n' to 'y' for

CONFIG_80211W = y

Perhaps because this is a new driver, the default debug logs are very many and to prevent it from wearing out your micro sdcard, you might want to do:

# echo 3 > /proc/net/rtl88x2bu/log_level

And you are good to go.

In summary the WiFi hardware having the Right Stuff for deauth-proof IEEE 802.11w are:
1. Qualcomm Atheros AR9565 (Acer Aspire E1, Asus X751L)
2. Qualcomm Atheros QCA9377 (Acer Aspire F15)
4. Ralink RT5370 (Raspberry Pi 3 Model B Plus)
5. Realtek RTL8812BU (no-name China USB dongle)
6. TP-Link TL-WN822N v1.1
7. Samsung Galaxy Note 5 (and Fan Edition) as client device. The Galaxy Note 3 does not work.

Seven devices with the Right Stuff, just like the seven Project Mercury astronauts. The next step is to rebuild my WiFi Bridges to comply with IEEE 802.11w. But that is another story. 

Happy Trails.

Update: Removed the D-Link DWA-123 from the list, as it did not work. In the Raspberry Pi 3, weird kernel driver interactions caused the built-in  BCM4345 driver (brcmfmac) to work, but only with a Realtel RTL8188EU device plugged in. The last Raspbian update caused it to stop working so BCM4345 results are still pending

No comments:

Post a Comment