Earlier in the book, we explained the basics of Wi-Fi LAN technology and provided an intuitive notion of what security is all about. In this chapter, we jump into the details of the various known attacks against the security standards used in building wireless LANs, including IEEE 802.11. Some of the material may appear complex, and at least one of the attacks requires a reasonable background in cryptography for full understanding. We present the information as simply as possible; but if you're not interested in the details, skip to the next chapter, which discusses how attackers can use techniques such as described in this chapter to break into a poorly protected wireless network.
In Chapter 4, we classified attacks into four broad categories: snooping, modification, masquerading, and denial of service. In this chapter, we cover the material somewhat differently by classifying the various attacks by the security mechanism that it breaks. We also categorize the attacks so you'll understand what a successful attack provides to the bad guys.
There are numerous ways to classify something as complex as security. Chapter 4 focuses on the goals of the attacker, that is, what the attacker gains if he is successful. This section introduces another method of classifying attacks based on the security mechanism targeted by the attacker.
Every effective security architecture uses one or more security mechanisms to implement the goals of the architecture. These basic security mechanisms are confidentiality, integrity, and availability.
Confidentiality protects against the inadvertent or malicious disclosure of sensitive information, that is, it conceals information. Usually, confidentiality is provided by cryptographic or access control mechanisms. Let's review the definitions of these mechanisms.
Encryption is the process of making information indiscernible to an adversary, and cryptography is the study of making and breaking encryption algorithms. There are two widely used forms of encryption: symmetric and asymmetric. With symmetric encryption, the communicating parties share a secret—a key—that is used for both encryption and decryption. With asymmetric encryption, the communicating parties usually have two keys, a private key for decryption and a public key for encryption. The inverse is also true. The private key can be used to encrypt some data. In this case, the result is essentially a signature that can be verified by anyone having knowledge of the corresponding public key, if he knew or could compute the value of the encrypted data. Now, let's discuss symmetric and asymmetric encryption in more detail.
Asymmetric encryption, also known as public key cryptography, uses a different key for decryption than the key used for encryption, as follows:
M = D(private_key, E(public_key, M)),
where M is the message, D is the decryption function, and E is the encryption function.
Usually, the two keys used in the process are referred to as a key pair, with one key called the private key and the other key called the public key. The public key is shared with anyone for communications purposes, and the private key remains known only to the holder, or principal, of the key pair. The public key is usually shared in the form of a certificate that includes information that uniquely identifies the holder of the key pair as well as the signature of the issuer—a trusted entity that vouches that the identity bound to the public key in the certificate is correct. The process that issues and revokes public-key certificates is called a public key infrastructure, or PKI.
An example of an asymmetric encryption algorithm is the widely used RSA public key algorithm designed by Rivest, Shamir, and Adleman (Rivest et al., 1979).
Symmetric encryption uses the same secret key, k, for both encryption and decryption, in other words:
M = D(k, E(k, M).
Examples of popular symmetric encryption algorithms include the RC4 (Ron's Cipher 4) by Ron Rivest and AES (Advanced Encryption Standard) ciphers, both of which have already been covered in some detail (RC4 in Chapter 6, and AES in Chapter 12). Symmetric ciphers operate in one of two fashions—stream or block. In a stream cipher, such as RC4, each byte of the plaintext or ciphertext is processed individually—that is, a byte is the basic unit. In a block cipher such as AES, the plaintext or ciphertext is grouped together into blocks of a predetermined and fixed size and then processed as a single unit.
When two parties wish to communicate securely using a symmetric cipher, they first must agree upon the shared secret, k, in a secure fashion. This is usually accomplished via key distribution or key agreement, both of which are forms of key management, which we discuss next.
Key management systems provide the means for implementing cryptographic periods via the secure distribution of new keys on a regular basis. An important point is that disclosure of the secret key during distribution would cause any cryptographic system to fail, and failing to regularly change keys would weaken most cryptographic systems. Therefore, every security architecture should use a robust key management system.
Of the two approaches to key management, manual and automatic (electronic) systems, manual systems are more prone to risk because they significantly depend on human assistance, which has historically been the weakest link in any security architecture. Automatic systems, while more difficult to design, are significantly more robust when correctly designed, implemented, and operated.
Access control is another mechanism that supports confidentiality. We previously followed the analogy of the much-valued doorman who allows only those who live in an apartment building to enter it. Essentially, the purpose of access control is to allow only those who are authorized to use or view system resources. Typically, this is accomplished through an access control list (ACL), which in its simplest form is a look-up table based on some identity criteria. Access control mechanisms work very closely with authentication as they rely on a valid identity (proven by authentication) to make decisions concerning access. Remember we first introduced access control in Chapter 8 and authentication in Chapter 6.
There are two aspects to integrity. With source integrity—also known as authentication—the information's originator is known and credible. With data integrity, we seek to prevent inadvertent or malicious modification of the data.
Source integrity (authentication) is the process of proving either a principal's identity or a trusted source of data/system resources. Strong authentication requires two elements. The first is a common trust element—something or someone whom the object doing the authentication trusts and who can vouch for the subject or person being authenticated. The second element is a unique identity for the subject being authenticated. For example, when you use a check to pay for goods, the cashier usually asks to see your driver's license to ensure that it matches the name on the check. In other words, the clerk is authenticating your identity by trusting the Department of Motor Vehicles to have verified your identity before issuing you a driver's license. Although not foolproof, the difficulty of forging drivers' licenses encourages merchants to use them as verification when accepting checks.
Authentication works closely with access control mechanisms, which require a verified identity to make access decisions.
Ensuring data integrity requires the detection and, ideally, the prevention of unauthorized modifications. Whereas cryptography detects integrity violations, access control prevents integrity violations.
Access control for data integrity is similar to using access control for confidentiality; the mechanism prevents attackers from accessing and thus modifying the data. The cryptographic approach is somewhat different in that it uses a cryptographic hash function to create a unique hash value or fingerprint of the data. To be considered a cryptographic hash function, an algorithm must meet four requirements:
The hash value must be easy to compute.
Creating data that results in a specific hash value must be computationally difficult so that it is difficult for adversaries to replicate that hash value and make undetected alterations to data.
The hash function must be one way, making it difficult to recreate the data based solely on the hash value.
Collisions—that is, identical hash values for two random data sets—must be difficult to find.
Given a cryptographic hash function, detecting integrity violations is straightforward. First, we compute the hash value for a given data set. Then, we compute a new hash value over the same data at a later time and compare it to the previous value. If the two values are not equal, the data was modified. We do this using message authentication codes and digital signatures.
Message authentication codes (MAC[1]) use a keyed one-way function to provide message authenticity proving that the contents have not been altered in route.
A keyed cryptographic hash is the most common way to build a MAC, requiring a shared secret, k, between the communicating parties and an agreed-upon cryptographic hash function, H. To send a message, M, along with another MAC, the sender computes the MAC using MAC = H(k M, k), and sends <M, MAC> to the recipient.
Upon receipt, the receiver computes a MAC value over M and compares the computed value to the received MAC. If the two values are the same, the message authenticity is valid.
While the simple MAC shown previously provides message authenticity, it should not be used in practice because a much stronger MAC exists. The HMAC MAC has a formal basis for its security properties (Krawczyk, 2003).
Digital signatures use a cryptographic hash function such as MD5 or SHA1 along with public key cryptography to ensure message authenticity and data integrity. To compute a digital signature, the sender first computes a hash value h of the message M and then encrypts this hash value using an asymmetric algorithm, typically RSA, with the sender's private key. This process of computing a digital signature is shown below:
h = H(M)
S = ERSA(private_key, h)
The sender now sends the message M and the signature S to the recipient. To verify the authenticity of the message, the receiver calculates the hash value of the message, h´, and decrypts the signature S using the sender's public key to obtain the original hash value h. The receiver now compares the two hash values: If they are equal, the message is authentic; if they are not, the message was either tampered (data integrity attack) or not tampered while in route from the expected sender (source integrity). The process of generating the two hash values is shown below:
h′ = H(M)
h = DRSA(public_key, S)
Some people wrongly believe that cryptography provides a complete security solution. It does not. Cryptography is an extremely important tool in providing security, but it is not the complete solution to our security problems.
The original (1999) version of the IEEE 802.11 specification defines several security mechanisms. The first is the wired equivalent privacy (WEP) protocol, which was designed to provide users with the same level of confidentiality protection as that of a wired network. The standard also includes a shared key authentication mechanism and integrity protection against inadvertent errors. While access control is not specifically addressed in the standard, most vendors have implemented an access control list mechanism based on MAC addresses.
In the 1999 version of the standard, confidentiality is implemented through the WEP protocol, which uses RC4 for encryption (Menezes et al, 1996; Schneier, 1996). RC4 is a proprietary stream cipher designed by Ron Rivest in 1987. The algorithm was reverse-engineered and made public anonymously in 1994. While the algorithm has received a great deal of public attention, RSA Labs still claims the algorithm is a trade secret.
RC4 is a remarkably simple cipher. As a result, the performance of the algorithm is high. It also makes describing the algorithm easy. There are two major phases in RC4. The first phase is the key setup algorithm (KSA), which establishes a 256-byte array with a permutation of the numbers 0–255. The permutation in the array, or S-box, is established by first initializing the array with the numbers 0–255 in order. The elements in the S-box are then permuted through the following process. First, a second 256-byte array, or K-box, is filled with the key that repeats as needed to fill the array. Next, the bytes in the S-box are swapped according to the pseudocode in Equation 15-1.
Example 15-1. RC4 Key Schedule Algorithm
i = j = 0; For i = 0 to 255 do J = (j + Si + Ki) mod 256; Swap Si and Sj; End;
The next phase in RC4 is the pseudorandom generation phase. In this phase, the algorithm in Equation 15-2 generates a pseudorandom byte R.
Example 15-2. RC4 Pseudorandom Generation Algorithm
i = (i + 1) mod 256 j = (j + Si) mod 256 Swap Si and Sj K = (Si + Sj) mod 256 R = SK
To produce n pseudorandom bytes, the algorithm executes Equation 15-2 n times. To encrypt plaintext, the stream of generated pseudorandom bytes is combined with the plaintext bytes using the XOR function as a combining function, as shown in Equation 15-3:
where Ci is the ith ciphertext byte, Pi is the ith plaintext byte, and Ri is the ith pseudorandom byte. The decryption process is just the inverse encryption shown in Equation 15-3 and is shown in Equation 15-4.
The equations shown in Equations 15-3 and 15-4 are a Vernam cipher (Vernam, 1926). The Vernam cipher, designed by Gilbert Vernam during World War I while working for AT&T, is the only completely secure encryption system provided that Ri is a true random byte. In this case, Equations 15-3 and 15-4 are known as a one-time pad. To be completely secure Ri must be truly random, and a random sequence must never be used more than once. Because the former Soviet Union made this serious mistake following World War II, the American National Security Agency was able to decrypt a number of one-time pad enciphered messages sent by Soviet agents in a project code named VENONA (U.S. NSA, 1999).
RC4, however, is not a completely secure encryption system because it generates pseudorandom bytes, not truly random bytes. WEP uses RC4 along with an initialization vector (IV) to ensure that each message encrypts differently along with a 32-bit cyclic redundancy check to protect data integrity during the transmission of encrypted 802.11 packets.
WEP uses a 24-bit IV in an attempt to ensure that RC4's pseudorandom byte stream is not reused because reusing the same pseudorandom byte stream creates depth, which can make the attacker's job easier. The sender uses a unique key with every packet that is derived by appending the shared secret key, k, to the publicly known IV. This process is shown in Figure 15.1.
WEP uses a 32-bit cyclic redundancy check (CRC) as an integrity check value (ICV). The ICV detects any changes (malicious or inadvertent) in the transmitted message's underlying plaintext. Unfortunately, while a CRC easily detects most inadvertent changes, it does not provide integrity or message authenticity capabilities against malicious changes. Thus, an attacker can easily modify messages protected by a CRC.
A CRC uses the mathematics of finite fields, more specifically, GF(2). Fortunately, the mechanics (not the mathematics) of how a CRC works are easily explained. A message M that is n + 1 bits long can be represented as an nth-degree polynomial, M(x). For instance, consider a message consisting of only the single ASCII letter “O,” which is represented in binary as 01001111. The polynomial corresponding to this message is 07 + x6 + 05 + 04 + x3 + x2 + x + 1, or x6 + x3 + x2 + x + 1.
For a CRC to work, both the sender and the recipient must agree upon a polynomial G(x) of degree m that will be used to calculate the CRC.[2] This polynomial will be used as a divisor for the message.
The WEP CRC polynomial is G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1, with m = 32 (IEEE, 1997). Transmitting an n + 1-bit message, M also transmits an additional m bits, for a total message length of n + m + 1 bits. We'll call the message and the additional m bits the polynomial P(x). The m + 1 bits added to the original message make P(x) divisible by G(x) with a remainder of 0. The m + 1 bits are determined by increasing the degree of M(x) by m, then by multiplying M(x) by xm to obtain M´(x), and then dividing M´(x) by G(x). The remainder, if any, is then subtracted from M´(x), resulting in P(x)—the transmitted value of n + m + 1 bits.
Verification of the CRC by the recipient involves a similar process. The recipient divides P(x) by G(x), and if the remainder is 0, the message does not contain unintentional errors. The key word here is unintentional because CRCs do not prevent the introduction of intentional errors when the attacker knows G(x).The attacker only needs to modify M(x) and calculate new m + 1 bits, just as the sender did. An example of how to calculate a CRC is provided in Appendix B.
Figure 15.2 shows the WEP datagram format. The preamble of the datagram is a four-octet value that includes the 24-bit IV in plaintext, a 6-bit pad, and a 2-bit keyID value.
The WEP datagram format can be represented by C = RC4(IV, k) ⊕ <M, CRC(M)>, which shows that RC4 encrypts both the message and the results of the CRC calculation (ICV).
An important point to remember about WEP is that the plaintext and the pseudorandom bytes produced by RC4 are combined with a linear function, XOR. This fact causes significant problems for WEP that are discussed later in this chapter.
The 802.11 standard neither addresses link-layer key management nor does it provide recommendations for upper-layer key management. The standard, instead, relies only on manual key management, which is difficult to perform in a timely manner when the number of hosts is large.
As a result, only a few major vendors initially implemented any form of key management or key agreement in their high-end products, and all of these products use upper-layer methods. Unfortunately, the vendors do not provide sufficient information to determine the level of assurance their products provide. Worse, in some cases, available details indicate that vendors' “solutions”' worsen the problem by using protocols with well-known vulnerabilities—for example, an unauthenticated Diffie-Hellman key agreement.
The 802.11 standard offers two methods for using WEP keys. The first provides a window of four keys. A station or access point (AP) can decrypt packets enciphered with any one of the four keys; transmission, however, is limited to one of the four manually entered keys—the default key. The second method is called a key mappings table. In this method, each unique MAC address can have a separate key. According to the 802.11 specification, a key mappings table should have at least ten entries. The maximum size, however, is likely chip-set dependent. Having a separate key for each user makes the cryptographic attacks found by others slightly more difficult because the traffic per key will be reduced, but enforcing a reasonable key period remains a problem as the keys can only be changed manually.
Access control is a major component of any secure architecture. The previous 802.11 standard does not define any means for access control. As a result, most vendors implement access control lists using the client's MAC address as its identity, and one major vendor implements a proprietary access control using a shared secret.
Each access point can limit network access to clients using a listed MAC address. If the client's address is not listed, access to the network is prevented.
A major wireless vendor has defined Closed Network, a proprietary access control mechanism. With this mechanism, a network manager can use either an open or a closed network. Anyone is permitted to join an open network, but only clients with knowledge of the network name, or SSID, can join a closed network. In essence, the network name acts as a shared secret. Unfortunately, because the SSID is sent over the air unencrypted, it is not a well-protected secret.
The current IEEE 802.11 standard does not have a robust mechanism designed specifically for integrity purposes. Some claim that the 32-bit CRC ICV function provides integrity; but, as we have seen, this is not the case in practice.
The 1999 specification has only two forms of standardized authentication in 802.11—open system and shared-key authentication.
Open system authentication is the default authentication protocol for 802.11. As the name implies, this method authenticates anyone who requests it; in essence, it provides a NULL authentication process. This method was likely included in the standard to permit the use of a single-state machine that supports authenticated and unauthenticated operation.
Shared-key authentication uses a standard challenge and response along with a shared secret key to provide authentication. The station wishing to authenticate, the initiator, sends an authentication request management frame indicating that it wants to use shared-key authentication. The recipient of the authentication request, the responder, responds by sending an authentication management frame containing 128 octets of challenge text to the initiator.
The responder generates the challenge text by using the WEP pseudorandom number generator (PRNG) with the shared secret and a random IV. The IV is always sent in the clear as part of a WEP-protected frame. Once the initiator receives the management frame from the responder, it copies the contents of the challenge text into a new management frame body and then encrypts it with WEP, using the shared secret along with a new IV selected by the initiator. The initiator then sends the encrypted management frame to the responder. The responder decrypts the received frame and verifies that the 32-bit CRC integrity check value (ICV) is valid and that the challenge text matches that sent in the first message. The entire process is shown in Figure 15.3.
Unfortunately, all of the security mechanisms defined in the 1999 version of the IEEE 802.11 standard have been proven ineffective. The problems range from issues with the lowest primitives up to the high-level protocols used.
There are numerous flaws in both RC4 as used in WEP and in WEP itself that indicate that WEP provides no effective protection at this point.
Since 1994, researchers have identified a series of small flaws in RC4, none of which resulted in a practical attack. More recently, however, Itsik Mantin and Adi Shamir described a reliable distinguisher[3] for RC4 ciphertext. While this flaw was not a break, it identified a statistical bias in the second output word of RC4's pseudorandom generator. Shortly thereafter, Scott Fluhrer joined Mantin and Shamir in authoring a paper that did result in a practical and complete break (key recovery) of RC4 as used in WEP, and their attack has subsequently been implemented and released in several open source projects.
In a paper presented at the Fast Software Encryption (FSE) 2001 conference, Mantin and Shamir (2001) described a bias in the second word of the pseudorandom stream produced by RC4: Zero occurs as the second word with twice the expected probability (1/128 instead of 1/256) in what should be a pseudorandom sequence with all values equally likely. While this may seem a minor problem, it allows ciphertext produced by RC4 to be easily distinguished from ciphertext produced with random cipher systems and it lays the groundwork for a much larger result described below.
Several months later, Scott Fluhrer and colleagues found a devastating attack against a class of keys used in RC4 that leak information about the secret key. Unfortunately for WEP, the class of weak keys found by Fluhrer, Mantin, and Shamir were exactly those used by WEP (Fluhrer et al., 2001).
Fluhrer and his colleagues found that when RC4 is used with an initialization vector appended or prepended to the secret key, certain values of the IV produce a weak key. An adversary who collects enough of these weak keys passively through eavesdropping can recover the secret key in linear time with respect to the key size; in other words, an attack against 104-bit WEP is only slightly more difficult than an attack against 40-bit WEP. Furthermore, the attack relies only on the first byte of output from the RC4 pseudorandom generator, as determined by the equation: S[S[1] + S[S[1]]], where S is the S-box used in the implementation of RC4.
In most cases, determining the first pseudorandom byte would be difficult because of the variability of the underlying plaintext. But because WEP is used in an IP data-networking environment, the first byte of the vast majority of packets is 0xAA, a value in the LLC header. Thus, we have known plaintext and can easily recover the first pseudorandom byte.
Recovering the secret key now involves passively collecting enough packets of the form <keybyteindex+3, 0xFF, N>, where keybyteindex is the index of the secret key we are trying to recover and N is any byte value. This form of packet lets us guess the true key byte with an accuracy of 5%, and the trick is to collect enough such packets to ensure a correct guess. Fluhrer et al. estimate that approximately 60 such packets are required, and Stubblefield et al. (2002) found that 256 packets always selected the correct key byte. This process is iterated until all key bytes are determined.
Fluhrer et al. estimated they would need approximately four million packets to recover a 104-bit key. However, Stubblefield et al. implemented the attack and found they needed between four and six million packets to recover each key byte in an unoptimized attack. Stubblefield also optimized the attack so as to reduce the number of required packets to one million. Recovering this quantity of packets depends on the network load and can range from less than one hour in a moderately to heavily used network (300 or more packets per second) to several hours in a lightly used network.
In addition to the problems with RC4, WEP itself has a number of flaws running the entire range of field elements in the protocol.
WEP uses a pitifully small 24-bit IV space (224 or 16,777,216).[4] Assuming a moderate to heavy network load, this space is exhausted within a few hours and creates an IV collision—that is, the same <IV,K> pair is used to encrypt two different plaintexts. When multiple hosts share the same encryption key in a network, the time between collisions is obviously much shorter.
The consequence of an IV collision is significant with a stream cipher. Because of the linearity of the XOR combining function, deriving the underlying plaintext is much easier.
Given two ciphertexts produced with the same <IV, K> pair:
C1 = RC4(IV,K) ⊕ P1
C2 = RC4(IV,K) ⊕ P2
XORing the two ciphertexts together removes the pseudorandom stream generated by RC4 and produces the XOR of the two plaintexts (Borisov et al., 2001).
C1 ⊕ C2 = (RC4(IV,K) ⊕ P1) ⊕ (RC4(IV,K) ⊕ P2)
C1 ⊕ C2 = P1 ⊕ P2
The XOR of two plaintexts makes it significantly easier to recover the two plaintexts because of their well-known structure.
The WEP protocol provides no form of message authentication; thus, it allows intercepted messages to be replayed or sent again without modification (Borisov et al., 2001). While replaying packets will not permit an adversary to become a peer on the network, it can result in a significant denial-of-service attack and can also be used to reduce the cost of other attacks. This lack of message authentication also permits attackers to create man-in-the-middle attacks.
WEP uses a 32-bit CRC that is a linear function of the plaintext. Although WEP's RC4 encryption covers the ICV, the stream encryption also uses a linear combiner, XOR. As a result, we can manipulate an intercepted packet by flipping bits in the data and CRC portions of the packet to create a new—but still valid—packet with a different plaintext than the original (Walker, 2000; Borisov et al, 2001).
Recall how WEP produces ciphertext C by XORing the plaintext with the key stream. The attacker's goal in this attack is to produce a new ciphertext C´that decrypts to a new valid message with a valid ICV. Unfortunately, the attacker can accomplish this without knowing the value of the secret encryption key. Because both the RC4 encryption and the ICV are linear in nature, the attacker can modify an intercepted message by XORing the appropriate bits in the message portion of the ciphertext, and then calculating a new CRC of the changes and XORing this new CRC with the CRC portion of the datagram. The following equations, taken from Borisov et al. (2001), show this process mathematically.
C' = C ⊕ < Δ, CRC(Δ) >
C' = RC4(IV,K) ⊕ < M,CRC(M) > ⊕ < Δ, CRC(Δ) >
C' = RC4(IV,K) ⊕ < M ⊕ Δ, CRC(M) ⊕ CRC(Δ) >
C' = RC4(IV,K) ⊕ < M', CRC(M ⊕ Δ) >
C' = RC4(IV,K) ⊕ < M', CRC(M') >
The above derivation works because the WEP CRC is linear—that is, CRC(M) ⊕ CRC(Δ) = CRC(M ⊕ Δ). An example message modification is shown in Appendix B.
The research literature has not discussed the possibility of using active measures to speed the process of obtaining enough packets for a successful Fluhrer, Mantin, and Shamir attack. Obviously, active measures only make sense on lightly loaded networks.
The two possible approaches are simple. In the first and easiest approach, traffic analysis identifies an address resolution protocol (ARP) request packet. The ARP request is replayed continuously (remember WEP has no replay protection) until it collects enough packets from the ARP responses to determine the RC4 key. The second approach involves slightly more work. Here, we wait until we see an ARP request message and build upon it until it provides enough known plaintext to recover an adequate pseudorandom stream to forge Internet Control Message Protocol (ICMP) ping packets (Petroni, 2003). Ping packets are forged and the responses collected until the RC4 key can be collected.
Experimentation indicates that approximately 450 ping packets and replies can be sent per second between a station (STA) and an AP, and thus we can collect the required one million packets in approximately thirty-seven minutes. Of course, this attack fully loads the network, but if done during off-hours, it would likely remain unnoticed.
Several vendors, however, are now filtering most of the Fluhrer weak IVs in their firmware. This prevents the attacker from collecting enough weak IVs to recover the WEP secret key, but it reduces the cost of a previous attack against WEP, as described next.
This attack leverages several poor design aspects of WEP. The first is the lack of replay protection, the second is the nature of the CRC used, and the third is the fact that WEP is a stream cipher rather than a block cipher. The attack involves two steps (Arbaugh, 2001 and Petroni, 2003). The first step, or base phase, involves recovery of an initial amount of pseudorandom stream from traffic analysis (eavesdropping). The second step, the inductive phase, then forges messages with the recovered pseudorandom until a dictionary of all IVs is created.
During the base phase, we need to collect enough pseudorandom stream for a given IV so that we can begin to forge packets. The commonly used Dynamic Host Control Protocol (DHCP) makes this easy. We simply wait until we see a DHCP discover or request message that provides us with a base of known plaintext. This base is 38 bytes in length, composed of the following known elements:
| 6 bytes |
| 20 bytes |
| 8 bytes |
| 4 bytes |
[5] The 2 bytes of the UDP checksum are usually set to all zeros in most DHCP implementations. Thus, we do not need to calculate that field. | |
This provides us with a total of 38 bytes of pseudorandom stream, which is sufficient to forge ICMP echo request packets, also known as ping packets. We use a ping packet because it elicits a response from the targeted host, and it permits an arbitrary amount of data to be appended to the echo request.
Once we've recovered enough pseudorandom stream, we can begin the inductive phase. The inductive phase has two parts: recovery of the maximum transmission unit (MTU) and building the dictionary.
We need to recover a full MTU of the pseudorandom byte stream so we can recover a full MTU of the pseudorandom byte stream for every ping packet transmitted. The method that we use is the most complicated aspect of this attack, and it leverages the fact that the CRC provides redundant information about the underlying plaintext and the fact that WEP is a stream cipher rather than a block cipher. Our goal is to recover the MTU 1 byte at a time by guessing the next byte, and waiting for confirmation that we guessed correctly.
We begin by crafting a ping packet in a very specific fashion. We start with the 38 bytes recovered in the inductive phase, and we set n = 38. A proper ping packet without any additional payload is 34 bytes (38 bytes when the CRC or ICV is added), but we want to send a packet of 39, or n + 1 bytes. We do this by guessing the 39th byte and constructing the ping packet as shown in Figure 15.4.
We create a packet of n – 3 bytes (or 35 bytes—ping packet plus 1 payload byte). This is the data portion in Figure 15.4. We next calculate the CRC/ICV over this data portion, but we append only the first 3 bytes of the result. Now, we XOR this data with the n bytes of the pseudorandom stream, and prepend the IEEE 802.11 header and the appropriate IV, which results in a packet of n bytes. Finally, we guess the n + 1 byte and append it to the packet. Now, we have the specially crafted ping packet. We transmit it, and wait a small amount of time for a response. If we get a response, we know we guessed the correct n + 1 byte and we can proceed to recover the corresponding pseudorandom byte. If we don't get a response, then we guessed incorrectly and we continue to try the remaining 255 byte possibilities. Once we get a response, we need to recover the n + 1 pseudorandom byte, as shown in Figure 15.5.
Because the host we pinged responded with an ICMP echo response packet, we know that the byte we guessed was the correct ciphertext byte for our packet. We also know the corresponding plaintext byte—the fourth byte of the ICV that we didn't use in creating the packet. We now XOR these 2 bytes together (known plaintext with corresponding ciphertext), and we recover the n + 1 pseudorandom byte.
Now because we recovered the n + 1 pseudorandom byte, we continue this process (increasing n by one to recover the n + 2 pseudorandom byte) until we recover a full MTU—usually 1,500 bytes for Ethernet.
Once we've recovered the full MTU, we need to build a dictionary of all of the 224 (16,777,216) possible IVs used. This dictionary (assuming an indexed flat file) will be approximately 23.5 gigabytes—well within range of today's laptop computers.
The actual recovery of the pseudorandom stream for each IV leverages the fact that the ICMP echo response returns exactly the same data that was appended to the ICMP echo request. Thus, if we send a ping equal in size to the MTU, we'll get a response of exactly the same size. But, it will be encrypted with a different IV than the one in which we transmitted the IV. Therefore, we once again have known plaintext (the data we appended to the ping request) along with the corresponding plaintext. This permits the recovery of a full MTU's worth of pseudorandom for the returned IV. To build the full dictionary, we continue the above process until we have every IV.
The cost of the inductive chosen plaintext attack depends on how aggressive the attacker wants to be. We'll assume a moderately aggressive attacker in our calculations so we can approximate worst case for the defender.
In an implementation of the attack, the average time of recovery for a single byte in the inductive phase was 1.7 seconds/byte, and the average time to recover a full MTU (1,500 bytes) was 42.8 minutes. Once a full MTU is recovered, we need to build the dictionary. A current implementation of the attack recovers IVs at a rate of 11.5 msec/IV, or 53.7 hours to recover all 224 IVs with a single host—a fairly significant amount of time. However, building the dictionary is embarrassingly parallel and the total time to build the dictionary can be found by dividing 53.7 hours by the number of attacking hosts. Thus, an attacker using eight different hosts in the attack can reduce the time to around six hours—something to worry about, especially because the time required is completely independent of the key size. In other words, it takes approximately six hours to build the dictionary (or seven hours total) for both 40- and 104-bit WEP keys.
A number of vendors are now filtering IVs to protect against the multiple open source implementations of the Fluhrer et al. attack (see Chapter 16). The most aggressive filtering reduces the IV space by 6 bits to 218 (262,144)—a significant reduction in IV space, and a significant reduction in the overall time of the inductive chosen plaintext attack. The reduction in time occurs only with building the dictionary so we still must take 42.8 minutes to recover a full MTU. But now instead of taking over 53 hours to build the dictionary with one attacking host, we can build the dictionary in 50.3 minutes—a serious reduction in time and the size of the dictionary shrinks considerably as well.
Ironically, the countermeasure to one attack makes another attack significantly better—better in some respects than the attack the countermeasure was designed to prevent.
While the 1999 version of the IEEE 802.11 standard does not define a mechanism for access control, most implementations use MAC address-based access control lists. In addition, a major vendor has implemented a proprietary access control mechanism entitled Closed Network. This section describes the significant flaws found in each.
In theory, ACLs provide a reasonable level of security when we use a strong form of identity. Unfortunately, MAC addresses do not provide strong identity for two reasons. First, an attacker can easily observe MAC addresses because they must appear in the clear even when WEP is enabled. Second, some wireless cards allow their MAC address to be changed via software. As a result, an attacker can easily eavesdrop to determine valid MAC addresses and program the desired address into the wireless card, bypassing access control and gaining access to the network.
In most IEEE 802.11 wireless networks, the access point broadcasts the network identity using a text string called SSID. This allows a mobile device to search for specific networks by listening to broadcasts called beacons. The idea of the closed network is to treat the network name or SSID as a secret so the mobile device must have prior knowledge of the SSID before connecting. In practice, security mechanisms based on a shared secret are robust, provided the secrets are well protected when in use and when distributed. Unfortunately, although the SSID can be hidden in the beacon, there are several other management messages in IEEE 802.11 that contain the network name in the clear. (The actual messages containing the SSID depend on the vendor of the access point.) As a result, an attacker can easily sniff the network name to determine the shared secret and gain access to the network. This flaw exists even with WEP-enabled networks because management frames are not protected.
As previously discussed, the 1999 version of IEEE 802.11 provides only two forms of authentication. Obviously, the open method of authentication provides no security as all stations are permitted to associate. Unfortunately, although the shared-key authentication method was designed with security in mind, it is not secure.
An attacker can easily exploit the original IEEE 802.11 shared-key authentication through a passive attack by eavesdropping on one leg of a mutual authentication. The attack works because of the protocol's fixed structure, wherein the only difference between authentication messages is the random challenge, and the weaknesses in WEP (Arbaugh et al., 2001; Arbaugh et al., 2002). The attacker first captures the second and third management messages from the authentication exchange. The second message contains the random challenge in the clear, while the third message contains the challenge encrypted with the shared authentication key. Because the attacker now knows the random challenge P, the encrypted challenge ciphertext C, and the public IV, the attacker can derive the pseudorandom stream produced using WEPK, IVPR, with the shared key K and the public initialization variable, IV, as shown below:
The recovered pseudorandom stream, WEPK, IVPR, is the same size as the authentication frame because all the frame's elements are known: algorithm number, sequence number, status code, element ID, length, and the challenge text. Furthermore, all but the challenge text will remain the same for all authentication responses. The attacker now has all of the elements to successfully authenticate to the target network without ever knowing the shared secret K. The attacker requests authentication of the AP it wishes to associate/join. The AP responds with an authentication challenge in the clear. The attacker uses the random challenge text R and the pseudorandom stream—WEPK, IVPR—to compute a valid authentication response frame body by XORing the two values together. The attacker then computes a new ICV, as described by Borisov et al. (2001). Finally, the attacker responds with a valid authentication response message and associates with the AP to join the network.
The basic concept of man-in-the-middle (MiM) attacks was introduced in Chapter 4. In this section, we discuss the details of how exactly an attacker could establish a man-in-the-middle attack against your wireless network. There are two different methods to establish a man-in-the-middle attack in a wireless network. The first is using management frames and is specific to wireless networking, and the second is ARP spoofing, which is also a problem for wired networks.
Because the management frames lack any integrity protection, establishing a man in the middle with IEEE 802.11 based networks is easy (there's even a hacker tool that will do it for you, described in Chapter 16). MiMs can be established regardless of any protections (WPA, RSN, VPN, and so on) that you might be using but do not necessarily pose a threat if the security protocol is strong. MiM attacks are possible because there are no integrity guarantees provided at the link layer (layer 2), and MAC addresses are easily forged.
The attack begins (assuming that the target STA is already associated to an AP) by the attacker issuing a Deauthentication message to the target STA. This causes the STA to drop its association with its current AP and look to reassociate with another (possibly the old) AP. At the same time, the attacker establishes a malicious AP with the same ESSID and MAC address as an AP within range of the attacker but on a different channel than the valid AP. The target STA associates with the attacker's fake AP because it is denied service at the valid AP by the attacker's forged Deauthentication messages. Once the STA has associated with the bogus AP, the bogus AP immediately associates with the valid AP and begins forwarding all traffic so authentication (if used as in WPA or RSN) completes. This process is shown in Figure 15.6. The attacker now has complete control over the traffic stream between the STA and its valid AP. If encryption is not used, then the attacker can modify packets before forwarding. If encryption is used, packets can be denied or delayed. They can also be modified to assist in other attacks, as we'll see later in this chapter.
ARP spoofing has been a plague on wired networks for some time; and while there are some limited countermeasures available to prevent and identify ARP attacks, an ARP attack can still succeed more often than not. ARP identifies the MAC address for a given IP address. A client or STA wanting to communicate with a specific IP address issues an ARP-Request as a broadcast packet on the LAN asking to learn the MAC address of the given IP address. Because ARP packets do not have any integrity protection, anyone (even attackers with access to LAN) can respond with incorrect or malicious information, effectively poisoning the ARP cache of the requestor. Thus, from that point until the cache entry times out, the client uses an improper MAC address for the given IP address, causing all traffic to go to the attacker rather than the real recipient.
There is an important distinction between using management frames (as described in the previous section) and using ARP spoofing for establishing MiM attacks. With ARP spoofing, the attacker must have access to the link layer, whereas using management frames does not have this requirement. If encryption is being used, the attacker must first break the encryption (or be able to forge packets) before he can perform a successful ARP spoofing attack. With WEP-based networks, breaking the encryption, as we have seen, is a small problem. But with WPA- or RSN-based networks, this is a significant (and hopefully impossible) hurdle.
Because the attacker can inject himself between communicating parties (the STA and AP) in a man-in-the-middle attack, the attacker has the ability to completely control the content of the communications (if encryption and message authenticity are not used); and even if encryption and/or message authenticity is used, the attacker can still deny or delay communications.
This section examines two different problems that occur because of MiM attacks. In the first case, the attacker can hijack, or take over, a session; even when robust authentication and access control are used without encryption. In the second case, an MiM attack eliminates the protection afforded by the use of an encrypted tunnel.
Shortly after the IEEE 802.1x protocol was defined, a large number of users were considering using it for authenticating users at hotspots without using WEP. While in theory this is a good idea, using 802.1x this way didn't solve any problems (Mishra and Arbaugh, 2002). Essentially, the attacker simply waits until the STA is completely authenticated and then sends a forged Disassociate or Deauthentication management frame to the STA. At this point, the STA believes it no longer has a session and attempts to reconnect (the attacker can continue to send forged management frames to the STA, keeping it from establishing a session). The AP, on the other hand, believes there is still a session, and the attacker can now use that session, masquerading as the STA up until a reauthentication event takes place—usually in five minutes.
Finally, we earlier discussed in Chapter 9 the problems with EAP and so we won't duplicate that discussion here.
PEAP was designed to protect the EAP exchange from eavesdroppers (see Chapter 9). There were two reasons for this. The first was to provide privacy and allow users to remain anonymous to eavesdroppers because traffic analysis can be a significant threat in some cases, and the second was to provide protection for the EAP control messages EAP-Success and EAP-Failure. Unfortunately, an easy MiM attack eliminates all of the protection provided by PEAP when anonymous connections are supported.
In the first phase of PEAP, an anonymous tunnel is established between the STA and the AP, with the STA sending an anonymous identity if it likes. If the STA sends an anonymous identity, then it cannot be authenticated. A TLS tunnel is created nonetheless with the anonymous credentials, and phase 2 is started, which is a normal EAP session.
The attack against PEAP works by establishing the MiM prior to phase 1 of PEAP. The attacker establishes two different anonymous tunnels. The first (PEAP phase 1) is with the AP, and second (PEAP phase 1) is with the STA. In the first tunnel with the AP, the attacker masquerades as the STA, and in the second tunnel the attacker masquerades as the AP. The STA now begins phase 2 and the attacker sees the true identity information of the STA as well as having the ability to forge EAP control messages—just as if PEAP were not being used (Asokan et al., 2003).
We've made denial-of-service attacks into a separate section for several reasons. First, denial-of-service attacks are extremely difficult to protect against, and especially so with wireless. Any attacker with a bigger amplifier, antenna, or using more power, can deny service to an individual or group at the RF level. As a result, RF attacks are difficult but not impossible to prevent. The military, for instance, uses spread spectrum, frequency hopping, and probably ultrawide-band systems to mitigate the possibility of an attacker jamming important frequencies. We don't have that luxury because our equipment is readily available to our attackers. Therefore, RF-based denial-of-service attacks against IEEE 802.11-based networks (and actually any consumer wireless standard) are nearly impossible to prevent. An attacker with the know-how and access to the right equipment can mount a denial-of-service attack against your wireless network.
Another class of denial-of-service attack against the network and cryptographic protocols, specifically layer 2 or the MAC layer, is preventable. Unfortunately, neither the old nor the new Wi-Fi standards opted to protect against this form of attack—TGi debated the cost of protecting against layer 2 denial-of-service attacks, but opted for downward compatibility with the old standard rather than protection against denial-of-service attacks.
You may have noticed that the management frames, for example, Associate-request, don't have any integrity protection. That is, these frames can easily be forged by an attacker. An attacker can deny service to a station/client or to an entire access point, and in some cases across a LAN.
The attack is trivial with the right software (see Chapter 16). If the attacker wishes to prevent a station from using the Wi-Fi LAN, he has several choices. First, when the attacker can see the AP to which the station is associated, he simply forges a Disassociation or Deauthentication frame and sends it to either the AP or STA. The AP/STA, thinking that the station wishes to leave (or the AP no longer can service the STA), grants the request and closes the association. Unfortunately, both of these management frames (Disassociation and Deauthentication) permit the attacker to use the broadcast MAC address as the target. This results in all stations associated with the targeted AP being knocked off the AP.
Second, the attacker can deny service to a station when he can see an AP on the same wired LAN as the AP to which the target station is associated. In this case, the attacker sends a forged Association-request message with the target station's MAC address to an AP on the same wired LAN. The AP that receives the association request approves (because we don't authenticate until after association) it and sends out a layer 2 update frame to the wired LAN. The router or switch now begins forwarding traffic to the AP that just sent the layer 2 update, and the actual station no longer receives any traffic. Obviously, both of these attacks need to be constantly run to prevent service to a particular station, and this is one of the reasons why TGi opted not to protect against it.
Another method of denying service to a group is similar and involves loading up an AP with bogus stations such that the resources on the AP are exhausted and the AP either reboots or no longer permits new stations to associate to it.
TGi decided not to protect against these attacks because the majority of the participants felt that a determined attacker can always resort to an RF-based attack. The majority of the members of TGi also were concerned with potential problems with backward compatibility if integrity protection were added to management frames. Unfortunately, these attacks have been implemented in an open source tool (see Chapter 16).
Michael is a lightweight message authenticity algorithm (see Chapter 11). Because Michael provides only 20 bits of protection against message modification attacks, countermeasures were designed to prevent active attacks. These countermeasures are effective at preventing the creation of a forged message. However, they also introduce the potential for a denial-of-service attack against the entire AP.
A capable attacker can accomplish the WPA denial-of-service attack. The attack isn't trivial to accomplish, but it doesn't require rocket science either. Essentially, the attacker must accomplish three tasks. The first is to stop a valid packet from reaching the AP, and then, second, to modify the packet such that the ICV remains valid. The third and final task is to send the modified packet before a packet with a higher TSC is received by the AP.
Accomplishing all three tasks is easy once a man-in-the-middle attack is established between the AP and an STA. Because the attacker controls the connection between to the STA and AP, he can easily perform the first and third tasks. Performing the second task requires applying what we discussed earlier in this chapter and is shown in Appendix A to modify the message.
Once the attacker sends two such modified packets to the AP within a minute, the AP shuts down for exactly one minute, preventing traffic from all stations associated with the AP from communicating. The AP must also rekey stations immediately upon beginning service after the one-minute delay.
While this is a particularly brutal DoS attack, the same results are obtained by using a much easier attack—the management frame DoS described earlier.
Unfortunately, none of the original security mechanisms in IEEE 802.11 wireless local networks were robust. Adversaries easily bypass both the access control mechanisms and the shared-key authentication mechanism. Serious flaws in the WEP encapsulation process allow recovery of the secret encryption key and the malicious modification and replay of WEP-protected datagrams. Each of these problems alone poses a significant threat to deployed wireless networks—together, they make exploiting wireless networks easy.
Fortunately, both WPA and RSN prevent the confidentiality, integrity, and access control attacks (see Chapter 7). Unfortunately, however, neither WPA nor RSN prevents denial-of-service attacks using forged management frames. The topic was hotly debated during several TGi meetings, and the consensus of the task group, not necessarily the authors, was that DoS attacks are a fact of life in wireless networking and that protecting the management frames would create downward compatibility problems.
[1] The cryptographic and security community use the acronym MAC while the IEEE uses MIC (message integrity check). The reason the IEEE uses MIC is that the acronym MAC was already in use. In this chapter, we use MAC.
[2] How this polynomial is selected is beyond the scope of this book.
[3] Given ciphertext produced by an unknown system, a cryptanalyst uses a distinguisher to identify the cryptologic, or algorithm, that produced the given ciphertext.
[4] An interesting side note is that the attack by Fluhrer, Mantin, and Shamir would have been easier if the IV space were larger—solving one problem makes another worse. This is a good example of why security is difficult.