14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win 4096 14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win 4096 14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win 4096

At this point, the connection is terminated by sending a FIN to close the connection. Mr. Mitnick logs on to x-terminal from the computer of his choice and can execute any command. The

target system, x-terminal, is compromised:

14:18:41.347003 server.login > x-terminal.shell: . ack 2 win 4096 14:18:42.255978 server.login > x-terminal.shell: . ack 3 win 4096 14:18:43.165874 server.login > x-terminal.shell: F 32:32(0) ack 3 win 4096

If Mitnick were now to leave the computer named server in its mute state and someone else were to try to rlogin, he would fail, which might bring unwanted attention to the situation. Therefore, the connection queue is emptied with a series of RESETs.

We now see RSTs to reset the "half-open" connections and empty the connection queue for

server.login:

14:18:52.298431 130.92.6.97.600 > server.login: R 1382726960:1382726960(0) win 4096

14:18:52.363877 130.92.6.97.601 > server.login: R 1382726961:1382726961(0) win 4096

14:18:52.416916 130.92.6.97.602 > server.login: R 1382726962:1382726962(0) win 4096

14:18:52.476873 130.92.6.97.603 > server.login: R 1382726963:1382726963(0) win 4096

14:18:52.536573 130.92.6.97.604 > server.login: R 1382726964:1382726964(0) win 4096

Detecting the Mitnick Attack

As we have mentioned, this chapter serves double duty: to tell the story of the Mitnick attack and also to set the stage for the final section of the book. As we complete this chapter, let's introduce the elements needed to detect and respond to an attack like this. The attack could have been detected by both host-based and network-based intrusion-detection systems. It could have been detected at several points, from the intelligence-gathering phase all the way to the corruption of /.rhosts file, when the target system was fully compromised. Intrusion detection is not a specific tool, but a capability, a blending of tools and techniques. In fact, a number of vendors, including NAI and ISS, offer hybrid systems that can perform log file analysis and packet analysis at the host system. As you read through the material in this book, you will see examples of detects by firewalls and by host-based and network-based intrusiondetection systems.

TCP spoofing is becoming harder all the time because many operating systems now randomize their initial sequence numbers, though Microsoft is a notable exception. With vulnerable operating systems, this is still a valuable technique for the more advanced attacker. SYN floods still work on many TCP stacks, although modern operating systems are much more resistant. And of course, even if a SYN flood will not work to take out one side of a trust relationship, there are denial-of-service attacks that can shut down an operating system. Much safer alternatives exist (secure shell, for example), but system administrators continue to use the r- utilities. If we cannot field a capability that enables us to detect the Mitnick attack, what can we

detect? To restate, the Mitnick attack serves as an excellent indicator of intrusion-detection capability. Why make such a big deal of this? It turns out that almost a decade later, TCP hijacking is still almost impossible to reliably detect in the field with a single tool.Various products can demonstrate a detect in a lab, but the number of false alarms (false positives) in the field makes this system feature close to useless. The good news is most of the Mitnick attack was trivially detectable; so, let's look at some ways to accomplish this.

Network-Based Intrusion-Detection Systems

Network-based intrusion-detection systems can reliably detect the following entire recon probe trace. As an analyst, you will be tempted to ignore a single finger attempt, but the pattern in entirety really stands out and should never be ignored. Consider some of the ways networkbased intrusion-detection systems might detect this recon probe:

14:09:32 toad.com# finger -l @target 14:10:21 toad.com# finger -l @server 14:10:50 toad.com# finger -l root@server 14:11:07 toad.com# finger -l @x-terminal 14:11:38 toad.com# showmount -e x-terminal 14:11:49 toad.com# rpcinfo -p x-terminal 14:12:05 toad.com# finger -l root@x-terminal

Trust Relationship

The scan is targeted to exploit a trust relationship. The whole point of the Mitnick probe was to determine the trust relationship between systems. There must have been some form of earlier intelligence gathering to determine which systems to target. If Mitnick could do this from a network, the site should be able to do the same thing, perhaps even better. Trained analysts who know their networks can often look at an attack to determine whether it is a targeted attack, but intrusion-detection systems don't currently have this capability.

Port Scan

Intrusion-detection systems can usually be configured to watch for a single attacker coming to multiple ports on a host. Port scans are a valuable tool for detecting intelligence gathering.You saw toad.com fire three probes to x-terminal. However, two of them (showmount and rpcinfo) will probably be directed at the same port (portmapper), which is at TCP/UDP 111. It is certainly possible to set the alarm thresholds to report connection attempts to two different ports on a host computer in under a minute. In actual practice, however, this would create a large number of false alarms. It wouldn't take long for the analyst to give up and set the threshold higher. Therefore, a network-based intrusion-detection system probably would not detect this probe as a port scan.

Host Scan

Host scans happen when multiple systems are accessed by a single system in a short period of time. In the example, toad.com connects to three different systems in as many minutes. Host

scan detects are extremely powerful tools that force attackers to coordinate their probes from multiple addresses to avoid detection. In operational experience, we have found that one can employ a completely stupid brute-force algorithm (flag any host that connects to more than five hosts in an hour, for example) with a very acceptable false positive rate. If you lower the window from an hour to five minutes, connects to three or more hosts will still have a low false positive rate for most sites. If the intrusion-detection system can modify the rule for a host scan to eliminate the hosts or conditions that often cause false positives (for example, popular web servers, real audio, any other broadcast service), the trip threshold might be able to be set even lower than five per hour and three per five minutes. The host scan detection code in an intrusion-detection system should be able to detect the example recon probe.

Connections to Dangerous Ports

The recon probe targets well-known, exploitable ports. For this reason, the recon probe is very close to a guaranteed detect. Network-based intrusion-detection systems can and do reliably detect connects and attempted connects to SUNRPCs. On the whole, the attacker has some advantages in terms of evading intrusion-detection systems; she can go low and slow, and she can flood the system with red herring decoys and then go for her actual target. She probably has to go after a well-known port or service to execute the exploit, however, and this is where the intrusion-detection system has an advantage. SUNRPCs are a very well-known attack point and every intrusion-detection system should be able to detect an attempt against these services.

Host-Based Intrusion-Detection Systems

Because the attack was against a UNIX system, this review considers detecting the attack with two types of commonly used UNIX tools: TCP Wrappers and Tripwire. TCP Wrappers log connection attempts against protected services and can evaluate them against an access control list to determine whether to allow a successful connection. Tripwire can monitor the status of individual files and determine whether they were changed. When considering host-based intrusion-detection systems, you want at least these capabilities. Using tools such as PortSentry and LogSentry from www.psionic.com, you can achieve an even greater level of detection and protection by watching the logs and the packets addressed to the host system.

TCP Wrappers

TCP Wrappers or xinetd would detect the probes or attacks at the host level. For TCP Wrappers to work, you must edit the /etc/inetd.conf file to wrap the services that were probed, such as finger. It is also a good idea to add access control lists to TCP Wrappers. If a system is going to run a service such as finger, you can define which systems you will allow to access the finger daemon. That way, both the access would be logged and the connection would not be permitted. The following fabricated log entry shows what three TCP Wrappers finger connection events might look like on a system log facility (syslog):

Dec 24 14:10:29 target in.finger[11244]: refused connect from toad.com Dec 24 14:10:35 server in.fingerd[21245]: refused connect from toad.com

Dec 24 14:11:08 x-terminal in.fingerd[11066]: refused connect from toad.com