So in Part 1 of this series on Airtight WIPS, we looked at how Airtight determines if an AP is rogue, or an “on-network rogue” by some vendors definition. Now that we have found an AP is plugged into my network, what do I do with it. In Airtight, we can quarantine the rogue AP, meaning we will try to prevent clients from associating to it.
In looking at what the Airtight system is doing, I decided to leverage my 1 year eval of Omnipeek aquired from the #WLPC conference. Thanks @KeithRParsons for putting this on.
But before we look at what Airtight is doing to protect me, let’s take a baseline. Just an example of our client associating to this
Here you can see a pretty textbook capture of the authentication/association process of “Jake’s iPhone 5S” to my survey-5 SSID (open).
Now let’s engage the quarantine of this rogue AP. For this example, we are going to manually quarantine one of my rogue APs. I chose manual just to ensure I am not accidentally containing any of my home networks and impacting my wife during testing. Here is a quick screenshot of me doing this. It’s a pretty simple process, just select the rogue AP and clicking the Quarantine button.
Now that we are protecting my clients from the big bad “survey-5” rogue network, I’m going to repeat the process.
So for starters we see a deauthentication frame after both the Association Request and Response. Let’s look at the Deauth sent just after the Association request. The first indication I see is that the deauth frame was sent at 6Mbps, whereas in the previous example, all the management frames were sent at 12Mbps This tells me this is the Airtight AP sending this frame and spoofing the rogue SSID. Now lets look at the details of this packet:
So the Airtight AP sent a broadcast de-authentication packet spoofed from the rogue SSID. This is fine since A. this rogue is on my network and B. I’ve decided to quarantine it. I was half expecting to see a unicast deauth, but broadcast works fine in this scenario.
Now let’s look at the deauthentication that occurs right after the association response. This time it appears that the deauth is coming from my iPhone. Notice again that it is sent at 6Mbps.
We can see that the Airtight is now pretending to be my iPhone, saying that my iPhone has decided to leave the rogue SSID. I honestly didn’t expect this, but it totally makes sense. In addition to make sure the client has left, it makes sense we should also send AP a deauth so it ends the clients session, ensuring the client is dropped if it doesn’t listen to the deauth message. Comparing the signal strength to my client
We see 22dbm difference, so I’m positive that this packet isn’t coming from my phone, which is very close to the capture adapter. Both the rogue and the Airtight AP are in the lab about 30 feet away.
As a side note, I did see some odd behavior on my iPhone during the deauth. Instead of just disconnecting, the iPhone displayed a PSK entry field, even though this is an open SSID.
I didn’t see the same behavior on my windows laptop, so this may be some Apple specific behavior. Hopefully one of the Apple guys reads this and leaves a comment (in my dreams).
My windows 7 laptop was able to connect to the AP. But while I was able to establish a connection, it was very short-lived. We see the Airtight change gears and send some unicast deauth packets to both the client and AP.
Shortly after connecting, we see omnipeek detect a wireless duration attack, which just appears to be a CTS to self with a very large duration field:
After we this, my laptop starts probing and tries to associate again. We see the same deauth results and the duration attack is repeated with a different NAV value occurs and the laptop gives up disconnects. The Airtight appears to say, well if you won’t listen to me, I’ll just use the duration attack to reduce your ability to do anything on this WLAN until you give up.
I’m sure there are some more methods to the Airtight WIPS. I know I’ve heard them speak on ARP poisoning as one of the tools in their toolbelt, but this post is running long as it is. I’m very impressed by Airtights ability to contain rogue clients and access points. They’ve also done a great job making the classification of networks easy to manage. In the next part of this series, I’m going to look at some common scenarios that I’ve found in my travels as a wireless engineer. I would consider these scenarios commonplace and they are not designed as ways to “beat” WIPS, but to show off how well the Airtight system combats common rogue technologies and attacks against WLANs.
For Part 3: I’m going to round up some gear and put together some typical rogue AP type scenarios and show how the Airtight system defends and protects your clients.
ToDSFromDS 