So, we had a false positive in a sense; it was not an attack. Instead, it was just a young kid who figured that because he could configure a DNS system, he was "eleet." He just needed a bit of calibrating and everything was all right. Ignoring the traffic leads to some dangerous choices; an analyst should not disable an intrusion-detection system filter, for example, for a potentially dangerous attack signature. The analyst must verify that the detect is not a false positive before reporting it. Some people think I was overly harsh with the young chap. I would ask them to keep in mind the problems such activity could cause at the CIRT level. Remember, only you can prevent false positives.
Note that modern DNS servers running BIND 8 choose an unprivileged port above 1024, but they probably won't choose 31337 consistently.
This story also illustrates how important it is for your organization not just to report detects to your CIRT, but also to share with other intrusion-detection-capable organizations that have something in common with you. This is how I determined the 31337 wasn't just a fluke. Also, at times you might need to shun an Internet address block if they are being antisocial.
Shunning Works!
Once, a major Internet service provider was not providing support when its address block was being used to attack our sites. Time and time again we tried to reach its organization to get help. Finally, we blocked them (email, web, the whole nine yards). Within three weeks, they were screaming in pain because they were starting to lose money; corporate customers were pulling out. They agreed to be responsive in the future and to triple their Internet abuse staff. Who could ask for more?
This concludes the discussion about common false positives. Strictly speaking, the exploit is when the attacker goes for the kill and the software or technique exploits a vulnerability in a computer system. In actual practice, it is very difficult to distinguish between scanning for vulnerabilities and the actual attack. In fact, the current generation of attack tools do both; they scan to find vulnerabilities and they also attack. Therefore, this section contains a bit of mix and match, primarily considering vulnerabilities, but also touching on scanning for vulnerabilities when appropriate.
I am not the only one struggling with categorizing these traces in a nice organized manner. The research side of intrusion detection has been working on this problem for years and has not yet produced an accepted taxonomy of attacks. The Database of Vulnerabilities, Exploits, and Signatures (DOVES) project released a CD-ROM with its work on categorization in February 1999. For further information, contact Dr. Matt Bishop (bishop@cs.ucdavis.edu). Mitre has fostered the creation of the Common Vulnerability Enumeration (CVE). The CVE is probably the most significant effort and enjoys wide support from the vendor community; more than 2,000 vulnerabilities have been accepted by its editorial board at this time with an additional 1,700 candidates. For further information, check out CVE's web site at cve.mitre.org.
The following section examines traces from IMAP exploit attempts.
IMAP Exploits
No series of exploits has reaped as much havoc on the Internet as IMAP. Buffer overflows, such as the IMAP vulnerability, are not uncommon; several major problems have occurred with DNS buffer overflows as well. Because these programs run as root, the attack is potentially devastating, leaving the attacker with root access.
10143 Signature Source Port IMAP
The pattern here is the classic pattern of one of the most devastating buffer overflows ever unleashed on the Internet. Note that this scan contains two destination networks. Also note the time gap between packets. The gap is so large because this scan was targeting every Class B network on the Internet. This trace comes from mid-1997, and this particular signature is rarely seen now:
14:13:54.847401 newbie.hacker.org.10143 > 192.168.1.1.143: S 14:24:58.151128 newbie.hacker.org.10143 > 172.31.1.1.143: S 14:35:40.311513 newbie.hacker.org.10143 > 192.168.1.2.143: S 14:43:55.459380 newbie.hacker.org.10143 > 192.168.2.1.143: S 14:54:58.693768 newbie.hacker.org.10143 > 172.31.2.1.143: S 15:05:41.039905 newbie.hacker.org.10143 > 192.168.2.2.143: S 15:13:59.948065 newbie.hacker.org.10143 > 192.168.3.1.143: S
111 Signature IMAP
The following trace is another IMAP scan/exploit that has a repeatable signature. The fixed source port, the fixed sequence and acknowledgment fields with the 111, and of course the window size of 0 is a nice touch. From a signature-use standpoint, this one is particularly interesting. We started to see it in late 1998 following the large numbers of source port 0 and SF set scans, (these are shown next), and then it disappeared. In early 1999, this signature reappeared. I have no idea what the story behind this behavior is; it is as if the software got lost for a few months! Here is the trace:
00:25:09.57 prober.2666 > relay.143: S 111:111(0) win 0 00:25:09.59 prober.2666 > relay.143: S 111:111(0) win 0 00:42:50.79 prober.2666 > web.143: S 111:111(0) win 0 00:43:24.05 prober.2666 > relay.143: S 111:111(0) win 0 00:43:24.07 prober.2666 > relay.143: S 111:111(0) win 0 00:44:20.42 prober.2666 > relay2.143: S 111:111(0) win 0 00:44:42.62 prober.2666 > ns2.143: S 111:111(0) win 0 00:44:42.64 prober.2666 > ns2.143: S 111:111(0) win 0 00:44:42.67 prober.2666 > ns1.143: S 111:111(0) win 0 00:44:42.69 prober.2666 > ns1.143: S 111:111(0) win 0
Exploit Ports with SYN/FIN Set
One of the fascinating patterns to watch has been the various mutations of a pattern called SYN/FIN (or more commonly, SF). This is one of the most significant patterns in intrusion detection in the sense that an analyst will almost certainly have seen this and should be expected to know this pattern. The earliest instantiation I am aware of is the attack Jackal.c from late 1996, and the most recent variation I have seen was a buffer overflow against secure shell in December 2001. Attackers set SYN/FIN because it passes through a static packet filter, because they block on a SYN only. However, if a packet with SYN/FIN gets to either a Windows or UNIX system with that port open, they respond with a SYN/ACK. This is great from an attacker's point of view, because it penetrates the perimeter and still lets them compromise the system. Take your time with this section to look at some of the major variations of this pattern and to learn its history.
Source Port 0, SYN and FIN Set
The first clue I had about the following trace was a post to bugtraq in March 1998. I did not actually pick this trace up for another month. Here, the signature is source port 0, which is not logical; and both SYN and FIN flags are set, which is also not logical. An intrusion-detection system ought to be able to pick up this kind of trace! Note the random-appearing subnets 26, 24, 17, 16, 24, as well as hosts. This is possibly to make the scan less obvious. Also note the speed of the scan. Scan detectors should be able to detect five connect attempts to five different hosts in about a quarter of a second. Take a look:
13:10:33.281198 newbie.hacker.org.0 > 192.168.26.203.143: SF 374079488:374079488(0) win 512
13:10:33.334983 newbie.hacker.org.0 > 192.168.24.209.143: SF 374079488:374079488(0) win 512
13:10:33.357565 newbie.hacker.org.0 > 192.168.17.197.143: SF 374079488:374079488(0) win 512
13:10:33.378115 newbie.hacker.org.0 > 192.168.16.181.143: SF 374079488:374079488(0) win 512
13:10:33.474966 newbie.hacker.org.0 > 192.168.24.194.143: SF 374079488:374079488(0) win 512
The preceding scan presents several interesting advantages. FINs might be allowed through filtering devices even if SYNs are not. This improves the probability of a response. Also, because the FIN signals connection tear down, some logging systems will potentially fail to report the connect attempt. SYN/FIN was a trademark of a scanning tool named jackal, which was purported to penetrate firewalls. The challenge with this signature is that more than one exploit/scan is believed responsible for creating it. A more current tool that can generate a similar signature is nmap, the most effective intelligence-gathering tool yet deployed by attackers.
Source Port 65535 and SYN FIN Set
The following trace is an interesting variant of the preceding trace. This was collected in November 1998. There is speculation that this pattern is probably the result of an attack tool that enables the user to select any source port she wants. Although I have no doubt that such a tool either exists or will exist in the near future, that does not begin to explain why intrusiondetection analysts have collected hundreds of examples with source port 0 and a large number with source port 65535. In the early days, before 1999, analysts had not yet collected any examples with any other source port and SYN/FIN set. The source port was hard-coded into the software and that the source port 65535 is a second-generation code branch from the original. The trace follows:
16:11:38.13 IMAPPER.65535 > ns2.org.143: SF 3794665472:3794665472(0) win 512 16:11:38.13 IMAPPER.65535 > ns2.org.143: SF 3794665472:3794665472(0) win 512
DNS Zone Followed by 0, SYN FIN Targeting NFS
Although IMAP has been an effective target of opportunity for attackers, it certainly isn't the only target. The following trace has similarities to the source port 0 and SYN/FIN set pattern. In this case, however, we are dealing with a double dipper. First, the attacker tries an attack against TCP 53, which is also DNS. The difference is you use TCP 53 rather than UDP 53 when you want a zone transfer—in essence, a host table of the site.