accesses since September 3, 2004
copyright notice
link to published version: Communications of the ACM, December, 2004
accesses since September 3, 2004Hal Berghel and Jacob Uecker
In our last column (September, 2004) we discussed the history and practice of War Driving. We noted the inherent insecurities in the 802.11 protocol standards, and reported some rather frightening statistics (e.g., over 60% of the Wireless Access Points discovered in the 4 th Annual WorldWide War Driving Competition had no form of encryption enabled!)
We also pointed out that there is a perfectly lawful and legitimate use for wireless monitoring, but when it is used with unlawful or unethical intent, it is generally characterized as War Driving. We observed that War Driving is now ubiquitous. A good illustration of this is provided by the WiGLE.net online database of WAPS.
Having established that the practice of War Driving is commonplace, the extent of the risk remains to be shown. We will consider three scenarios. But first, the unavoidable preliminaries.
SERVICE SET IDs
Since our goal is to discuss wireless security, we'll frame our discussion in terms of a very high-level overview of wireless technology.
We normally associate the term "wireless networks" with the 802.11 family of protocols, the most popular of which at the moment is various flavors of 802.11 (aka "WiFi"). The foundation of an 802.11 network is the "basic service set" (BSS). Service sets may be defined as a tier structure:
Tier 0: Independent BSS (IBSS) or "ad hoc" network = df. Any cluster of wireless-enabled computers (aka "stations") inter-communicating between themselves.
Tier 1: Infrastructure BSS =df. A cluster of one or more stations connected with a Wireless Access Point (WAP, or simply AP). In this mode, all stations communicate with each other through one WAP at a time - no direct station-to-station communication is permitted.
Tier 2: Extended Service Set (ESS) =df. A cluster of BSSs where interconnected WAPs serve as bridges between service areas.
The "Service Set ID" or SSID is a 32 byte or less network name of a service set ( A list of default SSIDs can be found at http://www.cirt.net/cgi-bin/ssids.pl ) . This name is used by other network devices to initiate a connection. WAPs may be configured as "open" or "closed." In the open mode, the WAP broadcasts its SSID to the world; in closed, it doesn't. Any computer with a WiFi card set to SSID=ANY will attempt to authenticate with the open WAPs with the strongest signals. This is called "association polling" and is built into XP by default when wireless is enabled as may be confirmed by the familiar menu bar caption, below.
Therein is our first security consideration. Is it advisable to broadcast the name of the WAP to the world? Where WAPs are concerned the best practice is to avoid drawing any more attention to the WAP than necessary. Disabling SSID broadcast and setting the signal strength as low as possible without losing the signal is a good first step.
However, closed WAPs only deter primitive network beacon sniffers (e.g., NetStumbler). Beacon Sniffers (aka "active sniffers") continuously broadcast probe requests to entice WAPs to respond. Closed WAPs will not respond unless the probe requests contains its SSID (which means it has to be known in advance), so beacon sniffers are both extremely noisy (and trivial to detect) and provide an incomplete scan. However, greater stealth can be achieved by "passive" sniffers that operate with the network card in monitor mode. Monitor mode captures all traffic on frequency regardless of source or destination as long as the signal is strong enough. This is to be distinguished from promiscuous mode which captures all traffic on the network to which you are associated and is not a default option on all wireless cards.
In monitor mode, passive sniffers like AirMagnet and Kismet monitor all wireless transmission close enough to detect, irrespective of source and destination, without themselves generating any betraying traffic themselves.
So what does a closed WAP buy us? Not much, for the serious invader. But shutting off the SSID broadcast is still worth the effort, if for no other reason than it discourages casual sniffing and WAP mapping by hacker wannabes.
WEP
The goal of Wired Equivalent Privacy (WEP) was to bring some of the security available in wired networks to WiFi. Unfortunately, the designers bungled the job (see Mantin, et al, below). WEP suffers from two fundamental deficiencies: (1) was poorly designed, and (2) it was poorly implemented. Other than that, it's fine.
A key WEP vulnerability results from the implementation of the RC4 symmetric, stream cipher algorithm. Simple stream ciphers work by XORing a stream of bits (the key) with the plaintext to come up with the cipher text that is transmitted and reversed at the other end. In its simplest form this stream cipher wouldn't be secure because a string of zeros in the plaintext would produce the actual key in the cipher text due to the way XOR works. The RC4 algorithm relies on a pseudo-random number generated initialization vector (IV) to control the scrambling of the keystream to provide the desired robustness.
WEPs implementaion of RC4 is flawed in several ways. This allows the algorithm itself to be attacked and the key to be revealed. The first problem with WEP is that the IV is always pre-pended to the key prior to generation of the keystream by the RC4 algorithm. Secondly, the IV is relatively small (3 bytes) which produces a lot of repetitions as the scant 16.77 million variations are re-used to encrypt millions of packets. Third, some of the IVs are "weak" in the sense that they may be used to betray information about the key.
Since the first data to be encrypted in a WEP packet is the SNAP header (as with IP and ARP packets), the first byte of this header is almost always 0xAA. A weak IV has a format of B+3::ff::X (where B is the byte of the key to be found, ff is the constant 255, and X is irrelevant). WEP cracking usually relies on accumulated traffic produced by weak IV values. Since the IV is transmitted with the packet in plaintext, weak IVs are easy to detect. The key value of B is determined after the B+4th iteration of the key scheduling algorithm. Given a sufficient amount of traffic, and repeated applications of this strategy, we can recover the entire key. As a rule of thumb, a few million packets generate enough weak IV traffic to recover 40-bit WEP keys.
WAPS, WEP, SSIDs, AND THE ART OF AIRJACKING
We illustrate the vulnerabilities of WiFi technology with three examples.
Case 1: WAP with SSID broadcast enabled, and no WEP enabled
This configuration invites the greatest vulnerability. It is also the most common for most of the WAPs are shrinkwrapped with this configuration. The 2004 World Wide Wardrive Competition reported that 27.5% of all WAPs fall into this category.
We begin the "penetration test" with a wireless scan of our environment. Figure 1 reveals the result of a scan of our lab with a WAP set up in this configuration. To distinguish it from other WAPs, we set our SSID to "NoWepWap."
Figure 1: AirMagnet Scan of Active WAPs
This AirMagnet screenshot reveals a cornucopia of useful information about our WAP. The top half of the left panel is the alarm window. Our WAP is identified in by the box in the 9 th line. We note that we're broadcasting on channel 6 on 802.11g, that the manufacturer is D-Link, and the MAC address is available. There's also a "red bell" alarm associated with this "NoWepWap" that reports that we are not using encryption. (To call AirMagnet "feature-rich" is an understatement!). So the challenge of eavesdropping on our WAP becomes irresistible.
The connection to NoWepWap is a no brainer. After receiving the menu bar pop up shown above, we're one click away from connecting (Figure 2).
Figure 2: Using the Windows GUI to Automatically Connect to an "Open" WAP. Click "connect" and you're in.
Case 2: WAP with SSID broadcast disabled, and no WEP enabled
This configuration offers the second greatest vulnerability level, not far behind Case 1. It is only minimally better protected because disabling SSID broadcast only hides from the primitive beacon sniffers, not the sophisticated passive scanners like Kismet and AirMagnet. It will also not appear as an available network to Windows, because Windows requires that the SSID of the target WAP be specified prior to the authentication request. If the SSID isn't known, it can't be entered manually and connectivity is blocked. While no deterrent of significance, disabling SSID broadcast might discourage the neighbor's kid from using you for free Web access.
Case 3: WAP with SSID broadcast disabled, and WEP enabled
This configuration is the least vulnerable (do not read "secure" into this) of all of the configuration options. The 2004 World Wide Wardrive Competition reported that only 38.4% of all WAPs fall into this category.
By enabling WEP and disabling the SSID broadcast, not only will the hacker have to find the SSID of the network, but also the WEP key must be found. The SSID may be obtained by adding a passive sniffer to our arsenal, so we may safely assume we have that in hand. But what do we do about the WEP barrier?
The brute force of 40-bit or 104-bit keys is unrealistic. However, we know enough about the WEP implementation of RC4 that we are confident that we can count on packets that were encrypted with weak initialization vectors to give up the goods. If only there were some utility... Enter AirSnort.
Figure 3 shows the basic interface to the AirSnort WEP cracking utility. We call your attention to Air Snort's ability to determine whether packets are encrypted and, more important, whether they are "interesting." An interesting packet is one that was generated with a weak IV! Given enough time and volume of wireless data, AirSnort will crack any WEP key. As a rule, once AirSnort receives a few million packets, it has enough data to recover the key.
Figure 3: The AirSnort WEP Cracker Interface. (note "interesting column")
Once this information has been found, Windows can immediately authenticate to a WAP (Figure 4)
Figure 4: The Windows Manual Interface for Authenticating to a WAP
CONCLUSION
We promised you a three-part analysis of WAP vulnerability. You should come away from this column with the thought that even the most "secure" WAP configuration is insecure. That doesn't diminish the utility of WiFi, but it should alert us to potential risks.
Actually, the dangers are far greater than given here. We have only discussed the use of widely available utilities to authenticate to a WAP without permission. More aggressive attacks of wireless networks include denial of services, man-in-the-middle attacks, forced de-authentication of authorized users, WAP MAC address spoofing, to name but a few. Recently questions have been raised about the reliability of the successors to WEP, WPA, EAP and LEAP. Wireless neighborhoods are only as safe as the neighbors.
URL PEARLS
AirMagnet ( www.airmagnet.com ) is arguably the best-of-breed wireless monitor/scanner. It is a commercial product designed for Windows notebooks and PDAs. Kismet (www.kismetwireless.net), though less fully featured, is a very powerful, open source *nix utility that integrates well with AirSnort and Ethereal for weapons-grade packet analyses.
Perhaps the most widespread active wireless sniffer is NetStumbler ( www.stumbler.net ), though the volume of "noise" it produces and the fact that it will only work with "open" WAPs drastically limits its use in real-world applications.
WEP cracking tools are in no short supply. Airsnort ( airsnort.shmoo.com ) is an open-source *nix utility as is WepCrack (wepcrack.sourceforge.net). WepAttack ( sourceforge.net/projects/wepattack) is a newer tool from Sourceforge that uses active dictionary attacks in much the same way as modern password crackers. Sourceforge's WEPWedgie (sourceforge.net/projects/wepwedgie) falls on the invasive side of the WebCracking wall. As Sourceforge puts it, "WEPWedgie is a toolkit for determining 802.11 WEP keystreams and injecting traffic with known keystreams."
The motherload of WAP maps is available on the Wireless Geographic Logging Engine Website (http://wigle.net). As of this writing, WiGLE's database and mapping technology includes over 1.6 million WAPS. If you can't find the WAP of interest there, you can probably live without it. The statistics used above are reported on the 2004 WorldWide Wardrive Website at http://www.worldwidewardrive.org.
The term "WiFi" is associated with the Wireless Ethernet Compatibility Alliance (WECA). Additional detail may be found on their Website ( www.wi-fi.org -remember to include the hyphen).
The seminal paper that started the world of WEP cracking was Itsik Mantin, Adi Shamir and Scott Fluhrer's "Weaknesses in the Key Scheduling Algorithm of RC4" abundantly available via Websearch. For a quick hop cf. http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf .
A variety of WiFi security vendor sites provide additional detail on vulnerabilities. Airdefense ( www.airdefense.net ) and AirMagnet( www.airmagnet.com ) provide several interesting white papers.
A useful guide to 802.11 wireless technology is Matthew Gast's 802.11 Wireless Networks: The Definitive Guide, O'Reilly & Associates, Sebastopol (2002). A good first pass at WiFi security issues may be found in chapter 7 of O'Reilly's Wireless Hacks by Rob Flickenger (2003). A useful introduction to the practical side of setting up and securing a wireless network is Jeff Duntemann's Wi-Fi Guide, Paraglyph Press, Scottsdale (2004).