Tài liệu Intrusion Detection Patterns 2 pptx

Trang 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.”

Trang 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

Trang 3

Mscan Exploit driven scripted attack

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

Trang 4

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)

Trang 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

Trang 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

“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

Trang 7

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

Trang 8

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 fromhost: 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*

Trang 9

Hunting SGI Systems

21:17:12 prober.1351 > SGI.imap: S19051280:19051180(0) win 512

21:17:12 prober.1352 > SGI.5232: S

12879079:12879079(0) win 51221:17:12 prober.1353 > SGI.telnet: S42734399: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

Trang 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.89 badguy.com.26617 > goodnhacked.com.5135: udp 308

21:07:17.83 goodnhacked.com.5135 > badguy.com.26617: udp 41

21:07:59 6C: goodnhacked.com telnetd[5020]: connect from some.edu21: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.”

Trang 11

uname –a, which gives operating system and kernel info

id, which gives user and group IDs of the user executing the command

w, who is logged on, account names, etc

Trang 12

[**] OVERFLOW-NOOP-X86 [**]

04/19-17:12:25.711444 210.164.71.242:1205 -> z.y.x.98:53

TCP TTL:42 TOS:0x0 ID:3736 DF

*****PA* Seq: 0xB97BEC5 Ack: 0xF636597E Win: 0x7D78

TCP Options => NOP NOP TS: 366539572 314575081

90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90

… 00 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 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 65 73 6F 63 6B 69 6E 61 64 64 72 69 6E rthesockinaddrin

79 65 61 68 79 65 61 68 69 6B 6E 6F 77 74 68 69 yeahyeahiknowthi

73 69 73 6C 61 6D 65 62 75 74 61 6E 79 77 61 79 sislamebutanyway

77 68 6F 63 61 72 65 73 68 6F 72 69 7A 6F 6E 67 whocareshorizong

6F 74 69 74 77 6F 72 6B 69 6E 67 73 6F 61 6C 6C otitworkingsoall

Detect by Laurie Zirkle, GIAC contributor

The point of this slide is to show that from a purely traffic analysis point of view, you can’t tell the difference between a zone transfer and a DNS buffer overflow If you just look at the header, you see a TCP connection to port 53 You need to dig deeper to determine what this really is

The technique here relies on a program that expects to grab a fixed size “chunk” of information; this

is very common

The attacker has padded the actual attack with no ops, represented by the 90s on your slide We deleted a lot of these Then machine code follows, which is executed with the privilege level of the program, in this case root

Trang 13

0000: 4500 00a4 00f9 4000 4006 efa1 c0a8 6401 E @.@ d.

0010: c0a8 6467 0439 0035 1599 71de 4679 ec46 dg.9.5 q.Fy.F

beginning of the data portion of the packet This increases the likelihood that the malicious code will

be executed properly, since the attacker may not know the exact state of the target's memory stack Second, we can see the string /bin/sh in the data portion, which you shouldn’t be seeing as part of

a DNS request, and is probably the command that the attacker is trying to execute on the remote machine

There was speculation in September 2000 by Mixter that there is a second similar pattern loose in the wild, but no trace had been submitted as of September 30, 2000 to either GIAC or Incidents If you have any traces of attacks to DNS with hex content, please send these to intrusion@sans.org

Trang 14

Oct 13 05:26:24 host1 ftpd[3415]: ANONYMOUS FTP LOGIN FROM

WU-FTPD Remote Shells

Detect by Jose Nazario, posted to GIAC in October 2000

There are a couple variations of this attack, as shown by the Snort filters below Like the example on the previous slide, the idea is to pad with the nulls and then execute the shell

msg: "IDS287 - FTP - Wuftp260 venglin linux"; content: "|31c031db31c9b046 cd80 31c031db|"; flags: AP;)

(msg: "IDS287 - FTP wuftp260 Venglin Linux"; content: "|31c031db31c9b046 cd80 31c031db|"; flags: PA; depth: 32;)

(msg: "IDS288 - FTP wuftp260 Venglin BSD"; content: "|31c0 50 50 50b07e cd80 31db 31c0|"; flags: PA; depth: 32;)

Trang 15

The detect and analysis was done by Glen Williamson

An attacker(s) may control one or more master servers; each master server can control multiple daemons The daemons carry out coordinated packet based attacks against one or more victim systems The network usually is run with attacker(s)Æ master(s)Ædaemon(s)Æ against victim or victims

Communication from the Trin00 master to the daemon is accomplished via UDP packets on port

27444 Had a connection been made back to the master from the potential daemon (this machine) it would have been via port 31335/udp

The initial “png” command sent to the daemon by the master would have replied with a “PONG” on the port 31335/udp, had the daemon (host) been previously compromised Also noted in the activity above is the default password “144ads1”

Tiêu đề	Network vulnerability scanning, network mapping
Thể loại	presentation
Năm xuất bản	2000-2001

Định dạng
Số trang	26
Dung lượng	577,5 KB