Part IV: Intrusion Infrastructure

15 Mitnick Attack

16 Architectural Issues

17 Organizational Issues

18 Automated and Manual Response

19 Business Case for Intrusion Detection

20 Future Directions

Chapter 15. Mitnick Attack

In the final section of the book, we will look at automated and manual responses, and architectural and organizational issues. We will use this chapter on the Mitnick attack to serve as a transition between this higher-level material and the more fundamental material that we have already covered. The Mitnick attack is one of the most famous intrusion cases to ever occur. If you are in the intrusion business, you should be aware of the techniques used by Mitnick to attack Tsutomu Shimomura's systems. In this chapter, we will also introduce many important issues, including reconnaissance and scanning for trust relationships. We will also consider perimeter and host defenses that are related to intrusion detection for our future discussions.

A primary source for this information is drawn from Shimomura's post on the Mitnick attack. If you want more information on the subject, or to get expanded versions of the quotations you see here, refer to [e-mail] (Tsutomu Shimomura), comp.security.misc (date: 25 Jan 1995).

Exploiting TCP

The techniques Mr. Mitnick used were technical in nature and exploited weaknesses in TCP that were well known in academic circles, but not considered by system developers. The attack used two techniques: SYN flooding and TCP hijacking. Although SYN floods today can disable systems, the operating systems at the time of the attack, 1994, were far more susceptible to attack. The SYN flood kept one system from being able to transmit. Although it was in a mute state, the attacker assumed its apparent identity and hijacked the TCP connection. Mitnick detected a trust relationship between two computers and exploited that relationship. Surprisingly, few things have changed since then; for instance, computer systems are still set

up to be overly trusting, often as a convenience to the system administrators or users.

IP Weaknesses

A number of reconnaissance, exploit, and denial-of-service attacks take advantage of flaws in the architecture or implementation of the Internet Protocol stacks. In Chapter 4, "ICMP," we discussed the use of broadcast ICMP in both network mapping and denial of service with Smurf. In Chapter 3, "Fragmentation," we discussed penetration of perimeters with fragments as well as

malicious fragmentation with gaps and illegal offsets.

Some of these are older techniques, but new attacks based on programming flaws in IP implementations are being developed all the time. The following TCPdump trace is from the

SNMP test tool PROTOS, released in February 2002:

18:49:54.519006 10.0.0.1.59108 > 10.0.0.2.161: GetRequest(33)

.1.3.6.1.2.1.1.5.0[len3<asnlen4294967295] (DF) 0x0000 4500 004c 0000 4000 4011 269f 0a00 0001 0x0010 0a00 0002 e6e4 00a1 0038 0efc 302e 0201 0x0020 0004 0670 7562 6c69 63a0 2102 0206 9202 0x0030 0100 0201 0030 1530 1306 082b 0601 0201 0x0040 0105 0044 84ff ffff ff02 0100

When we first ran this test against a Red Hat Linux 7.0 box, two interesting things happened: The SNMP server application on the Linux box crashed, and the Ethereal network analyzer also crashed. Why did they crash? If you notice the ASN.1 length in the square brackets at the top of the trace, you will notice it is four billion some odd bytes. That is a lot of free memory to try to allocate, and attempting to do so crashed the SNMP and Ethereal applications. As we work our way into the Mitnick attack, we will see that available memory was a major issue in that attack. One simple way to exhaust memory that is used every day is intentionally not completing the three-way handshake. The weakness of TCP that Mitnick exploited comes from a design flaw in the early implementations of TCP stacks; however, this approach still does harm to some IP stacks.

TCP's Roots

When TCP was being developed, you couldn't purchase much memory for machines. If you could get 4 megabytes on a server, you were doing quite well. Therefore, the implementers of IP protocol stacks were very conservative.

The Internet is an outgrowth of a project from the 1970's by the US Department of Defense Advanced Research Projects Agency (ARPA). The ARPANET, as it was then called, was designed to be a non-reliable network service for computer communications over wide areas. In 1973 and 1974, a standard networking protocol, a communications protocol for exchanging data between computers on a network, emerged from the various research and educational efforts involved in this project. This became known as TCP/IP or the IP suite of protocols. The TCP/IP protocols enabled ARPANET computers to communicate irrespective of their computer operating system or their computer hardware.

For further information and the source of this quotation, see

www.ie.cuhk.edu.hk/~shlam/cstdi/history.html.

Let's take a closer look at this memory exhaustion problem. To an application program such as ftp or telnet, sockets are the lowest layer, a programming interface to networking hardware. IP is another layer and is above sockets. TCP sits on top of IP. Because TCP is connection oriented, it has to keep state information, including window and sequence number information. A typical Internet protocol stack contains information relating to sockets. TCP is connection oriented (or stateful), so the server must keep track of all condition states and sequence numbers.

The C code below came from my Unix workstation. It can be thought of as a database record
with a number of fields. The key point is that each of these fields consumes memory.
struct ip {
#if defined(bsd)	/* header length */
u_char ip_hl:4,
ip_v:4;	/* version */
#endif
#if defined(powerpc)	/* version */
u_char ip_v:4,
ip_hl:4;	/* header length */
#endif

u_char	ip_tos;		/* type of service */
short	ip_len;	ip_id;	/* total length */
	u_short		/* identification */
field */	short	ip_off;	/* fragment offset
			/* dont fragment flag */
#define IP_DF 0x3000
#define IP_MF 0x4000		ip_ttl;	/* more fragments flag */
	u_char		/* time to live */
	u_char	ip_p;	/* protocol */
	u_short	ip_sum;	/* checksum */
*/	struct	in_addr ip_src, ip_dst; /* source and dest address
};

The preceding header file fragment is taken from an IP header file on a SunOS 4.1.3 system. A struct—in this case, struct ip—can be thought of as a database record and the items inside

as fields for that record. Every time a new connection is processed, these structs have to be created for socket, ip, and other protocol information. That takes memory, and lots of it. After a server replies to a SYN, it has committed memory and must keep it committed until the timer, usually set at about sixty seconds, allows the memory to be released if the connection is never established. Because memory is finite, the designers of stacks have set limits. The SYN flood attack exploits the queue size limit of the number of connections that can be simultaneously waiting to be established for a particular service. Though some modern operating systems are more resistant to these SYN flood attacks today, many are not. An unpatched Solaris 2.5 with a

GB of memory will still be DoSed after 32 SYNs.

SYN Flooding

In a modern SYN flood, the goal is simply to throw hundreds or thousands of packets per second at a server to exhaust either system resources, as we have discussed, or even network resources when the rate is high enough.

When an attacker sets up a SYN flood, he has no intention to complete the three-way handshake and establish the connection. Rather, the goal is to exceed the limits set for the number of connections waiting to be established for a given service. This caused IP stacks in the 1994 era to be unable to establish any additional connections for that service until the number of waiting connections dropped below the threshold. Until the threshold limit is met, each SYN packet generates a SYN/ACK that stays in the queue (which was generally between 5 and 10 total connections), waiting to be established. Today, queues can be much larger; ranges between 100 and 1000 are reasonable.

SYN Floods Five Years Later

SYN flooding was in the news in February 2000 with the famous DDoS attacks that were used against Yahoo! and other high-profile Internet sites. In the intervening years since the Mitnick attack, there have been some improvements in system networking stacks and perimeter defenses. The answer of the attackers has been simple: raise the number of SYNs by several orders of magnitude. The SYN flood described here is fairly elegant; the ones common to the Internet today are pure brute force.

Each connection has a timer, a limit to how long the system waits for connection establishment. The hourglass in Figure 15.1 represents the timer, which tends to be set for about a minute. After the time limit has been exceeded, the memory that holds the state for that connection is released and the service queue count is decremented by one. After the limit has been reached, the service queue can be kept full, preventing the system from establishing new connections on that port with about 10 new SYN packets per minute.

Figure 15.1. Getting down to it.

Covering His Tracks

Because the only purpose of the technique is to perform a denial-of-service attack, it doesn't make sense to use the attacker's actual Internet address. The attacker is not establishing a connection; he is flooding a queue, so there is no point in having the SYN/ACKs return to the attacker. The attacker doesn't want to make it easy for folks to track the connection back to

him. Therefore, the source address of the packet is generally spoofed. The following IP header is from actual attack code for a SYN flood. At the very bottom, notice the dadd and sadd for

destination and source address, respectively:

/* Fill in all the IP header information */

packet.ip.version=4;	/* 4-bit Version */
packet.ip.ihl=5;	/* 4-bit Header Length */
packet.ip.tos=0;	/* 8-bit Type of service */
packet.ip.tot_len=htons(40);	/* 16-bit Total length */
packet.ip.id=getpid();	/* 16-bit ID field */
packet.ip.frag_off=0;	/* 13-bit Fragment offset */
packet.ip.ttl=255;	/* 8-bit Time To Live */
packet.ip.protocol=IPPROTO_TCP;	/* 8-bit Protocol */
packet.ip.check=0;	/* 16-bit Header checksum (filled in
below) */	/* 32-bit Source Address */
packet.ip.saddr=sadd;
packet.ip.daddr=dadd;	/* 32-bit Destination Address */

As the following code fragment shows, this technique even uses an error-checking routine to

make sure the address chosen is routable, but not active. When the attacker enters an address, the attack code pings the address (notice the slickping line in the following code fragment)

to ensure it meets these requirements. If the address is active, it sends a RESET when it receives the SYN/ACK for the system under attack. When the target system receives the RESET, it releases the memory and decrements the service queue counter, rendering the attack ineffective. From an intrusion-detection standpoint, these bogus packets assembled for the purpose of attacking and probing can be called crafted packets. Quite often, the authors of software that craft packets make a small error at some point, or take a shortcut, and this gives the packet a unique signature. You can use these signatures in intrusion detection. When you