1 IDIC – SANS GIAC LevelTwo ©2000, 2001 1 Intrusion Detection Patterns Patterns Please send patterns to intrusion@sans.org Those who do not know history are doomed to repeat it! Welcome back. We are getting ready to enter the final, major section of this intrusion detection course. From here on out, we will be examining a number of intrusion detection signatures dating back as far as 1997. One of the things that is unique about this collection is that almost every pattern is a bonafide detect from the wild, as opposed to lab created signatures. There are a couple of exceptions to this; each of them is included for a reason and will be noted as an exception on its slide. 2 IDIC - SANS GIAC LevelTwo ©2000, 2001 2 Section Overview •A Word of Warning •Denial of Service Attacks •Network Vulnerability Scanning •Network Mapping •Information Gathering •Subtle and Stealthy Attacks •Coordinated Attacks intrusion@sans.org This slide shows an overview of the topics we will cover. If you see patterns in these categories that are not included in this course, we hope you will send them to intrusion@sans.org so they can be added to the collection. Keep in mind that intrusion detection is easy when you know the answer, when it is a familiar pattern; however, it can be hard and frustrating when you do not know the answer. Behind every pattern in this course is also a story. There was a time we did not know these answers and had to find them out. This is why it is so important for each of us to help develop the knowledge of the community. Even patterns that are not added to the main course can be kept in an appendix in case they are ever needed by an analyst. Well, let’s get started. The first section we will cover is common errors. Your next slide is titled A Word of Warning. 3 IDIC - SANS GIAC LevelTwo ©2000, 2001 3 A Word of Warning Certain patterns tend to be commonly misinterpreted. As an analyst, strive to have the highest possible degree of accuracy. One day, you may have to make a tough call and you want as much credibility as possible. Common Errors It is OK to make a mistake. Well, it had better be, because each of us will. Granted, the mistake many analysts make is to hide their heads in the sand and ignore what is happening and keep their mouths shut and then later claim to know what is going on. This is not the philosophy we teach. We have and will continue to share a number of stories with the goal of helping you see the process that we have gone through to attain the level of knowledge we have today. Of course, we have made a number of mistakes. For a given pattern there may be more than one possible interpretation; in fact, we will see this as we move through the material. A good analyst knows how to play the odds and also when to question the accepted answer. A good analyst also knows how to avoid the common errors. In this next section we will discuss some common errors. If you will allow us to take a page from the Shriner’s mottos, “We screw up beyond all belief so you don’t have to.” 4 IDIC - SANS GIAC LevelTwo ©2000, 2001 4 UDP “High Port Scan” "7252" "29Mar2000" "12:58:31" "drop" "33434" "209.67.29.9" "my.net.100.100" "udp" " len 64" "7253" "29Mar2000" "12:58:32" "drop" "33434" "209.67.29.9" "my.net.100.100" "udp" " len 64" "7254" "29Mar2000" "12:58:33" "drop" "33434" "209.67.29.9" "my.net.100.100" "udp" " len 64" "7255" "29Mar2000" "12:58:34" "drop" "33434" "209.67.29.9" "my.net.100.100" "udp" " len 64" Correct analysis: F5Labs traceroute variant Common Errors This pattern is often mistaken as a UDP high port scan; please see the analysis by Ron Ryan, GCIA. Port 33434 is the first port used in a UDP traceroute - see the IANA port assignments located at http://www.isi.edu/innotes/iana/assignments/port-numbers. Normally when a traceroute is performed, the destination port number is incremented on each attempt. The first packet sent will use destination port 33434 and have a TTL of 1. The first router that receives the packet decrements the TTL value to 0, which causes an ICMP time exceeded error. The second and third packets will also have a TTL of 1, and they will use destination ports 33435 and 33436. The next three packets sent by traceroute will use a TTL value of 2 and destination ports of 33437, 33438 and 33439, respectively. This activity will continue with the TTL values being decremented at each intervening router. As the initial TTL values increase, the packets get through more routers before the TTL is decremented to 0. Assuming that you don’t know the TTL value, the destination port is normally a good indicator of how far away the tracing host is. The larger the value, the more hops that have taken place. You won’t normally see a traceroute packet with a port value of 33434 that gets to your firewall. Intervening routers will have caused traceroute to increment this value on each successive attempt. There are a number of products on the market today, from companies like Cisco, Resonate, Nortel, F5LABS and GTE, that perform distributed load balancing. F5Labs’ 3DNS, GTE Hopscotch, Resonate Global Dispatch, and Cisco’s Distributed Director are all capable of performing load balancing across multiple Points of Presence, or POPs. The hop count mechanism is a method of mapping the best route from the client to a POP. The latency, as measured by the traceroute mechanism used by the load balancer, establishes an optimal path. The trace is initiated when a gethostbyname query is issued on behalf of the client by the local DNS server or cacheing appliance. The trace is directed at the source of the query and not at the client. 5 IDIC - SANS GIAC LevelTwo ©2000, 2001 5 Back Orifice!!! (31337 is a default destination port for BO) 11:20:44 ns1.com.31337 > ns2 arpa.net.53: 38787 A? peoarbs.arpa.net. (34) 11:52:49 ns1.com.31337 > ns1 arpa.net.53: 39230 ANY? hq arpa.net. (36) Keys to Understanding A? is a request for an IP address, the most common DNS query. ANY? is a request for all records; this is similar to a zone xfer. (36) or (34) is the size of the payload. All of this matches the expected format of a DNS query. It walks like a duck, quacks like a duck, probably isn’t BO! Common Errors Historically, DNS server to server communications tended to come from port 53 and be addressed to port 53. This is no longer the case. BIND 8 will simply choose a port above 1024, a non privileged, or non assigned port. One could also set the port for the DNS server to any arbitrary number. In this case, the port was set to 31337, which upset some network defenders that were concerned it was Back Orifice. From a traffic analysis standpoint, you know it is not BO. For one thing, we are looking at source port 31337, not destination port 31337. However, 31337 is a great pattern to look for! There are more clues here. In the traffic analysis section, we learned to give some credence to where the packets are coming from. Here we see nameserver nomenclature. We can verify this is actually a registered nameserver pretty easily. Of course, that doesn’t preclude someone from compromising a nameserver and using it for nefarious purposes. In this case we simply called the owner of the system and he explained that he had chosen 31337 and was getting a lot of criticism for the choice. By the end of the phone call, he had decided that he probably wanted to make a change. 6 IDIC - SANS GIAC LevelTwo ©2000, 2001 6 Ftp99cmp Win Trojan [**] FTP99cmp [**] 04/09-23:18:35.467634 151.164.1.8:53 -> 208.188.225.121:1492 UDP TTL:246 TOS:0x0 ID:35890 DF Len: 175 07 11 81 80 00 01 00 01 00 02 00 02 03 32 32 35 225 03 31 38 38 03 32 30 38 07 69 6E 2D 61 64 64 72 .188.208.in-addr 04 61 72 70 61 00 00 06 00 01 C0 0C 00 06 00 01 .arpa 00 00 1A F3 00 31 03 6E 73 31 06 73 77 62 65 6C 1.ns1.swbel 6C 03 6E 65 74 00 0A 70 6F 73 74 6D 61 73 74 65 l.net postmaste 72 C0 3A 0B EA 5F 5A 00 00 0E 10 00 00 03 84 00 r.: _Z 09 3A 80 00 00 0E 10 C0 0C 00 02 00 01 00 00 1A .: F3 00 02 C0 36 C0 0C 00 02 00 01 00 00 1A F3 00 6 06 03 6E 73 32 C0 3A C0 36 00 01 00 01 00 00 1C ns2.:.6 20 00 04 97 A4 01 01 C0 81 00 01 00 01 00 00 1C 20 00 04 97 A4 01 07 Common Errors Older BIND 4 server to server communications used source port 53. Some poorly implemented perimeter systems allow anything with source port 53 through. This false positive also shows the danger of detection on a single packet as opposed to watching the whole stream. According to one of the GCIA students, FTPcmp99 opens up an FTP server on your Windows 95/98/NT system. The FTP server registers itself under the key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run Obviously the default port must be 1492. So this is wired into a Snort rule, and it lights off when it sees this packet. The analyst takes one look at the asciification on the right and says, hmmm, source port 53 to 1492. 1492 is a perfectly reasonable ephemeral source port. This could be a DNS response, not a stimulus. Judging from the fact that it looks like a DNS reply duck and quacks like a DNS reply duck, the analyst prefers this answer to the possible trojan. 7 IDIC - SANS GIAC LevelTwo ©2000, 2001 7 Is this a stimulus or a response? (1) 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 Common Errors This is a tough one; in fact, we are going to use two slides to do this one. First, let’s introduce the problem. If one of our most powerful tools is sorting by stimulus or response, what do we see on this slide? Is this a stimulus or a response? The wise analyst might answer “maybe.” What do we know about this? • One way dataflow from mysystem’s echo port to IRC • The timing is pretty quick; we are sending packets quickly • In terms of Size does matter, we have two flavors of packets, 600 and 64 • We are hitting random ports on IRC Remember when we started this whole course series, the first thing we looked at was the pepsi UDP flooder software? While this is not exactly the same as that, can you see the family resemblance? And in our traffic analysis section, we mentioned that when we see an IRC server is involved, that can be helpful information since they get hammered a lot. So it seems reasonable that a partial answer is that somehow our computer, mysystem, is mixed up in a denial of service attack against an IRC server. That does not answer the core question of whether this is a stimulus or a response, however. If it is a stimulus, it is probably software, such as trojan software that resides on mysystem and just happens to use echo, port 7, as the source port. If it is a response, then why don’t we see the stimulus? So we pull some more traffic, and on the next slide we get an additional clue. 8 IDIC - SANS GIAC LevelTwo ©2000, 2001 8 Is this a stimulus or a response? (2) 07:00:03.733316 myhost> irc.some.where: icmp: echo reply 07:00:03.749546 myhost.echo > irc.some.where.45932: udp 600 07:00:04.044893 myhost> irc.some.where: icmp: echo reply 07:00:04.062594 myhost.echo > irc.some.where.25057: udp 600 07:00:04.120963 myhost> irc.some.where: icmp: echo reply 07:00:04.138398 myhost.echo > irc.some.where.55640: udp 600 07:00:04.185552 myhost> irc.some.where: icmp: echo reply 07:00:04.203068 myhost.echo > irc.some.where.65348: udp 600 Common Errors Remember when we learned to draw a link diagram in the traffic analysis section with the Out of Spec traffic? We could surmise that we were probably dealing with two way traffic even though we couldn’t see both sides of the traffic. The simplest explanation for the echo reply packets we see in front of us is that they were stimulated by echo requests. We just don’t see them for some reason. There are several possibilities for this: • Asynchronous routing • Back door connection • Misconfigured switch From Stephen Northcutt: “Well, hopefully you are familiar enough with your site that you know how your routing is configured. My CIRT thought “back door” when they saw this. In other words, they thought someone was stimulating my host through an illicit connection to attack IRC. To do this, the attacker might need to use source routing, which isn’t commonly associated with dumb ol bash the IRC server denial of service attacks. A backdoor connection could cause this pattern, but make that your second guess. I will admit though, the first time I saw this pattern, my blood pressure went through the ceiling. These days, I pick up the phone and dial the network operations folks at the site where the sensor is located. This pattern is often caused by poorly configured VLANs in a switched network environment causing the sensor to only see one side of the traffic.” 9 IDIC - SANS GIAC LevelTwo ©2000, 2001 9 SYN Flood The real deal 14:18:22.5166 flooder.600 > server.login: S 1382726960:1382726960(0) win 4096 14:18:22.5660 flooder.601 > server.login: S 1382726961:1382726961(0) win 4096 14:18:22.7447 flooder.602 > server.login: S 1382726962:1382726962(0) win 4096 14:18:22.8311 flooder.603 > server.login: S 1382726963:1382726963(0) win 4096 14:18:22.8868 flooder.604 > server.login: S 1382726964:1382726964(0) win 4096 14:18:22.9434 flooder.605 > server.login: S 1382726965:1382726965(0) win 4096 14:18:23.0025 flooder.606 > server.login: S 1382726966:1382726966(0) win 4096 14:18:23.1035 flooder.607 > server.login: S 1382726967:1382726967(0) win 4096 14:18:23.1621 flooder.608 > server.login: S 1382726968:1382726968(0) win 4096 14:18:23.2284 flooder.609 > server.login: S 1382726969:1382726969(0) win 4096 14:18:23.2825 flooder.610 > server.login: S 1382726970:1382726970(0) win 4096 14:18:23.3457 flooder.611 > server.login: S 1382726971:1382726971(0) win 4096 14:18:23.4083 flooder.612 > server.login: S 1382726972:1382726972(0) win 4096 14:18:23.9030 flooder.613 > server.login: S 1382726973:1382726973(0) win 4096 14:18:24.0052 flooder.614 > server.login: S 1382726974:1382726974(0) win 4096 Common Errors The trace above is a valid SYN flood; in fact, it is “the” SYN flood that we learned about in the Mitnick attack. On the next slide we morph the trace a bit to illustrate a point. From our earlier studies on the “elegant” SYN flood, we learned that through a design flaw, it was possible to execute a denial of service attack against a server with 6 – 10 packets per minute. You can imagine that system designers have been trying to get this fixed ever since. Most modern operating systems are not vulnerable to this particular SYN flood. However, we keep hearing about SYN floods and not in ancient literature either; do they still work? Certainly, just not at a packet rate of 6 – 10 per minute. Modern SYN floods exhaust resources by sending a much larger number of SYN packets and though there are countermeasures, there comes a point where there isn’t much you can do, just too many packets flying around. One last point before we go to the next slide: just how do intrusion detection systems report a SYN flood? Essentially, you would count the number of SYNs over a time period like 5 seconds. If the IDS had no notion of state, that would be the end of it. If you had too many SYNs, raise an alarm. If you have a more sophisticated system, you can decrement the counter when you get lone ACKs completing the 3-way handshake and possibly on RST as well. [Narrator – historical information, do not read.] Source: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura), comp.security.misc Date: 25 Jan 1995 “About six minutes later, we see a flurry of TCP SYNs (initial connection requests) from 130.92.6.97 to port 513 (login) on server. The purpose of these SYNs is to fill the connection queue for port 513 on server with "half-open" connections so it will not respond to any new connection requests. In particular, it will not generate TCP RSTs in response to unexpected SYN-ACKs.” 10 IDIC - SANS GIAC LevelTwo ©2000, 2001 10 SYN Flood Common Error 14:18:22.5166 host.600 > server.25: S 1382726960:1382726960(0) win 4096 14:18:22.5660 host.601 > server.25: S 1382726961:1382726961(0) win 4096 14:18:22.7447 host.602 > server.25: S 1382726962:1382726962(0) win 4096 14:18:22.8311 host.603 > server.25: S 1382726963:1382726963(0) win 4096 14:18:22.8868 host.604 > server.25: S 1382726964:1382726964(0) win 4096 14:18:22.9434 host.605 > server.25: S 1382726965:1382726965(0) win 4096 14:18:23.0025 host.606 > server.25: S 1382726966:1382726966(0) win 4096 14:18:23.1035 host.607 > server.25: S 1382726967:1382726967(0) win 4096 14:18:23.1621 host.608 > server.25: S 1382726968:1382726968(0) win 4096 14:18:23.2284 host.609 > server.25: S 1382726969:1382726969(0) win 4096 14:18:23.2825 host.610 > server.25: S 1382726970:1382726970(0) win 4096 Note: This is a fabricated trace; compare sequence numbers to the previous slide. Most modern OSes are resistant. Most IDS SYN Flood detects are actually false positives. Common Errors Kind of hard to tell the difference between this page and the previous, yes? In fact, impossible, if you notice the sequence numbers. We simply altered the previous trace with find and replace. What is the point? It is not unusual to see a mailer “syn flood”…. If your mail server is down. After all, mail is queued up and processed (generally) every hour. The longer the server is down, the more mail gets queued up and the bigger the “SYN flood” becomes. The other very common false positive is Microsoft Internet Explorer visiting a web page; it will create a connection for each .gif, .jpeg, .html etc., up to a limit of 32. The bottom line: As a general rule, be very slow to report a SYN flood; there is a high chance of reporting a false positive. You don’t need an IDS to detect a bonafide modern SYN flood; hints this is happening include: • Cursor echo on an affected system takes over a minute • Network operations starts making groaning sounds like Red October clearing 600 meters • Smoke rising from your router We are sure you get the general idea! [...]... it was in fact a hardware problem Does that mean you could let your guard down and assume that every weird packet was benign? Remember, for many patterns there is more than one reasonable interpretation With large packet flows there may be patterns inside the patterns The wise analyst plays the odds, calls it with the odds, but remains alert for other possibilities 14 Common Errors Scanned by IRC server... the source for a large number of anomalous patterns In the next slides we will look at one of the famous signatures of the Demon Internet pattern to help you practice your technical analysis skills However, the more important lesson is to never let your technical analysis get in the way of the fundamentals The most important signature for the Demon Internet patterns were that one of your hosts was always... these ports open; they aren’t just scanning your site They attempt to avoid connections through proxies as a best effort to avoid problems Tim White has mapped a couple additional servers and documented their patterns: starchat.net Dec 23 13:53:39 irc[998]: connect host=unknown/172.16.57.138 destination=208.213.162.254/6667 Dec 23 13:53:39 unix: securityalert: tcp if=hme1 from 208.213.162.254:3343... your site has an unusually small MTU for some reason, and then you will see tons of it This means that a good percent of the fragmentation that you do see was intentionally done to either hide from intrusion detection systems or to attempt a denial of service 31 Denial of Service Attacks Echo-Chargen Loops 08:08:16 08:21:48 08:25:12 08:42:22 08:47:21 08:51:27 08:53:13 spoofed.net.echo spoofed.net.echo... connection” 19 Denial of Service IDIC – SANS GIAC LevelTwo ©2000, 2001 20 We hope you enjoyed the last section; you had a large number of opportunities to practice your traffic analysis skills against some patterns that have been known to throw analysts in the past In the next section of the course, we will look at denial of service attacks If you are willing to be a shade liberal and not spend your life... 5 win ack 7 win 8755 (DF) R 109669:109669(0) win S 109670:109670(0) win IDIC - SANS GIAC LevelTwo ©2000, 2001 26 Do you remember the first time you saw the acronym BSOD? Blue Screen of Death; to the intrusion analyst it means a reachable or active TCP port, the URG flag set and an invalid value in the pointer field To Windows users all over the globe, it meant having their systems lock up, especially... 2144 (DF) 01:25:44.417554 B.http > A.1833: S 5450:5450(0) ack 96247896 win 4096 So what was the user looking for at oh_dark_thirty? $ egrep A access_log A- - [19/Jun/1998:01:25:42 -0400] "GET /Docs/how.to.hack.unix.html HTTP IDIC - SANS GIAC LevelTwo ©2000, 2001 31 The example above is truncated so it will fit on the slide This is far from conclusive, but check it out At the top of the slide... host, ProxyScan.MD.US.Undernet.Org, to start figuring out the pattern IDIC - SANS GIAC LevelTwo ©2000, 2001 16 Detect by Andy Johnston, GCIA; analysis by Julie Lefebvre, GCIA Andy is a co-author of the Intrusion Signatures and Analysis book; here, one of his detects is being used for a student practical We will let Julie tell it in her own words, but we want to come back with the wrapup “When I first . 1 IDIC – SANS GIAC LevelTwo ©2000, 2001 1 Intrusion Detection Patterns Patterns Please send patterns to intrusion@ sans.org Those who do not know history. the final, major section of this intrusion detection course. From here on out, we will be examining a number of intrusion detection signatures dating back