Following on from my survey of 802.11b, I picked up a Lucent WaveLAN PCMCIA card and spent a weekend learning what monitor-mode capture actually shows. This post is the writeup of what I observed and what tooling exists.
The technical detail is rougher than I would normally publish. The discipline is preparatory — by next year I expect tools and techniques in this space to be substantially more developed, and a record of where things are right now will be useful background.
The hardware and software
WaveLAN is one of the few cards that supports monitor mode reliably under Linux. Cisco's Aironet cards also work, with the right driver. Most other cards on the market do not have driver support that reaches the radio in raw mode. This is not by design; it is an artefact of which manufacturers shipped Linux drivers.
With the WaveLAN card, the kernel module that exposes monitor mode is part of wlan-ng. The setup is typical for an immature Linux subsystem — patches against specific kernel versions, hand-edited config files, a small mailing list of people who have made it work. With about an evening of fiddling I had a working setup.
Monitor mode is the wireless equivalent of tcpdump's promiscuous mode for Ethernet. The card stops associating with any access point, listens to whatever frequency it is tuned to, and passes every received frame to the user-space capture tool. The tool I am using is wlanctl, which can dump captured frames in pcap-compatible format that tcpdump and Snort can then read.
What I see at home
My first capture was around my own home, with my own access point running. The expected result was a stream of frames from my own network and nothing else. I got more than that.
My own network: clear, as expected. About 200 frames per minute on a quiet link, mostly beacons and authentication traffic, with a low rate of actual data.
A neighbour's network, which I had not known existed. Their SSID is the manufacturer's default. Their security configuration, on the available evidence, is whatever shipped out of the box. I am about 15 metres from their access point, through a brick wall.
A second neighbour, fainter signal, also with default SSID, on a different channel.
Neither neighbour is doing anything that requires my attention. The fact that I could see both of them, from inside my own flat, with no special equipment, told me something about the deployment landscape that I had not fully appreciated. The third floor of any block of flats in any UK city is going to be saturated with overlapping wireless networks within five years.
What an attacker sees
From a 15-minute capture, the kind of information an attacker passively collects:
SSIDs of every access point in range. From beacon frames. Even "hidden" SSIDs are visible from association requests.
MAC addresses of every device that talks, including the access point and every associated client. This gives the attacker the device topology of the network.
Manufacturer of each device, derived from the OUI (the first three bytes of the MAC). Most devices end up identifiable to a model from this alone.
Volume and timing of activity, which leaks information about what users are doing — even when WEP is enabled. "This client is currently downloading something at 4 Mbit/s" or "this client just sent a small packet that probably is not data" are derivable from the radio observations.
With WEP disabled, the full plaintext of every frame.
With WEP enabled, the encrypted payloads, the IVs, and the known frame structure. This is the data on which the WEP weaknesses I wrote about earlier are eventually exploitable.
This is, all of it, invisible to the operator of the network being captured. The capture leaves no log. The capturing card is in radio receive-only mode and emits nothing.
The current state of WEP attacks
The published attacks on WEP that I am aware of, in roughly increasing order of practicality:
Statistical attacks against IV repetition. If the same IV is used with two different plaintexts, the XOR of the ciphertexts equals the XOR of the plaintexts. With enough captured frames, an attacker can build up enough information to recover the plaintexts. This requires very large captures — hundreds of thousands of frames — and is rarely the practical attack.
Bit-flip attacks against the integrity check. Because WEP uses CRC-32, an attacker can flip bits in the ciphertext and predict how the corresponding plaintext changes, and arrange for the CRC to remain valid. This allows the attacker to modify encrypted traffic without knowing the key. Practical and demonstrated.
Authentication-handshake exploitation. The challenge-response in WEP authentication leaks information about the keystream. An attacker who captures one handshake can encrypt arbitrary frames into the network without knowing the key. Practical.
FMS-style key-recovery attacks. Specific weak IVs leak information about specific bytes of the key. The FMS paper is being formalised this year; I expect a tool implementing it within 12 to 18 months. This will be the breakthrough that makes WEP keys recoverable in practice from a few hours of captures.
The current state is that WEP is broken in research but not yet broken in operational reality. The gap is closing fast. By 2002 I expect WEP to be functionally broken — meaning a tool any attacker can run will recover keys from any normal deployment in minutes.
What this means for deployments
The defensive implications, written down for my own use:
WEP buys time, not security. Treating WEP as the only protection on a wireless network is a critical mistake. The right architecture is the one I described last week — wireless treated as the equivalent of the open internet, with VPN tunnels for actual confidentiality.
Channel selection matters less than people think. Picking a non-default channel does not hide your network. Wireless monitoring tools scan all channels.
Hidden SSIDs do not hide. I have already covered this. Worth saying again because it keeps coming up in deployment discussions.
MAC filtering is theatre. Same point. The MAC is on the wire, the attacker can clone it.
The actual defence is at the network architecture level. Treat wireless as untrusted. Apply VPN over the top. Firewall the wireless segment. Do not trust the link layer.
What I am doing with the capability
I am going to keep the WaveLAN card in regular use — partly to learn the technique, partly to track the evolution of the attack tools. The capture data is going into my honeypot's offsite storage, where it can be analysed alongside the other captures.
For my own home wireless network, the architecture is unchanged from what I described last fortnight. I have, however, generated new WEP keys (since the old ones may have been observed by anyone passively listening) and added a small Snort signature for unusual outgoing traffic on the wireless segment. If a neighbour ever decides to attempt to use my network, the signature will fire.
For the small wireless deployments I have set up for friends, I am sending a short note about the issue — not to alarm them, but to be sure they understand what their setup actually protects against. The architecture I built for them already accounts for this; the discipline is in making sure they understand why the architecture is what it is.
More as the year develops. Wireless is going to be a recurring topic. The next post is back to the more conventional ground — a spring rule-writing review for my Snort sensor.