Despite a few good online articles and countless alarmist news items
decrying parasitic War Drivers and War Chalkers contributing
to the moral decay of the country, a surprising number of people still
install wireless equipment with all of the defaults enabled. There are
a huge number of access points in use today that unintentionally advertise
a default SSID, bridge directly to an Ethernet network, and use no encryption
whatsoever (or a WEP key left on the factory setting, and therefore
easily deduced).

But even if all standard precautions are in place, how much "security"
do wireless access points actually provide? Having heard all sorts of
widely varying estimates and assumptions from people who should be able
to make an educated guess, I finally decided to see for myself what
it would take to circumvent the security of my own standard 802.11b
network.

The Test Environment

Since my "production" wireless network is actually an open node on Seattle
Wireless, I decided to put together a temporary lab network consisting
of the following:

A "Graphite" AirPort

An iMac with an AirPort card running OS X

An iBook with an AirPort card running the Debian Linux distribution

In order to make the test as difficult as possible, I decided to create
a "closed" network (that doesn't broadcast the SSID), enable WEP, and
also implement a MAC address filter. The AirPort was set to the SSID
stealthy, with the unlikely deduced WEP key of t8$Gc. I added a MAC
address filter that only allowed the airport card in the iMac to connect
to it. I also set the AirPort to channel 1 (the only unused channel
in my immediate area). The Ethernet on the AirPort was connected to
my local house network, and configured to use NAT.

After resetting the Airport, I verified that I couldn't detect the stealthy
SSID from either the iMac or the iBook. I then connected to the AirPort
with the iMac, specifying the network name and WEP key explicitly. I
got a DHCP lease of 10.0.1.2, and verified that I could in fact browse
the web. To be sure that the MAC filter was working properly, I also
verified that I could not associate with the AirPort from the iBook,
even using the proper WEP key and SSID. I then set the iMac to flood
ping the AirPort, in order to generate a large amount of wireless traffic:

rob@imac:~$ sudo ping -f 10.0.1.1

Now everything was in place to test this configuration with the iBook.

Step 1. Detect the Network

Of course, the first step was to detect the network's presence. This
was easily accomplished with Kismet. As you can see in Figure 7-1, the
stealthy network was detected immediately.

Figure 7-1: A "stealthy"
network detected

Note that the network would be detected instantly (provided that someone
was actually using it), regardless of whether I had called it stealthy
or something original and tricky like kpX284W_m. Obfuscating the SSID
of your network does nothing to enhance the security of your wireless
network, regardless of whether you broadcast beacons or not. For the
record, I started Kismet at 18:23, at which point it began logging all
802.11 frames that it encountered. Now that I knew the channel and SSID
of the target network, it was time to move to the next step.

Step 2. Find a Valid MAC Address

I know of two ways to find valid MAC addresses for a given network. You
could associate with the AP and run an IP layer network sniffer such
as Ethereal or tcpdump).This is, of course, the hard way, particularly
if you already have Kismet handy.

The easy way is to select the network you are interested in (hit ss to
sort by SSID, and arrow down to it if necessary) and then view the associated
clients (hit c). Presto, you have a list of MAC addresses for clients
that are using the network, and presumably are on the permitted MAC
table. Wireless clients send their MAC address in the clear, regardless
of whether the AP requires WEP or not.

These steps took just a few seconds (it actually took me longer to run
the screen grab utility than to execute the attacks). Now came the tricky
part: cracking the WEP key.

Step 3: Crack the WEP Key

It is entirely possible to have AirSnort crack an 802.11 stream in real
time. In my meager testing, I have found this to be fairly unstable
using Debian on an iBook. Rather than risk a crash in the middle of
my test, I decided to just run it against the pcap dump that Kismet
creates automatically. I opened the dump file immediately, and then
checked its progress every ten minutes or so.

As you can see in Figure 7-2, AirSnort was successful in finding the
WEP key (t8$Gc) after only 3.4 million packets.

Figure 7-2: WEP key
found

I stopped Kismet, and noted the time. It was now 19:50. One hour and
27 minutes had passed, and Kismet had accumulated only 490,796,602 bytes
(that's less than 490MB, or considerably less than a single CD ISO).
I think this was a particularly lucky run, as many people have reported
having to log a couple of gigabytes of data before AirSnort could guess
the key.

Now armed with the correct SSID, a valid MAC address, and the WEP key,
I could actually attempt to access the wireless network. Note that until
now, absolutely no information has been transmitted by the iBook, making
detection of this attack a practical impossibility.

Step 4. Logging In

After quitting Kismet and taking the wireless card out of monitor mode,
I configured the iBook to use the proper network parameters:

Ah, but what IP address information should I use? Up until now, I hadn't
looked at any IP layer traffic. Kismet could not reveal the IP range,
because it didn't have the WEP key. At this point, I could have started
up Ethereal and looked at the captured pcap dump, but it was much simpler
to view the network data in real time using tcpdump like so:

Since the ping flood was still running, I quickly hit Control-C to kill
tcpdump. Using tcpdump with the -n switch, IP addresses that are actively
in use on the network are revealed. Based on this information, it is
possible to infer that the stealthy network is using 10.0.1.x, it is
most likely using a class C or class A netmask, and 10.0.1.1 is probably
a good guess at the default router. Had this been an actual real-world
network, it would have been trivial to find the default router and local
DNS servers by looking at actual network traffic in Ethereal.

Rather than step on the IP address being used by the iMac (10.0.1.2),
I decided to pick a different address altogether. If this would work,
it should allow the iMac and iBook to coexist on the network without
too much interference.

As you can see, I was able to ping yahoo.com (and had full network access
from that point on). Given the correct SSID, WEP key, and a valid MAC
address, the AirPort could not distinguish me from the iMac, and therefore
could do nothing to keep me out. Note that while the AirPort can't tell
the difference, a program such as arpwatch can detect many sorts of
MAC address shenanigans, but only if the AirPort is configured as a
bridge. Since it is set up as a NAT in this configuration (as many APs
are by default), the sharing of MAC addresses between clients is completely
invisible to the rest of the network.

Post Mortem

I hope this little experiment gives you some idea of what you are up
against when relying on the built-in security measures of 802.11b. Using
inexpensive hardware and freely available tools, a typical Wi-Fi network
can be easily cracked in a mere hour and a half (although it will probably
take a bit longer on average, depending on how busy the network is,
potentially offset by a bit of luck).

What does this mean for wireless security? Should we run screaming to
our system administrators and toss the whole lot into the garbage? Of
course not. This whole exercise is presented to drive home this point:
If you are concerned about wireless security, you must use strong application-layer
encryption and authentication. Much of the rest of this chapter details
other freely available tools that you can use to protect your network
and your wireless users against these attacks.