Dispelling the Myth of Wireless Security

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:


root@ibook:~# ifconfig eth1 hw ether 00:30:65:1E:81:9B
root@ibook:~# iwconfig eth1 key 's:t8$Gc'
root@ibook:~# iwconfig eth1 essid stealthy


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:


root@ibook:~# tcpdump -n -i eth1
19:52:08.995104 10.0.1.2 > 10.0.1.1: icmp: echo request
19:52:08.996412 10.0.1.1 > 10.0.1.2: icmp: echo reply
19:52:08.997961 10.0.1.2 > 10.0.1.1: icmp: echo request
19:52:08.999220 10.0.1.1 > 10.0.1.2: icmp: echo reply
19:52:09.000581 10.0.1.2 > 10.0.1.1: icmp: echo request
19:52:09.003162 10.0.1.1 > 10.0.1.2: icmp: echo reply
^C


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.


root@ibook:~# ifconfig eth1 10.0.1.3 netmask 255.255.255.0 broadcast 10.0.1.255
root@ibook:~# route add default gw 10.0.1.1
root@ibook:~# ping -c2 yahoo.com
PING yahoo.com (66.218.71.198): 56 data bytes

--- yahoo.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 32.5/32.8/33.2 ms


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.

Resources

Check out these sites for the tools mentioned throughout this hack:

• Kismet
• AirSnort
• tcpdump
• Ethereal
• arpwatch

First appeared at O’Reilly’s Wireless DevCenter

Written for the intermediate to advanced wireless user, Wireless Hacks is full of direct, practical, ingenious solutions to real-world networking problems. Whether your wireless network needs to extend to the edge of your office or to the other end of town, this collection of non-obvious, “from the field” techniques will show you how to get the job done.