Detecting 802.11 Discovery Apps

Joshua Wright writes "I have written a white paper on detecting 802.11 Wireless LAN Network Discovery applications. Wireless LAN discovery through the use of applications such as NetStumbler, DStumbler, Wellenreiter and others is an increasingly popular technique for network penetration. The discovery of a wireless LAN might be used for seemingly innocuous Internet access, or to be used as a "backdoor" into a network to stage an attack. This paper reviews some of the tactics used in wireless LAN network discovery and attempts to identify some of the fingerprints left by wireless LAN discovery applications, focusing on the MAC and LLC layers. This fingerprint information can then be incorporated into intrusion detection tools capable of analyzing data-link layer traffic. "

Comments

Re:Ok, so you've detected an intrusion...

[ihowson]

Exactly. "Sir, can I look inside your bag? We think you've got a laptop trying to invade our WLAN". Eat me.

There was a paper on how to track people scanning your WLAN by triangulating their location from several access points (here), but that seems like an awful lot more effort than just securing the network in the first place.

It might be useful for statistical interest (go to the boss asking for money because X number of people have been trying to hack the WLAN). Package it up and install it on a machine somewhere.

Note that this won't pick up Kismet (not that anything will, short of scanning for moving RF emissions from a computer). But that's another point entirely.

Re:securing

[rlangis]

Not really. My RG-1000 AP has this ability in the firmware. Speaking of which, I really should enable that... ;)

AP Radar

[dgp]

A new style of network discovery is available in the linux 2.5 kernel and in 2.4.20. Jean Tourrilhes'
Wireless Extensions for Linux version 14 and later contains a method to scan all channels for access points for a short period of time, then return to the wireless card's original state. This is implemented in the wireless drivers themselves so it works with any model of card. The 'iwlist' utility in the newer wireless tools suite will show this functionality.

There is a GTK+ application I have written called AP Radar that also makes use of this functionality. This utility has just reached a point where it can replace the need to run iwconfig and a dhcp client. Start the application and click on the ESSID that you want to associate to. AP Radar will set the ESSID and Mode of the wireless card, and launch a DHCP client (pump). Its meant as an end-user tool to simplify the process of connecting to an access point rather than a full featured net stumbler.

The advantage to using AP Radar over a full blown net stumbler like kismet is that you stay associated with the access point you are using, while still scanning for new APs in the area. With kismet and the others, your association is lost and you must reconnect after you're done scanning.

Security for WLAN's - Smack your closest vendor

[jjackson]

I am currently in an email conversation with LinkSys over the topic of securing a small WLAN that I set up to link my home network to my office (in a house across the street) and ran into a real problem with their WAP11 v2.2 AP's.

With 2 AP's set up in ethernet bridge mode (Shick as Slit!), if I enable WEP, the AP's encryption will get out of sync in very short order under heavy traffic loads (such as FTP'ing a file across the network at full speed). Once out of sync, I have to reset both AP's. With WEP disabled, the AP's perform OK.

After several tests I was able to reproduce these results each and every time... so I emailed LinkSys about their broken WEP support. Here is the response I got:

----------
Dear Mr. Joshua,

Thank you for contacting Linksys Customer Support.

With regard to the problem, can you provide the complete set up of your
network? About WEP, it is advised that you disable WEP keys in your access
point to avoid possible degradation of wireless transmission. The encryption
causes your network to slow down in terms of wireless transmission because
prior to transmission, the data are encrypted and decrypted at the receiving
end. Hence, the result is to slow the efficiency of your data transfer. For
a small network where there aren't much important files to be transferred,
it is advised that WEP keys are disabled.

About the firmware, the access point should have no problem connecting to
one another although they have different firmwares.

Have a nice day!

Sincerely,

Glythel Ria M. Penus
Product Support Representative
Linksys
-----------------------

If you are wondering what the firmware issue is about, I noticed that one of the new AP's came with an undocumented revision of the firmware (1.01f), so I attempted to downgrade it the version listed on their web site (1.01c), which also happens to be the version that the other AP is running. It won't do a downgrade.

So, for my solution, I used a firewall product that my company has developed to run IPSEC across an unsecured wireless link. Fortunately, in bridge mode, the Linksys AP's will only to the another WAP11 that has its MAC specified in the allowed list.

Even if this wasn't my business LAN, how many people that need a wireless network never transfer anything "important"? More to the point, how many people don't care if the neighbor leeches Internet service off of the cable modem that they are paying for?

This is not the first time I have seen this idiocy come from a vendor... my brother in law was recently instructed to remove the last several Windows Critical Updates from his Windows 2000 computer by an M$ phone-monkey, telling him that if it wasn't broke in the first place, that he shouldn't have tried to fix it.

KIsmet saves the day

[Phork]

The key point of this paper is that you cant detect passive monitoring(RFMON mode), so tools like kismet which usse it are not detectable. The only way to mess with these types of tools is to send out falsified data to confuse that scanner, but this will still not let you detect them.

Re:KIsmet saves the day

[Phork]

You're totally right on this, and theoretically it would work. A technique similar to this was used in some place(im thinking it was the UK) to detect unliscensed shortwave receivers. Basically how it worked was they went around with RDF(radio direction finding gear) tuned to common IFs(intermediate frequencies, if you dont know what this means, read a tutorial on heterodyne). Im not sure what kind of demodulating technique is used in 802.11b cards, so that technique may or may not work. I think im going to have to investigate this.

Re:KIsmet saves the day

[suwain_2]

That was sort of my point -- omnis don't have the gain of a directional antenna. You can get a fairly high-gain omni (11 dBi+), but they're things like stacked collinear, and I'm not sure if anyone makes anything of that sort for the 2.4 GHz (802.11b) band. (I suppose it'd be pretty short, though.) Anyway, sorry if I wasn't too clear in my original post. If you find one, I'll buy a few too. ;)

Re:Wrong approach

[g4dget]

Sure it does: you use some form of VPN for clients on the wireless LAN. Only they can get routed anywhere.

Re:Not necessarily possible?

[mesocyclone]

Actually, a "can" is not a circulator, but rather a high queue resonant cavity. They are very different things. A circulator is normally used for two purposes:
1) keep energy received by the antenna from getting into the final amplifier and generating spurious products (which is why they are *required* at most shared sites)
2) Protecting the transmitter from antenna failure, since the third terminal on the circulator is typically hooked to a dummy load.

Can's are used to create narrow band filters. On a typical FM repeater, they are used to duplex the transmitter and receiver to the same antenna (and hence they form a "duplexor"). Additional cans may be used to further reduce spurious emissions, and to protect the receiver from known strong out-of-band signals.

I assume by exciter you really mean local oscillator. And as I mentioned, the receive amp will in fact reduce the exciter output. The diode... well, why the heck would you put a diode in the circuit? It doesn't make any sense.

LO leakage is a well known problem with any superheterodyne receiver design. There are a number of methods to solve it (including appropriate mixers, pre-amps, trapping out the RF frequency, etc). I have *never* heard of anyone suggest using a diode for that purpose. It just does not compute.

The real problem with the approach of detecting the LO is that in any but the worst designed receiver, it will be way down in output power compared to the transmitter. Sniffing for LO's is thus inherently disadvantaged compared to sniffing for transmitters.

It's not a "can"

[Andy Dodd]

It's a duplexer. Although the main components of a duplexer (resonant cavities, as another poster mentioned) are essentially large thick-walled cans. (Except supercheap poor-man's-duplexers made from coffee cans - They exist but they are pretty high-loss)

These are usable in amateur applications because of the fact that repeaters transmit and receive on different frequencies. (Standard offset is 600 kHz in the 2 meter (144-148 MHz) band, 5 MHz in the 70 cm (440 MHz) band). 600 kHz is VERY close spacing at 144 MHz, which is why high-Q resonant cavities are needed, not L/C filters. They are needed because repeaters operate full-duplex (transmitting and receiving at the same time).

Such a thing doesn't exist for WLAN cards because of the fact WLAN devices transmit and receive on the same frequency (but not at the same time.) T/R switching is usually handled by diodes. (A diode, despite what a poster said, WILL block RF if biased properly. But to RF, it's bidirectional, either on both ways or off both ways, depending on the DC potential across the diode) Plus even in the "off" state, they'll leak a bit.

An isolator will allow RF to go in only one direction, while blocking RF going the other direction. These are expensive ($40-50 in quantities of 50+, probably more for one with coaxial connections).

Still, you can put all you want in the antenna feedline to make sure RF goes only one way - The receiver LO is going to leak out of the device housing. It'll be weak, but it'll be there. It'll be a CW signal, which will make it easier to detect despite being weak.

In RFMon mode, you don't need to take any measures to block RF going up the antenna feedline - The card will be stuck in receive mode with the transmitter shut down. Of course, the fact that your card is not transmitting means you can use a simple unidirectional preamp for receive rather than an expensive RF-sensing bidirectional amp. (These switch from receive to transmit when they sense RF coming from the transmitter).