Attacks Without Keys

Getting the keys is the ultimate success for an attacker, but it's surprising how much information can be obtained without ever needing to compromise the keys. In some cases it's possible to completely breach security. In this section we look at a few of the activities attackers might perform as an alternative to key attacks.

Snooping

First, consider snooping. Let's imagine you are an attacker within range of your target a Wi-Fi LAN that is using secret keys and hence is encrypting messages in some way. Let's also assume you have a modified Wi-Fi card designed to intercept data. You have a lot of knowledge about IEEE 802.11 protocols as well as higher-level protocols like TCP/IP. "You" may be a very clever person with a PhD in communications…or in this context, "you" may be a sophisticated program running on the laptop of a total moron. Either way, the question is, what can be seen?

First of all, you can see and read all the information coming from the access points.[2] Therefore, you know the network name (or SSID). If the network name is something obvious like "accounts_department," you can get an idea of what the users on the network might be doing. You have most likely identified the manufacturer of each access point by looking at its MAC address, and you may even know the model number based on the capabilities or proprietary information that each includes in its beacons. If that model has any hidden flaws, that information might be useful. Some security advisers propose disabling SSID broadcasts; but while this step may reduce "war driving" attacks (see Chapter 3), it provides only a short-term advantage, as the information will be discovered as soon as a new user connects to an access point.

[2] Access points transmit regular beacon messages advertising various pieces of information. This is covered in detail in Chapter 5, "IEEE 802.11 Protocol Primer."

As an attacker, you may also see quite a bit of data going to and from an access point. By watching for a while, you will be able to count how many wireless devices are connected to each access point (just by looking for different MAC addresses). You will also be able to identify the manufacturer of the wireless adapter in each case from the first three bytes of the MAC address. If the network is using WEP, you might be able to see whether everyone is using the same key (shared) or whether each device has a separate key by looking at bits in the IEEE 802.11 header. That information could be useful later.

So far, it has been easy. But when you capture any of the data packets, you cannot interpret them because they are encrypted. We are not considering attempts to decrypt the packets here because that is an attack on the secret key and is covered in the next section. So if you are not going to try to crack the code, can you do anything useful?

You can, using a technique called traffic analysis. Traffic analysis is the study of message externals, for example, frequency of communication and size. So, the first thing is to watch the size of the packets. You should be able to identify which protocol they are using by checking the length. For example, certain TCP/IP messages, such as acknowledgment frames, have a fixed length and occur with a typical regularity. This applies to other protocols, too, so the length of the packets can tell you the network protocol in use. Let's suppose it is TCP/IP. You can look out for messages such as DHCP discover messages that are used to give IP addresses to the network.

You can also get information from the timing of messages. By watching messages go to the network from a user and timing when messages come back, you can probably guess whether that user is browsing the Web or working on a local server. Even the amount of data being sent around might give a clue as to what is happening. For example, a sudden increase in activity might mean that the payroll is being prepared or that a shipment is being prepared. Unfortunately, it is possible to learn a whole lot about the types of things going on in a network just by watching packet lengths and noting timing without looking inside the packets. However, you cannot see anything really useful, such as the message content. Like the voyeur watching the neighbor's window when the blind is down, you'll see shadows that tell you whether someone is "in the room," but nothing more.

So, by itself, snooping an encrypted LAN can only provide information about how, when, and by which devices the network is being used. This information by itself is of limited use; but combined with other information the attacker might gain from other methods or sources, it can be very helpful. So now let's look at the prospects for combining snooping and modification.

Man-in-the-Middle Attack (Modification)

Suppose two people are communicating traditionally in security literature, they are called Alice and Bob. Alice receives messages from Bob and Bob receives from Alice. Suppose there is an attacker able to intercept and cut off the communications. Suppose that the attacker can imitate Bob while sending to Alice and imitating Alice while sending to Bob. In this case Alice and Bob are subject to a "man-in-the-middle" attack, as shown in Figure 4.1. Such attacks can be used to modify messages in transit without detection.

Figure 4.1. Man-in-the-Middle-Attack

graphics/04fig01.gif

There are (at least) two ways to modify a message: you can modify it on the fly or you can capture, modify, and replay the message, a technique known as store and forward. Modification on the fly is really hard. You would need to send a burst of radio transmission at just the right moment to cause the receiver to interpret a bit incorrectly. Because of the sophisticated modulation used in Wi-Fi LANs, bits are not sent individually but in groups coded together, making it very difficult to change a single bit at a time. Therefore, we will, for the moment, assume that any modification occurs due to a store-and-forward approach by the attacker; on-the-fly modification might be possible in theory, but we won't cover the topic any further.

The store-and-forward method is called a man-in-the-middle modification attack. The principle is simple enough in wired networks: an attacker cuts the wire, receives all the data, and is careful to send it on so the two devices at the ends don't know their data is being intercepted. There is, for example, a man-in-the-middle attack possible at every forwarding router in the Internet, which is one reason the Internet is treated as totally insecure.

In Wi-Fi LANs a man-in-the-middle attack is a little more difficult to mount because there is no wire to cut. The enemy must stop the receiver from getting the message on the initial transmission so he can then forward it after exercising his evil intent. The procedure could work something like this. To become a man-in-the-middle between mobile device (Mob) and the access point (AP), the enemy must:

  1. Listen for a message from Mob to AP.

  2. Read in the message up to the checkword[3] at the end.

    [3] The checkword is used by the receiver to detect any errors in the data.

  3. Transmit a sudden burst of noise to corrupt the checkword this causes AP to drop the message as invalid, but the attacker now has a copy of the valid message.

  4. Forge an acknowledge message with AP's address and send it to Mob; now Mob thinks the message has been received by AP.

  5. Recalculate the correct checkword and send the captured message to AP; AP thinks it came from Mob.

  6. Wait for an acknowledgment message from AP and send a burst of noise so Mob ignores it and doesn't see two acknowledgments for the same packet.

Clearly, this procedure is not simple, but it is absolutely feasible and would effectively put the attacker in the middle of the communications. Neither the access point nor the mobile device would have any idea that the communications were intercepted.

Another approach and one that is much more likely to occur would be for the enemy to set up a bogus access point. The bogus AP identifies a real AP in advance. When an unwitting mobile device sees the bogus AP and tries to associate, the bogus AP simply copies all the messages it receives to the valid AP, substituting its own MAC address. Similarly, it copies all the messages received from the good AP back to the mobile device. By this method, it doesn't need to know the encryption keys because the MAC address fields that it modifies are not encrypted. As a result, all the data between the mobile device and the good AP goes through the bogus AP en route.

Once the enemy is established in the middle of a communication, he has the opportunity to mess with the data. Remember that this intervention is possible even when the data is encrypted and without the enemy knowing the secret keys. The question is, what can modification achieve without the attacker knowing the keys?

There is really very little that can be accomplished by modifying individual messages, unless you have some knowledge about the contents of the messages before they were encrypted. The enemy has some information about most packets because the TCP/IP header has a fixed format and some of the fields have fixed or obvious values (such as the length field). The attacker might like to modify the destination IP address to try to get the data sent out over the Internet (to him). This is a really hard attack to accomplish, however, and it is quickly detected by the sender because it would be hard (but not impossible) to get a response back.

More can be achieved if the attacker is allowed to replay captured messages. For example, suppose the attacker spots an ICMP message going from the mobile device to the network server. An ICMP message is a short administrative message sent between devices in a TCP/IP network. The attacker could guess what the ICMP message type is from the length. Many ICMP messages require a response from the server that the enemy will also see (although it is still encrypted). Remember that the enemy can't read either message but can make an educated guess at much of the content. Furthermore, if the enemy can send the same encrypted ICMP message again, the server might come back with a response every time thinking it came from the valid device.

Now the attacker can play games. The ICMP message contains a checkword. If the attacker changes a single bit and resends the message, after decryption the checkword will indicate an error and the message will be thrown away. The attacker will notice that there was no reply from the server. So what if the attacker can modify both a data bit and some of the checkword bits? If he is allowed to try over and over, maybe tens of thousands of times, eventually the enemy will find a combination that gets a response from the server again. By playing this game, an attacker could eventually decode the message. At the end of several hours, he has found out the IP address of the mobile device and the server. For a fuller description of this attack, see Borisov et al. (2001). Although this is a potentially successful attack, it's no big deal. A lot of work would be required for a relatively small amount of information. However, even a small crack cannot be considered acceptable in a security system. As in a dam wall, small cracks can lead to real breaches and eventually the collapse of the system.

Active attacks are sometimes difficult to carry out, and they run the risk of being detected. Nonetheless, against some systems, WEP being one of them, active attacks can accomplish a great deal for the attacker. However, the new security methods of WPA and RSN are resiliant to such attacks. This is one reason why most attackers will try to get the keys. With the exception of DoS attacks, attacks without keys are generally used only as a step toward determining the keys. Once an enemy has the keys, your only hope is to detect the intruder, shut down the network, and change the lock.



Real 802.11 Security(c) Wi-Fi Protected Access and 802.11i
Real 802.11 Security: Wi-Fi Protected Access and 802.11i
ISBN: 0321136209
EAN: 2147483647
Year: 2005
Pages: 151

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net