Part V: Appendixes

A Exploits and Scans to Apply Exploits

B Denial of Service

C Detection of Intelligence Gathering

Appendix A. Exploits and Scans to Apply Exploits

In this appendix, we will examine a number of network traces. Each has a story to tell. Most of these traces are in the TCPdump format. This format is consistent with the traces in the book TCP/IP Illustrated, Volume 1: The Protocols, by Richard Stevens (published by Addison Wesley, 1994). This reference should be at the fingertips of any serious intrusion-detection analyst

False Positives

This appendix starts with some of the errors analysts are prone to make. Although the Computer Incident Response Teams (CIRTs) hire some top-notch analysts, the errors in this first section are just subtle enough that they might slip by them as well. On the surface, many CIRTs say that they prefer that you report liberally, even if you are afraid it might be a false positive. I agree, to a point, although I think that if you are not sure what something is you should say so right in the report! In the final analysis, you (as the analyst) are closest to the data. You see the network traffic on a daily basis. To steal a line from America's second-favorite

bear, "Only you can prevent false positives."

All Response, No Stimulus

The following trace is the classic pattern commonly mistaken for a backdoor. Before going too far, however, take a look at some of the characteristics of the trace so that you don't miss anything. At 7:17, the sensor observed a packet from mysystem, the source port was echo (or

7), the packet was addressed to target1 destination port 24925, and the size was 64 bytes:
TIME	SRCHOST SRCPORT >	DSTHOST DSTPORT	Proto Size
07:17:09.615279	mysystem.echo	> target1.24925:	udp 64

The first time I saw this, my blood pressure went through the ceiling; I just knew I was dealing with a backdoor. Why, you might ask? Well I knew that my site blocked incoming echo at the firewall, so it was not possible that someone was bouncing echoes off of mysystem. Therefore, my reasoning was that I was either dealing with some form of malicious code, a UDP flooder of some sort that had a signature of source port 7, or there was a backdoor. Now, that was bad reasoning because no one in his right mind would write malicious code that used 7 as a source port—it would be too likely to draw attention.

When I searched for the stimulus traffic, however, I could not find it, and that is what confused me. In truth, the network perimeter had changed over the weekend and someone really was bouncing echoes off of mysystem. Why didn't I see the stimulus traffic? The two most likely possibilities are asymmetric routing and a misconfigured spanning port. Some older implementations of switched networks in spanning mode only span one direction of the traffic,

which can cause a false positive. Here is the trace:

07:17:09.615279 mysystem.echo > target1.24925: udp 64 07:17:10.978236 mysystem.echo > irc.some.where.40809: udp 600 07:17:11.001745 mysystem.echo > irc.some.where.14643: udp 600 07:17:11.146935 mysystem.echo > irc.some.where.49911: udp 600 07:17:12.254277 mysystem.echo > irc.some.where.28480: udp 600 07:17:12.350014 mysystem.echo > irc.some.where.20683: udp 600 07:17:12.835873 mysystem.echo > target1.5134: udp 64 07:17:13.266794 mysystem.echo > irc.some.where.16911: udp 600 07:17:13.862476 mysystem.echo > target1.32542: udp 64 07:17:14.032603 mysystem.echo > irc.some.where.32193: udp 600 07:17:14.579404 mysystem.echo > irc.some.where.24455: udp 600 07:17:14.619173 mysystem.echo > irc.some.where.5120: udp 600 07:17:14.792983 mysystem.echo > irc.some.where.47466: udp 600 07:17:14.879559 mysystem.echo > target1.16878: udp 64 07:17:15.308270 mysystem.echo > irc.some.where.12234: udp 600

Spanning Ports

Switched networks are a major challenge for network-based intrusion detection. A sensor with a single network interface, one that listens in promiscuous mode and also reports to the analysis station, might upset some switched network configurations.

If your network operations folks want you to add a second interface to the sensor, you should try to accommodate them. Use one interface to listen in promiscuous mode; it doesn't even need an IP address. The other interface can be for communication with the sensor. In fact, this is pretty much the best practice for running a network intrusion-detection sensor these days as it helps protect the sensor from attackers and makes it harder to detect.

If the preceding trace is not caused by a misconfiguration of a spanning port on a switched network, what else could cause it? A backdoor connection or malicious code could certainly cause this pattern, but make that your second guess.

This trace is titled "All Response, No Stimulus." IP communications generally have a stimulus and a response. When analysts encounter traces they don't understand, their job is to determine what the stimulus was. This determination helps answer the questions about what is going on. This trace stands out because you can tear through all the traffic, but you cannot find the stimulus; this is all the sensor sees. The event of interest in this case is the packets being sent to mysystem's echo port.

What else can you learn from this trace? For starters, what is this echo thing, and what does it do? The echo program reads a string and repeats it. Think of it as an automated liberal arts undergraduate student. Now that you know the expected behavior of echo, it is possible to fill in the blanks for what the traffic should have looked like (if the sensor is misconfigured, for example, or if we are dealing with a backdoor connection).

The simulated, reconstructed traffic is as follows:

07:17:09.527910 target1.24925 > mysystem.echo: udp 64 07:17:09.615279 mysystem.echo > target1.24925: udp 64 07:17:10.823651 irc.some.where.40809 > mysystem.echo: udp 600 07:17:10.978236 mysystem.echo > irc.some.where.40809: udp 600

So what does that show? It shows target1 and irc.some.where sending a string to mysystem and getting the string echoed back. Now why would they do that? The answer is they probably wouldn't. Even if one system was to use echo for testing or to troubleshoot, two using it simultaneously stretches coincidence past the breaking point. This is probably a denial-of- service with target1 and irc.some.where as the intended victims. A wise rule of thumb is to turn off any network service on a computer system you don't actually need. If the system administrator for mysystem had commented echo out of /etc/inetd.conf, this trace would have never happened. If this hasn't convinced you to turn echo off yet, that's okay—additional traces

later on show more fun with echo.

This trace has yet another problem. The destination ports include 24925, 40809, 14643, 49911, and so on. Because these are echo replies, we assume they were the source ports from the sending system. The range is more random than normal for source ports, however; generally, you can expect to see 24925 followed by 24926 and so forth. Therefore, these are probably replies to crafted packets. Mistaking a trace for a "backdoor" pattern (when it is, in fact, a misconfigured switched network) can happen, but it is not that common.

Take a look at one final example of "All Response, No Stimulus" before moving on. At first

glance, this too might be perceived to be an attack of some sort:

11:38:54.010000 masker.com > 192.168.133.127: icmp: address mask is 0xfffffe00

11:39:43.180000 masker.com > 172.16.33.116: icmp: address mask is 0xfffffe00 11:53:37.780000 masker.com > 192.168.58.105: icmp: address mask is 0xfffffe00 11:56:43.690000 masker.com > 172.16.178.85: icmp: address mask is 0xfffffe00 12:15:52.550000 masker.com > 172.16.121.67: icmp: address mask is 0xfffffe00 12:25:41.800000 masker.com > 172.16.247.72: icmp: address mask is 0xfffffe00 12:45:07.470000 masker.com > 172.16.110.69: icmp: address mask is 0xfffffe00 12:45:31.530000 masker.com > 172.16.167.73: icmp: address mask is 0xfffffe00 12:58:23.350000 masker.com > 192.168.214.116: icmp: address mask is 0xfffffe00

Remember the ICMP address mask request? It asked a host to respond with the subnet mask of the network on which it resided. Although the TCPdump output does not have the word reply in it, you do see the words address mask and a hexadecimal number. These are replies to address mask requests. All the hosts receiving these replies are nonexistent hosts, however, so they could not have initiated the request.

Again, it appears that the culprit is spoofing the 192.168 and 172.16 IPs and firing them at masker.com. Why would someone most likely do this? An educated guess is some kind of flooding attempt to masker.com using a different delivery mechanism than an ICMP echo request. Truthfully, it really doesn't matter what kind of activity you direct at a target host if flooding and perhaps a denial of service are the intent. Now, take a look at a false positive that

has fooled many beginning analysts.

Scan or Response?

Take a look at the following detect that appeared on Shadow's hourly web wrap-up. Shadow is configured to look for traffic destined for UDP port 1080, which is the socks proxy server. There are some associated exploits, so we want to be alerted when someone shows interest in the

socks port. Here it is:

18:20:12.080000 dns.com.53 > myhost.com.1080: 5 NXDomain* 0/1/0 (128) 18:20:12.300000 dns.com.53 > myhost.com.1080: 6 NXDomain* 0/1/0 (119) 18:20:12.410000 dns.com.53 > myhost.com.1080: 7* 1/0/0 (48)

But, look carefully at what is going on in this output. Does anything look vaguely familiar to you? Concentrate on the notation after the 1080. Is that your final answer, or perhaps maybe you want to use a lifeline to the audience? What about the source port? A correct response does not yield a million dollars or help ratings during TV Sweeps month, but isn't this reminiscent of some kind of DNS activity? Yes, it appears to be a response from dns.com to myhost.com for multiple DNS queries that were issued. The identification numbers for the queries are 5, 6, and 7, and query number 7 received one resource record, no authority records, and no additional records.

Because this smacks more of response than scan, you need to look at outbound traffic from your network to see whether this was a DNS query initiated by myhost.com. Sure enough, the

following output puts this all in perspective:

18:20:11.870000 myhost.com.1080 > dns.com.53: 5+ (50) 18:20:12.090000 myhost.com.1080 > dns.com.53: 6+ (41) 18:20:12.310000 myhost.com.1080 > dns.com.53: 7+ (32)