Unauthorized Activity I

Overview

In Chapter 2 we looked at the normal processes that occur in network communication. In this chapter, we will examine abnormal network traffic patterns and the problems that they can create or mask.

Some of the problems are intrinsic to the design of the Internet, which was not developed with security as a primary goal. The original Internet design was based on cooperating, friendly hosts communicating over secure lines. The main concern was robustness of traffic delivery in the face of outages, and routing protocols were developed to automatically reroute traffic when outages occurred.

Other network-level communication security problems occur in so-called “dark corners” of the specifications. Although much effort was devoted to specifying standard behavior for participating hosts, there is enough wiggle-room in some areas to allow for differing interpretations of the standards.

Also, not to be forgotten is the bug-prone nature of complex systems, of which the TCP/IP stack is a prime example. Some systems may crash or exhibit other anomalous behavior when confronted with illegal input. The Nmap tool has been developed for mapping operating systems, based on network stack behavior under these odd conditions, which can often distinguish between operating system patch levels, as bugs are corrected, and new or different behavior is noted.

Generally, there are two classes of network attacks of interest to an IDS. First, there are the network-level attacks, corresponding to the session layer and below on the OSI reference model, which attempt to subvert, disrupt, or gather information on the transport of data from source to destination. Some of these attacks are examined in this chapter.

The other main division of network attacks, corresponding to the presentation layer and above, are the application-level attacks, in which the transport mechanism is not subverted, but instead is used to transfer attack data to and from the target host. Again, the goal is to subvert, disrupt, or gather information on targeted systems. Some of these attacks will be discussed in Chapter 4.

General IDS Limitations

Some important applications straddle the line between the network level and the application level. These notably include IDS applications and firewalls, which are applications that must be intimately familiar with the lower-level workings of network protocols. As these applications exist to protect important computer assets (and, in fact, are important assets themselves), some attacks specifically target, disable, or evade these mechanisms. As a consequence, users of these applications expect them to be robust, as they need to be able to handle the onslaught of malicious traffic.

One type of attack that firewalls and IDS systems can be prone to is an attack based on resource exhaustion. Every system has memory, CPU, or bandwidth limitations, and by causing one of these limited resources to be completely expended, the operation of the system will be degraded, and it may possibly fail. This problem is not confined to these perimeter defense mechanisms, but because they are so critical, failures in these systems have a much more devastating effect on security than normal attacks.

In order to track connections, firewalls and IDS applications generally need to establish a connection record for each active connection as it is established. If excessive connection requests are made, one of the critical resources (memory, CPU, or bandwidth) may be entirely consumed. Hackers use the SYN flood technique to create this type of denial-of-service (DoS) attack.

In a perfect world, IDS and firewall applications would function without fail, within the limitations of their hardware. In practice, bugs have been discovered, and hackers have exploited them. One popular IDS had a vulnerability concerning fragmented packets that could result in an attacker gaining root access to the IDS box. Another less well-known IDS had a vulnerability in its memory allocation functions, such that specially crafted packets could cause it to crash by consuming excessive CPU cycles.

Many IDS systems make marketing claims in their sales literature about the maximum bandwidth that they can handle. As is common in the computer industry, such marketing claims need to be taken with a grain of salt—they typically describe ideal situations and generally do not reflect real-world usage. Currently there are no IDS systems that can keep up with a full gigabit connections, so flooding a network connection with traffic is another technique that can cause an IDS or firewall to fail, or to miss certain attacks.

Network Protocol Abuses

This chapter focuses on abuses of the protocols that drive the Internet, from the bottom of the OSI model up to the session layer. (The presentation and application layers are covered in Chapter 4.) Because the higher layers depend on those below them, it is easy to imagine that a subversion of lower-level protocols will have a profound impact on the higher levels. Fortunately, though, most of these subversions cause a denial of service, meaning that some or all of the services depending on these lower levels will fail or will show degraded performance.

There are, however, classes of attacks that attempt to spoof, or fake, legitimate traffic. Under some circumstances, systems may believe that the traffic is indeed legitimate, and they may respond in a trusting manner to traffic that is, in fact, generated by a malicious party. We will look at attacks and abuses as they affect the various networking protocols: ARP, IP, UDP, TCP, and ICMP.

ARP Abuses

As was discussed in Chapter 2, ARP (Address Resolution Protocol) is used by hosts to determine the hardware address corresponding to a desired IP address so that systems can communicate. There is no authentication of either the request or the response, so it is fortunate that ARP requests are confined to the local subnet. However, if a system is compromised by an intruder, they may wreak havoc on that subnet with a variety of abuses, such as ARP flooding, MAC spoofing, and ARP spoofing.

ARP Flooding

Before we discuss why flooding a network with spoofed ARP packets has security implications, we should discuss the differences between switched and unswitched networks.

Unswitched networks, built on Ethernet hub technology, transmit all traffic to all ports on the hub. The hub itself is a relatively unsophisticated device that merely regenerates the traffic to all ports and resolves packet collisions. ARP packets go to all hosts connected to the hub.

A switched network, by contrast, uses an Ethernet switch, which attempts to deliver traffic to only those ports where the communicating hosts reside. The advantage of this, of course, is the decreased network traffic that hosts must deal with, because they only see the traffic addressed to systems on that switch port. The hosts do not see traffic destined for hosts on different switch ports. For practically all applications, this is an unalloyed win. The only applications that could possibly suffer under this system would be those that expect or desire to see all of the traffic traversing the switch.

The method that a switch uses to determine the routing of traffic is entirely passive—it maintains a cache of ARP responses that it has seen traversing the network, and it routes traffic addressed to a specific hardware address to the port that it saw the ARP response come from. When a switch is confronted with a packet addressed to a hardware address that it hasn’t cached, it must temporarily revert to “hub” mode and send that packet to all ports on the switch. The port that responds is recorded in the ARP cache.

As with other real-world device, there are limitations on the number of entries that a switch can keep in its ARP cache. If the cache is full, and a packet referencing a previously unknown hardware address is seen, a switch has several possible strategies to continue functioning, albeit at a degraded performance level:

• The switch could simply revert to hub mode for those hardware addresses that aren’t in its cache. Performance will suffer, but traffic will continue to be delivered.
• The switch can simply decide to flush its buffer and repopulate from new data received. Under this scenario, packets will be delivered in hub mode until the switch relearns the port locations of the hosts.

Under either of these scenarios, traffic destined to specific ports will “leak” and be seen by other ports. This traffic is of potential interest to attackers, who may run the type of application that benefits from this leakage—one that “sniffs” the wire for traffic destined for other hosts. A sniffer application will silently listen to all (or selected) packets on the wire and record them for later perusal by the hacker. Passwords, confidential information, or other sensitive data may be recorded. Clearly, this is a major problem, as a stealthy hacker could remain on a system and quietly record this information for an extensive period without detection.

All of this means that on a switched network a hacker can possibly gain access to more network traffic than you might expect by creating a flood of spoofed ARP reply packets, overflowing the switch’s ARP cache, and thus forcing it into hub mode.

MAC Spoofing

Traffic can be disrupted on a network if two Ethernet adapters have exactly the same hardware (or MAC – Media Access Control) addresses. If all adapters are from major, recognized vendors, this problem is unlikely to occur, as each vendor is assigned a block of addresses from which they assign a unique address to each card manufactured. However, bargain basement or offshore manufacturers have been known to hijack addresses from other manufacturer’s address ranges. In practice, even this is unlikely to cause a conflict, as there are 248 (over 280 trillion) separate hardware addresses available, and all that is required is that the hardware addresses of systems on the local subnet be unique.

Most people are surprised to discover that practically every Ethernet adapter can be reprogrammed to have any desired hardware address. Although this reprogramming is rarely done, except in cases where a software license is tied to the hardware address, hackers can reprogram the Ethernet adapter on a system to spoof that of another system on the network (hence the term MAC spoofing), which typically will result in neither system being able to communicate. If the hacker chooses the same hardware address as the local router, all communication outside the subnet will be disrupted.

ARP Spoofing

Along the same vein as MAC spoofing, ARP response packets can be spoofed to redirect traffic or disrupt it. Imagine that system A wants to communicate with system B, so it sends out an ARP request asking, in effect “Whoever has B’s IP address, please send your hardware address.” A hacker on system C who sees this request could spoof an ARP response packet saying “I’m B—here’s my hardware address,” but inserting C’s hardware address instead. Of course, unless system B is prevented from responding, it is likely to respond as well. Which system A actually ends up communicating with depends on the timing of the responses seen by A.

Clever hackers can combine this ARP spoofing with a denial-of-service attack on system B to prevent it from responding, possibly using a SYN flood, or source-quench flood (both of which are discussed later in this chapter). By combining several network attacks in this manner, the hacker on system C may convince system A that system C is really system B, and may therefore be able to subvert system A. A hacker could also forward the (now snooped) traffic to system B, so that A and B are less likely to notice anything wrong. There are a number of tools that help in this sort of attack—one of the best is the dsniff arpspoof tool by Dug Song.

IP Abuses

IP is the unreliable transport protocol used to carry all the upper-level protocols on the Internet. IP provides the transport and delivery of datagrams but does not provide mechanisms to verify that datagrams from a host are actually from that host. In actuality, this is an almost impossible problem to solve, as nearly every host has the capability of acting as a router, and thus could be legitimately forwarding traffic on behalf of another system. This model, therefore, allows for the possibility of faking (or spoofing) the source or destination of packets.

IP Address Spoofing

In a perfect world, all ISPs would perform ingress and egress filtering to ensure that packets entering or exiting their network actually are addressed to hosts in their address space. Unfortunately, improper configuration, among other factors, is responsible for the problem of IP address spoofing. Border routers are often not configured to reject traffic to or from the networks behind the router.

Ingress and Egress Filtering

There are some IP addresses which should not, under normal circumstances, be seen crossing the perimeter to or from the Internet. The term ingress filtering refers to the process of filtering our obviously bogus addresses entering into a network, while egress filtering refers to outbound traffic. A simple example would be that an enterprise with public IP space on the internet should reject all traffic claiming to be from their address space, but coming from the external Internet. Similarly, the same enterprise should filter all outbound traffic, and only allow traffic with source addresses in their IP space to exit the perimeter. Generally, the RFC 1918 addresses are also filtered in- and out-bound.

For instance, suppose your business uses an address range of 172.16.0.0 to 172.16.255.255 (the IP addresses involved would not be assigned to an actual business, as they are private addresses reserved for use in an intranet—see RFC 1918 for more information, www.faqs.org/rfcs/rfc1918.html). Accordingly, the border router should not allow inbound traffic addressed to anything but the 172.16.0.0/16 subnet. Outbound traffic should be rejected (and possibly investigated) if the source address is not from the 172.16.0.0/16 subnet.

One would think that ISPs and Internet backbone providers would perform this filtering on traffic traversing their networks. Typically, however, large ISPs cannot efficiently perform such traffic filtering, due to the continually changing nature of the address ranges that they service. The problem is even more intractable when packets enter the Internet backbone, since at that point the true source of the traffic is no longer known, and it thus must be assumed to be legitimate.

One set of addresses that should never be seen at a border are the private address spaces (as defined in RFC 1918), which are reserved for internal use by independent networks (such as the addresses in the previous example). These addresses are never routed on the Internet. Surprisingly, even these addresses are sometimes seen at network perimeters connected directly to the Internet. This is due to the fact that, for performance reasons, packets on the Internet backbone are often not filtered. However, it is an excellent idea to filter all the RFC 1918 address ranges at border routers, since they have no business coming in from the Internet at large.

The intent is that as a consequence of the lack of filtering on the internet at large, an inbound packet generally cannot (by itself) be proven to be from the host that it purports to be from. When two way communication is actually established, though, the confidence level that the host is who it purports to be goes up, but is not completely assured, as the possibility exists that an intermediate hop has been compromised, and is thus spoofing the traffic.

Because of this lack of filtering, a host has little assurance that a packet arriving from an untrusted link (such as a connection to the Internet) actually originates from the host that it purports to be from. Several software packages (such as hping and Libnet) exist that will craft packets precisely as an attacker intends.

An IP address spoofing attack, then, consists of packets injected into the network with an IP address that is different than the actual IP address of the system sending out these packets. One reason for using these spoofed addresses is clear: the actual attacker is shielded from the adverse consequences of these actions. The downside, of course, is that any return packets are sent back to the purported sender, rather than to the actual sender, which means that an attack using spoofed packets is a “fire and forget” attack, with no feedback directly going to the sender. This behavior may, indeed, be desired by the real attacker, since the return packets could be construed as an attack on the purported sender (see Figure 3-1).

Figure 3-1: IP address spoofing attack

Unless the attacker also controls a point on the return path to the alleged sender, they will have no knowledge of the critical information required to establish a TCP connection. In particular, without knowing the sequence number in the returned SYN/ACK packet, a valid connection cannot be established. If, however, the attacker has a system that can sniff the wire that the return packet travels, a valid packet could be synthesized. In general, however, established TCP sessions can be considered to be operating between the hosts they appear to be.

So, what would the system that is the alleged source of the packet see? Since the original packet wasn’t sent from the host, the host would only see the return packet. In the case of a faked TCP SYN packet sent to a target, the SYN/ACK packet (assuming the target port has a listener) would be routed back to the alleged source, which, not having initiated the connection will respond with a RST packet. Even in this simple example, the traffic amplification possibilities of spoofing can be discerned—one spoofed packet caused two additional packets to be broadcast on the Internet. Furthermore, both the (alleged) source and destination hosts could naively assume that the other host had engaged in an unsolicited, possibly hostile, connection. Due to this spoofing problem, counterattacking the apparent source of hostile packets is problematical, even aside from potential ethical and legal issues.

So far, with TCP, we can see that there will be a characteristic pattern when spoofed packets are used. When spoofing is used with connectionless protocols (such as UDP or ICMP) the activity is not so easy to detect, as the transaction often consists solely of an outbound request packet followed by an inbound reply packet. A spoofed packet arriving at an open UDP port, such as DNS which uses UDP port 53, could appear to be a perfectly normal request for name resolution. In that case, the name server would send its response back to the purported originating host, which would, most likely, reject the packet as never having been sent, and it would send an ICMP port unreachable packet back. Again, one spoofed packet caused two response packets. It is generally possible to assume that an unsolicited response is likely caused by spoofing.

A much more insidious attack is generated by sending spoofed UDP packets to port 7 (echo) or port 19 (chargen). This attack, called the fraggle attack, is generated by an attacker who sets both the source and destination ports to one or the other of these on two hosts that the attacker is targeting. As shown in Figure 3-2, an unending series of packets will be transmitted between the two systems as they ping-pong back and forth. When we examine specific amplification techniques in the “Traffic Amplification” section that follows, we will see how an attacker can use an attack of this type to wreak havoc throughout an entire subnet. Best practices generally recommend that these ports, and others with little or no reason to be exposed on the Internet, be blocked at the perimeter. Hosts usually also have no need to expose these ports and generally should disable them.

Figure 3-2: UDP fraggle attack

Another similar attack (which most modern systems guard against) is the so-called land attack. In this attack, the source and destination IP addresses are both set to the victim’s address, and the port is set to UDP 7 or 19, as in the fraggle attack. Of course, a packet of this nature is always synthetically generated, since no host will send a packet to itself over the network but would instead route the data internally. On a vulnerable host, this packet will cause it to ping-pong with itself, causing CPU utilization to zoom up to 100 percent.

Spoofing is problematic with ICMP traffic as well. Recall that the ICMP specifications specifically disallow responding with an ICMP error packet to an ICMP error packet to avoid an endless avalanche of error conditions. However, spoofed ICMP packets can be used to disrupt communications, as we will discuss in the “ICMP Abuses” section later in the chapter.

Traffic Amplification

Spoofed packets can also be used to cause an amplification effect if they are sent to a broadcast address. For instance, a typical private network might have a range of 192.168.1.0 to 192.168.1.255. Although there are a total of 256 addresses in this range, the lowest and highest addresses are reserved for network use. The broadcast address is the highest address (numerically) in the subnet, in this case 192.168.1.255. When a packet is sent to this address, it is delivered to all hosts on the subnet, which may (but are not required to) respond to this packet.

Since the one packet is communicating with multiple hosts, it is impossible to establish valid TCP connections to broadcast addresses, since TCP, by design, is strictly host to host. Thus any TCP connection directed to a broadcast address is either the result of a misconfiguration of the sender, or it is malicious in intent.

As UDP and ICMP are not connection oriented, each host may indeed respond, with potentially devastating results. In the smurf attack, the attacker spoofs an ICMP echo request packet (commonly used by the ping utility) with a source address indicating the intended victim, and a destination address that is the broadcast address of the network that will participate in the attack. When the echo request packet is processed by hosts on the network, many of them (those that respond to the broadcast address) will send an ICMP echo reply to the victim, which means that potentially hundreds, or thousands, of such replies will be sent at once. This poses not only a potential bandwidth problem for the target host, which receives many packets at once, but possibly a bandwidth issue for the participating network. Even worse, if the victim address is also a broadcast address, all hosts on the victim’s subnet will receive all this unexpected traffic!

Another variation on the UDP fraggle attack has one or both of the addresses set to a broadcast address. Potentially, all hosts in one network could be ping-ponging messages with all the hosts on the other network, probably bringing both networks to their knees.

To defend against these sort of amplification attacks directed to broadcast addresses is fairly easy—border routers can be configured to reject traffic directed to the broadcast addresses in the subnet, and hosts can generally employ host-level firewalls to provide an additional level of defense. Unless they are needed by applications, most hosts can safely firewall off the broadcast address of their subnets.

Packet Size Inconsistencies

As was discussed in Chapter 2, the IP header contains a 16-bit total packet length field, giving a maximum packet length of 65,535 bytes. Also in the header is the IHL field, which specifies the size of the header in 32-bit words. Logically, therefore, we would expect the data portion of the packet to be the difference between the values in these two fields.

As the data portion of an IP packet is the protocol-specific header and data, we would also expect the length fields in the protocol-specific headers to be consistent. In the case of TCP, for instance, there is a data offset field that specifies where the header ends and the data portion begins. Naturally there must be enough room in the total packet length to accommodate this offset field.

In the UDP header, there is the UDP length field, which is computed as the total size of the UDP packet, including the header and excluding the IP header. This field should exactly match the data portion computed from the previous IP header.

Packets with these inconsistencies should fail the sanity checks of most IP stacks, and thus will typically be silently rejected by most hosts.

IP Packet Fragmentation

All hosts must accept packets with a minimum length of 68 bytes, as was discussed in Chapter 2—this gives space for the maximum-sized IP header of 60 bytes and a data portion of 8 bytes. However, this doesn’t mean that a fragment less than 68 bytes in length is considered invalid. The minimum size of the IP header is 20 bytes, and the last fragment could be as small as 1 byte if the unfragmented packet size was 1 greater than a multiple of 8. You could, therefore, theoretically see valid IP packets as small as 21 bytes.

IP fragments are an example of the dark corners in the IP specification.

Problems with Fragments

Packet reassembly resulting from fragmentation is not as straightforward as might be expected. There are several problems with fragments:

• Duplicate fragments If duplicate fragments are received with differing content, which fragment is saved? The first? The second? Should both be discarded? Systems exist that implement all of these strategies.
• Overlapping fragments If a fragment is received whose contents partially overlap an already received fragment, should the new packet’s contents take precedence over the original packet’s contents? You might think that this would be obvious evidence of an intrusion attempt, since overlapping fragments should never occur in normal network operations. This, however, has proven not to be the case for traffic traversing the Internet. Recall that the routing path that traffic traverses may change in response to network conditions, including outages, and some network routes will have different MTUs than others. Thus, if a packet is retransmitted, it may travel over a different route and be fragmented differently. If both sets of fragmented packets make it to the target host, they may indeed overlap. What would indeed be strange is for the overlapping sections to have differing contents, which would either indicate transmission difficulties or malicious crafting of packets. Overlapping fragments, however, are very rare in actual practice, and they generally should be investigated for malicious intent.
• Ping of death A fragment offset can be given along with a packet size that causes the total packet length to be greater than the maximum of 65,535 bytes. (This was famous several years ago as the aptly named ping o’Death, which used a crafted ICMP echo request packet of this nature to crash many systems.) For instance, the maximum offset that a fragment can have is 65,528. If a packet has this fragment offset, the data portion of the packet (computed as total length minus IHL) should not exceed 7 bytes, as this would cause the total packet length to exceed 65,535 bytes. In the case of Ethernet, which has a maximum data packet size of 1,500, an attacker could create a fragment with an offset of 65,528 and (assuming an IP header size of 20 bytes) a data portion of 1,480 bytes, giving a total (reconstructed) packet length of 67,008. If the system allocates a maximum 65,535-byte buffer for IP packets and fails to detect this overrun, it is possible that other data in the operating system will be overwritten by this malicious packet, potentially causing it to crash. When this problem was discovered, all major operating system vendors issued a patch to ignore packets that would cause this erroneous condition. Any packet with these characteristics is definitely malicious in nature and synthetically generated, as no TCP/IP stack will deliberately send these packets.
• Odd-sized packets Except for possibly the last fragment of a packet, it is highly suspicious if a fragmented packet has a length that is not an even multiple of 8, since packets are fragmented in multiples of 8.
• Firewall evasion Fragments can be used for firewall evasion. Among other factors, firewalls will typically make access decisions based on the source and destination addresses and ports. Unless the fragment contains that part of the packet that contains the source or destination ports, the firewall may not have enough information to make the correct decision. Some firewalls solve this problem by not allowing fragments, or by performing packet reassembly before passing the packet along to its ultimate destination. Having firewalls reassemble packets adds its own potential for resource exhaustion by malicious parties.

An IDS is concerned with the effect that these problem packets will have on the end host, but most IDSs are currently not equipped with detailed knowledge of the ultimate destination hosts, so they can’t create a fully accurate picture. Unfortunately, applying patches to a system will sometimes alter a system’s fragment-reassembly characteristics, so acquiring and maintaining accurate data is difficult. However, even without detailed knowledge of how the traffic will affect the end host, an IDS can presume that packets of this nature are malicious and can alert the operator.

TTL Issues

Malicious hosts can use a combination of retransmission and TTL games to fool an IDS into believing that it has seen the traffic that a host has seen, when, in fact, the IDS could be mistaken. Ideally an IDS will know the packet-reassembly strategy of the target host. It also, ideally, should know the number of router hops between itself and the systems it is monitoring. This is an area of active research in the IDS field.

Let’s assume the border IDS is five hops away from an attacker, and that a targeted system is two hops past that. Suppose the attacker sends a normal packet with a TTL of 6: the IDS will see the packet, since it has another hop left, but the packet will never make it to the target host. So far, no harm has been done, other than the IDS wrongly assuming that a packet was received by the target. Next, the attacker sends a similar packet, but with malicious content and a TTL of 7. If the IDS is acting under the assumption that the host will accept only the first of duplicate received packets, it may believe that nothing untoward has happened. The target host, however, only saw the second packet, which had malicious content (see Figure 3-3). This is an example of targeting an IDS specifically to evade detection. Ideally, even though the IDS does not correctly detect the nature of the attack, it can infer malicious intent, due to the receipt of two differing duplicate packets, and it should report this anomaly.

Figure 3-3: IDS evasion by manipulation of TTLs

IP Options

Several options in an IP header have security implications for the IDS analyst. Hosts are not required to implement option processing, but they are expected to forward those that they do not implement. The options that follow are obsolete, and packets containing them are generally considered malicious, and are often blocked at border routers.

Record Route

The record route option in the IP header was designed to provide a mechanism to determine the route that the packet took from source to destination. Each hop a packet takes will, if the header contains space, record the IP address of the router. This option has no obvious use, as modern tools, such as traceroute, are more capable of determining routes between hosts.

Loose and Strict Source Routing

Loose and strict source routing are used to specify the actual route that a packet is expected to take while traveling from source to destination. Strict source routing specifies the exact route, hop by hop, that the packet must take. Loose source routing also specifies the route that the packet must take, but there may be additional, unspecified hops between any two routers in the list.

The danger with source-routed packets is that it is not possible to trust the apparent source of the packet. If a hacker controls a router (which could be any device configured to act as a router, not just devices labeled as routers), then the hacker can control the routing of the packets, thus causing their system to appear to be have a legitimate address.

For this reason, hosts and border routers are well advised to drop source-routed packets, as no legitimate use for them exists. Indeed, many hosts, by default, are configured to ignore these packets. IDS sensors can assume that these packets are malicious in intent.

Internet Timestamp

The Internet timestamp option requests the timestamp from the system’s perspective, in a return packet. This has limited value, but it may give a potential attacker an idea of the level of system administration on the target. With all the other malicious traffic out there, the use of this option is fairly benign, but in combination with other traffic it may be an indication of subtle probing.

Port 0

For both TCP and UDP, port 0 traffic is considered unusual, since it is officially a reserved port and shouldn’t be used for any network communications. Any port 0 traffic is probably not legitimate, since the packets are probably generated synthetically.

Why the prohibition against using port 0? Although the original motivation for not allowing this port to be used is shrouded in the mists of time, it appears most likely to be due to the desire to have an in-band method of signaling the operating system to select a port. Instead of hard-coding port numbers, or writing code to find an open port, the Unix socket interface allows the programmer to specify port 0, which causes the operating system to select an ephemeral port for the communication. If all 65,536 port numbers were valid, an additional parameter would be needed to specify this option. Or, in other words, if port 0 was not prohibited, all 65,536 port numbers could be valid parameters to the Unix socket interface, which would entirely use up the 16-bit field allocated to this parameter. Therefore, there would be a need to have an additional parameter, which would be an “I don’t care” field. “this option” == “I don’t care” or (another way of specifying it) “the system allocates a port.” Having 0 as a magic marker meaning that the port number is unspecified is useful, and it does not measurably reduce the effectiveness of TCP or UDP. After all, very few hosts will actually be using all 65,535 ports at the same time!

Port 0 connections may be an attempt to fingerprint the host, as differing platforms respond in different ways. In general, hosts and firewalls should be configured to drop all port 0 UDP or TCP traffic.

UDP Abuses

The UDP header is so primitive as to appear impervious to abuse. After all, the header contains only source and destination ports, packet length, and checksum. It should be clear by now that these can all be spoofed by a malicious party, so further authentication is needed if the source of the packets is to be trusted. Furthermore, UDP can be used for traffic amplification, as was discussed earlier. But can the UDP header itself be abused?

UDP Checksum

Surprisingly, the UDP checksum is only optionally computed. If this 16-bit field is exactly 0, it signifies that the UDP checksum wasn’t computed on transmission and shouldn’t be checked upon reception. As UDP was originally intended as a lightweight protocol on much smaller and slower systems than modern equipment, a performance advantage was gained by not computing this checksum. However, without the checksum, there is no way to detect whether the packet was corrupted in transit.

Even inexpensive systems these days can completely fill a 100 megabit channel, and thus the reliability advantage of using a checksum greatly outweighs any minor performance gain in not computing it. Currently, there is really no legitimate reason for hosts to not compute the checksum, so any packets that have the UDP checksum turned off are questionable and may be subtle evasion attempts, although it is difficult to see what advantage would be gained by an attacker doing this.

TCP Abuses

We now turn to TCP-specific abuses. As we’ve seen, it is relatively difficult to spoof a full TCP connection, unless the hacker controls a router in the route between the two system, so traffic that travels on a fully established connection can be presumed to be between the two systems indicated. This means that an attacker can usually be identified if any abuses occur on an established TCP connection. We will reserve discussion of these types of abuses to Chapter 4, as abuses on an established connection are usually at the application level.

It is important to note, however, that there are certain network-level abuses that can be triggered by spoofed packets: TCP retransmission and TCP flags can be used maliciously; SYN floods and backscatter can overwhelm hosts; SYN or RST packets can but shouldn’t contain data; and initial sequence numbers can sometimes be predicted.

TCP Retransmission

As discussed in Chapter 2, TCP retransmits packets to introduce a level of reliability to the unreliable IP transport mechanism. When TCP retransmits a packet, the retransmitted packet should be exactly the same as the original packet. Of course, it may be fragmented differently during transport, but the data portion of the reassembled TCP packet should exactly match the original packet. If an IDS sees a retransmitted packet (with correct checksums) that has different contents than the original packet, it can assume either a buggy TCP/IP implementation or a malicious attack.

TCP Flags

A close examination of the TCP header (shown in Figure 2-5 in Chapter 2) will reveal that it contains flags that are incompatible with each other in normal use. For instance, a SYN flag should never be seen with a FIN or RST flag, as the resulting combination does not correspond to any legitimate activity of the TCP stack.

Various TCP stacks react differently to these illegal inputs—in fact, the differences in reaction to various TCP flag combinations are used by programs such as Nmap or queso to identify the operating system type. Some stacks will, in fact, crash when confronted with this type of illegal input. In general, though, the main purpose of traffic of this nature is to perform recon on a network, for vulnerability analysis purposes. Table 3-1 shows some of the flag combinations that are often used for these purposes.

Table 3-1: Invalid TCP Flag Combinations

TCP Flags	Problem
(none)	A packet with no flags is neither Session Initiation (SYN), Midstream (ACK), nor Termination (FIN/RST). It is not part of any valid TCP transaction.
SYN/FIN	The flag combination indicates both Session Initiation (SYN) and Session Termination (FIN), an impossible condition.
SYN/RST	The flag combination indicates both Session Initiation (SYN) and Session Termination (RST), an impossible condition.
SYN/FIN/ACK	This flag combination indicates Session Initiation (SYN), Midstream (ACK), and Session Termination (FIN), an impossible condition.
SYN/RST/ACK	This flag combination indicates Session Initiation (SYN), Midstream (ACK), and Session Termination (RST), an impossible condition.
All Flags	Often called the Xmas Tree flag combination, this combines the problem of Initiation, Midstream, and Termination flags with the PSH and URG flags (which in themselves are valid).

SYN Floods

Many TCP implementations are vulnerable to a resource-exhaustion attack known as SYN flooding, in which excessive requests are made to create sessions, thus causing memory utilization to explode. In an attack of this nature, numerous SYN packets are sent to an open TCP port. The target host will send back a SYN/ACK packet, create an entry in its pending-connection queue, and await the completion of the TCP three-way handshake. At this point, the connection is often termed half open. Queuing this connection takes a finite amount of memory, so if many SYN packets are received that fail to complete the three-way handshake, increasing amounts of memory will be consumed.

If these SYN packets are spoofed from addresses that do not exist, no response packet containing SYN/ACK will be received, and the pending connection queue will expand. As was explained in Chapter 2, TCP makes judicious use of timeouts, so eventually the pending connection will be torn down, and the memory will be freed, typically within three minutes. However, an enormous amount of spoofed traffic can be sent before this timeout occurs. Contributing to this potential problem is the fact that most systems typically have a fixed size for the pending-connection queue. When this queue fills, the system will be unable to accept new, potentially legitimate, connections, and may even crash.

To deal with this potential denial-of-service attack, hosts employ several strategies, either individually or in combination:

• Limiting connection rate Hosts can introduce rate-limiting software that permits only a certain number of pending connections in a given timeframe. Connection requests in excess of this limit are simply ignored by the host. The system can then be tuned to ensure that pending bogus connections are timed out at a rate greater than or equal to the maximum rate that they can enter, thus ensuring that the table doesn’t overflow. The downside of this strategy is that legitimate connection attempts may also be rejected, although due to TCP retransmission, the originating host will attempt several transmissions, one of which may get through.
• Purging stale connections Some hosts will purge a randomly chosen stale connection request from the pending-connection queue when a new request is made and the table is full. This neatly handles the problem, as old connection requests are likely to be from a SYN flooding attack, rather than legitimate connections. It is possible, though, that a legitimate connection could be discarded if its response time is slow, or if the rate of connection requests is extremely fast.
• Using SYN cookies The SYN cookie is a recently developed technique. In this technique, the initial sequence number is cryptographically derived from the IP addresses and port numbers of the connection, and a SYN/ACK packet is sent back with this initial sequence number, without retaining a pending connection queue. When an ACK packet is received at a host that implements SYN cookies, and it is determined not to be part of an established connection, that host will perform the same cryptographic calculation, and the value will be compared with the received sequence number. If the two values correspond, the connection is then considered established, and normal communication takes place. Although this technique is a technical violation of RFC 792 (timeouts are not enforced as described in the RFC), it neatly solves the problem, as no memory is consumed to keep track of half-open connections. The biggest drawback is the requirement for the receiving host to compute this cryptographic sum for every unsolicited ACK packet received, thus potentially creating a CPU utilization problem for the host. At present, modern hosts can compute this checksum at network rates, but legacy hosts may be subject to a different denial of service via ACK packets if they implement this mechanism.

Backscatter

The term backscatter refers to the response SYN/ACK packets that a SYN-flooded host will send in response to receiving the SYN packets. If the source address of the original SYN packet is spoofed, the SYN/ACKs will be sent to that spoofed address, which may use all the network bandwidth for the spoofed host or network.

Backscatter can easily be detected as a flood of SYN/ACK packets without an initial SYN being sent. If the spoofed host exists, it will most likely send an RST packet back to the spoofed originating host, further increasing bandwidth utilization. However, the RST is an unexpected godsend to this spoofed host, since it can close down the connection and release the pending connection from the queue, thus avoiding some of the ill effects from the original SYN flood attack. For this reason, SYN floods are most effective (from a hacker’s viewpoint) if the host that receives the backscatter (the spoofed source of the SYN flood) does not, in fact, exist, because the SYN flooded host must then wait for a timeout.

SYN with Data, RST with Data

Although it is not seen in normal traffic, RFC 792 does not disallow the transport of data in a SYN, FIN, or RST packet. Generally, the initial SYN packet and the return SYN/ACK are expected to be used solely for establishing a session. Similarly, a FIN or RST is expected to be used exclusively for session teardown. Normal TCP/IP stacks will not send data in these packets, and they may not process the data correctly if it is seen in these packets. Thus, IDSs that see such packets can generally assume that they are crafted, with the possible intent of evading or subverting normal mechanisms.

Initial Sequence Number Prediction

As has been mentioned, it is difficult to spoof a TCP connection, largely because of the difficulty in predicting the initial sequence number that the remote host will select. If this initial sequence number could be predicted, a reasonable facsimile of a connection could be spoofed. Of course, without knowledge of the return packet (which we’re assuming here, since a hacker wouldn’t need to predict the sequence number if the return packet could be directly observed), and particularly without knowing the number of bytes sent back, a continuous conversation would be difficult to maintain.

However, two factors work in favor of the attacker here:

• Many TCP services have easily predictable responses, and thus the byte count can be guessed with reasonable accuracy, although the actual response, in this case, won’t be accessible. The attacker could even connect normally prior to the attack and empirically attempt to determine the size of the likely response.
• Many system compromises can be completed in a single packet, thus removing the necessity for seeing any responses. A favorite technique of hackers is to compromise a vulnerable service with the injection of some sort of back door in the same packet. The hacker later performs a normal connection to the back-door port, which has no apparent relation to the original attack.

The success of spoofing TCP connections, in these cases, would be predicated on the ease of predicting the initial sequence number used by the target host. In most cases on modern operating systems, this is an impossibly difficult task, as the 32-bit ISN is essentially chosen randomly. On some desktop operating systems, though, the ISN is a simple increment of the previous ISN, thus possibly allowing this type of attack to be successful. Often, too, TCP stacks in embedded devices (such as printers) will use predictable ISNs.

ICMP Abuses

ICMP packet spoofing can be used to create denial-of-service situations by falsely propagating error indications throughout the network. As ICMP is not session oriented, a received ICMP packet cannot be authenticated as actually coming from the alleged host. Usually ICMP errors are considered transient, so unless an attacker continuously spoofs network error messages, the disruption generally will cease when the packets stop arriving at the victim.

Destination Unreachable

There is an entire family of ICMP destination unreachable packets that indicate that a network, host, or specific port is unreachable for a variety of reasons. If a host receives such a packet alleging that a network service it wishes to access is unreachable, it may cease transmitting, thus causing a disruption of communication.

Host Quench

Host quench is a deprecated method of signaling to a sending system that the receiver cannot keep up with the flow of data. On receipt of a packet of this type, sending hosts are expected to slow down traffic to the receiver. If an attacker knows that host A and host B regularly communicate, spoofed ICMP host quench packets could disrupt such communication. It would be even more effective if the hacker spoofed these packets from each host to the other one, so that each host thinks the other one wants it to stop.

Minor ICMP Abuses

In general, security professionals hold that it is best to minimize the amount of information that is leaked to potential attackers. Several ICMP requests can be used for information-gathering purposes, although they are now somewhat antiquated, as much more sophisticated information-gathering mechanisms exist. However, for completeness, we will mention two ICMP information requests and responses:

• An ICMP timestamp request packet sent to a host is responded to with the time that the system understands it to be.
• An ICMP address mask request is responded to with the subnet mask that the host is using.

These items of information are of minor use to attackers. As mentioned before, the amount and type of information that a host leaks can give an attacker an idea of the level of care and skill of system administration. In particular, a significant discrepancy in the timestamp of the system with the true time is a negative indication of system administration ability. Just as in more traditional forms of illicit activity, attackers are much more likely to target the easy marks.

The functions of the ICMP mechanism are not generally accessible to application programs, whereas application programs do control which UDP or TCP services are offered. As ICMP has no such control mechanism, the recommended procedure is to firewall off these ICMP requests, either at the host or network level.

Covert Data Channels

Although by no means confined to ICMP, the problem of covert channels is more pronounced with ICMP because ICMP is often not examined as closely by IDSs as are other protocols. A covert channel can be defined as a hidden communications mechanism. When a system has been compromised by other means, some hackers will use these covert channels in an attempt to hide their activities.

There are a few basic things to know about covert channels:

• If the channel has a legitimate use, data can be hidden in unused fields or otherwise unassigned areas of the communications channel. ICMP traffic is ideal for this, as an ICMP packet generally is quite small (usually 36 bytes or less), and the remainder of the packet can be used for surreptitious data transport.
• In general, the speed of the data transfer on a covert channel is inversely related to the ease of detection of the channel. If one errant byte is transmitted each week, the chances of detection are very low, but this rate of data transfer is probably too low for any but the most patient attackers. Except possibly in long-term espionage situations, bit rates associated with interactive traffic and download would be expected, in which case ICMP packets would again be ideal.
• For added security, covert channels are often encrypted. The easy availability of encryption packages, such as PGP and SSL, provide this capability.

ICMP has been mentioned as a possible covert communications channel for hackers because tools are available for these communications that hackers have been known to use, such as loki, icmp-backdoor, and sneaky-sneaky-1.12.

Even more subtle and troubling covert channels exist, as in the Linux sucKIT tool, which waits quietly for specific packets in a specific sequence (or with a particular payload) to activate a back-door connection. If this tool is installed, it could be configured to activate if it saw a packet to port 4567, then another one to 6543, then another to 8765 from the same system. It could then wake up and initiate a root shell that the hacker could connect to. Detecting a sophisticated back door of this type is extremely challenging.

We haven’t even scratched the surface of this topic, and clearly further study is needed by IDS vendors to counter these types of threats.

Summary

That the Internet has been so robust is really a tribute to the genius of its pioneers, but it has begun to show its age. Various network level abuses have been discussed, which can disrupt or redirect normal traffic, and evade detection. We have seen how each of the major protocols used in the Internet Protocol suite can be misused, and suggested several mitigations or corrective actions, which can help to defend systems and networks from these abuses.

In Chapter 4, we will proceed to examine abuses of common applications built on top of these network services.