Tài liệu Intrusion Detection Patterns 2 pptx

1 IDIC – SANS GIAC LevelTwo ©2000, 2001 1 Intrusion Detection Patterns 2 Network Vulnerability Scanning, Network Mapping Hello, and welcome to the second section in a series that examine intrusion detection patterns that we have assembled in the last few years. In the previous section, we discussed some of the errors often made by analysts in the heat of the battle, and in this section we will concentrate on scanning and mapping activities that have become so common on the Internet. Please turn your attention to the next slide, titled “pcAnywhere.” 2 IDIC - SANS GIAC LevelTwo ©2000, 2001 2 pcAnywhere Dec 24 18:02:13 cc1014244-a kernel: securityalert: udp if=ef0 from attacker8:1044 to victim on unserved port 22 Dec 24 18:03:15 cc1014244-a kernel: securityalert: udp if=ef0 from attacker8:1046 to victim on unserved port 5632 Take a look at the destination port in the first log entry on the slide. Port 22 means Secure Shell (SSH), right? Not quite, since in this case the transport protocol is UDP, which is not generally used for SSH traffic. A UDP port 22 connection attempt, especially when followed by an almost immediate connection to UDP port 5632 is almost always indicative of a pcAnywhere probe. Take a look at the analysis below, performed by Matt Scarborough. Note that different versions of pcAnywhere use different ports when attempting to locate pcAnywhere agents, and that it is possible to prevent a pcAnywhere host from answering by modifying an appropriate registry setting. Matt writes: “Symantec's pcAnywhere client versions 7.5x and higher can scan a entire subnet for a host by setting the last octet of its host's TCP/IP address to 255. Entering multiple subnets is possible. Multiple subnets will be scanned. Trial versions of pcAnywhere are available for download from Symantec. This makes for an attractive hacking tool, and might account for some of the increased scans on the following ports. ver - TCP - UDP 2.0 - 65301 - 22 7.0 - 65301 - 22 7.5 - 65301 - 22 7.52 - 5631 - 5632 8.x, 9.x - 5631 - 5632 Changing the default ports within the pcAnywhere client/host is possible. You can prevent a pcAnywhere host from answering a remote scan by creating and setting this Registry DWORD value to 0 HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\pcANYWHERE\CurrentVersion\Syst em\DisplayHostInList” 3 IDIC - SANS GIAC LevelTwo ©2000, 2001 3 Mscan Exploit driven scripted attack 06:13:23 srn.org.6479 > victim.org.23:S 06:13:28 srn.org.1579 > victim.org.80:S 06:13:33 srn.org.2467 > victim.org.143:S 06:13:38 srn.org.3861 > victim.org.53:S 06:13:43 srn.org.1496 > victim.org.110:S 06:13:47 srn.org.1943 > victim.org.111:S 23 Telnet, 80 Web, 143 IMAP, 53 DNS, 110 POP, 111 Portmapper More information about this attack is in your notes pages. Note how conveniently the alleged attacker scans for some of the more critical services in under 25 seconds. This is certainly not the fastest port scan, but it is quick enough to suggest that it was performed using an automated tool to probe for potential vulnerabilities on the targeted system. In fact, it is likely that the scan presented on the slide was performed using a tool called Multiscan, or simply “mscan.” AUSCERT described mscan in their AL-98.01 advisory on 20 July 1998: “AusCERT has received reports indicating a recent and substantial increase in network scanning activity. It is believed that intruders are using a new tool called ‘Multiscan’ or ‘mscan’. This tool enables the user to scan whole domains and complete ranges of IP addresses to discover well-known vulnerabilities in the following services: statd, nfs, various cgi-bin programs, (eg: 'handler', 'phf' & 'cgi-test'), X, POP3, IMAP, Domain Name Servers finger.” The complete text of the AusCERT advisory can be found at the following URL, and another demonstration of the attack performed using mscan is presented on the next slide. http://www.ja.net/CERT/JANET-CERT/mscan.html 4 IDIC - SANS GIAC LevelTwo ©2000, 2001 4 YA Multiscan 13:05:04 scan.2578 > 192.168.1.1.23:S 922736:922736(0) win 8192 13:05:04 scan.2577 > 192.168.1.1.888:S 922735:922735(0) win 8192 13:05:05 scan.2575 > 192.168.1.1.12345:S 922734:922734(0) win 8192 13:05:05 scan.2576 > 192.168.1.1.31337:S 922734:922734(0) win 8192 Full scan shown on notes page, probably in development, cycled several times against same target. JAN 99 detect. This slide presents yet another trace of a scan that was most likely orchestrated using Multiscan. A more complete trace can be found in the notes below. The purpose of such an attack is to test for a wide variety of ports that might or might not be open on the targeted system. Stealth is not considered at all; the attacker either assumes no one is checking the logs, (true in a large number of cases), or deploys the attack at night or over a weekend. The probe is then run quickly and completely. If vulnerabilities are detected, they are rapidly exploited. More advanced tools deploy a set of exploits against it in order to try to break in as soon as a potentially vulnerable, active port is detected. Once you’ve examined the mscan log file below, please turn your attention to the next slide, titled “Trojan Scan – May 2000.” 13:05:02.437871 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:02.442739 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:03.071918 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:03.079767 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:03.680841 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:04.274991 scanner.2578 > 192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:04.278967 scanner.2577 > 192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:05.391873 scanner.2575 > 192.168.1.1.12345: S 922734:922734(0) win 8192 (DF) 13:05:05.392074 scanner.2576 > 192.168.1.1.31337: S 922734:922734(0) win 8192 (DF) 13:05:06.079211 scanner.2575 > 192.168.1.1.12345: S 922734:922734(0) win 8192 (DF) 5 IDIC - SANS GIAC LevelTwo ©2000, 2001 5 Trojan Scan - May 2000 193.189.191.218:4073 to 24.3.21.199 port 1001 193.189.191.218:4074 to 24.3.21.199 port 1243 193.189.191.218:4076 to 24.3.21.199 port 12346 193.189.191.218:4077 to 24.3.21.199 port 21544 193.189.191.218:4078 to 24.3.21.199 port 21554 193.189.191.218:4079 to 24.3.21.199 port 30100 193.189.191.218:4080 to 24.3.21.199 port 61466 Typical cable modem country activity This scan is indicative of some of the new patterns emerging in late April - May 2000, when we began seeing probes to destination ports that were increasingly unknown to us. At the time we assumed that these were probably just minor variations of existing Trojans. By now most of these ports are listed in the SANS ID FAQ (http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm), but as analysts you should be prepared to face traffic patterns unknown to you at the time of the incident. 6 IDIC - SANS GIAC LevelTwo ©2000, 2001 6 Crazy 8s – Jun 1999 With signature TOS 0x82 Key to understanding: Type of Service (TOS) is a field in the IP header. Only four bits of the field are actually used. If all four bits are zero this means normal service. The legal values are specified by RFC 1349. eight.1051 > 128.38.115.249.888: S 96177:96177(0) win 8192 (DF) [tos 0x82] eight.1051 > 128.38.115.249.888: S 96177:96177(0) win 8192 (DF) [tos 0x82] eight.1051 > 128.38.115.249.888: S 96177:96177(0) win 8192 (DF) [tos 0x82] Type of Service (TOS) is a field in the IP header meant to assign priority to network traffic. While this field is allocated 8 bits, only 4 bits are supposed to be used, as explained by Richard Stevens in his TCP/IP Illustrated book: “The type-of-service field (TOS) is composed of a 3-bit precedence field (which is ignored today), 4 TOS bits, and an unused bit that must be 0 … Only 1 of these [TOS] bits can be turned on. If all 4 bits are 0 it implies normal service.” Let us look at the TOS field of packets in the trace on this slide. 0x82 in hex is 10000010 in binary. This value is certainly abnormal, as far as TOS specifications are concerned, since one of the first of the 3 bits, which should not be used, is set. In this case, the TOS value serves as a signature of the software that crafted the packet. 7 IDIC - SANS GIAC LevelTwo ©2000, 2001 7 Multiscan #204 11:48:42 prober.18985 > host.arpa.net.794: S 1240987936:1240987936(0) win 512 11:48:42 prober.18987 > host.arpa.net.248: S 909993377:909993377(0) win 512 11:48:42 prober.19031 > host.arpa.net.386: S 1712430684:1712430684(0) win 512 11:48:42 prober.19032 > host.arpa.net.828: S 323265067:323265067(0) win 512 11:48:42 prober.19033 > host.arpa.net.652: S 1333164003:1333164003(0) win 512 11:48:42 prober.19149 > host.arpa.net.145: S 2112498338:2112498338(0) win 512 Very fast scan for unknown ports This is one more example of the types of multiscans that were in play in the 1999 timeframe. Note the speed of the scan and the obscurity of the probed ports. 11:48:42.413036 prober.18985 > host.arpa.net.794: S 1240987936:1240987936(0) win 512 11:48:42.415953 prober.18987 > host.arpa.net.248: S 909993377:909993377(0) win 512 11:48:42.416116 prober.19031 > host.arpa.net.386: S 1712430684:1712430684(0) win 512 11:48:42.416279 prober.19032 > host.arpa.net.828: S 323265067:323265067(0) win 512 11:48:42.416443 prober.19033 > host.arpa.net.652: S 1333164003:1333164003(0) win 512 11:48:42.556849 prober.19149 > host.arpa.net.145: S 2112498338:2112498338(0) win 512 11:48:42.560124 prober.19150 > host.arpa.net.228: S 1832011492:1832011492(0) win 512 11:48:42.560824 prober.19151 > host.arpa.net.840: S 3231869397:3231869397(0) win 512 11:48:42.561313 prober.19152 > host.arpa.net.1003: S 2435718521:2435718521(0) win 512 11:48:42.561437 prober.19153 > host.arpa.net.6: S 2632531476:2632531476(0) win 512 11:48:42.561599 prober.19165 > host.arpa.net.280: S 2799050175:2799050175(0) win 512 11:48:42.563074 prober.19166 > host.arpa.net.845: S 2065507088:2065507088(0) win 512 11:48:42.563115 prober.19226 > host.arpa.net.653: S 1198658558:1198658558(0) win 512 11:48:42.563238 prober.19227 > host.arpa.net.444: S 1090444266:1090444266(0) win 512 11:48:42.565041 prober.19274 > host.arpa.net.907: S 2414364472:2414364472(0) win 512 8 IDIC - SANS GIAC LevelTwo ©2000, 2001 8 Multiscan October 2000 Oct 9 20:03:37 139.92.170.181:3126 -> z.y.w.34:143 SYN ******S* Oct 9 20:03:38 139.92.170.181:3137 -> z.y.w.34:53 SYN ******S* Oct 9 20:03:39 139.92.170.181:3142 -> z.y.w.34:110 SYN ******S* Oct 9 20:03:40 139.92.170.181:3145 -> z.y.w.34:23 SYN ******S* Oct 9 20:05:54 139.92.170.181:3572 -> z.y.w.34:79 SYN ******S* Oct 9 20:06:01 139.92.170.181:3606 -> z.y.w.34:23 SYN ******S* Oct 9 20:05:57 139.92.170.181:3586 -> z.y.w.34:143 SYN ******S* Oct 9 20:05:58 139.92.170.181:3592 -> z.y.w.34:53 SYN ******S* Oct 9 20:05:59 139.92.170.181:3600 -> z.y.w.34:110 SYN ******S* Key to Understanding: Probable reconnaissance, yet a year ago this would have likely been buffer overflows. The interesting thing about this trace is that we have been associating IMAP, DNS AXFER and POP (and finger if you go back far enough) with exploit code. I think the port 23 stands out in this case. There wasn’t a current IMAP or POP buffer overflow, and the Snort system didn’t alert on any rules. However, since the box is protected by PortSentry, as shown below with the partial correlation, it may not have had a chance to. Oct 9 20:03:29 hosty portsentry[594]: attackalert: Connect from host: slip139-92-170-181.sof.bg.ibm.net/139.92.170.181 to TCP port: 79 Oct 9 20:03:32 hostmi portsentry[307]: attackalert: Connect from host: slip139-92-170-181.sof.bg.ibm.net/139.92.170.181 to TCP port: 143 This attacker actually comes back the next day and does a repeat performance. Probably this is a huge scan; he has run through his target addresses and is now looping. Oct 10 00:07:51 139.92.170.181:1647 -> z.y.w.34:79 SYN ******S* Oct 10 00:07:57 139.92.170.181:1672 -> z.y.w.34:23 SYN ******S* Oct 10 00:07:54 139.92.170.181:1658 -> z.y.w.34:143 SYN ******S* 9 IDIC - SANS GIAC LevelTwo ©2000, 2001 9 Hunting SGI Systems 21:17:12 prober.1351 > SGI.imap: S 19051280:19051180(0) win 512 21:17:12 prober.1352 > SGI.5232:S 12879079:12879079(0) win 512 21:17:12 prober.1353 > SGI.telnet: S 42734399:42734399(0) win 512 Key to understanding: This portion probes a subnet that just happens to have SGI computers. 5232 is an SGI service for distributed graphics. This could indicate the site is partially mapped, or probed already. This is an example of vulnerability scanning against an individual machine. In this case, the attacker wants to exploit an SGI system. An attacker chooses a single target machine and attempts to discern what services are running on it and any other information that may be recovered remotely. This is accomplished through sending connection requests to many ports, (there are 65536 possible), and analyzing any response the target machine makes. Some vulnerability scanning tools only attempt to connect to a few well-known service ports. 10 IDIC - SANS GIAC LevelTwo ©2000, 2001 10 Still Hunting SGI Systems 21:07:16.63 badguy.com.26617 > goodnhacked.com.5135: udp 52 21:07:16.63 badguy.com.26617 > goodnhacked.com.5135: udp 52 21:07:16.66 goodnhacked.com.5135 > badguy.com.26617: udp 69 21:07:16.66 goodnhacked.com.5135 > badguy.com.26617: udp 69 21:07:16.89 badguy.com.26617 > goodnhacked.com.5135: udp 308 21:07:16.89 badguy.com.26617 > goodnhacked.com.5135: udp 308 21:07:17.83 goodnhacked.com.5135 > badguy.com.26617: udp 41 21:07:17.83 goodnhacked.com.5135 > badguy.com.26617: udp 41 21:07:59 6C: goodnhacked.com telnetd[5020]: connect from some.edu 21:08:18 6E: goodnhacked.com login[5021]: ?@some.edu as zippy 5135 is SGI Object Server Here is another example of an attacker who is apparently looking for SGI systems. Detect and analysis by Marc E. Labram, GCIA. Date: April 19, 2000 “History: Yes. There have been previous scans from this particular Asian ISP. The System Administrator of goodguy-hacked.com noticed an unauthorized account called zippy on the machine. Analysis: This particular trace shows that they were scanning for an open UDP port 5135, the SGI Object Server.” [...]... 00: 32: 36 .22 03 02 00: 32: 38 .24 3973 00: 32: 41 .25 4 622 00: 32: 44 .26 2961 00: 32: 47 .27 625 8 00: 32: 50 .28 5609 00: 32: 50 .28 6098 20 9 .20 7.135.133 > B.0 .25 5: ip-proto-191 48 B.4.5 > 20 9 .20 7.135.133: icmp:B.0 .25 5 unreach 20 9 .20 7.135.133 > B.1 .25 5: ip-proto-191 48 20 9 .20 7.135.133 > B .2. 255: ip-proto-191 48 20 9 .20 7.135.133 > B.3 .25 5: ip-proto-191 48 B.4.5 > 20 9 .20 7.135.133: icmp:B.3 .25 5 unreach 20 9 .20 7.135.133 > 25 5 .25 5 .25 5 .25 5: ip-proto-191... received I have the last 20 MB kept in 20 files of 1MB each.” 23 IP Type 54 08 :29 : 32. 60 726 0 08 :29 : 32. 60 726 0 08 :29 :41 .28 9953 08 :29 :41 .28 9953 1 72. 20 .20 .1 1 72. 20 .20 .1 1 72. 20 .20 .1 1 72. 20 .20 .1 > > > > 1 92. 168.1 .2: 1 92. 168.1 .2: 1 92. 168.1 .2: 1 92. 168.1 .2: ip-proto-54 ip-proto-54 ip-proto-54 ip-proto-54 44 44 44 44 May 19 10: 02: 33 zion kernel: Packet log: bad-if REJECT eth0 PROTO=54 129 .79.99.99:65535 MY.NET.175.104:65535... 44 4D 52 4F 43 4B 53 00 2E 2E 2F 2E 2E 2F ADMROCKS / / 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E / / / / / 2E 2F 2E 2E 2F 00 5E B8 02 00 00 00 CD 80 89 C0 / /.^ 85 C0 0F 85 8E 00 00 00 89 F3 8D 4E 0C 8D 56 18 N V B8 0B 00 00 00 CD 80 B8 01 00 00 00 CD 80 E8 75 .u 00 00 00 10 00 00 00 00 00 00 00 74 68 69 73 69 thisi 73 73 6F 6D 65 74 65 6D 70 73 70 61 63 65 66 6F ssometempspacefo 72 74 68... 17 Rexec Port 5 12 TCP 21 :30:17 prober.1439 > 33 420 8000:33 420 8000(0) 21 :30 :22 prober.1439 > 33 420 8000:33 420 8000(0) 21 :30:46 prober.1439 > 33 420 8000:33 420 8000(0) 21 :31: 02 prober.1449 > 340608000:340608000(0) 21 :31:07 prober.1449 > 340608000:340608000(0) 1 72. 20.18.173.5 12: win 61440 1 72. 20.18.173.5 12: win 61440 1 72. 20.18.173.5 12: win 61440 1 72. 20.18.173.5 12: win 61440 1 72. 20.18.173.5 12: win 61440 S S... in this case root 12 20: 32: 18.543187 external-host.1081 > my-dns-server.domain: S 3 623 7 623 1:3 623 7 623 1(0) win 321 20 (DF) 20 : 32: 18.543367 my-dns-server.domain > external-host.1081: S 11 823 95461:11 823 95461(0) ack 3 623 7 623 2 win 17 520 (DF) 20 : 32: 18.543 622 external-host.1081 > my-dns-server.domain: ack 1 win 321 20 (DF) 20 : 32: 18.681443 external-host.1081... Access [**] 04 /22 -20 :01:35.7 527 61 1 32. 239.114 .24 3 :29 208 -> z.y.x.80:80 TCP TTL:48 TOS:0x0 ID: 329 02 *****PA* Seq: 0x1F5D4C01 Ack: 0xFC85100B Win: 0xEFF7 47 45 54 20 2F 63 67 69 2D 62 69 6E 2F 69 6E 66 GET /cgi-bin/inf 6F 73 72 63 68 2E 63 67 69 3F 63 6D 64 3D 67 65 osrch.cgi?cmd=ge 74 64 6F 63 26 64 62 3D 6D 61 6E 26 66 6E 61 6D tdoc&db=man&fnam 65 3D 7C 2F 62 69 6E 2F 65 63 68 6F 20 24 48 54 e=|/bin/echo... 1 025 0 926 38:1 025 0 926 38(0) win 128 .25 6 .2. 0.http: S 1041868014:1041868014(0) win 128 .25 6.1.0.http: S 1 025 0 926 38:1 025 0 926 38(0) win 128 .25 6.3.0.http: S 1059077568:1059077568(0) win 128 .25 6 .2. 0.http: S 1041868014:1041868014(0) win 25 5 .25 5 .25 5 .25 5.http: S 1075 727 476:1075 727 476(0) 61440 61440 61440 61440 61440 win b.t.t.7905 b.t.t.7395 b.t.t.8160 b.t.t.7650 > > > > 128 .25 6.5.0.http: S 10 921 75088:10 921 75088(0) win 128 .25 6.3.0.http:... network if they allow oddball protocol types inside the network 22 Protocol 106 - QNX 79, 20 00-08-31 02: 04:58, 20 000 02, Unknown IP protocol, 24 .net1.sub2.1 62, cr000000a.rchrd1.on.wave.home.com, 24 .net1 .25 5 .25 5, , protocol=106, 2, A 79, 20 00-09-06 11:34:43, 20 000 02, Unknown IP protocol, 24 .net1.sub2.1 62, cr000000a.rchrd1.on.wave.home.com, 24 .25 5 .25 5 .25 5, , protocol=106, 4, A Key to Understanding: 106 is allocated... e=|/bin/echo $HT 54 50 5F 58 7C 2F 62 69 6E 2F 73 68 20 2D 73 20 TP_X|/bin/sh -s 48 54 54 50 2F 31 2E 30 0A 58 3A 20 65 63 68 6F HTTP/1.0.X: echo 20 27 7B 5F 69 6E 66 6F 73 72 63 68 2D 62 65 67 '{_infosrch-beg 69 6E 5F 7D 27 3B 75 6E 61 6D 65 20 2D 61 3B 69 in_}';uname -a;i 64 3B 77 3B 65 63 68 6F 20 27 7B 5F 69 6E 66 6F d;w;echo '{_info 73 72 63 68 2D 65 6E 64 5F 7D 27 0A 0A 7D 27 0A srch-end_}' }' 0A IDIC... do occur and have as long as we have been doing intrusion detection You should block TFTP at the border to your networks as a matter of course 16 TCP 111 – SUNRPC Netlogger Trace – from Shadow’s predecessor 12/ 03/97 12/ 03/97 12/ 03/97 12/ 03/97 12/ 03/97 12/ 03/97 12/ 03/97 12/ 03/97 12/ 03/97 02: 35:53 02: 35:56 02: 36: 02 02: 36:08 02: 47:46 02: 47: 52 03:09 :26 03:09 :29 03:09:35 muon.gov muon.gov muon.gov muon.gov . 41 44 4D 52 4F 43 4B 53 00 2E 2E 2F 2E 2E 2F .ADMROCKS / / 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E 2E 2F 2E / / / / /. 2E 2F 2E 2E 2F 00 5E B8 02 00 00 00. win 81 92 13:05:05 scan .25 75 > 1 92. 168.1.1. 123 45:S 922 734: 922 734(0) win 81 92 13:05:05 scan .25 76 > 1 92. 168.1.1.31337:S 922 734: 922 734(0) win 81 92 Full