Wireless NAC != Wireless IPS: AirTight...Leaks...

Rob Graham and I came in contact with some Airtight boxes. In case you don't know they are a maker of wireless IDS technology. Since we know a thing or two about wireless we wanted to look and see how these boxes work and if the perform as advertised. If you don't want to read the entire blog post the short answer is: not completely. In our quick peek we found 3 problems. If we were doing a real assessment we would have pulled out the screw drivers and, ICE gear, and disassembler but instead we looked at this from a blackbox remote perspective.

Problem 1: Protection relies on you being a good citizen.

One of the most touted features is the ability to shutdown rogue access points and give administrators the ability to control who has access points and who doesn't and which ones are legitimate and which ones are not. This is done by detecting the access point, determining if it is legitimate and then flooding it with deauthentication packets if it isn't. It does this by spoofing deauthentication packets in both directions from the user to the access point and from the access point to the user (Packet caps of this to the right). These packets are in the standard and are basically there to say "go away, I am not interested in working with you". So I am sure you are curious what happens if you modify you driver and an access point to ignore these types of packets? Nothing, you can just keep humming away and do whatever it is you want to. Now the argument we heard when we originally mentioned this to people is that these types of devices are not designed to stop determined attackers, just a clueless guy who plugs in a Linksys in accounting and those guys don't use custom wifi drivers. To bad, we do, and this company would have failed a penetration test. Relying on a remote attacker to adhere to a standard for your security too to work is crazy, that's as bad as the Cisco Security Agent API hooking that relied on you executing jumps to its analysis engine to work properly. In the Cisco case and the Airtight case you can just ignore the spec and the security breaks down.

Problem 2: Slowdown

We looked at how these devices would detect new access points. I thought at first it would be done via a combination of beacon and probe response to verify they were real access points but we noticed something. The device would detect the access point from what appear to be probe response packets and then one of their sensors would spoof a packet to be transmitted through the access point to itself. If it received the packet then it would know the access point is indeed on the network. So what happens if you generate hundreds of thousands of fake probe responses? There is such a slow down in responding to them that you could actually go about your normal business of plugging in a rogue access point and letting people external to your offices have access to you network before the sensors will actually detect it and start blocking it. Saturating it with about 10,000 fake probe responses meant that we would have between 1:30 minutes and 3:30 minutes before Airtight realized our access point had appeared. This may not seem like a lot but if you are trying to copy things out unseen or quickly infect a company with a worm, that all the time you need. We didn’t spoof for very long, but it appeared that if we left it running, we’d eventually fill up the database and take down the system.

Problem 3: It really does leak
In problem 2 it was noted to verify that an access point is actually on the network a sensor would spoof a packet to be transmitted through the access point and if it was received by the sensor the containment process would begin by generating fake deauthentication messages. This is a problem because it leaks information about your internal network. This method of determining whether or not an access point is on the network means that UDP packets are being generated with the internal IP address of not just the sensor sending the spoofed packets but also the management console and sending them over sniffable wireless access for all to see and capture. So even if you are not on the network and just sniffing the channel the AP is on you can get information on that company's internal network information like addressing scheme and layout; you could even write a snort rule to detect just these types of packets.. Thank you very much! With the work that has been done on Ferret we have become hyper sensitive to unintentional information leaks and this is definitely one.

Verdict: Great for clueless folks but will not keep out a skilled attacker

While these boxes may keep Bob from accounting from buying an access point at lunch and sharing your network to the world, they will not stop and in some cases aid a determined attacker in compromising your enterprise. They should not be labeled either "intrusion detection" or "intrusion prevention". These devices have no ability to stop a driver level attack like the ones we have previously discussed.

Also I hate recreating other peoples work. After we found these problems I was pointed to the paper below that contains information about the deauth problems. It has a far more in-depth review of the weaknesses and why most of these products just don't add up.http://802.11ninja.net/~jwright/802/papers/wlan-sess-cont.pdf