sans giac level two – intrusion detection in · web viewfor example, the class c network...

SANS GIAC Level Two – Intrusion Detection In DepthGCIA Practical Assignment – SANS 2001 Baltimore

Practical Assignment Version 2.9 – May 22, 2001

Jeffrey A. Holland, GCIA/GCIH/GSEC

Table of Contents

INTRODUCTION 3

ASSIGNMENT 1 – NETWORK DETECTS 5

ASSIGNMENT 2 – DESCRIBE THE STATE OF INTRUSION DETECTION 37

ASSIGNMENT 3 – “ANALYZE THIS” SCENARIO 52

REFERENCES 102

APPENDIX A 103

APPENDIX B 106

2

Introduction

Network Topology and Hardware Specifics:

The following image depicts the topology of the network used to capture the detects in Assignment 1.

The laptop running Snort version 1.7 was started in NIDS mode using the snort.org ruleset dated 4/4/01, the vision.conf rules located at http://www.whitehats.com/ids/vision.conf.gz, custom rules written for my network based the prior attacks my network had received. SnortSnarf version v052101.1 was used to analyze the alerts that Snort reported.

The Sun Ultra 60 running Snort version 1.7 was configured with a 6 GB var partition and started with the following command: ./snort –dve –l /var/log/snort. The box had a 400Mhz processor and 384MB RAM, and handled the full T1 traffic without any apparent packet loss. Any interesting alerts from the laptop running Snort or from the firewall logs were correlated against the data on the Ultra 60 running Snort in sniffer mode. All Snort packet traces were taken from the Ultra 60 for inclusion in the practical.

While the ISS IDS sensor logs were not included in this practical, the alerts were correlated against what Snort detected. In all cases, the information logged by Realsecure was less detailed than Snort, so only the Snort IDS logged were included in the practical. Gauntlet firewall logs, when available, were included as well.

The switch outside the firewall port mirrors all traffic to/from the internal network to the switch ports that the IDS sensors are plugged into.

Gauntlet Firewall Log Messages:

3

http://www.whitehats.com/ids/vision.conf.gz

Gauntlet firewall log messages are defined as follows according to NAI/PGP(http://www.pgp.com/support/technical-support/faq.asp?pCode=GNTUX):

The “no match in local screen” message occurs when someone on the outside network points directly to an inside interface of the firewall.

The “on unserved port” message occurs when someone tries to access the firewall on a port that the firewall is not allowing connections on.

The “packet denied by forward screen” message occurs when someone tries to connect to a private internal host from an external public host on an unserved port, or when an ICMP packet it sent from the external host to the internal host.

Examples of each of these log message types are shown below:

Jun 4 18:57:05 firewall.mycompany.com unix: securityalert: no match found in local screen: TCP if=hme0 srcaddr=203.239.54.93 srcport=2636 dstaddr=a.b.c.134 dstport=53

May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 216.61.164.172:54321 to a.b.c.6 on unserved port 54321

Jun 4 18:13:54 firewall.mycompany.com unix: securityalert: packet denied by forward screen: ICMP if=hme0 srcaddr=62.156.62.162 dstaddr=a.b.c.63

Snort IDS Log Messages:

Snort logs included in Assignments 1 and 2 were collected while running Snort with the d, v, and e flags. These flags will cause Snort to run in verbose mode, and log all application and link layer data. The Snort output contains all header and payload data. The payload data is shown in both hex format and the ASCII translation of the hex data. An example is shown below:

06/04-18:05:49.988468 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.63 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C 3F ...?

Microsoft Access Database:

A database containing the Snort data for Assignment 3 was created using Access 97. The database may be downloaded from the following URL: http://web2.airmail.net/a0055941/gcia_v2.9_snort_db.ZIP. Note that the database is roughly 20MB in compressed .mdb format and 4 MB zipped.

4

http://web2.airmail.net/a0055941/gcia_v2.9_snort_db.ZIP

http://www.pgp.com/support/technical-support/faq.asp?pCode=GNTUX

Assignment 1 – Network Detects

Detect #1 – ICMP Echo Request Broadcast Smurf Scan

Gauntlet Firewall Logs:







Note: The firewall did not record the packet sent to a.b.c.255. Since my firewall denies all inbound and outbound ICMP echo replies and requests, and there was no evidence of an echo reply to the attacker in the firewall logs, I am assuming syslog failed to log this packet to the /var/log/messages file.

Snort Logs:

Note: The ICMP payload and destination IP address were sanitized. The payload actually contained the destination IP address. However, the last octet of the IP address in the payload was left intact, as it was in the destination address. Thus, the last byte of the ICMP payload is the hex value of the last octet in the decimal representation of the destination address (ie. "3F" in hex is "?" in ASCII).

06/04-18:05:49.988468 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.63 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C 3F ...?

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:05:50.016481 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.64 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C 40 ...@

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

5

06/04-18:05:50.037793 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.127 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C 7F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:05:50.051438 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.128 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C 80 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:05:50.079689 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.191 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C BF ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:05:50.093392 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.192 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C C0 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:05:50.114644 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.254 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C FE ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:05:50.135531 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C 62.156.62.162 -> a.b.c.255 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHO0A 0B 0C FF ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Source of Trace:

This detect was obtained from the network I monitor at my present employer.

Detect Generated By:

The Gauntlet firewall detect was generated by a UNIX (Solaris 2.6) Gauntlet 5.5 firewall. The Snort detect was generated by Snort version 1.7 using the snort.org ruleset available at http://www.snort.org. The following Snort signature originally identified the attack:

alert icmp any any <> any any (msg:"ICMP Broadscan Smurf Scanner"; itype: 8; icmp_id: 0; icmp_seq: 0; dsize:4; )

6

http://www.snort.org/

Probability the Source Address was Spoofed:

While almost all Smurf attacks are spoofed, I believe this attack was not. The attacker appears to be doing reconnaissance scanning of my variably subnetted class C network for use as a Smurf amplifier. When I did a traceroute to the source IP address of the packets from a machine on the external side of my firewall, the host was 16 hops away. Note that the TLL in the packets is 240, so the attacker was no more than 15 hops away. A difference of one hop is very small, and lends support to the conjecture that the source address was not spoofed.

In addition, the IP address resolves to an address owned by Deutsche Telekom, one of Germany’s largest ISP’s. Since the network I monitor typically receives blatant and hostile attacks from various foreign countries, one of which is Germany, the probability these packets were spoofed is very low.

Description of the Attack:

This is a Smurf broadcast scan against suspected broadcast addresses in a variablysubnetted class C network. Snort originally identified this as scan possibly produced by the tool Broadscan. However, after careful review of the packets and both versions of Broadscan (broadscan.c and broadscan05.c), I believe a different tool called SendIP was used. This scanning technique, and the tool SendIP, is addressed in detail in Assignment 2 of this practical.

There is not a specific CVE entry for Smurf broadcast scanning, but there is one that addresses allowing ICMP echo requests to broadcast addresses. The URL is: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0513. Also, a more general CERT advisory on Smurf attacks is available at the following URL: http://www.cert.org/advisories/CA-1998-01.html. Note that an attacker could Smurf themselves and the network they reside on while doing Smurf broadcast scanning, so these advisories do indeed apply to this attack.

Attack Mechanism:

What differentiates this scan, which I’ll coin the “Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP Payloads” attack, is the crafted payload. The attacker uses a tool, such as SendIP, to modify the ICMP payload to contain the destination IP address. The rationale behind this is that the echo reply packet must return the payload data sent in the echo request packet, and therefore the attacker will know which broadcast address is legitimate. The attacker also sends an echo request packet to the network address of the suspected subnet. This aids the attacker in correctly identifying the subnetmask used to variably subnet the network. In addition, since Cisco routers echo the IP ID of the echo request packet in the echo reply and use a default TTL of 255 (like Solaris), limited OS fingerprinting analysis can be performed by the attacker.

7

http://www.cert.org/advisories/CA-1998-01.html

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0513

Once the attacker maps the network and discovers the broadcast and network addresses that reply, they can be used in a Smurf amplification attack. This attack is a simple but very effective DoS (Denial of Service) attack against the victim. Most often, the attacker spoofs the ICMP echo request packets using an unsuspecting third party’s IP address as the source IP address. If the third party is unaware their IP address is being used in the attack, and most often they are, they are themselves a victim of the attack. When the third party receives ICMP echo requests to its broadcast address with a destination IP address of the victim, all the third party machines that respond to broadcast pings from the subnet to which the broadcast address belongs flood the victim with ICMP echo replies. The third party’s echo replies then consume the victim’s bandwidth to the point that their network is possibly unusable.

Correlations:

Chris Kuethe reported similar traffic to his network in his GCIA practical (http://www.sans.org/y2k/practical/chris_kuethe_gcia.html#1.4). One fact Chris mentioned that I was not aware of is that “3dns and other load-balancers often seem to put the IP address of whatever they're probing in the payload.” [9]. This does not appear to be the case with my detect.

In the packet trace, the TOS was set to 0xC0, or decimal 192. The TOS field, according to Stevens in "TCP/IP Illustrated, Volume 1" cannot take on this value in non-corrupted, uncrafted IP header. More specifically, the low order bit of the 8-bit TOS field must be zero, and the first 3-bits are ignored in IPv4 today [2]. Thus, only the remaining 4-bits are to be used, and only one of the four bits can be turned on [2]. Given these facts, the TOS should never have a value a greater than decimal 16 or hex 0x10 (achieved when the high order bit of the 4-bit chunk is turned on).

However, according to http://project.honeynet.org/papers/finger/traces.txt, packets originating from a Cisco router use a TOS of 192, which is useful for doing passive fingerprinting. Do note that Cisco normally uses a IP ID of 0, which is not the case here. All the packets had an IP ID of 1206 and an ICMP ID and sequence number of 0. Since the packets all arrived within milliseconds of each other, the probability that the IP ID could be 1206 in every packet is very small. This is additional evidence of crafting by an attacker.

A search of the SANS CID (Consensus Intrusion Database) did not yield any hits. URL: http://www.incidents.org/cid/search.php. Search parameter: Source IP = 62.156.62.162.

Evidence of Active Targeting:

This could be a Smurf attack, but again it is unlikely. If it was, it was definitely targeted against my network or at my company in general. Assuming this was a Smurf broadcast scan, this attack was doing active targeting due to the packet payload and odd values in several of the IP and ICMP header fields.

8

http://www.incidents.org/cid/search.php

http://project.honeynet.org/papers/finger/traces.txt

http://www.sans.org/y2k/practical/chris_kuethe_gcia.html#1.4

Severity:

Criticality – None of the hosts in the network responded to this scan. However, had any host responded and was subsequently used as a Smurf amplifier, the incident would have had political, if not legal, repercussions for the company (and my career). Criticality = 3.

Lethality – This scan did not do any damage, but it could have resulted in the attacker mapping the network, or have even caused a DoS condition. Lethality = 3.

System Countermeasures – System countermeasures existed on the router (the command no ip directed-broadcast was applied to all interfaces), the firewall does not respond to echo requests, and all external machines behind the router and in front of the firewall do not accept connections from the Internet. However, all internal UNIX machines will respond to an echo request sent to the broadcast or network address. System Countermeasures = 3.

Network Countermeasures – The router does not accept directed broadcast pings, the firewall denies all inbound and outbound echo requests and replies, and was running the latest version of Bind (8.2.3-REL). Network Countermeasures = 5.

(Criticality + Lethality) – (System Countermeasures + Network Countermeasures) = Severity

(3 + 3) – (3 + 5) = -2

Defensive Recommendation:

The internal UNIX machines should be configured to not respond to an ICMP echo request in the unlikely event the firewall is compromised. In addition, the Snort box running in NIDS mode should have the following signature added to its local.rules file (after modifying the content string):

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Echo Request SendIP Smurf Scanner and Subnet Broadcast Recon"; itype:8; icmp_id:0; icmp_seq:0; content: "| The first two or three octets of your IP block in here, in hex, without spaces. See the note below. |";)

Note: If your IP block is the class C network 192.168.1 or the class B network 192.168, the content string should be: “|C0A801|” or “|C0A8|”, respectively.

Multiple Choice Test Question:

Which of the following is most likely to indicate a maliciously-crafted ICMP echo-request?

9

a) The destination IP address is embedded in the ICMP payloadb) The TOS value is greater than decimal 16, or hex 0x10c) The IP ID is 0d) The ICMP sequence number is 0

Answer - The best answer is (b). The destination address could appear in the payload (3dns and load balancers can create this kind of traffic), and the IP ID ICMP sequence numbers can be zero in an uncrafted packet. However, a TOS value greater than decimal 16 indicates either the packet was crafted or was created by an OS that uses a non-standard TOS value (such as Cisco IOS 12.0).

Detect #2 – DNS Named Version Request and BIND 8 TSIG BufferOverflow Attempt




Snort Logs:

06/04-18:49:01.105694 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A203.239.54.93:2636 -> a.b.c.134:53 TCP TTL:48 TOS:0x0 ID:54865 IpLen:20 DgmLen:60 DF******S* Seq: 0xB92DCE6D Ack: 0x0 Win: 0x7D78 TcpLen: 40TCP Options (5) => MSS: 1460 SackOK TS: 149957298 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:02.354439 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A203.239.54.93:2641 -> a.b.c.139:53 TCP TTL:48 TOS:0x0 ID:55337 IpLen:20 DgmLen:60 DF******S* Seq: 0xB93A3F09 Ack: 0x0 Win: 0x7D78 TcpLen: 40TCP Options (5) => MSS: 1460 SackOK TS: 149957427 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:08.558559 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A203.239.54.93:3131 -> a.b.c.229:53 TCP TTL:48 TOS:0x0 ID:56931 IpLen:20 DgmLen:60 DF******S* Seq: 0xB9E3E5C6 Ack: 0x0 Win: 0x7D78 TcpLen: 40

10

TCP Options (5) => MSS: 1460 SackOK TS: 149958046 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/04-18:49:08.558736 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x4Aa.b.c.229:53 -> 203.239.54.93:3131 TCP TTL:255 TOS:0x0 ID:34744 IpLen:20 DgmLen:60 DF***A**S* Seq: 0x16B9584F Ack: 0xB9E3E5C7 Win: 0x2798 TcpLen: 40TCP Options (6) => NOP NOP TS: 108073138 149958046 NOP WS: 0 TCP Options => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:11.538454 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A203.239.54.93:3131 -> a.b.c.229:53 TCP TTL:48 TOS:0x0 ID:58240 IpLen:20 DgmLen:60 DF******S* Seq: 0xB9E3E5C6 Ack: 0x0 Win: 0x7D78 TcpLen: 40TCP Options (5) => MSS: 1460 SackOK TS: 149958346 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:11.538621 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x42a.b.c.229:53 -> 203.239.54.93:3131 TCP TTL:255 TOS:0x0 ID:34903 IpLen:20 DgmLen:52 DF***A**** Seq: 0x16B95850 Ack: 0xB9E3E5C7 Win: 0x2798 TcpLen: 32TCP Options (3) => NOP NOP TS: 108073436 149958046

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:12.051970 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x4Aa.b.c.229:53 -> 203.239.54.93:3131 TCP TTL:255 TOS:0x0 ID:34924 IpLen:20 DgmLen:60 DF***A**S* Seq: 0x16B9584F Ack: 0xB9E3E5C7 Win: 0x2798 TcpLen: 40TCP Options (6) => NOP NOP TS: 108073488 149958046 NOP WS: 0 TCP Options => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:12.275333 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x42203.239.54.93:3131 -> a.b.c.229:53 TCP TTL:48 TOS:0x0 ID:58616 IpLen:20 DgmLen:52 DF***A**** Seq: 0xB9E3E5C7 Ack: 0x16B95850 Win: 0x7D78 TcpLen: 32TCP Options (3) => NOP NOP TS: 149958419 108073488

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:13.470766 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x48203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59035 IpLen:20 DgmLen:58Len: 38

11

4F A0 00 00 00 01 00 00 00 00 00 00 07 76 65 72 O............ver73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 sion.bind.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:13.471120 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x69a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34971 IpLen:20 DgmLen:91 DFLen: 714F A0 84 80 00 01 00 01 00 00 00 00 07 76 65 72 O............ver73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 07 56 sion.bind......V45 52 53 49 4F 4E 04 42 49 4E 44 00 00 10 00 03 ERSION.BIND.....00 00 00 00 00 09 08 43 72 61 79 20 43 39 30 .......Cray C90

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:13.698376 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x1FB203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59045 IpLen:20 DgmLen:493Len: 4734F A0 09 80 00 00 00 01 00 00 00 00 3E 41 41 41 O...........>AAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 3E 42 42 42 42 AAAAAAAAAAA>BBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 3E 43 43 43 43 43 BBBBBBBBBB>CCCCC43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC43 43 43 43 43 43 43 43 43 3E 00 01 02 03 04 05 CCCCCCCCC>......06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 ................16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 .......... !"#$%26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 &'()*+,-./01234536 37 38 39 3A 3B 3C 3D 3E 45 45 45 45 45 45 45 6789:;<=>EEEEEEE45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE45 45 45 45 45 45 45 3E 46 46 46 46 46 46 46 46 EEEEEEE>FFFFFFFF46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 FFFFFFFFFFFFFFFF46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 FFFFFFFFFFFFFFFF46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 FFFFFFFFFFFFFFFF46 46 46 46 46 46 3D 47 47 47 47 47 47 47 47 47 FFFFFF=GGGGGGGGG47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG47 47 47 47 00 00 01 00 01 00 00 00 01 00 FF 40 GGGG...........@66 f

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:13.698723 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x3Ca.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34979 IpLen:20 DgmLen:40 DFLen: 20

12

4F A0 89 81 00 00 00 00 00 00 00 00 O...........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:13.924807 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x228203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59049 IpLen:20 DgmLen:538Len: 5184F A0 00 00 00 01 00 00 00 00 00 01 3C 90 89 E6 O...........<...83 C6 40 C7 06 02 00 0B AC C7 46 04 97 C4 47 A0 [email protected] C0 89 46 08 89 46 0C 31 C0 89 46 28 40 89 46 1..F..F.1..F(@.F24 40 89 46 20 8D 4E 20 31 DB 43 31 C0 83 C0 66 [email protected] .N 1.C1...f51 53 50 CD 80 89 46 20 90 3C 90 8D 06 89 46 24 QSP...F .<....F$31 C0 83 C0 10 89 46 28 58 5B 59 43 43 FF 76 20 1.....F(X[YCC.v CD 80 5B 4F 74 32 8B 04 24 89 46 08 90 BD CB EF ..[Ot2..$.F.....36 5D 89 6E 04 C7 06 03 80 35 86 B8 04 00 00 00 6].n.....5......8D 0E 31 D2 83 C2 0C CD 80 C7 06 02 00 61 AE 89 ..1..........a..6E 04 90 31 FF 47 EB 88 90 31 C0 83 C0 3F 31 C9 n..1.G...1...?1.50 CD 80 58 41 CD 80 C7 06 2F 62 69 6E C7 46 04 P..XA..../bin.F.2F 73 68 00 89 F0 83 C0 08 89 46 08 31 C0 89 46 /sh.......F.1..F0C B0 0B 8D 56 0C 8D 4E 08 89 F3 CD 80 31 C0 40 ....V..N.....1.@CD 80 3E 41 41 41 41 41 41 41 41 41 41 41 41 41 ..>AAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 3E 42 42 42 42 42 42 42 42 42 42 42 42 42 42 A>BBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB03 43 43 43 10 06 00 00 00 B7 FD FF FF E3 FF FF .CCC............FF 00 FF FF FF 3E 41 41 41 41 41 41 41 41 41 41 .....>AAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA41 41 41 41 3E 42 42 42 42 42 42 42 42 42 42 42 AAAA>BBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB42 42 42 10 43 43 43 43 43 43 43 43 43 43 43 43 BBB.CCCCCCCCCCCC43 43 43 43 00 00 01 00 01 00 00 FA 00 FF CCCC..........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:13.925166 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x52a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34981 IpLen:20 DgmLen:68 DFLen: 484F A0 80 89 00 00 00 00 00 00 00 01 00 00 FA 00 O...............FF 00 00 00 00 00 11 00 00 00 3B 1C 20 5E 01 2C ..........;. ^.,00 00 4F A0 00 11 00 00 ..O.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/04-18:49:46.092931 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x42203.239.54.93:3131 -> a.b.c.229:53 TCP TTL:48 TOS:0x0 ID:2615 IpLen:20 DgmLen:52 DF***A***F Seq: 0xB9E3E5C7 Ack: 0x16B95850 Win: 0x7D78 TcpLen: 32TCP Options (3) => NOP NOP TS: 149961798 108073488

13

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/04-18:49:46.093058 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x42a.b.c.229:53 -> 203.239.54.93:3131 TCP TTL:255 TOS:0x0 ID:10263 IpLen:20 DgmLen:52 DF***A**** Seq: 0x16B95850 Ack: 0xB9E3E5C8 Win: 0x2798 TcpLen: 32TCP Options (3) => NOP NOP TS: 108076892 149961798

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/04-18:49:46.093208 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x42a.b.c.229:53 -> 203.239.54.93:3131 TCP TTL:255 TOS:0x0 ID:10264 IpLen:20 DgmLen:52 DF***A***F Seq: 0x16B95850 Ack: 0xB9E3E5C8 Win: 0x2798 TcpLen: 32TCP Options (3) => NOP NOP TS: 108076892 149961798

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/04-18:49:46.311656 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x42203.239.54.93:3131 -> a.b.c.229:53 TCP TTL:48 TOS:0x0 ID:2959 IpLen:20 DgmLen:52 DF***A**** Seq: 0xB9E3E5C8 Ack: 0x16B95851 Win: 0x7D78 TcpLen: 32TCP Options (3) => NOP NOP TS: 149961824 108076892

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Source of Trace:



The Gauntlet firewall detect was generated by a UNIX (Solaris 2.6) Gauntlet 5.5 firewall. The Snort detects were generated by the Snort version 1.7 using the snort.org ruleset available at http://www.snort.org, and the following custom Snort signature:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS BIND Version Request"; content:"VERSION"; nocase;)

Snort also alerted based on the following signature. The attack appears to be a slight variant of the TSIG Buffer Overflow attack, which first sends an inverse query to the victim before sending a false TSIG record. Thus, the signature below matched on the content in the first packet sent by the attacker after receiving the DNS version number they requested.

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS named iquery attempt"; content: "|0980 0000 0001 0000 0000|"; offset: 2; depth: 16; reference:arachnids,277; reference:cve,CVE-1999-009; reference:bugtraq,134;)


The probability this attack was spoofed is very low. The attacker is performing

14


reconnaissance (requesting the version of DNS being used) and launching an attack (buffer overflow attempt) all in the same attack. If the source was spoofed, the reconnaissance information and possible root access would not be available to the attacker. The attacker could be sending the return traffic to another network that is being monitored, but the IP address resolves to the Korea. Korea seems to be the source of, or launch pad for, numerous hostile attacks recently. Most likely, the attacker does not care if their attacks are noticed.


This is a combination of two attacks at once. The attacker is first attempting to negotiate a three way handshake with three different hosts. Then they request the DNS version number from the host that has negotiated a connection with them. After receiving the response, the attacker then appears to launch the BIND TSIG buffer overflow exploit against the responding victim host. After the victim host responds, the attacker either continues to communicate with the victim host, or tears down the TCP connection.

The CVE and CERT advisories for the Inverse Query (CVE-2001-0012) and TSIG Buffer Overflow (CVE-2001-0010) are listed below:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0012http://www.kb.cert.org/vuls/id/325431

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0010 http://www.kb.cert.org/vuls/id/196945

In addition, Paul Asadoorian wrote an excellent paper on the TSIG exploit located here:

http://www.sans.org/newlook/resources/IDFAQ/TSIG.htm

Attack Mechanism:

The attacker fist attempts to complete the three way handshake with three hosts:a.b.c.134, a.b.c.139 and a.b.c.229. The first two hosts are internal interfaces on the external firewall. The connections were dropped by the firewall, as shown in the Gauntlet logs above. The last host, a.b.c.229, is an unallocated IP address on the internal network. The firewall, which is running DNS BIND version 8.2.3-REL, is communicating with the attacker using this IP address. The attacker then requests the version of DNS being run on the firewall, and receives the string “Cray C90”. This is because the version number was hardcoded in /etc/named.conf by putting the following command in the options block:

version "Cray C90";

Having the version number of DNS that name server or firewall is running is quite valuable to an attacker, and organizations should not be providing this information.

15


http://www.kb.cert.org/vuls/id/196945



http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0012

The attacker then sends an iquery (Inverse DNS Query) to the victim host. Quoting Paul Asadoorian, “There is one problem with exploiting the TSIG code; you need to gather information about environment variables whose values are contained on the stack. Access to this information is accomplished by sending an IQUERY (Inverse Query) to the DNS server that will, due to a bug, return the information needed. This bug is known as Infoleak. ” [6].

Version 8.2.3-REL of DNS BIND is not vulnerable to the Infoleak bug, and therefore the environment variable information required for the TSIG exploit was not returned to the attacker. If we interpret the first four bytes of the payload of the victim host’s DNS response, we will see what was returned. The message format of a DNS query and response is as follows, where the first 12 bytes is the fixed-length DNS header [2]:

0 15 16 31Identification number Flags

Number of questions Number of answer RR’s

Number of authority RR’s Number of additional RR’s

Questions(variable length)

Answers(variable number of resource records)

Authority(variable number of resource records)

Additional information(variable number of resource records)

Figure 1: Format of DNS queries and responses

The identification number is the first 16 bits, or 2 bytes, of the DNS response payload. Referring to the victim’s response to the inverse query (shown below for ease of reference), we see that the identification number is 4FA0 in hex. Note that this number first appears in the attacker’s request for the DNS version number, and is returned by the victim to match DNS responses to requests.

06/04-18:49:13.698723 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x3Ca.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34979 IpLen:20 DgmLen:40 DFLen: 204F A0 89 81 00 00 00 00 00 00 00 00 O...........

The remaining 2 bytes of the payload are the DNS flags. The format of this field is as follows [2]:

0 16

16

QR opcode AA TC RD RA (zero) rcode 1 4 1 1 1 1 3 4

Figure 2: Flags field in the DNS Header Record

The fields in the Flags field are as follows [2]:

QR - A 1-bit field that indicates a query or response. A 0 means a query, and 1 means a response.opcode - A 4-bit field that indicates a standard query if the value is a 0, 1 for a inverse query, and 2 for a server status request.AA - A 1-bit flag used to indicate the answer is authoritative. TC - A 1-bit flag that indicates if the reply was truncated as it exceeded 512 bytes.RD - A 1-bit fields that indicates that a recursive answer is desired, and that the name server should handle the query itself.RA - A 1-bit field that means recursion is available. (zero) - A 3-bit field that must be 0.rcode - A 4-bit field that contains the return code. A value of 0 indicates “no error”, a 1 indicates a “format error” and that the name server was unable to interpret the query, and a 3 indicates a “name error” [7].

Referring to the victim’s response, the flag field value is 8981 in hex. Since each digit represents 4 bits, we must translate the hex values into binary and then use Figure 2 and the field definitions to interpret the hex code. The binary representation is as follows: 1000 1001 1000 0001. Thus, we find that the rcode field is set to 1, the RA field is set to 1, the RD field is set to 1, the opcode is 1, and the QR field is set to 1. What is of interest here is that the victim host’s response is saying that there is a format error with this inverse query.

Next, the attacker attempts to perform the TSIG buffer overflow with the following packet containing a false TSIG record and shell code (note that the packet is shown below for ease of reference, and only the first half of the payload data is displayed):

06/04-18:49:13.924807 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x228203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59049 IpLen:20 DgmLen:538Len: 5184F A0 00 00 00 01 00 00 00 00 00 01 3C 90 89 E6 O...........<...83 C6 40 C7 06 02 00 0B AC C7 46 04 97 C4 47 A0 [email protected] C0 89 46 08 89 46 0C 31 C0 89 46 28 40 89 46 1..F..F.1..F(@.F24 40 89 46 20 8D 4E 20 31 DB 43 31 C0 83 C0 66 [email protected] .N 1.C1...f51 53 50 CD 80 89 46 20 90 3C 90 8D 06 89 46 24 QSP...F .<....F$31 C0 83 C0 10 89 46 28 58 5B 59 43 43 FF 76 20 1.....F(X[YCC.v CD 80 5B 4F 74 32 8B 04 24 89 46 08 90 BD CB EF ..[Ot2..$.F.....36 5D 89 6E 04 C7 06 03 80 35 86 B8 04 00 00 00 6].n.....5......8D 0E 31 D2 83 C2 0C CD 80 C7 06 02 00 61 AE 89 ..1..........a..6E 04 90 31 FF 47 EB 88 90 31 C0 83 C0 3F 31 C9 n..1.G...1...?1.50 CD 80 58 41 CD 80 C7 06 2F 62 69 6E C7 46 04 P..XA..../bin.F.2F 73 68 00 89 F0 83 C0 08 89 46 08 31 C0 89 46 /sh.......F.1..F0C B0 0B 8D 56 0C 8D 4E 08 89 F3 CD 80 31 C0 40 ....V..N.....1.@

17

CD 80 3E 41 41 41 41 41 41 41 41 41 41 41 41 41 ..>AAAAAAAAAAAAA…

What is puzzling about this packet is that the shell command “/bin/sh” is not a contiguous string. The hex string C7 46 04 is inserted between the “/bin” and the “/sh”. At first I thought that this could be a case of packet corruption on the wire, or the attacker had a typo in their exploit code. Then I considered that it might be a case of IDS evasion, where the attacker is trying to evade any signatures that look for “/bin/sh” as a contiguous string. Also of interest is that this packet does not look very similar to the corresponding packet in Paul Asadoorian’s paper, but is exactly the same size. Note that the size of the payload is 6 bytes more than the maximum allowable 512 bytes, not including the IP or UDP header, and that the TC (truncation) flag is NOT turned on.

In the detect from my network, when compared to Paul Asadoorian’s trace, the fill in the packet payload has changed, as well as the “/bin/sh” string being broken apart. After digging into “TCP/IP Illustrated, Volume 1”, it appears that the attacker is using counts to obfuscate the existence of the /bin/sh string. Before going into counts, first notice that the attacker has sent one “question”. This is the first hex byte with a rectangle around it in the packet above. In Paul’s trace, the number of questions is 7. This could easily account for why the “/bin/sh” command is not located at the same byte offset from the beginning of the payload. The questions field is composed of a variable length query name and terminated with a zero byte, with the next two fields in the question being the query type and query class, both of which are 16 bits.

The purpose of the 1-bit count (which are the next two rectangles), is to identify the number of bits in each label in the query name. The labels indicate the number of hierarchical levels in the query name. For instance, spock.startrek.com has three labels, where the labels would have decimal value 5, 8 and 3. Thus, the query name in the detect has been broken down into two labels of cardinality 6 and 4, which are the following two rectangles above. The query name is terminated with a 0 (hex 00), and then followed by the 16-bit query type. The query type is 89F0 in hex (underlined in the packet above), which is 35312 in decimal. The query type 35312 is unassigned as of September, 2000 [8]. The query class value, which is 83c0 in hex and 33728 in decimal (italicized and following the query type in the above packet), is also unassigned [8].

The next packets in the detect (below) shows the victim host responding to the unsuccessful buffer overflow attempt with a rcode of 9 (reserved for future use [7]), an opcode of 0 (a standard query), and a QR value of 1 (it’s a response).

06/04-18:49:13.925166 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x52a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34981 IpLen:20 DgmLen:68 DFLen: 484F A0 80 89 00 00 00 00 00 00 00 01 00 00 FA 00 O...............FF 00 00 00 00 00 11 00 00 00 3B 1C 20 5E 01 2C ..........;. ^.,00 00 4F A0 00 11 00 00 ..O.....

18

Finally, there is a 32-second delay as the attacker's code most likely decides the necessary environment variable information was not returned and tears down the TCP session that it had previously opened with the victim host.

Correlations:

It does not appear this attack variant is in wide use, as no correlations were found. However, DNS version request attacks are quite common. [email protected] received the DNS Bind version request attack shown below, and is also available online at the following URL: http://www.sans.org/y2k/041101.htm.

Apr 8 20:00:35 hosty named[154067]: security: notice: denied query from [212.187.178.91].4887 for "version.bind"Apr 8 20:00:34 hostm named[5978]: security: notice: denied query from [212.187.178.91].4888 for "version.bind"Apr 8 20:00:36 hostj named[371]: security: notice: denied query from [212.187.178.91].4889 for "version.bind"

A search for a correlation of the BIND 8 TSIG buffer overflow attack proved fruitless. However, the attacker’s IP has been reported to the SANS CID as having generated traffic to port 53 TCP and UDP, and ICMP on 6/8/01. URL: http://www.incidents.org/cid/search.php. Search parameter: Source IP = 203.239.54.93.


The attacker targeted three IP addresses in a class C subnet. Two of the IP addresses wereinterfaces on a firewall that was running DNS. Given that this attack was against DNS BIND, this was active targeting.

Severity:

Criticality – While the firewall dropped the SYN packets bound for the internal firewall interfaces, it accepted the packet addressed to the unallocated IP address. However, DNS is designed to answer queries and return the version number (in its default configuration). Had a vulnerable version of BIND been running, the criticality would have been much higher. Criticality = 3.

Lethality – This attack did not do any damage to the network, but could have resulted in a root compromise if a vulnerable version of BIND was running on the firewall. Lethality = 5.

System Countermeasures – System countermeasures existed on the firewall. The version of DNS was obfuscated in the /etc/named.conf file, and a version of BIND, 8.2.3-REL, was being used that is not vulnerable to the Infoleak and TSIG exploits. The firewall was also fully patched. The firewall did respond to the attackers inverse query and TSIG record packets, but it was nothing that could be considered "crown jewel" quality. However, the firewall did respond to the attacker inverse query. System Countermeasures = 3.

19


http://www.sans.org/y2k/041101.htm

Network Countermeasures – The firewall was running the ISC (http://www.isc.org) recommended version of BIND at the time of the attack. A more secure architecture would have been a separate DNS server that is hardened and has BIND running in a chroot'd environment. Network Countermeasures = 3.

(Criticality + Lethality) – (System Countermeasures + Network Countermeasures) = Severity(3 + 5) – (3 + 3) = 2


A better method of defense than obfuscating the DNS version number would be to add the following substatement to the “options” block of the named.conf file for BIND 8.2.3 (or 8.2.4) to restrict all queries to only authorized servers:

allow-query {external.dns.server.ip.1; external.dns.server.ip.2; internal.network.1.address/subnetmask; internal.network.2.address/subnetmask; … internal.network.x.address/subnetmask; };

Next, update BIND to version 8.2.4, per the recommendation of http://www.isc.org. The newest version of BIND is always available here: http://www.isc.org/products/BIND.

Finally, run BIND in a chroot'd environment on a dedicated DNS server that has been hardened using YASSP (http://www.sans.org/newlook/resources/hard_solaris.htm) for a Solaris box, or Bastille-Linux (http://www.sans.org/newlook/projects/bastille_linux.htm) for a Linux box.


The maximum allowable size of a UDP DNS response payload, not including the IP or UDP header, is:

a) 532 bytesb) 1460 bytesc) 512 bytesd) 20 bytes

Answer - The correct answer is (c). DNS query responses are limited to 512 bytes of packet payload. If the payload exceeds 512 bytes, the data should be truncated and the TC flag should be set to "1" in the TC field of the fixed length DNS header flags field.

20

http://www.sans.org/newlook/projects/bastille_linux.htm

http://www.sans.org/newlook/resources/hard_solaris.htm

http://www.isc.org/products/BIND

http://www.isc.org/

http://www.isc.org/

Detect #3 - School Bus Trojan Scan






May 28 01:35:04 firewall.mycompany.com unix: securityalert: no match found in local screen: TCP if=hme0 srcaddr=216.61.164.172 srcport=54321 dstaddr=a.b.c.17 dstport=54321


Snort Logs:

05/28-01:26:58.569727 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C216.61.164.172:54321 -> a.b.c.6:54321 TCP TTL:238 TOS:0x0 ID:16995 IpLen:20 DgmLen:40******S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x28 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/28-01:26:58.572439 0:2:FD:4B:5C:60 -> 0:D0:59:13:7C:D2 type:0x800 len:0x3C216.61.164.172:54321 -> a.b.c.2:54321 TCP TTL:238 TOS:0x0 ID:16995 IpLen:20 DgmLen:40******S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x28 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/28-01:26:58.583086 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C216.61.164.172:54321 -> a.b.c.34:54321 TCP TTL:238 TOS:0x0 ID:16995

21

IpLen:20 DgmLen:40******S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x28 TcpLen: 20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Source of Trace:



The Gauntlet firewall detect was generated by a UNIX (Solaris 2.6) Gauntlet 5.5 firewall. Snort did not alert on this attack, as I did not have a signature to match on port 54321 TCP. The Snort box I had running in sniffer mode did capture the packets, however. A simple Snort rule is shown below that will detect this scan. Note that while a destination and source port of 54321 is highly unlikely, it is possible as part of normal IP traffic.

alert tcp $EXTERNAL_NET 54321 -> $HOME_NET 54321 (msg:"Possible School Bus Trojan Tasking";)

Also, the Snort detect shows an additional host being scanned (a.b.c.2) that the firewall logs did not detect. This was the Snort box running in NIDS mode in front of the firewall. This host was running IPchains and hardened using Bastille-Linux.

Finally, this attacker scanned 147 hosts in my class C subnet. For brevity, the firewall and Snort logs have been reduced to only show the first few hosts that were scanned.


The probability this scan was spoofed is unlikely. If it were, the attacker would not know if they contacted a listening trojan or not. The attacker could be sending the return traffic to another network that is being monitored, but based on the correlation data, it appears the host was probably compromised and the attacker was using it as a launch pad for their scans.


22

This attack is a scan for a listening School Bus Trojan. The attacker is searching for hosts that have a School Bus server installed on them and are accepting connections on TCP port 54321. If the attacker finds a host that has a listening server, they are able to remotely access the infected host. Note that this Trojan only affects Windows versions 95 and 98.

Very little information seems to exist on this Trojan. The Simovits site has some information on it, available at the following URL: http://www.simovits.com/trojans/tr_data/y1140.html. Packetstrom does not appears to have this Trojan available for download. Some of the sites found to have Schoolbus and/or Schoolbus 2.0 available appear to be foreign owned. Caution should be exercised in downloading the supposed Trojan from these sites.

http://sirmanteam.virtualave.net/html/trojan.html http://home.soneraplaza.nl/qn/prive/rolandus/hackstuf1.htm http://209.235.102.9/~kpb26432/files/trojan.htm

Attack Mechanism:

The attacker is attempting to initiate a three-way handshake with victim hosts on port 54321. If the victim host responds and the three-way handshake is completed, the School Bus client software can issue remote commands on the victim’s machine.

Of particular interest is the TCP sequence and ACK numbers of the packets. The sequence number is the same for all the connection attempts, and the Ack number is non-zero. According to TCP/IP Illustrated, Volume 1, the Ack field should never be set without the ACK flag turned on [2]. In addition, note that the IP ID field has also been hardcoded to 16995. This suggests that an automated tool crafted these packets.

Correlations:

The following correlations to this same attacker were reported to the incidents.org mailing list on May 29, 2001:

(Matt Fernow)May 28 12:41:41 ipmon[5875]: xl1 @0:19 b 216.61.164.172,54321 -> a.b.c.2,54321 PR tcp len 20 40 -S INMay 28 12:41:41 ipmon[5875]: xl1 @0:19 b 216.61.164.172,54321 -> a.b.c.1,54321 PR tcp len 20 40 -S INMay 28 12:41:56 ipmon[5875]: xl1 @0:19 b 216.61.164.172,54321 -> a.b.c.1,54321 PR tcp len 20 40 -R IN

(Brent Erickson)May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.1:54321 SYN ******S*May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.2:54321 SYN ******S*May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.3:54321 SYN ******S*May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.6:54321 SYN ******S*May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.4:54321 SYN ******S*May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.5:54321 SYN ******S*

23

http://209.235.102.9/~kpb26432/files/trojan.htm

http://home.soneraplaza.nl/qn/prive/rolandus/hackstuf1.htm

http://sirmanteam.virtualave.net/html/trojan.html

http://www.simovits.com/trojans/tr_data/y1140.html

May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.8:54321 SYN ******S*May 27 04:21:22 216.61.164.172:54321 -> xxx.xxx.123.10:54321 SYN ******S*

(Gary Portnoy)05/27-00:25:02.890304 0:2:4B:BC:B9:E0 -> 8:0:20:B8:F2:36 type:0x800 len:0x3C216.61.164.172:54321 -> x.y.z.7:54321 TCP TTL:240 TOS:0x0 ID:28897 IpLen:20DgmLen:40 ******S* Seq: 0x660963E4 Ack: 0x63610C07 Win: 0x28 TcpLen: 20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+05/27-00:25:02.891843 0:2:4B:BC:B9:E0 -> 8:0:20:B8:F2:36 type:0x800 len:0x3C216.61.164.172:54321 -> x.y.z.15:54321 TCP TTL:240 TOS:0x0 ID:28897 IpLen:20DgmLen:40 ******S* Seq: 0x660963E4 Ack: 0x63610C07 Win: 0x28 TcpLen: 20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+05/27-00:25:02.904206 0:2:4B:BC:B9:E0 -> 8:0:20:B8:F2:36 type:0x800 len:0x3C216.61.164.172:54321 -> x.y.z.25:54321 TCP TTL:240 TOS:0x0 ID:28897 IpLen:20DgmLen:40 ******S* Seq: 0x660963E4 Ack: 0x63610C07 Win: 0x28 TcpLen: 20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

A search of the SANS CID yielded reports of activity from this attacker dating 5/26/01 through 5/29/01. URL: http://www.incidents.org/cid/search.php. Search parameters: Source IP = 216.61.164.172 and Source/Target ports = 54321.


This attacker was deliberately scanning multiple networks on the Internet looking for a listening School Bus trojan. It is unlikely that the attacker was targeting my particular network, but they did scan most of the addresses in the subnet.

Severity:

Criticality – Since the scan attempted to connect with every box in my subnet, including the firewall and all Windows workstations, the criticality of this attack is high. Criticality = 5.

Lethality – Had any of the Windows hosts in the network been infected with the trojan, and the host was able to communicate on TCP port 54321 with the attacker, the lethality would have been high. Lethality = 4.

System Countermeasures – All the hosts on the external side of the firewall had a host based firewall, did not have an IP address assigned to its interface, or did not receive any packets from the Internet due to ACL's on the border router. All the web, application, and log servers on the internal side of the firewall were hardened with YASSP. All Windows machines were running anti-virus software whose signatures are updated weekly. Finally, the firewall does not accept connections on TCP port 54321, or allow outbound connections on this port either. System Countermeasures = 4.

Network Countermeasures – A properly configured network firewall, and host based firewalls on selected machines in the unprotected DMZ, mitigated the risk of this attack. Network Countermeasures = 5.

24



(5 + 4) – (4 + 5) = 0


The only recommendation is to add the following rule to the Snort box running in NIDS mode. While the port 54321 is hard to miss in firewall logs, having another alert to this particular attack scan is a good idea.

alert tcp $EXTERNAL_NET 54321 -> $HOME_NET 54321 (msg:"Possible School Bus Trojan Tasking";)


Consider the bolded text. Which of the following traces best indicates a crafted packet?

a) 192.168.1.1:54321 -> 192.168.1.10:54321 TCP TTL:238 TOS:0x0 ID:16995IpLen:20 DgmLen:40******S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x28 TcpLen: 20

b) 192.168.1.1:54321 -> 192.168.1.10:54321 TCP TTL:238 TOS:0x0 ID:16995IpLen:20 DgmLen:40***A**S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x28 TcpLen: 20

c) 192.168.1.1:54321 -> 192.168.1.10:54321 TCP TTL:238 TOS:0x0 ID:16995IpLen:20 DgmLen:40***A**S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x4470 TcpLen: 20

d) 192.168.1.1:54321 -> 192.168.1.10:54321 TCP TTL:238 TOS:0x0 ID:16995IpLen:20 DgmLen:40******S* Seq: 0x759C2DE3 Ack: 0x0 Win: 0x28 TcpLen: 20

Answer: The correct answer is (a). The acknowledgment field should never be set, or have a non-zero value, when the ACK flag is not set.

Detect #4 – Network Mapping Attempt Using Ident/Auth SYN-ACK and RST-ACK Packets



Snort Logs:

06/16-13:42:25.862612 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C

25

209.25.135.78:113 -> a.b.c.21:1063 TCP TTL:47 TOS:0x0 ID:49904 IpLen:20 DgmLen:44 DF***A**S* Seq: 0xCEE35D9D Ack: 0x262411B3 Win: 0x4470 TcpLen: 24TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/16-13:42:25.863229 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.21:1063 TCP TTL:47 TOS:0x0 ID:49923 IpLen:20 DgmLen:40 DF***A*R** Seq: 0xCEE35D9E Ack: 0x262411B3 Win: 0x4470 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/16-17:25:35.034206 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.22:1053 TCP TTL:47 TOS:0x0 ID:46775 IpLen:20 DgmLen:44 DF***A**S* Seq: 0xA2771CAF Ack: 0x662AB3F4 Win: 0x4470 TcpLen: 24TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/16-17:25:35.034698 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.22:1053 TCP TTL:47 TOS:0x0 ID:46778 IpLen:20 DgmLen:40 DF***A*R** Seq: 0xA2771CB0 Ack: 0x662AB3F4 Win: 0x4470 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/16-19:23:05.875818 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.18:1200 TCP TTL:47 TOS:0x0 ID:11335 IpLen:20 DgmLen:44 DF***A**S* Seq: 0x1C967005 Ack: 0xC633A6CD Win: 0x4470 TcpLen: 24TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/16-19:23:05.895233 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.18:1200 TCP TTL:47 TOS:0x0 ID:11516 IpLen:20 DgmLen:40 DF***A*R** Seq: 0x1C967006 Ack: 0xC633A6CD Win: 0x4470 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/17-14:04:20.300712 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.19:1122 TCP TTL:47 TOS:0x0 ID:58881 IpLen:20 DgmLen:44 DF***A**S* Seq: 0x845C4A11 Ack: 0xF6ABDB33 Win: 0x4470 TcpLen: 24TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/17-14:04:20.301139 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.19:1122 TCP TTL:47 TOS:0x0 ID:58888 IpLen:20 DgmLen:40 DF***A*R** Seq: 0x845C4A12 Ack: 0xF6ABDB33 Win: 0x4470 TcpLen: 20

26

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/17-14:38:00.640553 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.17:1222 TCP TTL:47 TOS:0x0 ID:33009 IpLen:20 DgmLen:44 DF***A**S* Seq: 0xC9147887 Ack: 0x862D048C Win: 0x4470 TcpLen: 24TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/17-14:38:00.641473 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.17:1222 TCP TTL:47 TOS:0x0 ID:33024 IpLen:20 DgmLen:40 DF***A*R** Seq: 0xC9147888 Ack: 0x862D048C Win: 0x4470 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/17-19:30:02.612168 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.135:1051 TCP TTL:47 TOS:0x0 ID:50598 IpLen:20 DgmLen:44 DF***A**S* Seq: 0x58E90088 Ack: 0x662AB3FD Win: 0x4470 TcpLen: 24TCP Options (1) => MSS: 1460 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/17-19:30:02.612661 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C209.25.135.78:113 -> a.b.c.135:1051 TCP TTL:47 TOS:0x0 ID:50607 IpLen:20 DgmLen:40 DF***A*R** Seq: 0x58E90089 Ack: 0x662AB3FD Win: 0x4470 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Source of Trace:



The Gauntlet firewall detect was generated by a UNIX (Solaris 2.6) Gauntlet 5.5 firewall. Snort did not alert on this attack, as I did not have a signature to match on packets with the SA and RA flags set. The Snort box I had running in sniffer mode did capture the packets, however. The following rule for Snort Version 1.7 will detect ident/auth scans such as this one:

alert TCP $ EXTERNAL_NET 113 -> $HOME_NET :1024 (msg: "Possible Ident/Auth Ack+ Scan"; flags: A+;)

Note that the only packet that was logged was the one bound for the internal interface of the firewall.


This scan could be the result of a DOS attack on a third party, or a SYN-ACK and RST-ACK scan of my network. If it was a DOS attack, the source IP is the intended

27

victim, and the attacker is intending we receive the responses from the client. If it was a SYN-ACK and RST-ACK scan, the attacker will want to see the responses that their stimulus packets initiated.

A third possibility is that the attacker has compromised the source IP’s host, and is monitoring for responses using a sniffer. This means that they are launching the attack from another location and spoofing their IP to be the source IP’s in the packets we receive. While this is a slightly more involved attack than a scan from the source IP’s host, it is possible that this is the case.

A whois and a traceroute on the source IP, 209.25.135.78, yielded the following (the first three hops have been sanitized):

Server used for this query: [ whois.arin.net ]Maxim (NETBLK-MAXIM-NETBLK-3)42712 Lawrence PlaceFremont, CA 94538USNetname: MAXIM-NETBLK-3Netblock: 209.25.128.0 - 209.25.255.255

Inet King Internet Service, Inc (NETBLK-MAX-CUSTNET-449)288 Blackcreek DriveCopperopolis, CA 95228USNetname: MAX-CUSTNET-449Netblock: 209.25.135.0 - 209.25.135.255

1 a.b.c.1 (a.b.c.1) 1.075 ms 1.008 ms 1.016 ms2 a.b.d.5 (a.b.d.5) 4.170 ms 4.711 ms 4.585 ms3 router.mycompany.com (w.x.y.z) 5.535 ms 5.214 ms 5.438 ms4 s4-0-1.crtntx1-cr1.bbnplanet.net (4.24.104.49) 7.185 ms 6.508 ms 6.589 ms5 s8-0-0.xcrtntx15-abovenet.bbnplanet.net (4.24.104.22) 7.742 ms 8.130 ms 7.760 ms6 core1-dfw1-oc48.dfw2.above.net (208.184.232.118) 8.231 ms 8.123 ms8.145 ms7 dca2-dfw2-oc48.dca2.above.net (216.200.127.206) 36.175 ms 36.496ms 36.938 ms8 sjc2-dca2-oc48.sjc2.above.net (208.184.233.133) 102.038 ms 102.235ms 102.021 ms9 core1-core4-oc48.sjc2.above.net (208.184.102.201) 101.946 ms103.481 ms 101.891 ms10 core6-sjc2-oc48.sjc1.above.net (216.200.0.177) 102.050 ms 102.056ms 102.507 ms11 sjc7-sjc1-ds3.sjc7.above.net (207.126.96.194) 103.291 ms 105.189ms 102.776 ms12 208.185.237.74.maxim.net (208.185.237.74) 104.080 ms 102.965 ms106.007 ms13 atm2-0.Fmt-1.hostcentric.com (209.25.128.9) 79.506 ms 79.290 ms79.851 ms14 VLAN6.FMT6509-1.hostcentric.com (66.40.24.70) 81.173 ms 79.516 ms80.950 ms15 * * *…30 * * *

Note that the domain name in the 12th hop and the IP in the 13th hop belong to IP blocks owned by Maxim.net. The IP in the 14th hops also belongs to Maxim, as shown in the following whois query output:

28

Maxim (NETBLK-MAXIM-4)42712 Lawrence PlaceFremont, CA 94538USNetname: MAXIM-4Netblock: 66.40.0.0 - 66.40.255.255

If we assume the TTL has not been crafted, this would mean that the attacker was most likely using a Linux or FreeBSD box that uses a default TTL of 64 (I’m ruling out VMS, HP-UX and OS/2, which are known to use TTL’s of 64). Subtracting 14 from 64 we get 50, and assuming the attacker’s ISP is blocking traceroute at some point in their network, we arrive very close to the TTL value of 47 in the packets received from the source IP. Thus, it appears that the packets arrived from an ISP that is leasing a class C network from the ISP/Collocation company Maxim (http://www.maxim.net), a subsidiary of Hostcentric.

Therefore, the probability the source IP was spoofed is small.Description of the Attack:

Unexpected RST-ACK or SYN-ACK packets are indicative of your IP being used in a spoofing attack. So, either the attacker really is launching the attack from the source IP in the trace against my network, or they are attacking the source IP’s network from an unknown network and are spoofing their source IP to be my network’s.

The latter case could be an indication of a TCP SYN DoS against ident, with the RST-ACK packets also contributing to tying up bandwidth. However, the DoS attack would need to be distributed to be effective. If it was a case of reverse ident scanning, where the attacker queries the ident port from an ephemeral port for connection information, the attacker will not receive the responses unless they are monitoring the local network that they are attacking. In addition, you would expect to see packets from many different hosts as the attacker queries different machines looking for one that will respond to a reverse ident scan.

The RST-ACK and SYN-ACK packets arrived over a 30-hour period, with a delay between the time each host in the network received a stimulus. Therefore, the attacker was most likely attempting to covertly map the network by sending crafted SYN-ACK and RST-ACK packets.

The CVE entry CAN-1999-0629 is under review for having ident/identd service running. The entry is located here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0629.

Attack Mechanism:

29


http://www.maxim.net/

If the destination host exists, the host will send a RST packet in response to the SYN-ACK, and the RST-ACK packet will be silently dropped. If the destination host does not exist, the SYN-ACK and RST-ACK elicit an ICMP destination unreachable message from an intermediate router, assuming a stateful firewall has not intercepted and absorbed the packets. In either case, the attacker will succeed in mapping the existence of the host on the target network.

The third scenario is that the site has a stateful firewall that absorbs all the packets from the attacker, as was this case with this scan. The attacker does not gain any reconnaissance information in this case, unless they have previously determined that the victim host exists. In this case, they may be able to deduce that the site has a stateful firewall in place and the packets have been silently dropped.

The attacker seems to be betting on the victim not using a stateful firewall and hoping that one of the packets elicits a response, and performs the scan over a period of 30 hours to try and remain stealthy. In addition, the attacker could be setting the source port to TCP 113 to make the packets appear to be responses from identd about connections initiated from an internal client to the attacker. Since an IDS like Realsecure 5.5 only identifies this as “IDENT” traffic, and does not display the flags set in the packet, this scan could easily go unnoticed or be disregarded.

Correlations:

The following paper authored by CanCert (Canadian CERT) has identified traffic very similar to the scan addressed in this trace:

http://www.cancert.ca/Docs/AL-2000.01Preliminary5Jan99.pdf

In particular, the paper identifies the following traces shown below. While the SYN-ACK scan used the IRC source port 6667, the paper identifies traffic as also originating from port 113 with these flags as well.

SYN + ACK Probe===============209.249.31.17.6667 > 192.168.0.1.1409: S 653661151:653661151(0) ack 674711610 win 16384 (DF)

RST + ACK Probe===============209.10.135.130.113 > 192.168.0.2.1264: R 0:0(0) ack 674711610 win 0

Note that the ACK number in these two packets was fixed, which was not the case in the scan of my network. According to the paper by NSWC referenced in CanCERT’s paper, http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt, recent RST-ACK scans have contained random sequence numbers.

A search of the SANS CID yielded reports of activity from this attacker dating 6/17/01 through 6/18/01. URL: http://www.incidents.org/cid/search.php. Search parameters: Source IP = 209.25.135.78, source port = 113, target port = 1024-65535, and

30


http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt

http://www.cancert.ca/Docs/AL-2000.01Preliminary5Jan99.pdf

protocol = 6 (TCP). Note these correlations did not contain any flag information. Perhaps the contributor was not using an IDS that captured the flag information in its output, such as ISS Realsecure 5.5. I confirmed that my ISS sensor did not capture the flag information from this scan.


Given the period of time over which the scan was conducted and the deliberate nature of the scan, there is definite evidence of active targeting against my network.

Severity:

Criticality – Since the scan attempted to connect multiple boxes in my subnet, including the firewall, the criticality of this attack is high. Criticality = 5.

Lethality – The attacker could have gained valuable reconnaissance information had the scan been successful. However, the scan could have at most mapped the existence of machines in the subnet. While not a good thing, existence mapping is not particularly lethal in and of itself. Lethality = 3.

System Countermeasures – The firewall did not respond to the SYN-ACK or RST-ACK packets. Had the other hosts received these packets they would have responded with a RST to the SYN-ACK and silently dropped the RST-ACK. However, there is little defense on a host level besides a host-based firewall or host ACL’s like Solaris 8 supports. System Countermeasures = 4.

Network Countermeasures – A properly configured network firewall, and host based firewalls on selected machines in the unprotected DMZ, mitigated the risk of this attack. The border router passes traffic to the proxy firewall, so no ICMP destination unreachable packets were returned from the internal network. Network Countermeasures = 5.


(5 + 3) – (4 + 5) = -1


The only recommendation is to add the following rule to the Snort box running in NIDS mode.

alert TCP $ EXTERNAL_NET 113 -> $HOME_NET :1024 (msg: "Possible Ident Ack+ Scan"; flags: A+;)


31

Reverse ident scanning is best identified by the following source and destination port pairs:

a) TCP 113, TCP 113b) TCP 1024 to 65535, TCP 113c) UDP 113, UDP 113d) TCP 113, TCP 1024 to 65535

Answer: The correct answer is (b). Reverse ident scanning is when the attacker queries the identd deamon on a server for information about the connection between the server and the attacking host, normally from an ephemeral source port.

Detect #5 – Outbound IRC Connection Attempt


Apr 5 15:47:00 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from a.b.c.216:4288 to 194.149.245.6 on unserved port 6667




...


Snort Logs:

No Snort logs were collected for this outbound connection attempt.

Source of Trace:



The Gauntlet firewall detect was generated by a UNIX (Solaris 2.6) Gauntlet 5.5 firewall. The following Snort signature would have identified the attack:

alert TCP $ HOME_NET any -> $EXTERNAL_NET 6667 (msg: "Outbound IRC Connection Attempt";)

32


Given that this scan was initiated on the internal network, the probability the packets were spoofed is very low. The system owner was contacted and it was confirmed they were working on the machine the date the scan occurred.


This connection attempt to port 6667 TCP, the default IRC server port, occurred on the internal network from a specific host over a period of approximately 46 minutes. Notice the interface the packets were detected on was the qfe0 interface. This interface is most often associated with a Solaris box with multiple interface ports, where the hme0 interface is the interface that listens for inbound connections and the qfe* interfaces are internal interfaces used for outbound connections.

Trojans will often infect a host and then attempt to connect to an IRC server to announce their presence. One possibility is that this was the PrettyPark.exe worm. However, this did not appear to be the case. After pulling the network connection and contacting the Program Security Officer, I was directed to install Tiny Personal Firewall and configure it to block outbound connections to port 6667 and turn on logging. I was then directed to monitor the box for further connection attempts before rebuilding the machine. A full virus scan was also run on the box with signatures that are updated weekly, and no infected files were found. Also, outbound mail messages occurring approximately every 30 seconds were NOT observed, nor were any further outbound IRC connection attempts.

Another possibility might be a variant of the exploit referenced in the following post by Para-Protect:http://www.para-protect.com/Advisories/Guests/2001/20010108.0900_ORA1.pdf.This paper identifies potential exploit code used in DDoS attacks that produces a signature similar to the one observed in the firewall logs above. According to Para-Protect [10]:

“The source port is between 4000 and 5000, and the destination port is always 6667 (the default port for IRC servers). An example of code of the type that may have been used to accomplish this attack is posted at http://packetstorm.securify.com/distributed/knight.c. An example of code of the type that may have been used to accomplish this attack is posted at (it is undetermined whether this code was actually used in the attack).”

While the source and destination ports of the connection attempt match the description of this exploit, an inspection of the source code reveals that this code attempts to read to the rc.local file:

FILE *file=fopen("/etc/rc.d/rc.local","r");

Note that the file /etc/rc.d/rc.local is a linux init script that runs after all other init scripts. Its intended purpose is to output information to the screen. In this exploit

33

http://packetstorm.securify.com/distributed/knight.c

http://www.para-protect.com/Advisories/Guests/2001/20010108.0900_ORA1.pdf

code, the attacker is appending their code to the end of the rc.local file, which is owned by root and is executable.

However, the host that generated this traffic was an NT 4.0 box. The binary will not run on a Windows machine if compiled from the source code referenced in the URL above. However, an attacker could have ported this code to Windows and created a statically linked binary that contained the necessary libraries to run independently.

Upon further investigation, it does not appear this was the Trinity or WinSatan Trojan. WinSatan was written in 16-bit code and supposedly does not run on NT, and Trinity is a Linux Trojan. The ScheduleAgent Trojan apparently works on Windows systems, but very little information was found.

Attack Mechanism:

Since the system owner used the Microsoft IE browser exclusively, the source of this connection attempt was believed to have been either a Java or ActiveX Trojan executed within the internal network. The actual cause of this connection attempt, other than the user not intentionally initiating this connection attempt, was not determined.

Whatever the infectous agent was, it tried to connect to the IP 194.149.245.6. A whois query on this IP shows the following:

Server used for this query: [ whois.ripe.net ]inetnum: 194.149.245.0 - 194.149.245.255netname: TELEACTION-SERVICES-OBERURSELdescr: Teleaction Services GmbH, Oberurselcountry: DEadmin-c: HH1239-RIPEtech-c: MS10091-RIPEstatus: ASSIGNED PImnt-by: RIPE-NCC-HM-PI-MNTmnt-by: XLINK-MNTmnt-lower: XLINK-MNTchanged: [email protected] 20000707changed: [email protected] 20000707changed: [email protected] 20000913source: RIPE

Performing a nslookup on the IP 194.149.245.6 results in the following URL: http://www.teresa.de. This site appears to be a German IRC server catering to material of an “adult nature”. Had the firewall not blocked the connection, the infectious agent could have contacted the IRC server with user and password information from the victim host.

Correlations:

34

http://www.teresa.de/

No correlations on SANS GIAC, CID, or Google was found for the destination IP 194.149.245.6.


This network trace occurred on a single machine within a class C subnet, and was targeted at a single destination host.

Severity:

Criticality – Since the infectious agent attempted to connect from the internal network on a development workstation to a German IRC server of questionable content, the criticality of this scan is high. Criticality = 4.

Lethality – The attacker could have gained valuable machine and password information had the connection attempt been successful. Lethality = 5.

System Countermeasures – The workstation in question was patched with Service Pack 6 and had updated McAfee virus scanning software installed. System Countermeasures = 4.

Network Countermeasures – The network firewall blocked the outbound connection attempt. System Countermeasures = 4.


(4 + 5) – (4 + 4) = 1


Personal firewalls should be added to all NT 4.0 workstations. Multiple license packs are available from most vendors for a reasonable price. A short training session for users is also recommended upon installation of the software. In addition, the following Snort rule should be added to the Snort box running in NIDS mode:

alert TCP $ HOME_NET any -> $EXTERNAL_NET 6667 (msg: "Outbound IRC Connection Attempt";)

Users, as well as system and security administrators, should become more familiar with IRC and it’s inherent dangers. The following paper should be recommended reading: http://www.sans.org/infosecFAQ/threats/IRC.htm.

Finally, disable ActiveX, Java and Javascript in Microsoft IE browsers, and Java and Javascript in Netscape browsers.


35

http://www.sans.org/infosecFAQ/threats/IRC.htm

Which of the following UNIX/Solaris Gauntlet firewall logs is most indicative of an internal host infected with a trojan, virus or worm that is attempting to contact an IRC server on the Internet?

a) Apr 5 15:47:00 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 192.168.1.1:4288 to 192.168.1.40 on unserved port 666

b) Apr 5 15:47:00 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 192.168.1.1:4288 to 192.168.1.40 on unserved port 6667

c) Apr 5 15:47:00 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from 192.168.1.1:4288 to 192.168.1.40 on unserved port 6667

d) Apr 5 15:47:00 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from 192.168.1.1:4288 to 192.168.1.40 on unserved port 666

Answer: The correct answer is (c). The default IRC sever port is 6667, and an internal host will attempt to exit the network over an internal interface on the firewall (in this case, the qfe0 interface).

36

Assignment 2 – Describe the State of Intrusion Detection

Netmask-based ICMP Echo Request Smurf Broadcast Scanning with Crafted ICMP Payloads using SendIP

This paper will address the specific reconnaissance technique coined “Netmask-based ICMP Echo Request Smurf Host and Broadcast Scan with Crafted ICMP Payloads” using the tool SendIP.

Reconnaissance Technique:

Name: Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP PayloadsVariants: Broadcast scans to IP addresses with a fourth octet of 0 or 255 are a generalization of this attack. This attack may also be launched without crafting the ICMP payload.Operating System: Any OS that responds to ICMP echo requests sent to a broadcast address.Protocols/Services: IP, ICMP, IP Subnetting, and IP BroadcastingDescription: This reconnaissance technique attempts to map a variably subnetted network's broadcast addresses for later possible use in Smurf attack. What is unique to this attack is that the ICMP payload has been crafted to contain only the broadcast IP addresses. A packet is also sent to the network address of the subnets that are being mapped since BSD-based stacks treat the network address as a broadcast address.

Exploit Details:

Name: SendIP (Version 1.5) Variants: Broadscan, SING, Hping, Hping2, and Nmap are just a few of the tools that can also perform Smurf broadcast scanning.Operating System: The exploit code was tested using Mandrake Linux 7.1. However, it should run on all Linux and UNIX systems.Protocols/Services: ICMPDescription: According to the author, Mike Ricketts, "SendIP has a large number of command line options to specify the content of every header of a RIP, TCP, UDP, ICMP or raw IPv4 and IPv6 packet. It also allows any data to be added to the packet. Checksums can be calculated automatically, but if you wish to send out wrong checksums, that is supported too." [11].

Protocol Description:

IP - Internet Protocol

IP is the transport mechanism for all TCP, UDP, IGMP, and ICMP messages. That is, TCP, UDP, IGMP, and ICMP messages are encapsulated in packets called IP datagrams that begin with a 20-byte standard header. If any IP options are present, the IP header

37

may be as large as 60 bytes. Also, note that IP is a connectionless, unreliable protocol that relies on best effort service instead of stateful awareness of successive IP datagrams. The IP header is shown in Figure 3 below:

The 4-bit version field refers to the version of IP. The current and most used version is version 4, referred to as IPv4. The 4-bit header length is the number of 32 bit words in the IP header, including any IP options. The 8-bit type of service, or TOS, field is composed of three separate parts: the top 3-bits is a precedence value that is not currently used in current versions of IP, a 4-bit TOS value, and an unused bit that must be set to 0. The 4-bit TOS value is set to 0 when normal service is implied, and is what is most often seen in IP datagrams today. The total length is the total length of the IP datagram in bytes. To derive the length of the data portion of the IP datagram, subtract the header length field from the total length field.

The 16-bit identification number is used to uniquely identify each datagram that is sent, and typically increments by one for each packet sent. The 3-bit flags field is used to identify if the packet is fragmented and there are more fragments to follow, or to tell IP not to fragment the datagram. The 13-bit fragment offset is used to repackage the packet stream at the destination host by keeping track of how far the fragment is located in creation order from the original datagram. The 8-bit time-to-live (TTL) value sets an upper bound on the number of hops, or routers, through which the datagram may travel before its lifetime expires. The TTL decrements by one for each hop it makes, and is initialized by the sending hosts' operating system.

The 8-bit protocol field is used to identify the protocol that is encapsulated in the IP datagram. The 16-bit checksum field only addresses the IP header, not the IP data

38

payload. The checksum is used to identify datagrams that were corrupted in transit. If so, the packets are discarded. The 32-bit source and destination address fields store the IP address of the sending and receiving hosts. The IP options field is rarely used, but does support options such as strict and loose source routing and security restrictions. Finally, IP encapsulates the data payload, such as an ICMP echo request message.

ICMP - Internet Control Message Protocol

ICMP is an integral part of the IP layer that acts like a higher level protocol such as TCP or UDP, and was designed for use as a network diagnostic tool. ICMP messages are sent in some of the following situations [1]:

1. When a datagram cannot reach its destination.

2. When the gateway does not have the buffering capacity to forward a datagram.

3. When the gateway can direct the host to send traffic on a shorter network route.

ICMP messages are sent inside a IP datagram using the standard IP header. Figure 4 is a diagram of a 20-byte IP datagram without options and an ICMP message:

ICMP echo request and echo replies are used to test if a host is reachable across a network. Historically, an echo request message is sent, and if the destination host is reachable, an echo reply message is returned. However, with the widespread use of protocol aware firewalls and router ACL's, this is no longer true. A host may refuse an ICMP echo request, but will accept a telnet connection to port 25 (SMTP) [2].

Figure 5, shown below, depicts the standard ICMP echo or echo reply message format:

As defined by RFC 792, http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0792.html

39

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0792.html

The first 8 bits of the ICMP echo and echo reply message is the type field, which defines the format of the remaining message. A type value of zero indicates the ICMP message is an echo reply, and an eight indicates an echo request. The next eight bit field is the code field, and is zero for both echo requests and replies. This field has numerous values in other ICMP types, such as type 3 (destination unreachable messages). The remaining 16 bits of the first four bytes is the checksum field. According to RFC 792, "The checksum is the 16-bit one's complement of the one's complement sum of the ICMP message starting with the ICMP type" [1].

The 16 bit identifier and sequence number fields are used to identify echos and replies when the code field is zero. Note that these fields may be set to zero. The identifier field is set to the PID (process ID) of the sending process in UNIX versions of Ping. The sequence number field is set to zero and increments by one for each ICMP echo request packet that is sent. The ICMP message payload is included next in the datagram, if it exists. Also, note that the payload data (as well as the identifier and sequence number) must be returned in the echo reply message. This requirement is what makes the "Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP Payloads" reconnaissance technique unique.

IP Subnetting

IP subnetting is used to partition a network into smaller sub-networks, or subnets. This is done by bit-masking the network IP address with a subnet mask. The subnet mask consists of a netid, subnetid and hostid portion. The first portion of the subnet mask determines the size of the netid and subnetid, and the remainder is the hostid. For example, the mask 255.255.255.224 has 24-bit netid, a 3-bit subnetid (the first 3 bits of the last octet), and a 5-bit hostid.

For example, the class C network 192.168.1.0 can be partitioned into two subnets using the subnet mask 255.255.255.128. By doing so, two new networks are created; 192.168.1.0/255.255.255.128 and 192.168.1.128/255.255.255.128. Note that each subnet will have a network address, a broadcast address, and a number of host addresses. Using our variably subnetted network example above, we get the following:

Subnet 1: 192.168.1.0/255.255.255.128Hosts: 192.168.1.1 - 192.168.1.126Broadcast Address: 192.168.1.127

40

Subnet 2: 192.168.1.128/255.255.255.128Hosts: 192.168.1.129 - 192.168.1.254Broadcast Address: 192.168.1.255

Finally, note that subnet masks may be expressed using an abbreviated notation known as CIDR (Classless Inter-Domain Routing). This notation is derived by adding up the number of 1’s in the subnet mask’s bitmask notation. For example, consider the network 192.168.1.0/255.255.255.128. The subnet mask 255.255.255.128 has a bitwise representation of 11111111 11111111 11111111 10000000. This string has twenty-five consecutive 1’s, so the network and subnet mask can be expressed using the notation 192.168.1.0/25.

IP Broadcasting

Broadcasting is used to distribute a single datagram to every host on the network or subnet. To accomplish this, a broadcast address exists such that when a packet is received at this address, it is forwarded to every host on that subnet or network depending on which type of broadcast was sent. There are four different types of IP broadcast addresses [2]:

Limited Broadcast Address:

The address 255.255.255.255 is known as the limited broadcast address. This address is never forwarded by routers, and appears only on the local wire.

All Subnets Directed Broadcast Address:

This broadcast relies on knowledge of the destination host's subnet mask. For instance, the class B subnet 192.168.255.0/24 has a broadcast address of 192.168.255.255, assuming the IP block 192.168.0.0 has been subnetted. In addition, BSD stacks will also treat the network address as a broadcast address.

Subnet Directed Broadcast Address:

This broadcast also relies on knowledge of the destination hosts’ subnet mask. This broadcast targets a specific subnet. For instance, the class C subnet 192.168.1.0/27 has a broadcast address of 192.168.1.31.

Network Directed Broadcast:

This broadcast address addresses a whole network. For example, the class A network 192.0.0.0 has a broadcast address of 192.255.255.255.

How the Reconnaissance Technique Works:

41

What differentiates the “Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP Payloads” reconnaissance technique from a general Smurf scan is the crafted payload. The attacker uses a tool, such as SendIP, to modify the ICMP payload to contain the broadcast IP address. The rationale behind this is that the echo reply packet must return the payload data sent in the echo request packet, and therefore the attacker will know which broadcast address corresponds to the responding machine. The attacker also sends an echo request packet to the network address of the suspected subnet. This aids the attacker in correctly identifying the subnet mask used to variably subnet the network.

To fully illustrate this attack, we will use a partial variably subnetted class C address block as an example. Many times networks are subnetted in this fashion to dole out various sized subnets to different groups within an organization.

Class C IP Block: 192.168.1.0 - 192.168.1.255

Subnet 1: 192.168.1.0/28Hosts: 192.168.1.1 - 192.168.1.14Broadcast Address: 192.168.1.15


Subnet 3: 192.168.1.32/27Hosts: 192.168.1.33 -192.168.1.62Broadcast Address: 192.168.1.255.63

Subnet 4: 192.168.1.64/26Hosts: 192.168.1.65 - 192.168.1.126Broadcast Address: 192.168.1.255.127


The attacker must decide how to scan the target network. Most often, they will target the subnets that are most commonly created. For example, these might include subnets with a last octet that is a multiple of 64 less 1 (since networks use zero-based counting), and thus have broadcast addresses of 192.168.1.63, 192.168.1.191 and 192.168.1.255. The attacker may also send an echo request to the network address of each of subnet, which also acts as a broadcast address on BSD-based stacks. These addresses would include 192.168.1.0, 192.168.1.128 and 192.168.1.192.

However, there are many different ways to variably subnet a class C network. To account for this, and minimize the number of broadcast scans needed to map the network, the

42

attacker sends echo requests to the broadcast and network addresses that they suspect might exist. To identify the networks that exist from those that do not, the attacker inspects the ICMP payload of the echo reply packets (assuming echo replies are received from the victim).

For example, suppose the attacker sent crafted ICMP echo requests to the following addresses: 192.168.1.0, 192.168.1.15, 192.168.1.40, and 192.168.1.47. The attacker is guessing we have a subnet with a network address of 192.168.1.0, a broadcast address of 192.168.1.15, and a subnet mask of 255.255.255.240. They are also guessing we have a subnet with a network address of 192.168.1.40, a broadcast address of 192.168.1.47, and a subnet mask of 255.255.255.248. Since the class C network described above does not have a 192.168.1.40 network, but does have a 192.168.1.0 network, they will be able to determine which of the two networks exist and if we are using machines that have a BSD-based stack. In addition, the attacker will know if they guessed the broadcast address correctly, and thus can deduce the subnet mask being used for that network. They accomplish this by inspecting the payload of the echo reply packets for the broadcast IP address that was hardcoded by the SendIP tool.

More specifically, if the attacker receives ICMP echo replies with payloads containing the IP addresses 192.168.1.0 and 192.168.1.15, they can deduce that the network 192.168.1.0 exists and uses a subnet mask of 255.255.255.240.

This technique allows the attacker to maximize the network topology information returned from a single scan, and yet remain somewhat covert among all the other ICMPecho requests an organization might receive.

How the Malicious Program Works:

SendIP works by taking command line arguments and building the desired packet based on the arguments. If an argument is not supplied, a default value is used. For instance, when crafting an ICMP echo request packet, if a value for the IP ID is not passed asan argument on the command line, the default value is set using a random value. If for any option the argument “r” is supplied, a random value is used. Also, the tool sets the ICMP ID and sequence number to 0.

To craft the ICMP payload, the attacker must pad the payload string with the appropriate amount of bytes to get past the ICMP header fields and into the ICMP payload. This is because the tool copies the payload string on the command line into the ICMP message data structure, and then overwrites the ICMP header fields with either the command line supplied arguments or the default values. If the attacker does not pad the payload string with the appropriate amount of fill, the corresponding amount of bytes from the payload will be truncated.

Diagram of the Attack:

The following diagram is just one representation of a network that is vulnerable to this

43

attack.

How to Perform Netmask-based ICMP Echo Request Smurf Broadcast Scanning With Crafted ICMP Payloads Using SendIP:

SendIP gives the user the option of crafting a TCP, UDP, RIP, or ICMP packet. The tool also has a man page that is bundled with the tar ball and rpm package. The SendIP command line format and options as defined in the man page are as follows:

./sendip <hostname> -p <type> –d <data> <options>

Where:<hostname> is the name of the host the packet is being sent to. If an argument is not supplied, the packet is sent to the localhost, 127.0.0.1.

<type> is the packet type. The default type is IP, but can be set to TCP, UDP or ICMP. RIP packets are transmitted via UDP, so all UDP options apply.

<data> is the packet payload in hex. If an argument is not supplied, the default is 10 bytes of 0’s. The “-d” flag must be used for passing payload data to the SendIP binary on the command line.

<options> are the field values the attacker may set from the command line.

Table 1 shows the IPv4 ICMP options, as defined in the SendIP man page. Note that the default value “Correct” means the value cannot be crafted or is determined based on other field values from the message. In addition, SendIP supports IPv6.

44

Option Flag ICMP Field Default Value Notes-ct Type 8 See RFC 792-cd Code 0-cc Checksum “Correct” See RFC 792

Table 1: ICMP IPv4 SendIP Command Line Options

Note that if an ICMP packet is to be sent to a broadcast address, the “-sb” option must be used. The argument that is supplied to the –sb option is the number of ICMP packets to be sent to the broadcast address.

SendIP also lets the attacker define the IP header field values on the command line. Table 2 below shows the SendIP options used to set these fields.

Option Flag IP Field Default Value Notes-is Source IP 127.0.0.1-id Destination IP “Correct”-ih Header Length “Correct”-iy Type of Service (TOS) 0 See RFC791-il Length “Correct”-ii Identification Number Random-ifr Reserved Flag 0-ifd Don’t Fragment 0-ifm More Fragments 0-if Fragment Offset 0-it TTL 255-ip Protocol “Correct for type”-ic Checksum “Correct”-io Options “not yet implemented”

Table 2: IP IPv4 SendIP Command Line Options

Using these options, an attacker could send a crafted ICMP echo reply to the host 192.168.1.21 with the destination address in the ICMP payload, a TTL of 255, a TOS of 0x04 (decimal 4), an IP ID of 41101, and a source address of 192.168.1.28 with the following command:

./sendip 192.168.1.21 -p ICMP -d "00000000c0a80115" -ct 0 -it 255 -iy 0x04 -ii 41101 –is 192.168.1.28

Note that the ICMP payload string is padded with 8 bytes of zeros, which is number of bytes preceding the ICMP payload as shown in Figure 5.

Signature of the Attack:

The following traffic shows a “standard” ping to a Cisco router and its reply, the

45

traffic signature of the SendIP tool to the network address and broadcast address of a subnet, and the resulting responses. The following traffic was generated on a class C subnet with the following characteristics (note that the IP addresses and MAC addresses have been sanitized):

Subnet Network Address: 192.168.1.0Subnet Netmask: 255.255.255.224Subnet Hosts: 192.168.1.1 - 192.168.1.30Subnet Broadcast Address: 192.168.1.31

The following host was used to generate the traffic:

Attacking host (Linux box running Mandrake 7.1): 192.168.1.28

A script was used to generate the “standard” ping and the SendIP pings. The script usedis as follows:

#!/bin/sh

ping 192.168.1.30

./sendip 192.168.1.0 -p ICMP -d "00000000c0a80100" –sb 1 -it 240 -iy 0xC0 -ii 1206 -ct 8 -is 192.168.1.28

./sendip 192.168.1.31 -p ICMP -d "00000000c0a8011F" -sb 1 -it 240 -iy 0xC0 -ii 1206 -ct 8 -is 192.168.1.28

Snort captured the traffic to a file using the following command:

./snort –dve > sendip_traffic

The responses to the broadcast packets were generated by machines running various version of Solaris (2.6, 7, and 8), as well as two Cisco 2600 routers. There was also NT machines in the subnet, but NT’s do not respond to echo requests sent to the broadcast address. The packet capture from Snort is shown below:

Here we see the attacker pinging the 192.168.1.30 host. Take note of the TTL, IP ID number, the TOS number, the ICMP ID and sequence number, and the ICMP payload data. These values are characteristic of a non-crafted ICMP echo request message sent from a Linux host. Note the payload will look different, and may contain more or less data, if the sender uses the “-s” option in their ping command.

06/11-10:12:13.191427 0:D0:59:13:a:b -> 0:30:80:3C:a:b type:0x800 len:0x62192.168.1.28 -> 192.168.1.30 ICMP TTL:64 TOS:0x0 ID:290 IpLen:20 DgmLen:84Type:8 Code:0 ID:38403 Seq:0 ECHOCD DF 24 3B F1 E7 02 00 08 09 0A 0B 0C 0D 0E 0F ..$;............10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./

46

30 31 32 33 34 35 36 37 01234567

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Here we see the ICMP echo reply from the Cisco router. Note the TTL value hasbeen set to 255, the TOS is 0, the IP ID, and the ICMP ID and sequence number arethe same as in the ICMP echo request. Also, the ICMP payload from the request is returned in the reply. The fact that the IP ID is the same can be used in doing OS fingerprinting in this attack.

06/11-10:12:13.192641 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x62192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0x0 ID:290 IpLen:20 DgmLen:84Type:0 Code:0 ID:38403 Seq:0 ECHO REPLYCD DF 24 3B F1 E7 02 00 08 09 0A 0B 0C 0D 0E 0F ..$;............10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./30 31 32 33 34 35 36 37 01234567

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Next we’ll see the attacking host sending crafted ICMP echo request messages to 192.168.1.0 using the SendIP tool. Notice the TTL, TOS, IP ID, and ICMP payload data are set to the values passed on the command line in the script above. In particular, notice the payload is the destination IP address in hex.

Here we send an echo request to the network address of the subnet.

06/12-10:56:37.916820 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2E192.168.1.28 -> 192.168.1.0 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHOC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Notice that the echo replies have a different IP ID than the request, except the hosts192.168.1.25 and 192.168.1.30 (both are Cisco routers).

06/12-10:56:37.916938 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.8 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:37552 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.916940 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.1 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:38350 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.916954 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.9 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:29590 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

47

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.916974 8:0:20:A9:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.26 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:50336 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.916977 8:0:20:FD:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.15 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:51382 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.916989 8:0:20:F8:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.14 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:30044 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.917776 0:2:16:3E:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.25 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/12-10:56:37.917979 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 00 ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Now the attacking host sends an echo request to the broadcast address of thetargeted subnet. Again, the payload is the destination IP address in hex.

06/11-09:16:50.509428 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2E192.168.1.28 -> 192.168.1.31 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:8 Code:0 ID:0 Seq:0 ECHOC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The remaining portion of the packet capture shows the hosts in the 192.168.1.0 network responding to the attacking hosts’ ICMP echo request to the broadcastaddress.

06/11-09:16:50.509535 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.1 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:12024 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.509551 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

48

192.168.1.8 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:11521 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.509572 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.9 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:3149 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.509606 8:0:20:F8:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.14 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:6493 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.509609 8:0:20:A9:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.26 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:29865 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.509621 8:0:20:B2:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.20 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:6403 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.509624 8:0:20:FD:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.15 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:30341 IpLen:20 DgmLen:32 DF Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.510403 0:2:16:3E:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.25 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+06/11-09:16:50.510589 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32Type:0 Code:0 ID:0 Seq:0 ECHO REPLYC0 A8 01 1F ....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Had the attacker not known the subnet mask, and sent two ICMP echo requests to the broadcast addresses 192.168.1.31 (subnet mask of 255.255.255.224) and 192.168.1.15 (subnet mask 255.255.255.240), he would have known which of the two subnet broadcast addresses was correct based on the ICMP echo reply packet’s payload.

How to Protect against Smurf Broadcast Scanning:

49

The following measures should be taken to protect your organization from being scanned for Smurf amplifiers and from suffering a Smurf attack.

1. Do not allow ICMP echo requests to or past your firewall from the Internet. Depending on your network policy, you may wish to block echo requests at the router and only allow in echo replies [3].

2. Do not allow ICMP directed broadcasts to the router directly connected to your internal subnets. For Cisco routers, apply the following command to every interface on the router: no ip directed-broadcast. Note that in Cisco IOS 12.0 and higher, this rule is the default [4].

3. Implement egress filtering to ensure a Smurf attack is not launched using reserved IP addresses to or from your internal network [5]. The following papers provide an explanation of egress filtering and gives illustrated examples on how to implement egress filtering and other critical router blocking recommendations:

What is Egress Filtering and How Can I Implement It? Egress Filtering v 0.2http://www.sans.org/infosecFAQ/firewall/egress.htm

Cisco Anti-Spoof Egress Filteringhttp://www.sans.org/dosstep/cisco_spoof.htm

Top Ten Blocking Recommendations Using Cisco ACLs - Securing the Perimeter with Cisco IOS 12 Routers

http://www.sans.org/infosecFAQ/firewall/blocking_cisco.htm

4. To determine if your network is being used a Smurf amplifier, or to see if ICMP echo request packets with crafted payloads are being sent to your network from known Smurf amplification sites, check http://www.netscan.org. This site contains a browsable and searchable list of known ICMP Smurf amplifiers.

5. Consider loading a Smurf amplifier-blocking ACL into your router. The following site has an option to print a current list of Smurf amplifiers in Cisco ACL format to your browser screen: http://www.powertech.no/smurf/list.cgi?format=cisco-acl. As of 6/10/01 at 21:12:51 CET, this list contained ACL rules for 668 known Smurf amplifier addresses.

6. Use an IDS such as Snort that can implement a custom signature that looks at the IP and ICMP header fields and packet payload to detect a "Netmask-based ICMP Echo Request Smurf Broadcast Scans with Crafted ICMP Payloads" attack. The following Snort Version 1.7 rule will accomplish this:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Echo Request SendIP Smurf Scanner and Subnet Broadcast Recon"; itype:8; icmp_id:0; icmp_seq:0; content: "| The

50

http://www.powertech.no/smurf/list.cgi?format=cisco-acl

http://www.netscan.org/


http://www.sans.org/dosstep/cisco_spoof.htm

http://www.sans.org/infosecFAQ/firewall/egress.htm

first two or three octets of your IP block in here, in hex, without spaces. See the note below. |";)

Note: If your IP block is the class C network 192.168.1.* or the class B network 192.168.*.*, the content string should be: “|C0A801|” or “|C0A8|”, respectively.

An ICMP echo request packet with a crafted IP ID, ICMP ID and ICMP sequence number sent from SendIP, and detected by Snort version 1.7 using the default signatures from http://www.snort.org, will be identified by the “ICMP Broadscan Smurf Scanner” signature in the icmp.rules file. This is a false identification. The Broadscan tools, as well as hping2 (all available at http://packetstormsecurity.org/UNIX/scanners), cannot craft the IP ID or the ICMP ID number without custom modification of the source code. See Appendix B for packet traces from the Broadscan and hping2 tools.

Of course the attacker could reverse the destination address octets in the payload, or devise a totally random mapping they store offline (ie 192.168.1.0 -> cat, 192.168.1.31 -> dog, etc.). This would render the Snort signature useless in this specific case. However, the “ICMP Broadscan Smurf Scanner” signature is generic enough that it will trigger on such a packet.

Finally, it should be noted that ISS Realsecure does not have the ability to detect this particular attack. Realsecure only identifies the packets as "ICMP Echo Requests". After inspecting the Access database table Realsecure uses to store the event data, very few of the IP and ICMP fields are logged. In particular, the TOS and ICMP payload data are not logged. These fields were critical in identifying this particular attack and the tool suspected of creating it.

Source Code:

The SendIP program is available at the following URL’s:

http://www.earth.li/projectpurple/progs/sendip.html

http://packetstormsecurity.org/UNIX/utilities/sendip-1.5.tar.gz

The program can be downloaded as a tar ball, source RPM or a binary RPM from the first URL, and as a tar ball from Packetstorm. There are numerous files in the package, including source code files, header files, a makefile and shell script, and a GNU Public License file. For this reason, the source code and its accompanying files will not be included here.

All testing and traces produced for Assignment 2 of this practical was done using SendIP version 1.5 from the Packetstorm web site.

51

http://packetstormsecurity.org/UNIX/utilities/sendip-1.5.tar.gz


http://packetstormsecurity.org/UNIX/scanners


Assignment 3 – “Analyze This” Scenario

Security Audit Analysis Results Overview for GIAC University

The following Snort log analysis was done using one-week’s worth of logs provided by GIAC University. The dates in mention are April 13, 2001 through April 19, 2001. Three different types of Snort logs were provided: Alert logs, OOS (Out-of-Spec) logs and Scan logs. One of each of these logs for the specified period was provided, for 21 total log files that are listed in Table 3 below:

Alert Logs OOS Logs Scan Logsalert.010413.gz oos_Apr.13.2001.gz scans.010413.gzalert.010414.gz oos_Apr.14.2001.gz scans.010414.gzalert.010415.gz oos_Apr.15.2001.gz scans.010415.gzalert.010416.gz oos_Apr.16.2001.gz scans.010416.gzalert.010417.gz oos_Apr.17.2001.gz scans.010417.gzalert.010418.gz oos_Apr.18.2001.gz scans.010418.gzalert.010419.gz oos_Apr.19.2001.gz scans.010419.gz

Table 3: Snort Logs Provided by GIAC University for Analysis.

What follows is an analysis of each of the log types, including specific information about events detected within those logs. Correlation information is provided for the top five source IP's against SANS GIAC alerts, other GCIA analysts, SANS CID database, and any posting found using the search engine Google. Insight is also offered into internal system compromises or possibly dangerous or malicious network traffic when possible. A final recommendation is also included about possible system misuse and/or compromise.

Although there are three different types of log files, not all the data is mutually exclusive of each other. Some data in various logs appears in other logs, while other data is unique to the log file that it came from (such as the OOS log data). To account for this, great care was taken to separate out log data into unique sets and not to analyze the same data across different log types.

A summary of the analysis process is described below, and is fully explained in Appendix A.

For the alert and scan logs a “top talkers” and “top destinations”, or the most active IP addresses in terms of network traffic, list is provided. In addition, external source address and registration information about the “top ten talkers” is provided.

The alert log data that neither originated from, nor was destined to, the internal network was singled out from the other alert data for analysis. An “attack signature” analysis of the alert files was done using the alert data and the tool SnortSnarf for the top five source and destination addresses. However, SnortSnarf does not analyze port scan data, so a separate data set containing only Snort spp_portscan totals was created.

The OOS data will be analyzed using a link graph and selected database queries.

52

Snort Alert Log “Attack Signature” Analysis

Figure 6: The main SnortSnarf page, which shows a prioritized list of events by number of occurrence.

53

SnortSnarf reported the following event signatures as shown in figure 6 above:

TCP SMTP Source Port traffic Alert

All sources triggering this attack signature

Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)204.214.6.215 1 1 1 1

All destinations receiving this attack signature

Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)MY.NET.201.32 1 1 1 1

Brief description of the attack

The attacker will often try to penetrate a network by setting their source port to a well-known port that is normally allowed past stateful firewalls. By setting the source port to 25, SMTP (Simple Mail Transport Protocol), the attacker is attempting to scan your network and possibly evade any IDS defenses.

In addition, this particular scan has a source port of 25 and a destination port of 1004. Note that any port less than 1024 is a reserved port. An internally initiated connection with a mail server will result in the initial SYN packet having a ephemeral (greater than 1023) source port. The server will then communicate back to the client with a source port of 25 and the ephemeral destination port. This is not the case as shown below in the Snort alert (remember that “MY.NET” was changed to “199.256” to analyze the traffic using SnortSnarf).

04/19-10:48:40.446704 [**] TCP SMTP Source Port traffic [**] 204.214.6.215:25-> 199.256.201.32:1004

Defensive recommendation

Use a stateful firewall that can detect an incoming connection from port 25 that was not initiated from the internal network.

Correlation

No correlations were found for the external source IP on the GIAC site, SANS CID, or on Google.

Probable NMAP fingerprint attempt


54

Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)212.171.49.18 1 1 1 1200.42.5.159 1 2 1 1


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)MY.NET.223.206 1 1 1 1MY.NET.221.134 1 2 1 1


This attack is an attempt to identify the Operating System (OS) of the destination hosts by seeing how they respond to packets that contain non-standard flag combinations (per the RFC's). This is what's known as OS fingerprinting. If the destination hosts respond to packets sent by the Nmap tool, they are then compared to a database of responses. This attack is a reconnaissances scan, and can be a prelude to a more serious and focused attack. More information about Nmap can be obtained here: http://www.insecure.org/nmap.

In addition, the attacker 200.42.5.159 is attempting to connect to your internal host MY.NET.221.134 on port 6346. Note that this is the default port for the Gnutella file sharing application.


The best defense against OS fingerprinting is a fully patched stateful firewall and an aggressive firewall policy. The attacker must receive a response to conduct OS fingerprinting. Only traffic into, and out of, your network that is necessary to your business function. For example, consider only allowing in ICMP echo-replies to your network, not echo-requests. Since attackers have used, and will continue to use, Nmap to scan your network, you should consider having your security administrator or a security contractor run Nmap on your network to find any vulnerabilities.

In addition, the system owner of the host MY.NET.221.134 should be educated about the dangers of Gnutella. More information about Gnutella is available here: http://www.gnutellanews.com/information/what_is_gnutella.shtml. If you policy permits, block incoming traffic to port 6346 at the firewall or border router.

Correlation

The only correlation found was for the source IP 200.42.5.159 was in the SANS CID database dated 4/24/2001 (http://www.incidents.org/cid/search.php, search parameter = 200.42.5.159).

Source IP Source Port Destination Port Protocol Date200.42.5.159 51 6346 6 (TCP) 4/24/01

55


http://www.gnutellanews.com/information/what_is_gnutella.shtml

http://www.insecure.org/nmap

The host 200.42.5.159 generated the following alerts in your Snort logs, and the attacker also tried to connect to port 6346 on the MY.NET.221.134 using a Null Scan.

04/13-02:11:03.619489 [**] Probable NMAP fingerprint attempt [**] 200.42.5.159:2055-> 199.256.221.134:6346

04/13-03:11:59.062700 [**] Null scan! [**] 200.42.5.159:2055-> 199.256.221.134:6346

ICMP Source and Destination Outside Network


Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)172.133.107.47 1 1 1 1172.128.180.68 1 1 1 1172.130.189.17 1 1 1 1


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)24.180.186.215 1 1 1 124.200.115.13 1 1 1 1

198.207.223.246 1 1 1 1


This ICMP traffic appears to be spoofed from your internal network. The attacker is spoofing their source address to be that of AOL's (America Online) class A netblock AOL-172BLK, a favorite target of script kiddies. Spoofing is done in an attempt to remain anonymous while possibly launching a Denial of Service (DoS) attack, or in an elaborate reconnaissance scan that include ARP or DNS cache poisoning. These packets can be very difficult to trace back to the true owner, even if logs from the victim and upstream ISP providers are correlated.


IP spoofing, when used in a DoS attack like Smurf, can be very dangerous. The best defense against IP spoofing within your internal network is performing egress filtering at your border routers. The following SANS paper provides an excellent description of and instructions on how to implement egress filtering: http://www.sans.org/infosecFAQ/firewall/egress.htm.

There is a CVE advisory under review for ICMP MTU path discovery packets when spoofing traffic between two UNIX hosts. The advisory information is located at the following URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0323.

56



Correlation

No correlations were found for the external source IP’s on the GIAC site, SANS CID, or on Google. Even if correlations were found, it would be very hard to trace the attack back to your own network.

Russia Dynamo – SANS Flash 28-jul-00


Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)MY.NET.178.42 6 6 1 1

194.87.6.109 2 2 1 1194.87.6.201 1 1 1 1


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)194.87.6.109 6 6 1 1

MY.NET.178.42 3 3 2 2


The Russia Dynamo traffic involved source port 8080 and destination port 2418. This is not the case in these attacks. The same class C network is involved, 194.87.6.0, but the traffic involves the reserved port 317 and numerous ephemeral ports. The source port 317 (TCP and UDP) is associated with the ZanNet application. According to the ZanNet web site, http://www.zannet.com:

"ZanNet is a combination Windows 95/98 network client and Unix server that provides you with a Windows 95/98 network drive to access your server files. ZanNet is intended to replace both File Transfer Protocol (FTP) and Telnet programs currently used to access web pages and other files through an Internet Service Provider (ISP)."

This application boasts being able to bypass Telnet authentication and not needing root access to install the binary. If an attacker is able to install this application on an internal machine via a trojaned application, they will have remote access to the victim machine.


Due to the numerous correlations to strange traffic emanating from the 194.87.6.0 network, this network should be blocked at the border routers, both inbound and outbound. In addition, your internal host MY.NET.178.42 should be inspected for trojans and other viruses. In particular, I recommend inspecting the host for the ZanNet application and remove it if it exists. You should also determine what this host's function is. If it is a host that contains any

57

http://www.zannet.com/

sensitive data, you should strongly consider rebuilding the machine using vendor supplied media.

You may wish to create a new set of Snort alert signatures for this traffic. The following Snort alerts are recommended for ZanNet.

alert tcp $EXTERNAL_NET :1024 -> $HOME_NET 317 (msg: "Possible Inbound Russia Dynamo - ZanNet TCP Traffic";)

alert udp $EXTERNAL_NET :1024 -> $HOME_NET 317 (msg: "Possible Inbound Russia Dynamo - ZanNet UDP Traffic";)

alert tcp $ HOME_NET 317 -> $ EXTERNAL_NET :1024 (msg: "Possible Outbound Russia Dynamo - ZanNet TCP Traffic";)

alert tcp $ HOME_NET 317 -> $ EXTERNAL_NET :1024 (msg: "Possible Outbound Russia Dynamo - ZanNet UDP Traffic";)

Correlation

The 194.87.6.0 network was reported as having generated and received "Russia Dynamo" traffic in the following reports:

http://www.sans.org/y2k/practical/Miika_Turkia_GCIA.htmlhttp://www.sans.org/y2k/110100.htmhttp://www.sans.org/y2k/072818.htm

Correlations for the host 194.87.6.201 were found on the SANS GIAC site. Links to theirlocations are below. Although the ports are not the same as in this trace, it does seem to indicate that the attacker does have malicious intentions. No correlations were found for the 194.87.6.109 host.

http://www.sans.org/y2k/072900-1100.htmhttp://www.sans.org/y2k/080400.htm

The following traces were taken from SnortSnarf concerning traffic to and from MY.NET.178.42:

04/16-18:14:34.196279 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 194.87.6.201:1075->199.256.178.42:31704/18-19:29:47.702235 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 194.87.6.109:1576->199.256.178.42:31704/18-19:31:26.986056 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 194.87.6.109:1597->199.256.178.42:31704/18-19:13:02.754291 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 199.256.178.42:317->194.87.6.109:149704/18-19:29:14.699876 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 199.256.178.42:317->194.87.6.109:1568

58


http://www.sans.org/y2k/072900-1100.htm



http://www.sans.org/y2k/practical/Miika_Turkia_GCIA.html

04/18-19:29:49.812165 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 199.256.178.42:317->194.87.6.109:157604/18-19:30:07.197961 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 199.256.178.42:317->194.87.6.109:158104/18-19:30:43.678466 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 199.256.178.42:317->194.87.6.109:158904/18-19:31:11.624247 [**] Russia Dynamo - SANS Flash 28-jul-00 [**] 199.256.178.42:317->194.87.6.109:1594

NMAP TCP ping!

Top 5 sources triggering this attack signature

Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)63.117.235.7 2 2 2 2204.155.48.3 1 1 1 164.245.33.112 1 1 1 1193.41.181.254 1 1 1 1207.30.174.254 1 1 1 1

Top 5 destinations receiving this attack signature


MY.NET.253.125 2 2 2 2MY.NET.60.14 2 2 2 2

MY.NET.100.165 2 2 2 2MY.NET.130.187 1 1 1 1


This is a case of the attacker scanning your network using the TCP ping feature of Nmap. The attacker sent packets from port 80 to ports 53, 80 and 137. If the attacker receives any responses, they are better informed at to what services are listening and could be potentially exploited.


The best defense against port scans is a stateful firewall with an aggressive firewall policy. The border router could also be configured to deny all services except those which are explicitly allowed. While this router configuration policy is not consistent with the "shared information" mission of most Universities, it is strongly advised that you consider it.

There is a CVE advisory under review for TCP SYN pings using Nmap against PCAnywhere. The advisory information is located at the following URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0324.

59


Correlation

The IP address 63.117.235.7 has been reported as scanning port 37852 UDP at SANS GIAC. The following URL describes this traffic: http://www.sans.org/y2k/041901.htm.

Tiny Fragments – Possible Hostile Activity


Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)202.39.78.124 16 16 9 963.227.41.165 6 6 4 4


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)MY.NET.228.54 3 3 1 1MY.NET.211.114 3 5 1 3MY.NET.201.6 2 2 1 1

MY.NET.212.198 2 7 1 5MY.NET.217.166 2 2 1 1


Packet fragmentation occurs when the packets are too large given the maximum transmission unit (MTU) of the interface the packet is being sent from, or on a router. If the original packet is too large, the packet is fragmented into smaller datagrams that are then reassembled at the destination.

The “tiny fragment attack” is when the attacker exploits the intended use of fragmentation and intentionally fragments their packets so small that the packet header is split across fragments. If the destination host's packet filtering rules and/or IDS only considers signatures based on all the information in the header, or does not enforce a minimum fragment size, the packet is allowed past the device without incident. More information on fragmentation attacks is available at the following URL's:

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1858.htmlhttp://www.sans.org/infosecFAQ/threats/frag_attacks.htm

Looking at a sample of this traffic, we see that there are no port numbers associated with the hosts. This indicates that this attack was done using ICMP. This is a characteristic of the Ping O’ Death attack, which most operating systems are no longer vulnerable to. Note that no correlations appeared in the scan or OOS logs for this attack.

60

http://www.sans.org/infosecFAQ/threats/frag_attacks.htm



04/14-02:44:23.398241 [**] Tiny Fragments - Possible Hostile Activity [**] 63.227.41.165 -> MY.NET.217.16604/14-02:59:40.607309 [**] Tiny Fragments - Possible Hostile Activity [**] 63.227.41.165 -> MY.NET.202.106


If you are using Cisco routers, the following URL contains information on implementing ACL's to protect against fragmentation attacks: http://www.cisco.com/warp/public/105/acl_wp.html. In particular, enforce a minimum fragment size on the first fragmented packet to insure entire IP packet header is available for inspection by the filtering device and IDS.

Using a stateful firewall that checks for fragment overlap is also advised. Note that Firewall-1 has know fragmentation attack vulnerabilities in certain versions of their product (see the URL http://www.sans.org/infosecFAQ/threats/frag_attacks.htm for more information).

Be sure all machines have fully patched operation systems so they are not vulnerable to the Ping O’ Death attack.

Correlation

The only correlation found for the two source IP's was in the SANS CID database dated 4/3/2001 (http://www.incidents.org/cid/search.php, search parameter = 202.39.78.124).

Source IP Source Port Destination Port Protocol Date202.39.78.124 0 0 17 (UDP) 4/3/01

Port 55850 tcp – Possible myserver activity – ref.010313-1



66.38.151.7 3 3 1 164.2.43.197 2 2 1 164.12.136.6 2 2 1 1

207.46.181.48 2 2 1 1



MY.NET.6.34 3 4 2 3MY.NET.253.41 3 28 1 3

MY.NET.6.7 2 5 1 3

61


http://www.sans.org/infosecFAQ/threats/frag_attacks.htm

http://www.cisco.com/warp/public/105/acl_wp.html

64.12.136.6 2 2 1 1


Myserver is a distributed DoS (DDoS) tool similar to Trinoo. According to a post by Randy Marchany that references mail from Joakim Bergkvist, "Essentially this exploit allows the hacker to send shell commands via the portmapper which will be executed with root privileges". The exploit apparently allows the attacker to gain root access to the victim machine via the RPC stat exploit and modifies inetd.conf to spawn a shell on port 9704 before restarting inetd. The tool also trojans the ps and ls binaries in an attempt to remain stealthy. Once the attacker installs the myserver agent, the Trojan apparently listens on port 55850 UDP for connections. Note that the rpc.statd exploit specifically targets Linux distributions.

Do note that the Snort signature title says, "Port 55850 tcp". Myserver supposedly runs on UDP port 55850. Either the title is a typo, and should say, "Port 55850 udp", or the author knows or is guessing that myserver has been altered to use the TCP port. Also, note that the traffic from this trace is almost exclusively between ports 55850 and 25. A few scans involving ports 8080 and 6346 to port 55850 were also logged. Given that ports 8080 and 6346 are often seen in exploit code, and the ephemeral port 55850 was used by multiple hosts to scan port 25 on your internal hosts, this is most likely not normal mail traffic.


Patch your rpc.statd package using the appropriate vendor patch and restart rpc.statd, or do not run rpc.statd at all. However, do note that not running rpc.statd will affect your ability to run NFS (Network File System). There is a CERT Vulnerability note located here: http://www.kb.cert.org/vuls/id/34043. There is also a CVE advisory located here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0666.

In addition, blocking unnecessary ports on the firewall is advised. Any stateful firewall that "denies what is not explicitly allowed" will help protect against this attack.

Finally, inspect the internal hosts MY.NET.6.34, MY.NET.253.41 and MY.NET.6.7. These hosts were either the source and/or destination of myserver traffic. If any of the machines are infected, follow your incident handling policy and at a minimum rebuild the boxes from vendor media.

Correlation

A posting concerning this DDoS tool appeared on the SANS GIAC website in mide 2000. The URL is: http://www.sans.org/y2k/082200.htm. No other correlations at GIAC or in the SANS CID were found as of 6/23/01.

Null Scan!

62





Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)142.103.50.152 3 3 1 1206.29.168.18 1 1 1 1200.42.5.159 1 2 1 1

193.41.181.254 1 1 1 124.4.215.116 1 1 1 1


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)MY.NET.224.102 3 4 1 2MY.NET.225.138 2 7 2 7MY.NET.209.250 1 2 1 2MY.NET.221.134 1 2 1 1MY.NET.221.66 1 1 1 1


A Null scan is when the attacker crafts a TCP packet that does not contain any flags. Since a TCP connection must use the three-way handshake, there must be at least one flag set in any normal TCP packet. Attackers use this technique to try to bypass firewalls that look for the SYN flag to be set in conjunction with restricted ports. This is also a useful technique for evading IDS signatures that look for certain flag combinations. Note that Nmap has the capability to perform this kind of scan.

While no discernible pattern was found among the source and destination ports of the various Null scans, ports 6688 (Napster Data), 6699 (Napster) and 6346 (Gnutella) occurred multiple times.


Use a stateful firewall with an aggressive firewall policy. Only the necessary services should be running on the firewall. A null scan of a closed port will elicit a RST packet, whereas a null scan of an open port will result in the destination host dropping the packet. Note that Microsoft TCP stacks are not vulnerable to null scans due to their noncompliance with TCP standards.

Correlation

The SANS CID database (http://www.incidents.org/cid/search.php) identified one correlation on 4/24/01 from the IP address 200.42.5.159:


63


High port 65535 udp – possible Red Worm - traffic



MY.NET.204.194 5 5 1 1MY.NET.70.242 5 5 4 4

62.156.14.212 3 3 2 2203.34.200.71 3 3 3 3


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)203.34.200.71 11 11 5 564.182.96.150 5 5 4 4

MY.NET.70.242 4 4 3 3MY.NET.217.230 2 2 1 1MY.NET.212.198 2 7 1 5


The Red Worm, now known at the Adore Worm, scans the Internet looking for Linux hosts that are vulnerable to exploits for the following services: rpc-statd, wu-ftpd, LPRng, and DNS BIND. Once it finds a vulnerable host and gains access via one of the listed exploits, it trojans the ps binary and moves the original to /usr/bin/adore. It then attempts to send various system information such as the output of an ifconfig command, and well as the /etc/shadow file. A detailed analysis of version 0.8 of the Adore worm can be found here: http://www.sans.org/y2k/adore.htm. Note that the code for this worm can be modified rather easily, so do not assume it listens on port 65535.

Note that the RC1 (Remote Control 1) Trojan listens on UDP port 65535. Since all of the connections involved port 65535 as the remote source or remote destination port, these traces could be indications of an internal user connecting to a Red/Adore Worm or RC1 client on the Internet. Simovits has a small amount of information on this Trojan at the following URL: http://www.simovits.com/trojans/tr_data/y1073.html.


William Stearns of Dartmouth University has written an Adore detection removal tool. You may find it here: http://www.ists.dartmouth.edu/IRIA/knowledge_base/tools/adorefind.htm. Since Snort detected possible Red Worm traffic, it is highly recommend you download this tool and run it on the hosts MY.NET.204.194, MY.NET.70.242, MY.NET.217.230, and MY.NET.212.198. In addition, block access to the web site go.163.com at the firewall and

64

http://www.ists.dartmouth.edu/IRIA/knowledge_base/tools/adorefind.htm

http://www.simovits.com/trojans/tr_data/y1073.html

http://www.sans.org/y2k/adore.htm

block email from the addresses [email protected], [email protected], [email protected], and [email protected].

If the Red Worm is not found on the internal hosts above, web server logs should be inspected to see what kinds of traffic these hosts created. In addition, the hosts below in the correlation section should be paid special attention to. They are producing traffic that indicates they may be port scanning hosts on the Internet. There is also evidence that your hosts are communicating with hosts on the Internet on port 65535.

Again, a properly configured and patched firewall will help protect your network from a worm and port scanning activities such as this.

Correlation

No correlations were found for the external source IP's on the GIAC site, SANS CID, or on Google. However, the queries MY_NET_204_194_qry, MY_NET_217_230_qry and MY_NET_212_198_qry from the Access database show the internal hosts creating traffic that Snort identified as port scanning behavior.

Day Time Src_IP_of_Portscan Total_Hosts_Scanned TCP_Packets UDP_Packets16 7:25:25 PM MY.NET.204.194 230 0 26416 8:05:26 PM MY.NET.204.194 162 0 18317 2:19:03 AM MY.NET.204.194 146 0 16317 11:53:29 AM MY.NET.204.194 169 0 18617 12:01:50 PM MY.NET.204.194 232 0 26117 12:48:53 PM MY.NET.204.194 187 0 21217 8:36:20 PM MY.NET.204.194 326 0 38818 12:22:20 AM MY.NET.204.194 169 0 19418 12:48:38 AM MY.NET.204.194 212 0 24018 4:05:07 PM MY.NET.204.194 183 0 20219 12:56:06 AM MY.NET.204.194 158 0 18419 1:21:45 AM MY.NET.204.194 303 0 34819 11:48:51 AM MY.NET.204.194 276 0 31519 12:06:35 PM MY.NET.204.194 291 0 33019 12:07:38 PM MY.NET.204.194 350 0 419

Day Time Src_IP_of_Portscan Total_Hosts_Scanned TCP_Packets UDP_Packets13 10:33:15 AM MY.NET.217.230 359 0 43513 1:26:43 PM MY.NET.217.230 14 0 1613 1:32:04 PM MY.NET.217.230 13 1 1213 1:32:27 PM MY.NET.217.230 66 0 7913 1:52:00 PM MY.NET.217.230 25 0 2613 2:01:23 PM MY.NET.217.230 47 0 4913 2:02:47 PM MY.NET.217.230 11 0 1413 2:03:31 PM MY.NET.217.230 39 0 4113 2:04:58 PM MY.NET.217.230 27 0 2813 2:06:29 PM MY.NET.217.230 52 0 5313 2:10:55 PM MY.NET.217.230 14 0 15

65

13 2:27:01 PM MY.NET.217.230 15 0 1513 2:27:06 PM MY.NET.217.230 34 0 3413 2:27:16 PM MY.NET.217.230 27 0 2913 2:28:02 PM MY.NET.217.230 22 0 2313 2:28:36 PM MY.NET.217.230 27 0 2713 2:32:52 PM MY.NET.217.230 52 0 5413 2:41:24 PM MY.NET.217.230 14 0 1413 3:34:07 PM MY.NET.217.230 102 0 12413 3:38:00 PM MY.NET.217.230 23 0 2413 3:38:10 PM MY.NET.217.230 39 0 3913 3:38:39 PM MY.NET.217.230 81 0 9813 4:10:51 PM MY.NET.217.230 21 0 2013 4:11:01 PM MY.NET.217.230 13 0 1413 7:33:55 PM MY.NET.217.230 37 0 3813 7:34:24 PM MY.NET.217.230 178 0 20213 7:48:15 PM MY.NET.217.230 28 0 2913 7:48:35 PM MY.NET.217.230 34 0 3713 7:52:21 PM MY.NET.217.230 125 0 16513 8:39:32 PM MY.NET.217.230 29 0 3013 9:34:53 PM MY.NET.217.230 17 0 1713 9:35:31 PM MY.NET.217.230 113 0 13413 10:35:00 PM MY.NET.217.230 20 0 2013 10:35:13 PM MY.NET.217.230 22 0 2213 10:41:19 PM MY.NET.217.230 51 0 5213 10:47:31 PM MY.NET.217.230 62 0 6413 10:49:09 PM MY.NET.217.230 52 0 5313 10:49:42 PM MY.NET.217.230 17 0 1713 10:50:26 PM MY.NET.217.230 55 0 5713 10:50:45 PM MY.NET.217.230 58 0 5913 10:51:13 PM MY.NET.217.230 27 0 2713 11:09:29 PM MY.NET.217.230 51 0 50

Day Time Src_IP_of_Portscan Total_Hosts_Scanned TCP_Packets UDP_Packets13 10:07:28 PM MY.NET.212.198 30 0 7414 11:11:53 PM MY.NET.212.198 1572 6 1679

Queso fingerprint



213.76.185.130 5 5 5 5213.64.149.61 4 4 4 4209.85.37.71 4 4 3 3158.75.57.4 3 3 3 3

66




Queso is a scanning tool similar to Nmap and hping2 that allows the attacker to determine which operating system the victim machine is using. In particular, it can set the reserved bits in a SYN packet. After viewing the SnortSnarf logs a little closer, port 6346 and 6347 appear quite frequently. Gnutella used port 6346, and some users configure Gnutella to listen on port 6347 to try and bypass packet filters that block TCP port 6346. Also observed were connection attempts to ports 113 (auth/ident), 2208 (the Rux.PSW Trojan listens on port 2208 TCP), and port 4087 (unknown).

Had any of the hosts been listening on these ports, the attacker could have identified the OS and possibly have found a listening service or Trojan.


A stateful firewall and fully patched machines will help protect against port scans that are attempting to do OS fingerprinting. NT machines in particular should be updated with the latest service pack.

There is a CVE advisory under review and an incident note from CERT on Queso scans. The advisory information is located at the following URL’s: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0454 http://www.cert.org/incident_notes/IN-98.04.html

Correlation

A correlation for the attacker IP 213.76.185.130 was found here: http://www.mynetwatchman.com/mynetwatchman/ListDetailIncidentsByDate.asp?IncidentId=46419.

The SANS CID database (http://www.incidents.org/cid/search.php) identified several correlations from the IP address 158.75.57.4:

Source IP Source Port Destination Port Protocol Date158.75.57.4 58913 6347 6 6/14/01158.75.57.4 40025 6346 6 5/17/01

67


http://www.mynetwatchman.com/mynetwatchman/ListDetailIncidentsByDate.asp?IncidentId=46419

http://www.mynetwatchman.com/mynetwatchman/ListDetailIncidentsByDate.asp?IncidentId=46419

http://www.cert.org/incident_notes/IN-98.04.html


158.75.57.4 53388 6346 0 12/12/00

TCP SRC and DST outside network


Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)169.254.101.152 25 25 14 14128.101.28.114 9 163 9 99192.168.1.92 4 4 2 2192.168.0.5 3 3 1 1

172.159.25.102 1 1 1 1


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)205.188.48.116 4 4 1 1209.242.124.6 3 3 1 1209.125.144.4 3 3 1 1205.188.48.117 3 3 1 1132.248.54.106 2 2 2 2


This TCP traffic, similar to the ICMP traffic described previously, appears to be spoofed from your internal network. The attacker is spoofing their source address to be that IANA (Internet Assigned Numbers Authority), University of Minnesota, and AOL.

Note that the destinations of these packets include AOL, an ISP, @Home network, and a University in Mexico.


The same recommendation here is made as with the ICMP spoofed traffic. The best defense against IP spoofing within your internal network is performing egress filtering at your border routers. The following SANS paper provides an excellent description of and instructions on how to implement egress filtering: http://www.sans.org/infosecFAQ/firewall/egress.htm.

Correlation

No correlations were found in the SANS CID. Even if correlations were found, it would be very hard to trace the attack back to your own network.

68


High port 65535 tcp – possible Red Worm - Traffic



MY.NET.201.206 19 19 1 1MY.NET.210.130 13 13 1 1MY.NET.253.24 5 5 2 2MY.NET.228.126 5 5 1 1



MY.NET.210.130 16 16 1 1MY.NET.228.126 6 6 1 1200.147.247.234 4 4 1 1

206.106.64.12 4 4 1 1


The same description as in the High port 65535 udp – possible Red Worm – traffic section above applies here. Of course, the difference is the traffic is TCP, not UDP. Note that the RC1 Trojan is known to run on both TCP and UDP 65535.


Again, the same recommendation made in the High port 65535 udp – possible Red Worm – traffic section applies here.

Correlation

No correlations were found for the external source IP 129.59.51.185 on the GIAC site, SANS CID, or on Google.

Watchlist 000222 NET-NCFC



159.226.41.166 41 41 1 1159.226.6.5 9 9 1 1

159.226.114.1 5 5 2 2

69

159.226.120.14 4 4 2 2


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)MY.NET.144.54 43 43 1 1MY.NET.100.56 41 41 1 1MY.NET.253.43 11 11 5 5MY.NET.6.47 9 9 1 1

MY.NET.253.52 3 3 1 1


These scans all originate from the 159.226.0.0 class B network, which is registered to the Computer Network Center Chinese Academy of Sciences. It appears that internal hosts are engaged in FTP and Telnet sessions with hosts in the 159.226.0.0 network. It also appears that mail is being sent from the attacker’s network to your internal hosts due to the appearance of port 25 (SMTP) and 113 (auth/ident) in the Snort logs.


This traffic is rather alarming. Port 20 traffic was seen in the Snort logs, which is the FTP data port. One of your internal hosts appears to be either transfering data to your internal network, or hosts within your network are compromised and the attacker is transferring data from the remote network to yours. I would have expected to see to bi-directional traffic for this alert. I suspect that your Snort signature is only alerting on incoming traffic from the attacker’s IP block. I would suggest modifying your signature to capture both inbound and outbound traffic. You may do this by using the “<->” operator in the Snort signature instead of a unidirectional operator, such as “->”.

The 159.226.0.0 network should be also blocked at the router via an ACL. The following Cisco ACL will do this (replace “101” and “MY.NET” with the appropriate values):

! Cisco - IOS Watchlist 000222 NET-NCFC ACLaccess-list 101 deny ip 159.226.0.0 0.0.255.255 MY.NET.0.0 0.0.255.255 log

In addition, the following hosts should be inspected for signs of misuse and/or compromise.

MY.NET.144.54 MY.NET.6.7 MY.NET.253.51MY.NET.100.56 MY.NET.4.3 MY.NET.253.41MY.NET.253.43 MY.NET.100.230MY.NET.6.47 MY.NET.6.35

MY.NET.253.52 MY.NET.6.34

70

Correlation

The following IP’s were correlated with other GCIA analyst reports at http://www.sans.org:

159.226.92.9http://www.sans.org/y2k/practical/Andy_Siske_GCIA.htm

159.226.41.166 http://www.sans.org/y2k/practical/Crist_Clark_GCIA.html

159.226.6.5http://www.sans.org/y2k/practical/Miika_Turkia_GCIA.html http://www.sans.org/y2k/practical/Crist_Clark_GCIA.html

connect to 515 from outside



130.185.51.62 41 41 40 40213.186.93.218 18 18 18 1864.217.203.219 15 15 13 13

199.34.68.4 8 8 8 8




This scan on the internal host destination port 515 is quite common on the Internet as of late. The attacker is most likely looking to exploit the Linux LPR (printer) daemon or BSD/Linux LPRng vulnerability. If the attacker finds a Linux host that is listening on port 515, and is vulnerable to this attack, the attacker may execute arbitrary commands on the victim or launch a buffer overflow attack and gain root access.


71

http://www.sans.org/y2k/practical/Crist_Clark_GCIA.html

http://www.sans.org/y2k/practical/Miika_Turkia_GCIA.html

http://www.sans.org/y2k/practical/Crist_Clark_GCIA.html

http://www.sans.org/y2k/practical/Andy_Siske_GCIA.htm

http://www.sans.org/

Again, a stateful firewall that blocks port 515 will help defend against this attack. Host operating systems should also be patched so that they are not vulnerable to this attack. Vendor OS vulnerability and patch information is located here: http://www.cert.org/advisories/CA-2000-22.html.

Finally, if you are running LPRng on any of your hosts, a version that is not vulnerable to the LPRng exploit should be used. Such a version is located here: ftp://ftp.astart.com/pub/LPRng/LPRng/LPRng-3.6.25.tgz.

A SANS alert on this scan is posted here: http://www.sans.org/newlook/alerts/port515.htm. There are also CVE advisories for the vulnerability located at the following URL’s:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0335 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0917

Note that none of your internal hosts was flagged as responding to these scans in the Snort logs that were provided.

Correlation

Laurie Zirkle apparently received traffic from the IP 213.186.93.218 because her posting of responses to host owners for April 2001 listed this IP. The posting is located here: http://www.incidents.org/archives/intrusions/msg00322.html.

The source IP 64.217.203.219 appeared in the SANS CID database dated 5/11/2001 (http://www.incidents.org/cid/search.php, search parameter = 64.217.203.219).

Source IP Source Port Destination Port Protocol Date64.217.203.219 0 515 6 (TCP) 5/11/0164.217.203.219 0 515 6 (TCP) 5/11/01

The source IP 199.34.68.4 appeared in the SANS CID database dated 4/25/2001 (http://www.incidents.org/cid/search.php, search parameter = 199.34.68.4).


Win Gate 1080 Attempt



72



http://www.incidents.org/archives/intrusions/msg00322.html



http://www.sans.org/newlook/alerts/port515.htm

ftp://ftp.astart.com/pub/LPRng/LPRng/LPRng-3.6.25.tgz





Wingate is a tool that allows users to simultaneously share an Internet connection. Wingate also installs the SOCKS proxy service on port 1080, and does not log the connection information from the attacker. This effectively allows the attacker to anonymize their scans by proxying their traffic though a server using Wingate.

More information on Wingate is available from the product website, located here: http://www.wingate.net. More information about SOCKS in regard to Wingate is located on the SANS website at this address: http://www.sans.org/newlook/resources/IDFAQ/socks.htm.


If you are using the Wingate application anywhere at your University, note that Wingate Pro may be configured to enforce user authentication. According to Wingate’s documentation at http://www.wingate.net/features/list:

“WinGate Pro offers several methods for client authentication; WinGate Internet Client, GateKeeper, or a browser based java authentication. Authentication can be based on user names, computer names, locations, time of day and much more.”

Whether you are using Wingate or not, proxy servers should be protected either with a firewall and border router ACL’s.

There are CVE and CERT advisories for the use and configuration of Wingate at the following URL’s:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0291 http://www.cert.org/vul_notes/VN-98.03.WinGate.html

Correlation

The following source IP’s were correlated with other GCIA analyst reports and the SANS CID database.

204.117.70.5

73

http://www.cert.org/vul_notes/VN-98.03.WinGate.html


http://www.wingate.net/features/list

http://www.sans.org/newlook/resources/IDFAQ/socks.htm

http://www.wingate.net/

http://www.sans.org/y2k/practical/chris_kuethe_gcia.html http://www.sans.org/y2k/072100.htm

217.10.143.54The source IP 217.10.143.54 appeared in the SANS CID database dated 6/9/2001 and 5/31/2001 (http://www.incidents.org/cid/search.php, search parameters: Source IP = 217.10.143.54, Target Port = 1080).


216.179.0.32

The source IP 216.179.0.32 appeared numerous times in the SANS CID between 4/24/01 and 5/21/01 (http://www.incidents.org/cid/search.php, search parameters: Source IP = 216.179.0.32, Target Port = 1080).

Source IP Source Port Destination Port Protocol Date216.179.0.32 4722 1080 6 (TCP) 5/21/01216.179.0.32 4722 1080 6 (TCP) 5/21/01216.179.0.32 1036 1080 6 (TCP) 5/17/01216.179.0.32 4098 1080 6 (TCP) 5/17/01216.179.0.32 3355 1080 6 (TCP) 5/17/01216.179.0.32 3980 1080 6 (TCP) 5/17/01216.179.0.32 2251 1080 6 (TCP) 5/16/01216.179.0.32 4675 1080 6 (TCP) 5/16/01216.179.0.32 2846 1080 6 (TCP) 5/16/01216.179.0.32 1584 1080 6 (TCP) 5/3/01216.179.0.32 3379 1080 6 (TCP) 4/27/01216.179.0.32 4692 1080 6 (TCP) 4/27/01216.179.0.32 3904 1080 6 (TCP) 4/24/01

SMB Name Wildcard



141.157.95.30 18 18 1 1MY.NET.219.146 7 7 4 4

66.74.68.29 6 6 1 124.93.44.178 4 4 1 1


74




http://www.sans.org/y2k/practical/chris_kuethe_gcia.html


MY.NET.135.67 8 10 4 6MY.NET.134.57 6 7 1 2MY.NET.134.227 4 4 2 2MY.NET.134.76 4 4 2 2


The SMB Name Wildcard signature is most likely the same or very similar to the following Snort signature from http://www.whitehats.com/ids/vision.conf.gz (export date: 20010628.1005).

alert UDP $EXTERNAL any -> $INTERNAL 137 (msg: "IDS177/netbios_netbios-name-query"; content: "CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|00 00|";)

What the source host is doing is requesting the NetBIOS name of the destination host. This is done as part of the Windows file sharing protocol to obtain domain, user and host id information. An attacker can use this reconnaissance information to launch future attacks. However, this traffic is generated in other instances. According the NetBIOS name query signature in the arachNIDS database, located at http://www.whitehats.com/IDS/177,

“Additionally, some desktop firewalls will automatically send the packets to any other host that connects back to the user (such as identd requests from a mail server or IRC server). NetBIOS name traffic is considered background noise on the network and should only be considered when combined with other forensic evidence that points to a problem/suspicion.” [12].

This traffic most often occurs between port 137 on both the source and destination hosts. However, the signature above looks for this traffic from any UDP source port. The Snort logs that were provided from your network show traffic from port 137 and various ephemeral ports to port 137. Note that the host MY.NET.220.110 sent netbios name queries from an ephemeral port to internal hosts in your network.


Unless specifically required, turn off file sharing on all Windows hosts. A stateful firewall that blocks the Windows NetBIOS port 135-139 should also be employed. All your internal Windows machines would also benefit from a personal firewall such as ZoneAlarm (http://www.zonelabs.com) or Tiny Personal Firewall (http://www.tinysoftware.com/pwall.php). For machines that require file sharing, use one of the former personal firewalls and set up a trust relationship between the hosts.

There are numerous CVE and CERT advisories for NetBIOS. A few are listed below: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0288

75


http://www.tinysoftware.com/pwall.php

http://www.zonelabs.com/

http://www.whitehats.com/IDS/177

http://www.whitehats.com/ids/vision.conf.gz

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0347http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0673http://www.kb.cert.org/vuls/id/32650http://www.cert.org/incident_notes/IN-2000-02.html

Correlation

No correlations were found for the external source IP’s on the GIAC site, SANS CID, or on Google.

SUNRPC highport access!



199.244.218.40 4 4 1 164.7.207.114 1 1 1 1


Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total)MY.NET.100.197 311 311 1 1MY.NET.209.10 4 4 1 1MY.NET.20.10 1 1 1 1


The first IP, 35.9.37.225, appears to be trying to connect to port 32771. This is known as the FileNet or rpc.ghost portmapper port. Since the source ports are all ephemeral, this scan looks like a connect-scan against the host MY.NET.100.197 over a period of approximately 6 seconds.

The second IP, 199.244.218.40, appears to be trying to connect from port 443, the well-known port for SSL (Secure Socket Layer). If this were an inbound SSL SYN connection, the attacker would be using an ephemeral port. This could be a case of the attacker using port 443 in an attempt to make this look like legitimate encrypted web traffic. There is a small chance the connection was initiated by an internal user using the ephemeral port 32771. However, I would expect to see more connections than the four packets that were logged, shown below:

04/13-18:23:46.239878 [**] SUNRPC highport access! [**] 199.244.218.40:443-> 199.256.209.10:32771


76

http://www.cert.org/incident_notes/IN-2000-02.html






In addition, these were the only packets logged from this source IP in the seven-day period that was examined. If this was a deliberate scan, the attacker is very cautious and/or patient. Based on the correlation information below, it appears this traffic is a deliberate port scan that is attempting to be stealthy by using port 443 as a source port.

The third IP, 64.7.207.114, tried to connect to the host MY.NET.20.10 from port 8080 to port 32771 with a single packet. Port 8080 is a well-known proxy server port. Most likely, this is a false positive as far as an attack is concerned. The connection occurred at 12:24pm on 4/14, as shown below:



The best defense against these attacks is to turn off RPC services if they are not required. Note that RPC is required to run X-Windows and Solaris CDE. If you cannot turn off RPC on your firewall (ie. you are running Gauntlet firewall and are running the espm-gui client locally), add an ACL on your border router to block inbound rpcinfo -p <ip address> requests. Be sure to do this for port 111, and 32771 if you are running RCP services on this port.

There are numerous CVE advisories for RPC. One such advisory under review is having RPC running at all: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0632.

Correlation

The source IP 199.244.218.40 appeared in the SANS CID database dated 5/15/2001 (http://www.incidents.org/cid/search.php, search parameters: Source IP = 199.244.218.40, Source Port = 443).

Source IP Source Port Destination Port Protocol Date199.244.218.40 443 3340 6 (TCP) 5/15/01199.244.218.40 443 3346 6 (TCP) 5/15/01199.244.218.40 443 3347 6 (TCP) 5/15/01

External RPC call

77







MY.NET.134.251 3 3 3 3MY.NET.135.5 3 3 3 3MY.NET.135.48 3 3 3 3


This attack is targeted at the destination port 111, or the RPC Portmapper service on UNIX hosts. These scans occur quite frequently on the Internet. As noted in the SUNRPC highport access! signature, even firewalls such as Gauntlet will respond to an rpcinfo -p request if they are running RPC services. The information returned to the attacker can them be used to more intelligently launch an attack against the victim hosts using an RPC exploit.


As mentioned above, turn off RPC services if they are not required. Also, block all inbound RPC requests to your internal network at the border router. If your firewall is running RPC services, consider disabling it and running without X-Windows. Also, use a version of rpcbind that does not allow proxy access. More specific information on RPC is available at the following CERT advisory: http://www.cert.org/advisories/CA-1994-15.html.

There are two CVE advisories under review currently for Portmapper: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0195 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0632

Correlation

The source IP 207.228.250.34 appeared 11 times in the SANS CID on 5/15/01 (http://www.incidents.org/cid/search.php, search parameters: Source IP = 207.228.250.34, Target and Source Ports = 111).


78





The source IP 61.74.156.205 appeared once in the SANS CID on 5/1/01 (http://www.incidents.org/cid/search.php, search parameters: Source IP = 61.74.156.205, Target Ports = 111).


The source IP 216.36.36.29 appeared in the SANS CID on 4/16/01 (http://www.incidents.org/cid/search.php, search parameters: Source IP = 216.36.36.29, Target Ports = 111).


SYN-FIN scan!






A SYN-FIN scan is used to probe a network for open ports and do OS fingerprinting using a flag combination that does not occur naturally as part of the TCP three-way handshake. By using this flag combination, the attacker may fail to be noticed by some older IDS's. More information on the SYN-FIN scan can be found here: http://www.whitehats.com/IDS/198.

Note that there were 978 alerts in the Snort alert files all originating from the single source IP 62.238.69.199. In addition, the source and destination port in all the packets was 21, the FTP command port. The source IP resolves to the Netherlands, and a whois query returned the following:

Server used for this query: [ whois.ripe.net ]inetnum: 62.238.0.0 - 62.238.95.255

79




netname: NL-ZEELANDNET-20001101descr: Provider Local Registrydescr: ZeelandNet BVcountry: NLadmin-c: PVDP1-RIPEtech-c: AK1555-RIPEstatus: ASSIGNED PAmnt-by: RIPE-NCC-NONE-MNTchanged: [email protected] 20001127source: RIPEroute: 62.238.0.0/16descr: ZeelandNetorigin: AS15542remarks: first postnotify: [email protected]: AS15542-MNTchanged: [email protected] 20001113source: RIPEperson: Pieter van der Poladdress: ZeelandNet BVaddress: Veerweg 16address: 4493 ASaddress: Kamperlandphone: +31 113 377778e-mail: [email protected]: PVDP1-RIPEnotify: [email protected]: [email protected] 19990714


If you are running a FTP server that allows connections from the Internet, place this server outside of the firewall protecting your internal network. Be sure to harden the OS and patch all software applications that are running on this box, such as WU-FTP. For more information on WU-FTPD, see the following URL: http://www.wu-ftpd.org.

It is highly advised that you do not allow inbound FTP to your internal network through your firewall. Also, use a stateful firewall if your are allowing outbound FTP connections to the Internet.

Multiple CVE advisories exist for versions of FTP servers and various OS's. It is recommended you review the FTP advisories on CVE: http://cve.mitre.org/cve, search parameter = ftp. A CVE advisory is under review for SYN-FIN packets with the more fragments bit set for Marconi ASX-1000 switches. The advisory is located here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0270.

80


http://cve.mitre.org/cve

http://www.wu-ftpd.org/

Correlation


Possible trojan server activity



MY.NET.202.34 576 576 1 1207.55.74.26 288 288 1 1211.56.113.59 26 26 22 22211.135.37.98 7 7 5 5



MY.NET.202.34 288 288 1 1129.82.88.173 27 27 24 24

MY.NET.222.50 6 6 6 6MY.NET.204.142 5 8 3 4


The alerts from this scan appear to be triggered when a packet arrives with a source or destination port of 27374. According to the following port list, http://www.SANS.ORG/newlook/resources/IDFAQ/oddports.htm, this port is associated with the trojans Bad Blood, SubSeven, SubSeven 2.1 Gold, Subseven 2.1.4, and DefCon 8. Most likely these alerts are related to a version of SubSeven, as this is currently one of the more popular trojans in use within the attacker community.

SubSeven is a remote control trojan for Windows machines that lets the attacker control the victim machine. The attacker uses their SubSeven client to remotely connect to the victim machine infected with a SubSeven server, typically on port 27374 TCP for version 2.1. SubSeven even has the option to notify the attacker when a victim machine infected with the server is online, and provides the attacker with the IP address and port on which the server is listening. More information on SubSeven is located here: http://www.sans.org/newlook/resources/IDFAQ/subseven.htm.

If we consider the top five source addresses for this scan, the following assumptions can be made:

81

http://www.sans.org/newlook/resources/IDFAQ/subseven.htm

http://www.SANS.ORG/newlook/resources/IDFAQ/oddports.htm

The source IP 129.82.88.173 appears to be scanning your internal network for SubSeven trojans listening on port 27374.

The internal host MY.NET.202.34 appears to be scanning the Internet for machines with Subseven servers listening on port 27374.

The source IP 207.55.74.26 appears to be responding to SubSeven tasking from a host located within your internal network (MY.NET.202.34).



Considering all the internal hosts that Snort detected as either sending or receiving traffic with a destination port of 27374, we can make the following assumptions:

The internal hosts MY.NET.202.34, MY.NET.98.142 and MY.NET.221.50 appear to be attempting to task Trojans listening on port 27374 on the Internet. Also note that MY.NET.221.50 also was identified in the "tcp Red Worm" alert as sending traffic to port 65535.

The internal hosts in the table below appear to be answering Trojan tasking requests. However, it is difficult to know this for sure. It appears that either the Snort logs do not contain bi-directional traffic logs for all the internal subnets, or that all the Snort sensors do not have the same exact set of signatures.

MY.NET.205.218 MY.NET.181.112 MY.NET.198.179 MY.NET.225.214MY.NET.146.51 MY.NET.185.73 MY.NET.202.89 MY.NET.182.19MY.NET.181.37 MY.NET.210.185 MY.NET.180.1 MY.NET.206.254MY.NET.15.178 MY.NET.184.200 MY.NET.182.107 MY.NET.188.1MY.NET.100.182 MY.NET.182.138 MY.NET.185.28 MY.NET.202.117MY.NET.182.198 MY.NET.222.226 MY.NET.181.105 MY.NET.180.192MY.NET.105.120 MY.NET.198.171 MY.NET.60.152 MY.NET.217.113MY.NET.204.214 MY.NET.160.128 MY.NET.180.185 MY.NET.181.172MY.NET.204.142 MY.NET.206.226 MY.NET.181.180 MY.NET.182.119MY.NET.182.71 MY.NET.229.54 MY.NET.222.166MY.NET.222.98 MY.NET.185.21 MY.NET.99.15MY.NET.223.50 MY.NET.184.28 MY.NET.222.50MY.NET.97.191 MY.NET.225.117 MY.NET.229.174MY.NET.182.95 MY.NET.184.29 MY.NET.60.17


Since your organization is a University, it is quite possible that the SubSeven Trojan has infected numerous machines within your internal network. Often times students will send the

82

latest joke or animated graphic within a .exe file to all their friends over the campus network. Since many Universities have high speed Internet access in the dorms, the trojan could make its way around the network very quickly.

It does not appear that your firewall is blocking port 27374 to or from the Internet. Your firewall should be configured to block this port. If you do not have a firewall, and are not able to install one for whatever reason, block traffic to port 27374 TCP at the border router. Next, inspect the three machines that appear to have been attempting to task trojans on the Internet. Also, if it can be determined who was using those machines at the time the traffic occurred, inform them of the dangers of scanning for trojans. Also, look at your Internet usage policy to determine if they were engaging in prohibited actions. An important last step would be to inspect all the machines suspected of being infected with the SubSeven Trojan. Use the following steps recommended by SANS in the SubSeven IDFAQ URL: http://www.sans.org/newlook/resources/IDFAQ/subseven.htm.

1. Edit SYSTEM.INI. If you find the line shell=Explorer.exe Task_Bar.exe, remove the Task_Bar.exe entry. Save SYSTEM.INI.

2. Edit win.ini and look at the lines containing run= and load=. If you find one of the files listed above, remove this entry (entries).

3. Start the regedit.exe and search for the files listed above. If you find an entry with one of the files, remove it.

4. Reboot

There are no specific CVE or CERT advisories for SubSeven. However, there are NIPC advisories on SubSeven located here: http://www.nipc.gov/warnings/advisories/2001/01-014.htmhttp://www.nipc.gov/warnings/advisories/2000/00-056.htm

Correlation

The following correlation for the source IP 211.56.113.59 was found for the destination port 12345 (Netbus trojan): http://www.sans.org/y2k/042401.htm.

UDP SRC and DST outside network



162.254.67.123 213 213 192 192128.101.28.114 154 163 90 99134.192.134.112 90 90 1 1169.254.114.199 47 47 35 35

83


http://www.nipc.gov/warnings/advisories/2000/00-056.htm

http://www.nipc.gov/warnings/advisories/2001/01-014.htm

http://www.sans.org/newlook/resources/IDFAQ/subseven.htm



134.192.148.14 90 90 1 1211.99.78.10 43 43 1 1164.124.101.2 14 14 5 5202.62.32.194 7 7 1 1


This UDP traffic, much like the ICMP and TCP traffic described previously, appears to be spoofed from your internal network. The attacker is spoofing their source address to be that of IANA (Internet Assigned Numbers Authority), University of Minnesota, and the University of Maryland at Baltimore.

The destinations include IANA (Internet Assigned Numbers Authority), University of Maryland at Baltimore, a Korean dial-up server, the DACOM Corporation in Seoul South Korea, and an ISP in Austria called Dolphin IT.

The destination address that resolves to IANA may be the result of an internal user or administrator testing a scanning tool and using a reserved IP address so as not to "attack" an assigned IP address owner. It could also be a typo on the part of the attacker.

Almost all these alerts were between the source and destination port 137, Windows NetBIOS. A few connection attempts to port 6346, Gnutella, were logged as well.


The same recommendation here is made as with the ICMP and TCP spoofed traffic. The best defense against IP spoofing within your internal network is performing egress filtering at your border routers. The following SANS paper provides an excellent description of and instructions on how to implement egress filtering: http://www.sans.org/infosecFAQ/firewall/egress.htm.

Correlation

No correlations were found in the SANS CID. Even if correlations were found, it would be very hard to trace the attack back to your own network.

Attempted Sun RPC high port access


Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)

84


24.248.185.123 1508 1508 1 1172.135.241.112 1118 1118 1 1205.188.153.98 1 1 1 1




This alert signature is similar to the SUNRPC highport access! alert in that the destination port is 32771, or the rpc.ghost portmapper port. However, the source port is 32786 in all but one case. Port 32768 is the RPC Filenet TMS port.

The one exception was a packet from 205.188.153.98 with source port 4000. Port 4000 is the well-known port for ICQ and the game Diablo. A whois lookup confirms that the source IP 205.188.153.98 belongs to AOL, which purchased ICQ in June 1998.


As stated in the Defense recommendation section of the "SUNRPC highport access!" alert, the best defense against these attacks is to turn off RPC services if they are not required.

Correlation

A correlation to the scan from the source IP 205.188.153.98 was found here: http://www.sans.org/y2k/practical/william_stearns_gcia.html.

Watchlist 000220 IL-ISDNNET-990517


Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total)212.179.21.187 1580 1580 1 1212.179.80.30 1010 1010 1 1212.179.179.2 800 800 5 5212.179.179.3 664 664 1 1

212.179.179.226 571 571 1 1



85

http://www.sans.org/y2k/practical/william_stearns_gcia.html

MY.NET.212.182 686 686 1 1MY.NET.222.2 664 664 1 1

MY.NET.224.170 571 571 1 1


This scan originates from the class B network 212.179.0.0. This class B network is broken up among the following ISP's:

Server used for this query: [ whois.ripe.net ]inetnum: 212.79.0.0 - 212.79.63.255netname: DE-POP-981102descr: POP Point of Presencedescr: PROVIDERcountry: DErole: Hostmaster POPaddress: POP Point of Presence GmbHaddress: Wendenstrasse 375-377address: D-20537 Hamburgaddress: Germany

inetnum: 212.79.64.0 - 212.79.95.255netname: BE-ASSURNET-990202descr: PROVIDERcountry: DErole: Assurnet IP OPERATORaddress: Assurnetaddress: 150 chaussee de La Hulpeaddress: 1170 Bruxellesaddress: Belgium

These scans targeted the following destination ports:

25 4237 4947412 4341 49491214 4342 49631267 4451 63461335 4484 63471496 4815 66883315 4851 66994190 4885 511434197 4887

These ports map to the following services (according to http://www.iana.org/assignments/port-numbers, the http://www.snort.org Port Databse tool, and the URL http://www.linuxrouter.org/listarch/linux-router/2000-12-01/msg00209.html).

86

http://www.linuxrouter.org/listarch/linux-router/2000-12-01/msg00209.html


http://www.iana.org/assignments/port-numbers

Note that Napster ports are not registered, and therefore can often change. However, 6688 and 6699 appear to be commonly used Napster ports.

*** (see below) VRML Multi User Systems UnassignedTrap Convention Port Unknown Unassigned

KAZAA Unknown Unassignedpcmlinux CTI System Msg Gnutella

Digital Notary Protocol Unassigned Gnutellaliberty-lm Unassigned Napster

CDID Unassigned NapsterUnassigned ABBS Dynamic and/or private portsUnassigned Unassigned

*** Besides SMTP, the URL http://www.SANS.ORG/newlook/resources/IDFAQ/oddports.htm lists the following Trojans associated with port 25: Ajan, Antigen, Email Password Sender - EPS, EPS II, Gip, Gris, Happy99, Hpteam mail, I loveyou, Kuang2, Magic Horse, MBT (Mail Bombing trojan), Moscow Email trojan, Naebi, NewApt worm, ProMail trojan, Shtirlitz, Stealth, Tapiras, Terminator, WinPC, and WinSpy.


A stateful firewall that blocks unassigned port numbers and well-known ports used by Napster and Gnutella is recommended. In addition, anti-virus software should be installed on the mail sever and all non-UNIX machines.

It is also be advised that you block this IP block at your border router. If you are using a Cisco router, the following ACL will accomplish this (replace MY.NET with the first two octets of your network, and "101" with appropriate extended ACL number):

! Cisco IOSaccess-list 101 deny ip 212.79.0.0 0.0.255.255 MY.NET.0.0 0.0.255.255 log

Correlation


Snort Scan and Alert Log “Top Talkers” and “Top Destination” Lists

Using the Access database, the following totals were observed:

“Top Ten Talkers” from the Alert logs and the “inside_alert_source_ip_count_qry” query:

Src_IP CountOfSrc_IP

87

http://www.SANS.ORG/newlook/resources/IDFAQ/oddports.htm

212.179.21.187 158024.248.185.123 1508192.168.0.53 1339

172.135.241.112 1118212.179.80.30 101062.238.69.199 978212.179.79.2 800

129.82.88.173 693212.179.80.3 664

MY.NET.202.34 576

“Top Ten Destinations” from the Alert logs and the “inside_alert_dest_ip_count_qry” query:

Dest_IP CountOfDest_IPMY.NET.219.34 2626MY.NET.218.30 1581

10.10.10.50 1339MY.NET.219.38 1245

MY.NET.212.182 686MY.NET.222.2 664207.55.74.26 576

MY.NET.224.170 571MY.NET.225.102 463MY.NET.218.218 328

“Top Ten Talkers” from the Scan logs and the “scan_data_source_ip_count_qry” query:

Src_IP CountOfSrc_IPMY.NET.228.134 13743MY.NET.220.66 10043

MY.NET.211.114 9619205.188.233.153 9370MY.NET.228.54 8829MY.NET.202.86 7147MY.NET.230.6 6296

MY.NET.219.34 459024.112.6.86 4164

205.188.233.185 4044

“Top Ten Destinations” from the Scan logs and the “scan_data_dest_ip_count_qry” query:

Dest_IP CountOfDest_IP24.13.123.8 2487

24.18.176.117 1463MY.NET.178.154 1315

4.17.91.71 1307MY.NET.145.166 1247

88

MY.NET.151.70 1229MY.NET.110.169 1151MY.NET.222.194 1119MY.NET.110.33 1114

MY.NET.106.179 1031

“Top Ten Talkers” from the Alert logs with repsect to portscan events only, and the “spp_portscan_src_ip_count_qry” query:

Src_IP_of_Portscan CountOfSrc_IP_of_PortscanMY.NET.217.182 347MY.NET.211.114 147MY.NET.219.222 131MY.NET.202.86 124MY.NET.228.54 123MY.NET.214.90 123MY.NET.230.6 118212.95.92.218 77

MY.NET.220.66 76MY.NET.202.194 76

Considering the top talkers and destinations from the tables above, we get the following comprehensive lists:

Top Ten Talkers (Exclusively from the Scan Logs)

Source IP Address Number of Packets Sent Destination PortsMY.NET.228.134 13743 Numerous ports ranging from 1047

to 65452MY.NET.220.66 10043 Numerous ports ranging from 1024

to 64610MY.NET.211.114 9619 Numerous ports including 80, and

ranging from 1024 to 65413205.188.233.153 9370 Numerous ports ranging from 6970

(Napster or possibly GateCrasher Trojan) to 7142

MY.NET.228.54 8829 Numerous ports including 53 (DNS), 80 (HTTP), 208 (Appletalk?), 443 (SSL), 666 (Doom or Trojan port), and ranging from 1024 to 65217

MY.NET.202.86 7147 Numerous ports including 80 (HTTP), 208 (Appletalk?), 666

(Doom or Trojan port), and ranging from 1024 to 65535

MY.NET.230.6 6296 Numerous ports including 53 (DNS), 80 (HTTP), 208 (Unused Appletalk

port), 443 (SSL), 666 (Doom or Trojan port), and ranging from 1025

to 65529MY.NET.219.34 4590 Ports 1045, 1065, 15101, 15202,

89

32767 (all unassigned) and 32768 (RPC)

24.112.6.86 4164 Port 21 (FTP)205.188.233.185 4044 Port 6970 (Napster)

Top Ten Destinations (Compiled from the Alert and Scan Logs)

Source IP Address Number of Packets Received Type of TrafficMY.NET.219.34 2626 Port 32771 (RPC)

24.13.123.8 2487 Port scan of ports 2 through 6147, and numerous ports ranging from

6558 to 65301MY.NET.218.30 1581 Ports 6688 (Napster) and 4831

(unassigned)24.18.176.117 1463 Ports 1095 (Possible RAT Trojan),

1098 (Possible RAT Trojan), 1116, 1138, 1159, 1160, 1168, and 28800 (all the rest are either unassigned or

obscure services)10.10.10.50 1339 Port 137 (NetBIOS). NOTE: This is

most likely spoofed traffic or NAT’d traffic that was not proxied

correctly.MY.NET.178.154 1315 Port 53 (DNS) and 6970 (Napster)

4.17.91.71 1307 Numerous ports ranging from 1058 to 4609

MY.NET.145.166 1247 Port 6970 (Napster)MY.NET.219.38 1245 Ports 4815 and 4197 (unknown)MY.NET.151.70 1229 Port 6970 (Napster)

Top-Ten Talkers with an External IP Source Addresses from the Scan Logs

The following is a list of the top-ten external talkers from the scan logs. Registration information about each of the IP addresses is also shown. While one cannot assume the IP address is legitimate (IP spoofing may have been used), knowing where an attack may have originated from may help determine a course of action. For example, foreign attacks typically generate more concern than domestic attacks for organizations that handle data of a highly sensitive nature.

Src_IP CountOfSrc_IP205.188.233.153 9370

24.112.6.86 4164205.188.233.185 4044209.178.22.233 397264.160.53.230 2922210.52.214.15 249924.148.30.123 2030212.95.92.218 1444210.99.142.175 1297

90

212.67.128.102 1187

205.188.233.153Server used for this query: [ whois.arin.net ]America Online, Inc (NETBLK-AOL-DTC)22080 Pacific BlvdSterling, VA 20166USNetname: AOL-DTCNetblock: 205.188.0.0 - 205.188.255.255Coordinator:America Online, Inc. (AOL-NOC-ARIN) [email protected] System inverse mapping provided by:DNS-01.NS.AOL.COM 152.163.159.232DNS-02.NS.AOL.COM 205.188.157.232Record last updated on 27-Apr-1998.Database last updated on 2-Jul-2001 23:05:40 EDT.

24.112.6.86Server used for this query: [ whois.arin.net ]Rogers@Home Ontario (NETBLK-ROGERS-1-BLOCK)1 Mount Pleasant RoadToronto, ON M4Y 2Y5CANetname: ROGERS-1-BLOCKNetblock: 24.112.0.0 - 24.112.255.255Maintainer: RHONCoordinator:Network Security, Fraud (AD30-ARIN) [email protected] (416) 935-4729Domain System inverse mapping provided by:NS.ON.ROGERS.WAVE.CA 24.112.32.2NS.BC.ROGERS.WAVE.CA 24.112.31.254Record last updated on 02-Jan-2001.Database last updated on 2-Jul-2001 23:05:40 EDT.

205.188.233.185Server used for this query: [ whois.arin.net ]America Online, Inc (NETBLK-AOL-DTC)22080 Pacific BlvdSterling, VA 20166USNetname: AOL-DTCNetblock: 205.188.0.0 - 205.188.255.255Coordinator:

91

America Online, Inc. (AOL-NOC-ARIN) [email protected] System inverse mapping provided by:DNS-01.NS.AOL.COM 152.163.159.232DNS-02.NS.AOL.COM 205.188.157.232Record last updated on 27-Apr-1998.Database last updated on 2-Jul-2001 23:05:40 EDT.

209.178.22.233Server used for this query: [ whois.arin.net ]Charter Cable/Pasadena LAN (NETBLK-CBLPASLAN-USER0058)2215 W Mission RoadAlhambra, CA 91802USNetname: CBLPASLAN-USER0058Netblock: 209.178.22.233 - 209.178.22.240Coordinator:Earthlink Network, Domain Administrator (DAE4-ARIN) [email protected] (FAX) 626-296-5113Record last updated on 01-Nov-1999.Database last updated on 2-Jul-2001 23:05:40 EDT.

64.160.53.230Server used for this query: [ whois.arin.net ]PPPoX Pool - Rback33 SNFC21 (NETBLK-SBCIS-10067-152318)303 second StSan Francisco, Ca 94107USNetname: SBCIS-10067-152318Netblock: 64.160.52.0 - 64.160.55.255Coordinator:Pacific Bell Internet (PIA2-ORG-ARIN) [email protected] last updated on 08-Jun-2000.Database last updated on 2-Jul-2001 23:05:40 EDT.

210.52.214.15Server used for this query: [ whois.apnic.net ]inetnum: 210.52.128.0 - 210.52.255.255netname: CNCNETdescr: China Netcom Corp.descr: New Telecommunication Carrier Based on IP Backbonecountry: CNadmin-c: ZM28-APtech-c: ZM28-APmnt-by: APNIC-HM

92

mnt-lower: MAINT-CN-ZM28changed: [email protected] 20000627source: APNICperson: Zhao Mingqunaddress: 9/F, Building A, Corporate Square, No. 35 Financial Street,address: Xicheng District, Beijing 100032, P.R.Chinacountry: CNphone: +86-10-86011588fax-no: +86-10-88091446e-mail: [email protected]: ZM28-APmnt-by: MAINT-CN-ZM28changed: [email protected] 20001208source: APNIC

24.148.30.123Server used for this query: [ whois.arin.net ]21st Century Telecom Group, Inc. (NETBLK-21CENTURY-NET2)350 N. Orleans St. Ste. 600Chicago, IL 60654USNetname: 21CENTURY-NET2Netblock: 24.148.0.0 - 24.148.95.255Maintainer: 21CACoordinator:Operations Coordinator, EnterAct Network (ENO3-ARIN) [email protected] (312) 588-2900 (FAX) (312) 588-2944Domain System inverse mapping provided by:NS0.ENTERACT.COM 207.229.143.3BIFROST.SEASTROM.COM 192.148.252.10ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLERecord last updated on 24-Jan-2001.Database last updated on 2-Jul-2001 23:05:40 EDT.

212.95.92.218Server used for this query: [ whois.ripe.net ]inetnum: 212.95.88.0 - 212.95.95.255netname: EVdescr: Est-Videocommunicationdescr: 26 Boulevard du president Wilsondescr: 67954 Strasbourg Cedexdescr: Francedescr: Ip Block #3 provided by SdVcountry: FRadmin-c: EA359-RIPEtech-c: SG727-RIPE

93

status: ASSIGNED PAnotify: [email protected]: SDVmnt-lower: SDVchanged: [email protected] 20001128source: RIPEroute: 212.95.64.0/19descr: FR-SDVdescr: SdV Plurimedia IP-Block #1origin: AS8839cross-mnt: SDVmnt-by: SDVchanged: [email protected] 19991209source: RIPEperson: Etienne ANSELMaddress: Est Videocommunicationaddress: 42, route de Bischwilleraddress: 67300 Schiltigheim, Francephone: +33 3 88 76 44 63fax-no: +33 3 88 76 44 69e-mail: [email protected]: EA359-RIPEnotify: [email protected]: RAIN-TRANSPACchanged: [email protected] 19970610source: RIPEperson: Salim GASMIaddress: SDV PLURIMEDIAaddress: 15, rue de la nuee bleueaddress: 67000 STRASBOURGaddress: Francephone: +33 3 88 75 80 50fax-no: +33 3 88 23 56 32e-mail: [email protected]: SG727-RIPEmnt-by: RAIN-TRANSPACchanged: [email protected] 20000309source: RIPE

210.99.142.175Server used for this query: [ whois.nic.or.kr ]Korea Internet Information Service V1.0 ( created by KRNIC, 2001.6 )# ENGLISHIP Address : 210.99.142.128-210.99.142.191Network Name : HUISONG-NETConnect ISP Name : PUBNET

94

Connect Date : 19980910Registration Date : 19980910[ Organization Information ]Orgnization ID : ORG32743Org Name : Huisong Elementary SchoolState : KYONGGIAddress : 1101-1,DalandongDonganKuZip Code : 430-058[ Admin Contact Information]Name : Kumjong RuOrg Name : Huisong Elementary SchoolState : KYONGGIAddress : 1101-1, Dalandong DonganKuZip Code : 430-058Phone : 0343 82 4222Fax : 0343 82 4224E-Mail : [email protected][ Technical Contact Information ]Name : Kyunghee ShinOrg Name : Huisong Elementary SchoolState : KYONGGIAddress : 1101-1, Dalandong DonganKuZip Code : 430-058Phone : 0343 82 4222Fax : 0343 82 4224E-Mail : [email protected]

212.67.128.102Server used for this query: [ whois.ripe.net ]inetnum: 212.67.128.0 - 212.67.159.255netname: UK-CALLNET-981118descr: Data River Ltd.descr: Provider Local Registrycountry: GBadmin-c: BRAD-RIPEtech-c: BRAD-RIPEstatus: ALLOCATED PAchanged: [email protected] 19981118changed: [email protected] 19981211changed: [email protected] 19990120changed: [email protected] 19990813changed: [email protected] 20010216source: RIPEmnt-by: RIPE-NCC-HM-MNTchanged: [email protected] 20010515changed: [email protected] 20010522

95

route: 212.67.128.0/20descr: Data River Ltdorigin: AS9169notify: [email protected]: [email protected]: CALLNET-MNTchanged: [email protected] 20000405source: RIPEperson: Bradley Mulockaddress: Brecon Houseaddress: Meridian Gateaddress: 207 Marsh Walladdress: Londonaddress: E149YTphone: +44 20 7001 9999fax-no: +44 20 7515 9525e-mail: [email protected]: BRAD-RIPEremarks: Data River Senior Network Engineerchanged: [email protected] 20010619source: RIPE

OOS (Out of Spec) Log Analysis

A link graph was constructed using Excel by querying the Access database for all source IP's and destination ports. This list was then sorted by IP address and then by port number in ascending order. Only the first 104 IP addresses were addressed, and an alias was used for each of the IP addresses. The graph and the alias legend are located on the following page.

Note that the IP 62.238.69.199 was not included in the link graph as it port scanned 2,832 hosts on port 21 in the internal network. If this IP address were included in the graph, the scale would be altered to the point that the other data would not be discernible.

96

IP alias Legend used in OOS Link Graph

A = 193.253.250.36 a = 12.13.23.4 AA = 192.117.120.140 aa = 206.29.168.18B = 217.80.130.190 b = 128.175.107.57 BB = 192.168.0.4 bb = 207.164.170.84C = 216.232.176.84 c = 128.46.156.117 CC = 193.252.174.191 cc = 207.195.107.131D = 217.0.99.111 d = 128.91.67.166 DD = 194.126.96.110 dd = 207.210.120.215E = 217.82.118.36 e = 129.2.146.31 EE = 194.145.131.208 ee = 208.178.240.96

97

OOS Source IP and Destination Port Link Graph

AA

BB

CC

DED

FE

GF

HG

I J

KL

M

N

OP

Q

R

ST

U

VW

XYaHbc

e

e

k q aa ppf ghi

u

QQ XX

dd

xxj kkk l m o w

y

AA

II

LL

NN

WW

gghh

nn

oo rrss wwyyn

n

o

yp

p r

PPRRSSTTUUVV ii jj

tt

uus

qq

ss t v xd

y

AA EEFFGG JJ NN

OO

ZZ

gg

z

BBCCDD HH KKKK

LL

MM

YY

ccZZbb

dd

dd

dd

ddee

ff

kkll mmmm

mmmm

mmmm

mm

vvvvvvzz

0

5

10

15

20

25

Source IP by Alias

Num

ber o

f Con

nect

ion

Atte

mpt

s by

Atta

cker

to th

e Sp

ecifi

c Po

rt

Port 0 Port 1 Port 5 Port 20 Port 25 Port 80 Port 4657 Port 1991 Port 2350 Port 2054Port 6699 Port 4815 Port 5501 Port 4835 Port 6688 Port 2285 Port 3654 Port 3662 Port 3665 Port 1269Port 6346 Port 1117 Port 4237 Port 6355 Port 3292 Port 4355 Port 21536 Port 113 Port 2208 Port 2792Port 1763 Port 1712 Port 1242 Port 6347 Port 5501 Port 4036 Port 3436 Port 4310 Port 6969 Port 1059Port 1487 Port 2055 Port 1598 Port 6700 Port 3032 Port 2329 Port 2552 Port 2554 Port 2557 Port 2559Port 3112 Port 3359 Port 3261 Port 1091 Port 1107 Port 1131 Port 1233 Port 1256 Port 20099 Port 50847Port 16105 Port 38469 Port 57575 Port 2507

F = 213.76.200.201 f = 129.217.240.77 FF = 194.236.142.115 ff = 208.2.208.230G = 209.221.200.17 g = 129.237.48.140 GG = 194.236.50.60 gg = 208.40.12.35H = 63.202.186.140 h = 129.93.206.89 HH = 195.132.20.167 hh = 208.40.12.97I = 62.238.69.199 (not shown in graph)

i = 130.111.152.76 II = 195.194.178.252 ii = 209.14.216.137

J = 209.43.130.136 j = 130.240.195.206 JJ = 198.142.52.2 jj = 209.179.226.136K = 216.34.38.95 k = 131.204.196.8 KK = 199.8.35.235 kk = 209.179.229.1L = 130.236.181.114 l = 131.204.206.150 LL = 200.42.5.159 ll = 209.179.229.9M = 130.79.11.43 m = 131.211.104.241 MM = 202.104.128.94 mm = 209.221.200.17N = 140.198.85.25 n = 132.68.148.60 NN = 202.50.71.50 nn = 209.233.26.247O = 141.89.233.53 o = 134.109.185.77 OO = 202.92.68.179 oo = 209.52.60.233P = 194.67.67.194 p = 139.142.84.242 PP = 202.92.69.172 pp = 209.77.13.138Q = 195.57.122.4 q = 142.165.130.184 QQ = 202.92.69.199 qq = 209.85.37.71R = 209.189.115.49 r = 142.166.129.39 RR = 202.92.70.1 rr = 210.54.80.221S = 212.106.240.48 s = 147.251.48.205 SS = 202.92.70.252 ss = 212.10.18.172T = 212.15.197.26 t = 147.46.64.75 TT = 202.92.94.214 tt = 212.104.166.2U = 216.158.45.26 u = 148.235.88.70 UU = 202.92.97.129 uu = 212.111.188.29V = 217.1.185.3 v = 150.216.125.188 VV = 202.92.98.32 vv = 212.171.49.18W = 217.136.5.157 w = 151.203.18.154 WW = 203.146.103.230 ww = 212.172.200.231X = 24.112.35.160 x = 152.33.102.201 XX = 204.185.36.143 xx = 212.32.176.6Y = 24.163.255.147 y = 158.75.57.4 YY = 204.244.73.241 yy = 212.68.217.211Z = 24.93.221.31 z = 165.121.40.102 ZZ = 205.251.212.132 zz = 212.95.81.20

By inspecting the link graph, we can observe the following:

Most of the connection attempts from external IP addresses contained one to three packets. The dense line of letters just above the x-axis indicates this.

A few selected ports received numerous hits. The top 25 ports with the most hits (besides port 21, which received 2,832 hits) is shown below:

Dest_Port CountOfDest_Port6346 234

80 6421536 41

20 406347 326699 286688 175501 13113 7

6700 72554 6

10281 64237 52055 5

98

50847 44657 4

32864 46345 4

50875 42054 4

54392 461538 414412 4

1 46355 3

Using these port connection totals and the link graph, we can observe how many hosts are trying to connect to the various ports. For instance, port 20 was hit by two external IP’s: G = 209.221.200.17 and H = 63.202.186.140. Port 80 received attempted connections for numerous hosts, with the top originating sender being R = 209.189.115.49. Port 6346 (Gnutella) received the most hits in the list above.

While link graphs are a great way to visually detect patterns and display data trends, the large number of OOS packets received makes detailed analysis difficult without creating a large number of graphs. To further analyze the data, specific queries were written based on selected well-known attacker techniques. The results are shown below:

SYN-FIN Scanning:

One internal host and one external host created all the detected SYN-FIN scans. The external host scanning 2,833 internal hosts using this technique. A subset of the data is shown below:

Day Time Src_IP Dest_Port Packet_Flags17 8:18:58 PM MY.NET.217.182 1478 **SF****

17 8:20:39 PM MY.NET.217.182 6346 **SF****17 11:01:58 AM MY.NET.217.182 11682 **SF****19 10:22:03 AM MY.NET.217.182 49349 **SF****18 7:55:21 PM 62.238.69.199 21 **SF****

“X-mas Tree” Scanning:

X-mas Tree scans are scans that send packets with all the flags set. The follows flag combination was used to query these packets from the database: 21SFRPAU. Twenty-two packets met these criteria. The data set is shown below.

Day Time Src_IP Dest_Port Packet_Flags13 6:28:22 AM 24.177.231.216 1214 21SFRPAU

13 12:02:44 PM 209.221.200.17 1256 21SFRPAU13 11:07:42 PM 24.70.144.150 6346 21SFRPAU

99

13 11:13:27 PM 24.141.138.19 1452 21SFRPAU14 7:27:40 AM 132.68.148.60 4237 21SFRPAU16 4:53:59 AM 213.132.153.55 6688 21SFRPAU16 11:25:28 AM 209.221.200.17 20 21SFRPAU16 11:27:13 AM 209.221.200.17 20 21SFRPAU16 11:29:27 AM 209.221.200.17 20 21SFRPAU16 11:33:16 AM 209.221.200.17 20 21SFRPAU16 11:58:12 AM 209.221.200.17 20 21SFRPAU16 7:17:27 PM 24.216.227.244 1511 21SFRPAU19 9:31:43 AM 62.161.99.251 6346 21SFRPAU19 10:23:44 PM 209.233.26.247 6346 21SFRPAU19 10:24:05 PM 63.202.186.140 20 21SFRPAU19 10:26:44 PM 66.27.58.133 58592 21SFRPAU19 10:30:00 PM 66.27.58.133 14412 21SFRPAU19 10:50:40 PM 64.210.30.8 6700 21SFRPAU19 11:03:13 PM 63.202.186.140 20 21SFRPAU19 11:05:40 PM 63.175.96.1 6346 21SFRPAU19 11:18:18 PM 63.230.236.52 6699 21SFRPAU19 11:39:43 PM 216.115.107.17 64828 21SFRPAU

Anomalous Activity and Compromised Machines on the Internal Network

Identifying compromised machines and computer misuse from an unfamiliar network’s logs is at best a risky endeavor. Having first hand knowledge of the network and a sense of what is “normal” is the best tool in identifying anomalous activity. Having said that, and using the logs that have been provided, the following recommendations should be considered for machines within your internal network.

Your internal host MY.NET.178.42 should be inspected for trojans and other viruses. A complete virus scan of the box is in order.

Inspect the internal hosts MY.NET.6.34, MY.NET.253.41 and MY.NET.6.7. These hosts were either the source and/or destination of possible “myserver” traffic.

The hosts MY.NET.204.194, MY.NET.70.242, MY.NET.217.230, and MY.NET.212.198 should be carefully inspected. If the Red Worm is not found on these internal hosts, web server logs should be inspected to see what kinds of traffic these hosts created.

Inspect the following hosts for the Red Worm alert as above: MY.NET.201.206, MY.NET.210.130, MY.NET.253.24, and MY.NET.228.126.

A possible SubSeven infestation of your internal network might have occurred. See Possible trojan server activity for more detail.

The internal host MY.NET.202.34 appears to be scanning the Internet for machines with Subseven servers listening on port 27374.

100

The internal hosts MY.NET.202.34, MY.NET.98.142 and MY.NET.221.50 appear to be at least attempting to task trojans listening on port 27374 on the Internet. Also note that MY.NET.221.50 was identified in the "tcp Red Worm" alert as sending traffic to port 65535.

The following hosts should be inspected for signs of misuse and/or compromise. In particular, a large amount of port 20 (FTP) traffic was observed between external hosts and these internal machines.

MY.NET.144.54 MY.NET.253.52 MY.NET.6.35MY.NET.100.56 MY.NET.6.7 MY.NET.6.34MY.NET.253.43 MY.NET.4.3 MY.NET.253.51MY.NET.6.47 MY.NET.100.230 MY.NET.253.41

Since OOS packets contain unusual or illegal TCP packet flag combinations, all internal hosts that send such packets should be inspected. The following is a list of such hosts, and how many packets they sent. These hosts should be inspected for possible compromise or misuse.

Src_IP CountOfSrc_IPMY.NET.217.182 315MY.NET.202.242 5MY.NET.225.42 1



101

References

[1] Postel, J. “Internet Control Message Protocol DARPA Internet Program Protocol Specification” RFC 792. September, 1981. URL: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0792.html (10 June, 2001).

[2] Stevens, W. Richard “TCP/IP Illustrated, Volume 1” Addison-Wesley, 1994. URL: http://www.bookpool.com/.x/a2x6nrz4y8/sm/0201633469

[3] Winters, Scott “Top Ten Blocking Recommendations Using Cisco ACL, Securing the Perimeter with Cisco IOS 12 Routers” August 15, 2000. URL:http://www.sans.org/infosecFAQ/firewall/blocking_cisco.htm (10 June, 2001).

[4] Cisco Sytems Inc. “Improving Security on Cisco Routers” 1992-2001. URL:http://www.cisco.com/warp/public/707/21.html (10 June, 2001).

[5] SANS Institute “Cisco Anti-Spoof Egress Filtering” Revision 1.26. March 23, 2000. URL:http://www.sans.org/dosstep/cisco_spoof.htm (10 June, 2001).

[6] Asadoorian, Paul “What is the TSIG vulnerability?” April 4, 2001. URL: http://www.sans.org/newlook/resources/IDFAQ/TSIG.htm (June 14, 2001).

[7] Albitz, Paul and Liu, Cricket “DNS and BIND: 3rd Edition" O’Reilly & Associates, Inc., 1998. URL (The 4th edition of “DNS and BIND” is now available. It’s purchase is suggested.): http://www.bookpool.com/.x/a2x6nrz4x1/sm/0596001584 (June 15, 2001).

[8] Eastlake, D. 3rd, Brunner-Williams, E., and Manning, B. “Domain Name System (DNS) IANA Considerations” RFC 2929. September, 2000. URL: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2929.html (15 June, 2001).

[9] Kuethe, Chris “GCIA Practical Assignment” February 22, 2001. URL: http://www.sans.org/y2k/practical/chris_kuethe_gcia.html#1.4 (June 10, 2001).

[10] Para-Protect “Operational Risk Advisory 20010108.0900/ORA1”, January 8, 2001. URL: http://www.para-protect.com/Advisories/Guests/2001/20010108.0900_ORA1.pdf (July 3, 2001).

[11] Ricketts, Mike “SendIP”, April 26, 2001. URL: http://www.earth.li/projectpurple/progs/sendip.html (June 2, 2001).

[12] Whitehats, Inc. “IDS177/NETBIOS_NETBIOS-NAME-QUERY”, June 27, 2001. URL: http://www.whitehats.com/IDS/177 (July 1, 2001).

102



http://www.para-protect.com/Advisories/Guests/2001/20010108.0900_ORA1.pdf

http://www.sans.org/y2k/practical/chris_kuethe_gcia.html#1.4


http://www.bookpool.com/.x/a2x6nrz4x1/sm/0596001584


http://www.sans.org/dosstep/cisco_spoof.htm

http://www.cisco.com/warp/public/707/21.html


http://www.bookpool.com/.x/a2x6nrz4y8/sm/0201633469


Appendix A

Detailed Analysis Process Used to Analyze GIAC University Snort Data

I chose to analyze the Snort files that were labeled with the dates 04/13/01 to 04/19/01. There were seven sources for the alerts, oos, and scan file types (one of each per day).

Tools Used in the Analysis Process

awk vi editor bash shell Perl, version 5.6.0 Microsoft Access 97 SnortSnarf, version 052101.1

Alert Files

The alert files alert.010413 through alert.010419 were cat’d together and redirected to the file alert.010413_to_010419 with the following command:

cat alert.010413 alert.010414 alert.010415 alert.010416 alert.010417 alert.010418 alert.010419 > alert.010413_to_010419.

To analyze the alert data, I modified all the entries in the alert.010413_to_010419 file that had the first two octets “MY.NET” to be “199.256”. This is because SnortSnarf does not interpret “MY.NET” correctly and thus causes the source and destination address to appear as “(no IP)” in the SnortSnarf signature page. To do this, I copied the file alert.010413_to_010419 to alert.010413_to_010419_modified. Although “199.256” is not a valid beginning portion of any network address, I first grep’d the alert.010413_to_010419_modified file to make sure this string not occur. It did not. Note that this modification was not necessary for analyzing the data in the Access database I created, so I left the “MY.NET” portion of the internal IP addresses intact.

I then vi’d the alert.010413_to_010419_modified file and replaced all occurrences of the string “MY.NET” with “199.256” by issuing the following command in “command mode” (achieved by hitting the escape key in vi):

:1,$s/MY.NET/199.256/g

The screen shot of the “SnortSnarf start page” is of the screen when the SnortSnarf.pl script was run using the alert.010413_to_010419_modified file as the argument.

I observed that SnortSnarf did not include the spp_portscan entries in the alert summary page. After looking at real Snort alert files from my own network, it seems that the portscan only produces an alert when a signature is matched. Thus, I decided I needed to grep out all the

103

portscan log entries with the string “TOTAL HOST” from my alert.010413_to_010419_modified file and analyze these separately.

The “outside network” events in the alerts file did not show up in the scan files, so I grep’d out these events to analyze separately. The file containing the “outside network” events was modified using vi commands such as :1,$s/\//:/g to replace the “/” character with a “:” to make the field delimiters uniform and importing the file into the database easier. I also used the awk command to pull out the time field and into another file (awk ‘{print $1}’ scan_data > scan_data_time). Many substitutions using vi and various awk commands were used to finally create a set of files I could import into the database and create a single table via a “make table” query.

I then modified the alert data using a few global search and replace command using vi and egrep’d out all lines with the string “spp_portscan” from the alert.010413_to_010419_modified file and redirected the results to a separate data file. Since the remaining alerts had variable length “alert messages” that were delimited by spaces, I used the Perl script below to extract all the fields with a colon “:” out of the data file and redirect those results to yet another data file. The results included the date, time, source IP, source port, destination IP, and destination port. This data was then loaded into the Access database for analysis as “inside alerts”, which are connection attempts that have a MY.NET.* address as either the source or destination address, or both.

#!/usr/bin/perl -w

use strict;

my ($line,@line,$found,$f);

while ( defined ($line = <>) ) {chomp $line;@line = split( /\s+/, $line);$found = 0;foreach $f (@line ) {## output field seperator$found and print " ";

if ( $f =~ /\:/) {print $f;$found = 1;}}$found and print "\n";}

Scan Files

104

The scan files were cat’d together and redirected to a new file. Similar vi and awk commands were used to properly delimit the data and the resulting file was then imported into the database. OOS Files

Next, I grep’d out the first line of each packet of the OOS files using the “MY.NET” string into a separate file. I then compared the number of lines in this new file to the number of packets that Snort processed (available at the bottom of the OOS file). In all cases, they were the same.

I then grep’d out the subsequent lines of each packet containing the TTL and ACK fields to separate files. Since the OOS data only included TCP packets, grep’ing on “TTL” and “Ack” are valid operations in terms of maintaining the data integrity while porting the data to the database. I then imported this data into the database and combined it into a single table using a “make table” query. I did not, however, load any payload data from the OOS files into the database.

Access Database

Finally, I wrote numerous queries that correlated data based on IP, port, time, protocols, etc. The database is located here: http://web2.airmail.net/a0055941/gcia_v2.9_snort_db.ZIP.

105

http://web2.airmail.net/a0055941/gcia_v2.9_snort_db.ZIP

Appendix B

Snort packet captures of the broadscan.c, broadscan05.c and hping2-beta54 tools sending crafted ICMP echo requests.

The Broadscan tools cannot craft an ICMP ID of 0, or a TOS value of 0xC0, without the attacker significantly modifying the source code. In addition, the broadscan packet captures below reflect a few modifications to the hardcoded IP octets in the source code to enable the tool to run on my network. These modifications did not affect the attack signature in any way, other than the destination address having a last octet that the original source code could not create. All the following traces were obtained from traffic created by binaries compiled and executed using Mandrake Linux 7.1.

broadscan.c

06/06-15:15:17.032604 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x62 192.168.1.28 -> 192.168.1.31 ICMP TTL:64 TOS:0x0 ID:1064 IpLen:20 DgmLen:84 Type:8 Code:0 ID:54020 Seq:0 ECHO 55 8F 1E 3B 3D 7F 00 00 08 09 0A 0B 0C 0D 0E 0F U..;=........... 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567

broadscan05.c

06/06-15:14:32.398046 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x62 192.168.1.28 -> 192.168.1.31 ICMP TTL:64 TOS:0x0 ID:1062 IpLen:20 DgmLen:84 Type:8 Code:0 ID:51716 Seq:0 ECHO 28 8F 1E 3B AD 12 06 00 08 09 0A 0B 0C 0D 0E 0F (..;............ 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567

Note that the -E option in hping2 could supposedly be used to read data from a file, which might create the crafted ICMP. However, I could not get the IP ID to hardcode to a single, unchanging value, or craft the ICMP ID to be 0. Hping2 can however craft the TOS value.

hping2-beta54

Output from the command: hping2 192.168.1.26 -1 -N 0 -o C0 -C 8 -K 0 -d 4

06/07-10:42:05.635143 0:D0:59:13:a:b -> 8:0:20:A9:a:b type:0x800 len:0x2E 192.168.1.28 -> 192.168.1.26 ICMP TTL:64 TOS:0xC0 ID:1104 IpLen:20 DgmLen:32 Type:8 Code:0 ID:44036 Seq:0 ECHO 58 58 58 58 XXXX

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


106

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Based on these packet captures, and those produced by SendIP, I believe the traffic in the first trace of Assignment 1 was produced by the tool SendIP.

107

sans giac level two – intrusion detection in · web viewfor example, the class c network...

Documents