Monday, April 30, 2007

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


7 comments:

Unknown said...

How did you come across these boxes? How do you know they have not been compromised? If you really want to evaluate this product or any other IDS product in aan ethical way, it seems like you would make a point to work with the vendor(s) unless the whole purpose of this exercise was to just slam a vendor .....

David Maynor said...

I know when something is critical of a vendor people come out of the woodwork to claim some sort of unethical treatment or that there were a host of problems. We often will work with vendors; in this case the problems are architecture problems that require redesigning the product. What vendor would knowingly admit that they have a product that doesn’t work as advertised? Also we noted that this was doing from a blackbox, remote perspective.

I fail to see how the boxes being compromised would change the fact that the “rogue AP” protection relies on the attackers wireless card accepting and honoring deauthentication packets. How could an attacker rewrite the software to cause a slow down when there are to many probe responses? If the machines were compromised the attacker wouldn’t be able to rewrite the wifi stack on the sensors to cause the information leakage. In short your conspiracy theories about slamming a vendor are incorrect, unless an attacker had the ability to rewrite the software the behavior described is not due to a compromise, and we even said that this was all remote, and finally the boxes being compromised would not be responsible for the fact that this is not a wireless IDS. At best it is a NAC solution.

Sounds like somebody has a sore spot otherwise you would have asked what other vendors are afflicted by these same problems. Also aren’t you an Airtight employee?

Abhinav Vaid said...

My full marks to David, this definitely happens to be none other than Airtight source. And I think we should maintain ethics and avoid anominity specially when we are making a technical evaluation related statements that could possibly directly or indirectly impact the business prospects.

mokum von Amsterdam said...

Rule one in my WLAN book:
When it comes to designing|implementing|reviewing WLAN solutions for customers: get Joshua Wright OR Max Moser over to check and double re-check. Both are lightyears ahead when it comes to WLAN. Last time Max did an audit|penntest he saved my ass. Seems like the Airtight peeps should talk kindly to him too.

Of course the point you are making is far broader: there are plenty more 'security solutions' who suffer from the same 'trust the bad guy to play nice' and the good guys not to use bad guys tricks. Remembers me of that large company who sells IPS and offers a US$50k for every 'know bad' to pass through, but refused to do the same for all 'know good' to get blocked :P

Unknown said...

I've seen comments on other blogs from the CTO basically defending the product and/or really downplaying this "review" of the product. Since you got their attention, this might explain some of the woodworkers on things like this, maybe a PR person speaking up in triage.

It's posts like this, though, that make me curious about the IPs of the commentors. :)

Mike Rothman said...

The CTO of AirTight left a comment on my blog (http://securityincite.com/blog/mike-rothman/the-daily-incite-may-1-2007#comment-1788) as opposed to on your blog. Seems a bit strange to me. I look forward to your response.

Unknown said...

David,

Thanks for this post. I happen to be an AirTight customer and I'm concerned about what you have found out. I originally was going to purchase one of the big-name wireless switch vendors that "include" WIDP but opted for a standard commercial AP and Airtight to save me a large chunk of change Now this makes my decision back then seem not such a good deal.

The best thing I have to say is that it protects folks that are legit wireless users from connecting to other wireless networks while connected to my wired network or while in wireless range.

Like you said, it protects against the fumbling user, but not the determined hacker...then again, i'm not sure what does in that case.

I'm guessing your not in the game of making recommendations (commercially) but what do you suggest an SMB to do?