Other Tools

Other tools are often used for network analysis. Although not strictly used as troubleshooting tools, they are often used in assessing coverage.

Finding, Measuring, and Mapping Networks

Searching for 802.11 networks is the first step in connecting to them. Several analysis tools exist to discover networks or assess the coverage area of existing networks. Taken to its extreme, the result of network discovery is "wardriving," in which a user

Figure 24-6. Entering WEP keys

with network discovery software logs the locations of access points. NetStumbler (http://www.netstumbler.com) and Kismet (http://www.kismetwireless.net) are two of the best-known tools.

Network detection is a passive process. Beacon frames can be collected with an 802.11 receiver, and there is nothing that can be done about it. Assuming your network will be discovered is the best policy. Instead of relying on obscurity, either by location, network name, or low transmission power, defend your network with appropriate security tools, such as the authentication and encryption methods discussed in Chapters 6 and 7. Although your network may be discovered, its data need not be.

WEP Key Recovery

Several open source tools are readily available to attack weak WEP keys. The best known is AirSnort, which was released in August 2001. Current code is available from http://airsnort.shmoo.com/. AirSnort was the first public implementation of the Fluhrer-Mantin-Shamir attack against WEP discussed in Chapter 5 and is the best known, but others exist.[*]

[*] See, for example, WEPcrack (http://wepcrack.sourceforge.net/) and Aircrack (http://www.cr0.net:8040/code/network/aircrack/).

WEP key recovery tools depend on certain classes of "weak" initialization vectors. Ethereal has borrowed the AirSnort classification code, and now reports weak IVs. Commercial tools have reported on weak IV usage for many years as well.

To defend against WEP key recovery attacks, network administrators shorten the key lifetime to anywhere between 5 and 15 minutes. Many vendors have patched code to avoid using weak IVs as well. In early 2002, the Interop Labs discovered that several vendors had reacted with surprising speed and prevented the use of weak IVs. By 2004, however, the list of vendors with fixes was almost the same, even with two years to apply the fix.

Key recovery time estimates

There are two components to recovering a key. First, enough frames with weak IVs must be gathered to mount an attack, which I refer to as the gathering time. Second, a successful attack must be run against the stored frames, which I refer to as the analysis time.[]

images/ent/U2020.GIF border=0>] For a discussion of analysis time, see http://securityfocus.com/infocus/1814.

In my experience, the time required to gather enough data to mount the attack is so much larger than the CPU time required to run the attack that the estimate of key recovery time is essentially equal to the gathering time. With enough samples to successfully attack, the analysis time is only a few seconds. The analysis time scales linearly, so the protection afforded by longer keys is only a few seconds. By doubling the key length, the CPU time required for the attack will double, but doubling a few seconds is still only a few seconds.

Authentication

Most 802.1X authentication protocols on wireless networks use TLS tunnels for security. The ssldump tool (http://www.rtfm.com/ssldump/) can be used to decode a TLS handshake as well as anything passed through the tunnel. Decryption requires a copy of the private keys used with any certificates.