joswr1ght

I recently published a paper on some research I completed regarding weaknesses in WLAN session containment with Network Computing. The end-result is that we (and by we I mean security researchers, of course) can easily bypass session containment efforts that use uni-directional deauth/disassoc frames, and we can fingerprint the WLAN IDS in use by watching how those frames are transmitted.

The full paper is at http://i.cmpnet.com/nc/1612/graphics...nment_file.pdf.

I'd love to hear comments. Thanks!

-Josh

__________________
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/

Today I stumbled across the world's largest hotspot. The SSID is "linksys".


Check out the SANS advanced wireless auditing and assessment course:
Los Angeles

joema

Very interesting.

I wasn’t aware that WLAN IDS vendors would use this, somewhat archaic, approach to session containment.

Now I don’t claim to be even have an average understanding of wireless technologies, but would think that having to depend on the client (rogue ap) to "abide by the rules" (ie. tcp resets, deauth, etc.) would be the worst possible solution.
As far as I am concerned, this should all be done by the IDS.

Correct me if I am wrong but would something like this not be feasible:

Have the IDS, "shun" the rogue ap/client by using simple "drop" based Control Lists, with the MAC of the ap/client as the source.
Utilizing the same signal strength calculations you mentioned in your paper, as a way to differentiate a rogue client from a valid client with the same Mac, could somewhat alleviate Mac spoofing.

Use it, don’t use it.

Roy_M

Firstly I´d like to say that the paper was very interesting.

I was actually unaware that WLAN IDS even existed so I was even more shocked at how sophisticated they are.

At the end of your paper you mentioned that some organisations may not be concerned about fingerprinting if they are using a RSN model. If someone is using a RSN model and a four way handshake for authentication, (client authenticates the AP as well as the network authenticating the client) why would they worry about rogue AP attacks? Doesn't bi directional authentication already mitigate these vulnerabilities?

In my opinion, it would be good if the IDS could increase the transmit power of an AP when a rogue AP is detected. Clients attempting to connect to the rogue AP will continually be de authenticated until they start to receive a better signal from the legitimate AP. Please tell me if that is a stupid suggestion.

Joshua Wright, didn´t you write asleap? Weren't you responsible for revealing MSCHAP and password vulnerabilities in Cisco´s LEAP?

David

renderman

I've been very wary of active defense IDS systems for wireless because tuning th things can be a right bugger.

While my level of skill and knowledge is probobly not at the same level, I'll comment anyways.

I was playing with Void11's deauth functions (really fun) and the white/black lists creating a poor mans version of a session containment IDS: If the Client/station is not on the white list, drop it's connection. You could probobly flesh that out to only allow valid client/AP mac pairings.

The problem I ran into and one that I think renders these systems (at least my spit and twine one) pointless is that once again, wireless does'nt stop at walls. If I setup a system in an office building, there's a pretty good chance that you'll be overlapping with other WLAN's and It's not very neighboorly to treat thier AP's as rogue and drop everything trying to connect to them. You could add thier AP to a white list, but you have now added a possible way for your attacker to spoof thier way in and increased the pool of MAC's to track.

If, in the unlikely event your the only network in range, there's the good chance that at some time or another, someone else in the area will try to setup a WLAN and be left scratching thier heads why no-one can connect and leaving you with a huge IDS log to figure out.

A more logical approach would be to monitor for rogue WLANS and have the system connect to them and determine the wired side MAC. If that MAC is on your net, isolate the switch port so no-one can do anything and no access is granted. This method would only really deter rogue AP's connected to your local net.

Monitoring your client MAC's and seeing where they connect in your bubble and denying the connection would still make sense though.

Does this make sense or did I miss something and initiate a cranial rectal interface?

Render

__________________
Never drink anything larger than your head!

Scaramental Wine Taster for the Church Of WiFi
Buy our books!
"I reject your reality, and substitute my own!" – Adam Savage
CoWF WPA Hash Tables

joswr1ght

Right, and not to mention possibly a violation of Part 15 FCC rules. See http://www.nwc.com/showArticle.jhtml...4302965&pgno=9 for additional background.

At Shmoocon, Laurent Butti and Franck Veysset presented on a WLAN IDS system they put together that, IMHO, rivaled some of the commercial offerings. I believe their technique to identify a rogue network as connected to the "protected" network is to connect to the AP and attempt to ping a fixed internal address known to exist on the wired network. If they get a response, they know the rogue AP is connected to their network, and have no worries about DoS'ing it.

Other vendors will monitor and build tables of known MAC addresses. By monitoring the wired interface of the WLAN IDS sensor as well as any other internal sources of MAC address (router ARP tables, switch CAM tables, NetDisco, whatever), a WLAN IDS system can populate a list of known-internal MAC addresses for the protected network. When a new rogue is discovered, some vendors categorize it as "unknown" until they observe a MAC address on the rogue network that matches the list of observed internal MAC addresses. Then, they can DoS the AP knowing that it is connected to their network and not a nearby "friendly".


Something I left out of the paper - if I can determine the policy that causes the session containment features to kick-in, I can spoof a legitimate station's MAC address to have the WLAN IDS system deauth legitimate client stations. Handy!

Further, if I can tie-up your WLAN IDS and keep it busy attempting to contain legitimate stations on a different channel, chances are pretty good that I can attack other nodes on the network without fear of being detected. Even better!

When I finish the paper on evading WLAN IDS systems, I'll post a copy here.

Thanks!

-Josh

__________________
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/

Today I stumbled across the world's largest hotspot. The SSID is "linksys".


Check out the SANS advanced wireless auditing and assessment course:
Los Angeles

joswr1ght

Mutual authentication does mitigate some rogue AP threats, but it does not help solve the problem of misconfigured (or poorly written) client systems. For example, depending on the configuration of your wireless client, it may be possible to force a victim to disconnect from a secure production network and reconnect to another network. I've used this technique to disconnect a node from a PEAP+TKIP network and connect to my rogue T-Mobile "hotspot".

It appears that someone pointed out a flaw in Windows XP during the Microsoft Blue-Hat session that Max Moser demonstrated to me a while back when we were writing Hotspotter: http://news.com.com/Microsoft+meets+...3-5747813.html. This is a prime example of good network security, poor client security, and why all wireless users should use personal firewalls.</soapbox>

NOTE: If anyone even mentions that this is an evi* tw** attack, I will be forced to ask the moderators to publicly castigate your (as if they needed a reason). As my friends at Shmoo will point out, we've been doing this long before it had a fancy name.


It's not a stupid suggestion, but it's not infallable either. Mutual authentication is what you really need in this situation, since stronger signal level doesn't consistently influence a client to connect to one AP vs. another with the same SSID.

Yes, that was me. I also wrote some other papers on WLAN IDS that I'll take the opportunity to point out here:

Layer 2 Analysis of WLAN Discovery Applications for Intrusion Detection - http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf

Detecting Wireless LAN MAC Address Spoofing - http://home.jwu.edu/jwright/papers/wlan-mac-spoof.pdf

Thanks for the comments, it's nice having an opportunity to discuss this kind of stuff. I don't get out all that much...

-Josh

__________________
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/

Today I stumbled across the world's largest hotspot. The SSID is "linksys".


Check out the SANS advanced wireless auditing and assessment course:
Los Angeles

renderman

I'm in Canada so it's Industry Canada that sets those regs, but yeah, they are fairly close in wording and intent.

I was there watching that and was very impressed. It was freaking hilarious to find out that when they were demonstrating the dissasoc attack being detected by running void11, the goons airmagnet gear went apeshit and they ran in thinking someone was DoS'ing the WLAN and they wanted to make an example, only to find it was the speakers

A fair bit of infrastructure required to keep everything in sync. I was playing with Void11 trying to create an 'enforcer' for a client who had problems with employees not using allowed hosts on the network (read: personal machines not vetted against the security policy). It's a simple office LAN, so just basic switches, firewall, etc. I was going to have Void11 sitting on top of the AP like g8t with his big barb wire covered bat, clobbering anyone using an unauthorised device. Problem was that it was in an office building and the chances of screwing with someone elses network was too big a risk.

To do a session containment setup like Laurent Butti and Franck Veysset had, required a fair bit of back end that does'nt scale to SMB networks very well (which is the market I service) Frankely the SMB market could use a decent IDS/Enforcer product to cover thier butts because they don't have the time/manpower to watch logs.

Fair idea. Again, 'must be this tall to enter'. The trick now becomes, how do you stop your client machines from drifting and connecting to non-company AP's (not maliciously setup ones, but neighboors)?

An attacker might just penetrate the 'linksys' neighboor and wait for someone to drift over to that net from your WLAN and do god-knows-what (client FW's and other things should be installed, but you know what I mean)


Already crossed my mind. Spoofing client MAC's and tripping the sensors could cause enough 'false positives' to convince IT to disable the session containment. Once again, tuning is essential.


Hide among the shitstorm. I like it

Look forward to it.

__________________
Never drink anything larger than your head!

Scaramental Wine Taster for the Church Of WiFi
Buy our books!
"I reject your reality, and substitute my own!" – Adam Savage
CoWF WPA Hash Tables

Roy_M

hah, I remembered because I wrote a 3rd yr computer security paper on Wireless security eg WEP, WPA, WPA2, LEAP, PEAP VPN etc, took me ages. Your writings on LEAP were heavily referenced if can remember rightly .

I´m doing a honours thesis next semester and starting my first proper paper. I´m finding it really hard to decide on a topic which is practically feasable to research. It is also difficult to find other relevant papers. I´m obtaining OPNET, network modeling software but I´m not sure about how useful that will be. Ever used it before?

I search http://scholar.google.com and http://citeseer.ist.psu.edu/ however I still have trouble finding good quality, FREE(damn IEEE) acedemic material. I used to read a lot of George Ou´s stuff but it all seems a little basic and repetive now. I guess my first question is: Where do you read?

Most of your stuff seems to follow a set order,

• Introduction/Backgrond

• Talk about a vulnerability

• Reccommend a solution

Thats fine for security, or if you are suitably hardcore enough to find vulnerabilities. I was thinking of writing a paper about speeding up handoff between 802.11 nodes for seamless VoWiFi. However, I cannot even begin to fathom how i could physically test any solution I propose. I could test existing handoff procedures using ethereal packet captures (they´re timestamped). But I´am not a good programmer and would never think of writing my own handoff procedure programs.

Any advice?

Cheers

joswr1ght

Expensive commercial software? Unless it's open-source and for Linux, I probably don't use it.

Why, the NetStumbler forums, of course!

I also check George's blog regularly, wardriving.com, wi-fiplanet.com, trade magazines (Network Computing, Network World, eWeek, etc), whatever else Google leads me to.

I use that format because I think that's what my target audience wants to see - an introduction, the problem and how we can mitigate the problem. If someone feels differently, please let me know.

You may want to have a conversation with your advisor about your paper topic. When I was completing my undergraduate work, my senior research project was designed specifically to produce information that solved a problem, not a re-hashing of other people's information in a new format. If coding isn't your thing, you might consider something else that would allow you to produce something that represents a unique product from your research.

-Josh

__________________
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/

Today I stumbled across the world's largest hotspot. The SSID is "linksys".


Check out the SANS advanced wireless auditing and assessment course:
Los Angeles

Dutch

No way... Unless you feel like adding a one page Executive Summary page, for us lazy former CTO's..

Dutch

__________________
All your answers are belong to Google. SEARCH DAMMIT!
Warning. Warning.
Low C8H10N4O2 level detected. Operator halted....