3.2 ACTIVE ATTACKS

Team-Fly

As mentioned in Section 3.1, an active attack "attempts to alter system resources or affect their operation" [1]. As such, it primarily threatens the integrity or availability of data being transmitted. The situation is illustrated in Figure 3.2. In this case, the data transmitted from the originator (on the right side) to the recipient (on the left side) may not only be observed but also fully controlled by the intruder (in the middle). What this basically means is that the attacker can modify, extend, delete, or replay any data unit.

click to expand
Figure 3.2: An active attack threatens the integrity or availability of data being transmitted.

As will become clear, the underlying reason why most active attacks are possible and fairly easy to launch is that the data units that are sent and received (e.g., Ethernet frames, IP packets, UDP datagrams, and TCP segments) are not protected in terms of authenticity and integrity. Consequently, it is simple to do such things as flooding a recipient to cause a denial of service, spoofing the identity of somebody else, or taking over and "hijacking" already-established TCP connections. Overviews of some of these attacks are discussed next. Keep in mind, however, that the attacks have been chosen randomly and arbitrarily, and that many other attacks are possible and likely to be discovered and published in the future.

3.2.1 Denial of Service

A denial of service (DoS) refers to the prevention of authorized access to resources or the delaying of time-critical operations. Consequently, a DoS attack prevents resources from functioning according to their intended purposes. It may range from a lack of available memory or disk space to a partial shutdown of an entire network segment. Typically, a DoS attack leaves one or more systems incapable of serving their original purposes.

In the past, many DoS attacks have been developed and deployed to crash the systems of a victim:

In an e-mail bombing attack an attacker floods the mail store of a victim with large bogus messages. E-mail bombing is an increasingly popular DoS attack, and there are many tools publicly and freely available on the Internet that can be used to launch e-mail bombing attacks against arbitrary e-mail accounts.
In a smurf attack an attacker multicasts or broadcasts an ICMP echo request (a "ping" message) with a spoofed IP address of the victim system. Each system that receives the request (because it listens, for example, to the multicast group) will send a response to the victim system. As a result, the victim system will be flooded and deny its services very rapidly.

Furthermore, any system connected to the Internet and providing TCP/IP network services is potentially subject to the TCP SYN flooding attack [8]. The potential for this attack arises at the point where the server has returned a SYN-ACK message to the client but has not yet received a corresponding ACK message in a TCP connection establishment process (refer to Figure 2.7 for an overview about the TCP three-way handshake connection establishment protocol). This situation refers to a half-open connection on the server side. As a matter of fact, the server has built in its own memory a data structure describing all parameters for pending half-open connections. If there was no limit to the number of half-open connections, a busy host could easily exhaust all its memory space trying to process connection requests. However, there is typically a small upper limit (e.g., 10) to the number of half-open TCP connections that can concurrently coexist in a system's backlog queue. When the queue limit is reached, any attempt to establish another TCP connection will fail until a backlogged connection becomes established, reset, or timed-out (typically after 75 seconds).

The TCP connection establishment process and the use of a backlog queue with a limited size can also be (mis)used to launch a simple but highly efficient DoS attack: The attacker only has to send a series of SYN messages to fill the victim system's backlog queue. If the attacker makes sure that the corresponding IP source addresses reference clients that are currently unable to respond to the SYN-ACK messages generated by the server, the SYN-ACK messages will be lost. Consequently, the final ACK messages will never be sent to the server and the server's backlog queue will eventually fill up. At that moment, however, the server will be unable to accept any new connection request until the backlog queue is (entirely or partially) emptied out. As mentioned, there is normally a time-out associated with each half-open connection, so the backlog queue will recover. However, the attacker can simply continue sending bogus SYN messages faster than the victim server expires half-open connections. In most cases, the victim of a TCP SYN flooding attack will have difficulty in accepting any new incoming network connection. The attack does not affect existing and open incoming connections not the ability to originate outgoing connections. However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.

In February 2000 some distributed denial of service (DDoS) attacks were successfully launched against commercial Internet sites, such as Yahoo!, Amazon, eTrade, eBay, CNN, and ZDNet.^[5] In a DDoS attack, the intruder distributes and installs attack agents (sometimes also called "zombies") on some compromised systems on the Internet. At some later point in time, he or she signals the start of the DDoS attack by sending a specific message to the attack agents. Each attack agent that receives the message then launches a DoS attack against the victim system. Consequently, the victim system is simultaneously attacked and flooded from multiple locations, which is why the attack is distributed.

Similar to traffic analysis attacks, protection against DoS and DDoS attacks is generally hard to achieve. This is similar to the physical world: How can you protect, for example, your letter mailbox against somebody filling it up with advertisement flyers, useless paper, or any other physical material? Contrary to the physical world, however, there is at least a chance to provide protection against specific DoS attacks in the digital world (most DDoS attacks remain difficult to protect against). For example, some DoS attacks can be prevented by setting up and enforcing ingress filtering (i.e., configuring routers to block IP packets that arrive with illegitimate source addresses) [9]. Furthermore, current research and development activities address the Internet traceback problem (i.e., how to determine the source of an attack on the Internet). The traceback problem is surprisingly difficult due to the stateless nature of Internet routing. For example, in [10] a number of probabilistic packet marking mechanisms are introduced that may eventually be used to address the Internet traceback problem. Unfortunately, probabilistic packet marking and related mechanisms cannot be provided at the edge and require the cooperation of many ISPs. Finally, another approach to protect an implementation against the TCP SYN flooding attack is to avoid establishing the state after having received an initial SYN message in the first place [11]. Such an approach is employed, for example, by SYN cookies as used in some UNIX systems. Instead of establishing the state, the corresponding information is returned to the client in a form that is protected in terms of authenticity and integrity. Only if the state information is resubmitted by the client in a corresponding SYN-ACK message and this information is verifiable, does the server establish the state in its backlog queue. This approach is certainly the right way to go. Unfortunately, however, it also requires a major modification of TCP and its connection establishment process.

3.2.2 Degradation of Service

One of the charactersitics of DoS and DDoS attacks is that a victim recognizes very easily (and immediately) that he or she is under attack (this is because his or her systems no longer work properly). Note that a complete DoS may not necessarily occur and that it may make more sense from an attacker's point of view to simply degrade the quality of service. One reason to launch a corresponding degradation of service attack is to frustrate the customers of the service and to give them a good reason to change their service provider. For example, if the provider of search engine X manages to degrade the quality of service of search engine Y, it is possible and very likely that customers of Y will change their behavior and start using alternative search engines. Similarly, you may think of many scenarios in which a company has a commercial interest to degrade the quality of service of one or several of its competitors to attract their customers. The main advantage of a degradation of service attack, as compared to a DoS or DDoS attack, is that it is less likely to be recognized immediately.

3.2.3 Spoofing Attacks

In addition to the DoS and degradation of service attacks discussed so far, TCP/IP-based networks offer many possibilities to launch spoofing attacks. Some examples are described in [12].

IP Spoofing

As already mentioned in Chapter 2, each IP packet carries a source IP address in the corresponding field of its IP header (refer to Figure 2.4 for the format of an IPv4 header and Figure 2.5 for the format of an IPv6 header). This address, however, is not used to route the IP packet to its final destination. Consequently, it does not really matter what IP address is included in this field of the IP header. The term IP spoofing is used to refer to an attack in which the intruder puts a wrong IP address in the source IP address field of the packets he or she sends out. The wrong IP address may include any 32-bit number.

DNS Spoofing

The DNS as it is used today has many vulnerabilities and security problems. For example, a simple spoofing attack may use the fact that logical names (e.g., http://www.esecurity.ch) are translated to IP addresses (e.g., the IP address of the Web server that hosts http://www.esecurity.ch) using the DNS. Consequently, if an attacker is able to control this mapping, he or she can establish any system under a given logical address. More specifically, if the attacker is able to have the DNS map http://www.esecurity.ch to an IP address of his or her choice, he or she can establish a faked HTTP server under this address. An obvious possibility to control the forward mapping is to compromise the corresponding DNS server and to alter the relevant entries in the DNS database accordingly.

More worrisome, there are also applications that use the DNS for authorization purposes. When a remote client connects to such an application server, the server takes the IP address of the client and queries its DNS name. If the returned DNS name is what the server expects (and trusts), access is granted. Against this background, a malicious user can grab a small IP address space and register a DNS server for the reverse mapping of the corresponding IP addresses. Note that there is nothing that prevents an administrator for a given IP address space from mapping an IP address back to an FQDN for which he or she is not authorized. The administrator can then map an IP address to a host name, which the application server is configured to trust. Therefore, when the application server receives a request from a client it should not trust, but whose IP address maps back to an FQDN it trusts, the server will give access to the client. Some of the more common applications that once did this have been redesigned to make sure that the DNS name reverts to the same IP address, but there are still many applications that do not do this extra step. For example, older versions of the Berkeley r-tools (e.g., rlogin and rsh), NFS, X Windows, and HTTP may still be vulnerable to this form of attack.

The underlying problem that is common to DNS spoofing attacks is that there is no way to verify that a DNS response comes from an authentic server and contains authentic data. To solve this problem, the IETF has worked out security extensions to the DNS, and these security extensions are commonly referred to as DNS Security, or DNSSEC in short. We address DNSSEC in Chapter 16 when we discuss application layer security protocols.

Sequence Number Guessing

The TCP three-way handshake connection establishment protocol (refer to Figure 2.7 and the related explanations) lends itself to the so-called sequence number guessing attack. We have already mentioned in the preface that Robert T. Morris, Jr., described the feasibility of this attack in a technical report in 1985 [13, 14].

The sequence number guessing attack basically exploits two weaknesses in most TCP/IP implementations:

A TCP/IP host, in general, does not verify the authenticity of the source IP address in packets it receives;
Initial sequence numbers, in general, are not randomly generated.

The first weakness allows an attacking host to send packets on behalf of another host (i.e., IP spoofing), whereas the second weakness allows the attacking host to guess initial sequence numbers that must be known to successfully establish a TCP/IP connection. In spite of the fact that initial sequence numbers are intended to be more or less random, the TCP specification proposes to increment a 32-bit counter by 1 in the low-order position about every 4 microseconds, and the BSD-derived UNIX kernels increment it by a constant every second, and by another constant for each new connection. In both cases, the resulting initial sequence numbers are not randomly generated and can be guessed with a high degree of confidence.

Let us assume a configuration as illustrated in Figure 3.3. There is an intranet environment that includes two hosts (i.e., host A and host B). Furthermore, there is a trust relationship between host A and host B (not illustrated in Figure 3.3), meaning that host A trusts host B in the sense that users that have been locally authenticated by host B can have specific commands (e.g., rlogin, rsh, and rcp) be executed by host A without having to provide authentication information. The existence of such trust relationships is very common in contemporary networked and distributed systems. Finally, there is an attacker C who wants to use the trust relationship between host A and host B to spoof a legitimate user of host B. What this basically means is that C tries to establish a TCP connection to A for which A believes it is connected to a legitimate user of host B. If C manages to establish such a connection, C can execute malicious commands at host A without having to provide a valid username and password.

click to expand
Figure 3.3: A configuration to illustrate the sequence number guessing attack

The sequence number guessing attack works in four steps:

C collects enough information to reliably predict the initial sequence numbers chosen by A. One possibility to collect this information is to establish a few TCP connections to A and to study the initial sequence numbers chosen by A for these connections.
C initiates a TCP connection establishment handshake protocol execution by sending a SYN message to A. This step is indicated with 1) in Figure 3.3. With regard to this protocol execution, C spoofs B, meaning that C uses B's IP address. After having received this SYN message, A would send a SYN-ACK message with its own initial sequence number Y to B (because A believes that B is trying to establish the TCP connection).
C sends an ACK message that establishes the TCP connection to A. Because C has collected enough information to reliably predict the initial sequence numbers chosen by A, C can guess the value Y. At this point, a TCP connection is established between A and C, and A thinks that A has connected to B.
C can execute an arbitrary command at host A.

What happens if B receives the SYN-ACK message that A sends out in step two of the three-way handshake? In this case, B would send an RST packet back to A and finish the handshake accordingly. Thus, to successfully launch a sequence number attack, C has to make sure that B does not receive A's SYN-ACK message. C can therefore launch a TCP SYN flooding attack against B, before he starts the sequence number attack against A, or simply wait until B is out of service or taken off the intranet.

There are certain precautions to address sequence number and TCP SYN flooding attacks. With regard to sequence number attacks, cryptographical authentication is obviously the right long-term solution. As this requires each host to change its TCP/IP software, however, a more practical and short-term solution is to generate sequence numbers that are randomly selected [15]. In addition, a firewall configuration can be adapted to resist some attacks of this sort. This is because, in most cases, the attacking host will be from the Internet, but it will send packets on behalf of a system that claims to be inside the firewall. To resist such an attack, a firewall can be configured so that if an IP packet arrives from the Internet with the source address of an inside host, the firewall discards and drops the packet. With regard to TCP SYN flooding attacks, we discuss some countermeasures in Part II.

3.2.4 Session Hijacking

When a TCP connection is established between a client and server, all information that is relevant for this connection is transmitted in the clear. This allows an attacker to learn the initial sequence numbers chosen by the client and server and to (mis)use this information to disturb or even take over (i.e., "hijack") an already-established connection. For example, it is possible for an attacker to create a desynchronized state on both ends of a TCP connection (so that the two points cannot exchange data any longer) and to create valid TCP segments that are encapsulated in IP packets for both ends [16]. Consequently, the attacker is able to completely take over and hijack the TCP connection. Note that this attack is successful even if the client uses strong authentication mechanisms (e.g., one-time passwords) to authenticate to the server. In fact, the attack starts after the connection establishment and authentication steps have taken place.

One possibility to protect against session hijacking attacks is to combine the authentication step with the exchange of a shared secret (i.e., sesson key) and to use this key to cryptographically protect (i.e., authenticate or encrypt) all subsequent communications.

^[5]There are many tools that can be used to launch DDoS attacks. Examples include Tribe Flood Network (TFN), Trin00, Stacheldraht (German for "barbed wire"), and TFN2K, an updated version of TFN. Most of these tools are publicly and freely available on the Internet. David Dittrich from the University of Washington has analyzed the tools. The corresponding reports are available at http://staff.washington.edu/dittrich/misc/tfn.analysis (for TFN), http://staff.washington.edu/dittrich/misc/trinoo.analysis (for Trin00), and http://staff.washington.edu/dittrich/misc/stacheldraht.analysis (for Stacheldraht). Also, a white paper entitled "Distributed Denial of Service Attack Tools" is available from Internet Security Systems at http://documents.iss.net/whitepapers/ddos.pdf.

Team-Fly