 |  |
4.8. Attacks Based on Low-Level Protocol Details
As we've discussed protocols, we've also mentioned some of the attacks against them. You will often see attacks discussed using the names given to them by the people who wrote the original exploit programs, which are eye-catching but not informative. These names multiply daily, and there's no way for us to document them all here, but we can tell you about a few of the most popular. In fact, although there are dozens and dozens of different attacks, they are pretty much all variations on the same few themes, and knowing the name of the day isn't very important.4.8.1. Port Scanning
Port scanning is the process of looking for open ports on a machine, in order to figure out what might be attackable. Straightforward port scanning is quite easy to detect, so attackers use a number of methods to disguise port scans. For instance, many machines don't log connections until they're fully made, so an attacker can send an initial packet, with a SYN but no ACK, get back the response (another SYN if the port is open, a RST if it is not), and then stop there. (This is often called a SYN scan or a half open scan.) Although this won't get logged, it may have other unfortunate effects, particularly if the scanner fails to send a RST when it stops (for instance, it may end up being a denial of service attack against the host or some intermediate device that's trying to keep track of open connections, like a firewall).Attackers may also send other packets, counting a port as closed if they get a RST and open if they get no response, or any other error. Almost any combination of flags other than SYN by itself can be used for this purpose, although the most common options are FIN by itself, all options on, and all options off. The last two possibilities, sometimes called Christmas tree (some network devices show the options with lights, and it makes them all light up like a Christmas tree) and null, tend to have unfortunate side effects on weak TCP/IP stacks. Many devices will either crash or disable TCP/IP.
4.8.2. Implementation Weaknesses
Many of the attacks that work at this level are denial of service attacks that exploit weaknesses in TCP/IP implementations to crash machines. For instance, teardrop and its relatives send overlapping fragments; there are also attacks that send invalid combinations of options, set invalid length fields, or mark data as urgent when no application would (winnuke).
4.8.3. IP Spoofing
In IP spoofing, an attacker sends packets with an incorrect source address. When this happens, replies will be sent to the apparent source address, not to the attacker. This might seem to be a problem, but actually, there are three cases where the attacker doesn't care:
- The attacker can intercept the reply.
- The attacker doesn't need to see the reply.
The attacker doesn't want the reply; the point of the attack is to make the reply go somewhere else.
4.8.3.1. The attacker can intercept the reply
If an attacker is somewhere on the network between the destination and the forged source, the attacker may be able to see the reply and carry on a conversation indefinitely. This is the basis of hijacking attacks, which are discussed in more detail later. Figure 4-6 shows an attacker using a forgery this way.
Figure 4-6. Attacker intercepting replies to forged packets
4.8.3.2. The attacker doesn't need to see the reply
An attacker doesn't always care what the reply is. If the attack is a denial of service, the attacked machine probably isn't going to be able to reply anyway. Even if it isn't, the attacker may be able to make a desired change without needing to see the response. Figure 4-7 shows this kind of attack.
Figure 4-7. Attacker using forged packets for denial of service
4.8.3.3. The attacker doesn't want the reply
Several attacks rely upon the fact that the reply (or better yet, lots of replies) will go somewhere else. The smurf attack uses forged source addresses to attack the host that's the apparent source; an attacker sends a forged packet to some host he or she doesn't like very much (call it "apparentvictim") with a source address of a host that he or she doesn't like at all (call it "realvictim"). "apparentvictim" then replies to "realvictim", tying up network resources at both victim sites but not at the attacker's actual location. The administrators at "apparentvictim" and "realvictim" then start arguing about who is attacking whom and why. This attack has a number of variants using different protocols and methods for multiplying the replies. The most common protocols are ICMP echo and the UDP-based echo service, both of which are discussed in Chapter 22, "Administrative Services". The most common method of multiplying the replies is to use a broadcast address as the source address. Figure 4-8 shows this kind of attack.
Figure 4-8. Attacker using forged packets to attack a third party
The land attack sends a packet with a source identical to the destination, which causes many machines to lock up. Figure 4-9 shows this kind of attack.
Figure 4-9. Attacker using looped forged packets
4.8.4. Packet Interception
Reading packets as they go by, frequently called packet sniffing, is a frequent way of gathering information. If you're passing around important information unencrypted, it may be all that an attacker needs to do.In order to read a packet, the attacker needs to get the packet somehow. The easiest way to do that is to control some machine that the traffic is supposed to go through anyway (a router or a firewall, for instance). These machines are usually highly protected, however, and don't usually provide tools that an attacker might want to use.
Usually, it's more practical for an attacker to use some less-protected machine, but that means that the attacker needs to be able to read packets that are not addressed to the machine itself. On some networks, that's very easy. An Ethernet network that uses a bus topology, or that uses 10-base T cabling with unintelligent hubs, will send every packet on the network to every machine. Token-ring networks, including FDDI rings, will send most or all packets to all machines. Machines are supposed to ignore the packets that aren't addressed to them, but anybody with full control over a machine can override this and read all the packets, no matter what destination they were sent to.
Using a network switch to connect machines is supposed to avoid this problem. A network switch, by definition, is a network device that has multiple ports and sends traffic only to those ports that are supposed to get it. Unfortunately, switches are not an absolute guarantee. Most switches have an administrative function that will allow a port to receive all traffic. Sometimes there's a single physical port with this property, but sometimes the switch can turn this function on for any port, so that an attacker who can subvert the switch software can get all traffic. Furthermore, switches have to keep track of which addresses belong to which ports, and they only have a finite amount of space to store this information. If that space is exhausted (for instance, because an attacker is sending fake packets from many different addresses), the switch will fail. Some of them will stop sending packets anywhere; others will simply send all packets to all ports; and others provide a configuration parameter to allow you to choose a failure mode.
Some switches offer increased separation of traffic with a facility called a Virtual Local Area Network (VLAN). On a normal switch, all the ports are part of the same network. A switch that supports VLANs will be able to treat different ports as parts of different networks. Traffic is only supposed to go between ports on different VLANs if a router is involved, just as if the ports were on completely separate switches. Normal tricks to confuse switches will compromise only one VLAN. VLANs are a convenient tool in many situations, and they provide a small measure of increased security over a plain switched network. However, you are still running all of the traffic through a single device, which could be compromised. There are known attacks that will move traffic from one VLAN to another in most implementations, and almost any administrative error will compromise the separation. You should not rely on VLANs to provide strong, secure separation between networks.
