In many cases, the unlicensed frequency bands operate like the wild west. There’s some restrictions in place around maximum transmit power and the ability to properly work around radar signals, but there’s nothing in the rules that dictates “Thou shalt not configure your old 802.11b gear to use channel 4 in a crowded high-rise office building in downtown Atlanta.” There’s just one guiding principle – you can attempt to transmit your own info by hook or by crook, but you can’t actively try to stop someone else’s transmissions.
There are valid methods to shut down an offending wireless system that are often included in enterprise wireless as part of a WIPS platform. These containment methods are important. They can allow an administrator in a highly secure environment to contain rogue APs that are plugged into their wired infrastructure, keeping the possible network breach contained until the team can find and remove the offending hardware. However, if this system is misconfigured, the WIPS platform will start attacking and containing valid neighboring wireless systems – and that’s very illegal.
How Does It Work?
When a client connects to an AP, it must first negotiate authentication and then set up an association to the BSSID. The authentication step is not the same as network authentication, which happens after the client joins the BSS. Think of these two steps as the equivalent of plugging in a network cable to your desktop. This is accomplished through authentication and association frames. If you’re curious to see them, use the following Wireshark filters:
Authentication: wlan.fc.type_subtype == 0xb
Deauthentication: wlan.fc.type_subtype == 0xc
Association Request: wlan.fc.type_subtype == 0x0
Association Response: wlan.fc.type_subtype == 0x1
This information is transmitted in cleartext over the air. Header information in wireless network communications is by default transmitted as unencrypted data – anyone out there listening can intercept it.
If a client needs to be removed from the network, the AP can send out a deauthentication frame to effectively unplug the proverbial cable. This frame removes the client from the BSS, cutting them off at L2 and prompting them to reconnect. Aruba uses this mechanism as part of their ClientMatch system… if a client decides to hang on to an overloaded AP for longer than is healthy, Aruba can attempt to negotiate a roam with that client. If all else fails, the Aruba system can deauth the client and attempt to steer the client to a better AP by manipulating probe responses. When used for “good,” the deauth frame is valuable.
When used for bad, it can completely gum up a network. Cutting someone off at L2 ensures that communication from layers 3 – 7 won’t go through.
A deauthentication containment countermeasure is where an AP spoofs the BSSID of a suspected rogue AP and spams out deauthentication frames to the broadcast address, effectively removing all clients from the AP. This is spammed out so rapidly that the AP becomes unuseable, removing the security risk.
So, how can you tell that someone is attempting to contain your system?
My Toolkit:
Here’s what you’re going to need. I use a Mac, so there’s a heavy emphasis on the toolkit from Adrian Granados.
SSID Discovery Tool: I use WiFi Explorer
Frame Capture Tool: This is critical. You will need a way to convert your wireless nic to “monitor” mode, which allows it to fully capture each piece of wireless traffic, not just data intended for your device. The Mac does this pretty well, but Windows does not. If you’re not on a budget, look at something like OmniPeek. If you’re on a budget, look at Acrylic’s NDIS drivers to allow a supported external WLAN adapter to go into monitor mode. And if you’re on a Mac like me, you can use AirTool.
Wireshark: Download this and play with it every chance you get. Packets and frames don’t lie, and this give you great insight into actual network traffic. Best of all, it’s free. I’m also using an awesome visualization set created by Joel Crane at Metageek. You can find it here.
Wireless Network Health (optional): I also use WiFi Signal. Not only does this show the health of your wireless connection, it also can give you an event log showing authentications, deauthentications, roams, and more.
Identifying the Attack:
First, identify an area of the building where you are getting the most complaints. Once identified, park your laptop as close as possible to an access point under your jurisdiction and launch your SSID Discovery Tool.
Identify the strongest signal from your network and make a note of both the channel and the BSSID of that signal. Here I can tell that the closest AP is using channel 36 at 40MHz. I can grab the correlating BSSID from the network table:
Once you identify the channel, launch your frame capture tool on that channel and listen for a minute or two. Open the resulting pcap in Wireshark once you’ve let enough time elapse and start poking around.
First, apply this filter:
wlan.fc.type_subtype == 0xc
This will show you all the deauthentication frames that have been sent out. You can see here that this capture clearly shows that this network is under attack. Over 13% of ALL frames transmitted were deauthentication frames.
Ok, let’s start narrowing it down further. Apply this filter next:
wlan.fc.type_subtype == 0x8 && wlan.sa == <BSSID of the SSID you are inspecting>
This will display beacon frames from your AP. Check the signal strength. In this case, we’ve got a good strong signal because we’re right next to the AP (right around -40 dBm on average).
Next, apply this filter:
wlan.fc.type_subtype == 0xc && wlan.sa == <BSSID of the SSID you are inspecting>
This shows deauthentication frames from your AP. Note the signal strength on the far right…
The deauthentication frames are coming in much weaker than the valid beacon frames. This indicates strongly that another AP is spoofing your system.
If you have WiFi Signal, you can attempt to associate the network with your client and then view the Events log to see the results. It’s not pretty. Note the timestamps here.
Determining who exactly is attempting to contain your system is trickier. In this scenario, I was in a crowded downtown location. The deauth attack had rendered wireless unuseable on their top floor, but the floor below was fine. This strongly indicated that their upstairs neighbors were at fault.
Knowing the companies name and their SSID, we returned to our SSID discovery tool and noted the BSSID of our neighbor’s system on the floor above us that was also on channel 36.
We then ran the following filter:
wlan.fc.type_subtype == 0x8 && wlan.sa == <suspect’s BSSID>
This shows us the beacon frames from our suspected attacker. In this case, the signal strength coming from their AP is very close to the signal strength of the spoofed deauth frames.
This SHOULD NOT be taken as a smoking gun, because (depending on the wireless intrusion prevention system) APs could be hopping off their regular channel to try and contain your system. Signal strength can also fluctuate from transmission to transmission depending on the complexity of your environment. However, this troubleshooting step can help provide more context to narrow down the problem.
Once you have an idea of who is containing your system, I recommend tactfully asking the suspected source of the disruption whether or not they have WIPs turned on. Not everyone has the luxury of specialization in a niche technology, so it’s fully possible that they aren’t aware of the full impact of their actions and wrongfully thought that turning on automatic rogue containment was a necessary step to secure their environment.
If that step fails, another (laborious) tact you can try is to once again return to filtering the deauth requests using:
wlan.fc.type_subtype == 0xc
Start digging through the deauths and take notes on the different source BSSIDs. There’s a good chance that it’s not just your network that’s under attack. Once you have compiled all the source BSSIDs, run this filter:
wlan.fc.type_subtype == 0x8 && wlan.sa == <source BSSIDs from deauth frames>
This will show you the beacon information from other networks that are also being attacked. You can pull the SSID information by going into the frame at IEEE 802.11 wireless LAN management frame > Tagged parameters > Tag: SSID parameter set:
This information shows us the names of the networks that are being contained by the attack. Make notes on where each network is located and look for a common neighbor. Chances are that the common neighbor is the source of the attack.
Wrongfully containing a neighboring SSID is taken very seriously by FCC – the FCC recently fined Marriott $600k for attempting to contain traveler’s hotspots. Most often containment is not turned on maliciously, but it will greatly impact the user experience on your network, so it’s in your best interest to get this sorted out ASAP.
Packet Wrangling 