17.3 Cracking WEP

The WEP protocol defines methods through which wireless data should be secured. Unfortunately, it can easily be cracked, as we will demonstrate . Although proposed standards (such as Wi-Fi Protected Access, or WPA) purport to ameliorate the known weaknesses in WEP, the reality is that WPA has backward compatibility issues with most 802.11b hardware. Thus, WEP continues to be the most prevalent (albeit flawed) primary encryption scheme for WLANs.

WEP uses the RC4 algorithm to encrypt its data. RC4 is one of the most popular methods of encryption and is used in various applications, including Secure Sockets Layer (SSL), which is integrated into most e-commerce stores. RC4 uses a streaming cipher that creates a unique key (called a packet key ) for each and every packet of encrypted data. It does this by combining various characteristics of a pre-shared password, a state value, and a value known as an initialization vector (IV) to scramble the data. This part of RC4 is known as the key scheduling algorithm (KSA). The resultant array is then used to seed a pseudorandom generation algorithm (PRGA), which produces a stream of data that is XORed with the message (plain text) to produce the cipher text sent over the airwaves.

The transmitted data consists of more than just the original message; it also contains a value known as the checksum . The checksum is a unique value computed from the data in the packet, used to ensure data integrity during transmission. When the packet is received and decrypted, the terminal checksum is recalculated and compared to the original checksum. If they match, the packet is accepted; if not, the packet is discarded. This scheme not only protects against normal corruption but also alerts the user to malicious tampering.

Once the data is encrypted, the IV is prepended to the data along with a bit of data that marks the packet as being encrypted. The entire bundle is then broadcast into the atmosphere, where it is caught and decrypted by the receiving party.

The decryption process is the reverse of the encryption process. First, the IV is removed from the data packet and is then merged with the shared password. This value is used to recreate the KSA, which is subsequently used to recreate the keystream . The stream and encrypted data packet are then XORed together, resulting in the plain-text output. Finally, the CRC is removed from the plain text and compared against a recalculated CRC; the packet is then either accepted or rejected.

Most experts consider RC4 to be a strong algorithm. However, due to various errors in the implementation of the IV, it is trivial to crack WEP. The following sections explain in detail how and why it is possible to crack WEP.

17.3.1 Data Analysis

When data is transferred via the airwaves, it can easily be captured using programs downloaded from the Internet. This type of monitoring was anticipated, and it is the reason WEP security was added to the 802.11 standard. Through WEP, all data can be scrambled to the point where it becomes unreadable. While WEP does not prevent the wanton interception of data, it protects the captured data from casual interpretation.

However, there are faults in implementation of RC4. If a hacker can determine what data is being sent before it is encrypted, the captured cipher text and known plain text can be XORed together to produce the keystream as generated by the PRGA. The reason for this flaw is that WEP produces the cipher text by merging only two variables together using XOR. Equation 1 depicts the final function of the RC4 algorithm, which encrypts the data:

Cipher text = Plain text XOR Keystream

As you can see, the only value masking the plain text is the keystream. If we reverse this process, we see that the only value masking the keystream is the plain text, as depicted by Equation 2.

Keystream = Cipher text XOR Plain text

It is a simple matter to extract a keystream from encrypted data, as long as we have both the cipher text and the original plain text. The cipher text is simple to capture; all that is needed is a wireless sniffer, and we can gather gigabytes worth of encrypted data from any wireless network.

17.3.2 Wireless Sniffing

The quality of a sniffer is directly related to the information it can provide for its user. For example, many hackers consider dsniff to be one of the best sniffers available ”not because dsniff captures any better than Ethereal, which is at the top of the list for many professionals, but because dsniff incorporates extra features, such as a built-in password sniffer, ARP spoofing technology, and more. These small additions make the program more streamlined, if collecting passwords is your goal. On the other hand, some troubleshooting requires the use of an expensive, all-in-one hardware/software sniffer package. These devices, which would be overkill for a small network, can collect gigabytes of data and never miss a packet.

In addition to landline sniffers, the introduction of wireless networks has caused the creation of a new niche of sniffers. Due to the unique physical and technical properties of WLANs, the quality and functionality of a wireless sniffer is tied to how well it can be integrated into an existing wireless network. Some sniffers only capture packets from WLANs to which they are associated, while others can capture data on all operating networks in physical proximity to them. For an 802.11b network, up to 14 different channels are used to transmit data. As a result, it is possible to have up to four different and totally separate WLANs in the same general area (several channels are used per network). To collect data from all local wireless networks, the wireless device on which the sniffer is operating has to operate in a passive mode. While this allows it to capture all data, the device will not be able to connect to any existing wireless network. In other words, it will be continuously jumping channels, which is similar to jumping networks several times a second. Due to the nature of networking, this process wreaks havoc on any communication sessions you attempt to capture. To make it even more complicated, sniffing a wireless network in passive mode requires special drivers, or at the minimum a patch to existing drivers.

When a network card is manufactured, it is assigned a unique identifier known as a Media Access Control (MAC) address. Since this address is supposed to be unique, it serves as one of the fundamental methods by which data is transmitted over a network. While there are many other communication protocols that sit on top of the MAC address to help with data flow, the MAC address is used in the first and last legs of the transmission process. It is important to understand the significance of the MAC address, because it indirectly affects the data a sniffer can access.

When a network card is operating normally, it actually scans each packet of data traveling over the network to see if any of the data is labeled with its MAC address. If there is a match, the data is passed up to the next layer in the protocol stack, and ultimately to the program to which it was sent. If the packet is not addressed to the NIC, for practical purposes it will be ignored.

Since the sniffer software actually operates above the hardware layer of the communication stack, it only receives data sent to the computer on which it is operating. In other words, the sniffer only sees local data. While this level of access can be helpful in some situations, the limited access restricts most troubleshooting efforts. This is where promiscuous mode comes into play.

When a network card is placed in promiscuous mode, it accepts all data passed on the wire to which it is connected, regardless of the MAC address. However, there are still some obstacles a sniffer must overcome to gain access to network traffic, including additional support for wireless data, which uses radio waves to pass data, and limitations due to networking technology.

There are many examples of wireless sniffers; an excellent example is Kismet (available from http://www.kismetwireless.net). However, if you are doing a walk-around site audit for a large campus, it may be more convenient to use a "pocket sniffer." An example is the Airscanner Mobile Sniffer (shown in Figure 17-2), which runs on Windows Mobile/PocketPC.

Figure 17-2. Using the free Airscanner Mobile Sniffer to perform wireless sniffing

It can be downloaded from http://www.airscanner.com and is free for personal use. It will enable you to do all of the following:

• Sniff wireless packets in promiscuous mode.

• Decode UDP, TCP, Ethernet, DNS, and NetBIOS packets .

• Conduct network analysis on an entire WLAN segmen.

• Customize filters for source and/or destination IP address, UDP port, TCP port, or MAC address.

• View real-time packet statistics .

• Save results of capture sessions.

• Export data to libcap format (e.g., Ethereal) for further analysis on a desktop PC.

With Airscanner Mobile Sniffer, you can export the packet capture from your pocket PC to a desktop for further analysis with Ethereal. Ethereal (discussed in Chapter 6) is one of the most popular desktop sniffers available. It performs packet sniffing on almost any platform.

17.3.2.1 Extracting the keystream

Now that we have obtained a wireless sniffer for capturing encrypted data from a WLAN, we can extract a keystream as long as we have both the cipher text and the original plain text. How do we know the original data value? The usual way an attacker can predetermine plain text is to trick someone into receiving or sending a predictable message. For instance, a chat session or email could provide an attacker all the plain text she needs. However, this method can be difficult if extraneous data becomes intermingled with the predictable data. For example, TCP/IP packets include IP headers and other distracting information. Checksums, proprietary data additions by the email server, and more can obscure the predictable data. Therefore, if an attacker is going to succeed with this method, she needs to send a message that increases the chances of obtaining predictable data. This could be easily accomplished using an email full of blank spaces (e.g., " ") or a long string of the same character (e.g., "AAAAAAAAAAAAAAAAAAAAAAAA").

Another method used to predetermine plain text is to look for known communication headers. TCP/IP packets include IP headers that are required to ensure proper delivery. If we can determine the IP address of the access point or client WNIC and make an educated guess about the rest of the data based on user habits, we can deduce the plain text. In fact, because of the way 802.11 is set up, almost every packet that is sent includes a SNAP header as its first byte. This simple fact is one of the major weaknesses through which WEP can be cracked, as you will learn later.

Assuming an attacker can determine the plain text of a message and use this to glean the keystream, what can she do with this information? The answer to this will become apparent as you read on. Also note that one or even a couple of keystreams by themselves are basically worthless. It is when you combine the knowledge gained in this type of wireless attack with other wireless hacking techniques that the power of knowing a keystream becomes manifest.

17.3.3 IV Collision

WEP uses a value known as an initialization vector , commonly called the IV. The RC4 algorithm uses this value to encrypt each packet with its own key by merging or concatenating the pre-shared password with the IV to create a new and exclusive packet key for each and every packet of information sent over the WLAN. However, if the sending party uses an IV to encrypt the packet, receiving parties must also know this bit of information if they are going to decrypt the data. Because of the way WEP was implemented, this requirement turned an apparent strength into a weakness.

WEP uses a three-byte IV for each packet of data transmitted over the WLAN. When the data is sent, the IV is prepended to the encrypted packet. This step ensures the receiving party has all the information it needs to decrypt the data. However, if we take a closer look at the statistical nature of this process, we quickly see a potential problem. A byte is eight bits. Therefore, the total size of the IV is 24 bits (8 bits x 3 bytes). If we calculated all the possible IVs, we would have a list of 2 ²⁴ possible keys. This number is derived from the fact that a bit can either be a 0 or a 1 (2), and there are a total number of 24 bits ( ²⁴ ). While this may sound like a huge number (16,777,216), it is actually relatively small when associated with communication. The reason is found in the probability of repeats.

The IV is a random number. When most people tie the word random to a number like 16,777,216, their first assumption is that an attacker would have to wait for 16 million packets to be transferred before a repeat. This is false. In fact, based on probability, you could reasonably expect to start seeing repeats (also known as collisions) after just 5,000 packet transmissions or less. Considering the average wireless device transmits a 1,500-byte packet, a collision could be expected with the transfer of just a 7-10 MB file ( 5,000 packets x 1,500 bytes = 7,000,000 bytes or 7 MB).

The keystream is produced from various properties of the password and the IV. In the case of a collision, the IV is known as a three-character value of "1:2:3". While we do not know the password, it is irrelevant, because it never changes. We can now deduce the keystreams generated by matching IV values.

This weakness is not so much the fault of WEP itself as of a small IV size. If the IV were several times longer, the time between repeated IVs would be larger, creating a more difficult scenario for any attacker attempting to send predictable data through a network. Considering a packet is generally 1,500 bytes long and the IV is only 3 bytes long, there would have been room for growth. However, in the name of speed and a maximized data flow, the protocol designers reduced the IV size.