[Intrusions] OGS: GIAC GCIA Version 3.5 Practical Detect Alexander Schinner
Alexander Schinner
schinner at acm.org
Sat Sep 18 07:33:57 GMT 2004
Hi all,
Here is my network detect required for the
GCIA certification assignment.
Any comments would be appreciated.
Thanks in advance,
Alex
Just looking!
=============
Source of Trace
---------------
The original tcpdump log file 2002.10.13 was downloaded from
ther given site[1]. According to SANS Institute, the
network traffic was captured using an unknown version of snort with an
unknown rule set, the data has been sanitized.
Before analyzing any network traffic it is highly recommended to have
some basic knowledge about the network itself. Without this
knowledge, a lot of questions cannot be answered and it will be hard
to judge the severity of an attack. As the only data provided by GIAC
is the tcpdump log file, we will at first try to make good, reasonable
guesses on the network.
Using the program ipanalyze, we see that 245 IP-addresses are
contributing to this log:
host> ipanalyze -r ~/SANS/raw/2002.10.13 -o '%d\n%s' | sort -u | wc -l
245
The next step of our little network analysis is to check the frequency
of the different IP addresses grouped by class B networks. With some
luck, the most frequent among those should be the local network.
207.166.0.0/16 3109
64.154.0.0/16 1086
66.159.0.0/16 663
205.188.0.0/16 430
209.11.0.0/16 117
63.111.0.0/16 107
209.10.0.0/16 71
64.12.0.0/16 48
255.255.0.0/16 35
207.68.0.0/16 30
The biggest block of addresses occurs in the subnet 207.166.0.0/16
with 68 addresses ranging from 207.166.11.232 to 207.166.252.249. By
checking the MAC address, we try to prove that this is the local
network.
If the mac addresses in network 207.166.0.0/16 are mostly belonging to
NIC manufactures, the computer is most probably part of a LAN. This
would be another strong hint for the assumption that 207.166.0.0/16 is
the local network.
host> ipanalyze -r 2002.10.13 -o '%m\n%M' | sort -u
00:00:0c:04:b2:33
00:03:e3:d9:26:c0
Bad luck, only two mac addresses were found, both belonging to
CISCO. This means, we are sniffing between two switches, routers or
firewalls. Now we can try to get some information by mapping the mac
addresses to the IP addresses.
host> ipanalyze -r 2002.10.13 -o '%M %s\n%m %d' | sort -u
00:00:0c:04:b2:33 12.11.133.5
00:00:0c:04:b2:33 12.111.47.194
00:00:0c:04:b2:33 12.47.193.41
[... deleted some lines ...]
00:00:0c:04:b2:33 80.4.49.69
00:00:0c:04:b2:33 80.4.53.36
00:00:0c:04:b2:33 80.6.223.204
00:00:0c:04:b2:33 81.98.104.191
00:03:e3:d9:26:c0 207.166.103.217
00:03:e3:d9:26:c0 207.166.104.170
00:03:e3:d9:26:c0 207.166.106.95
[... deleted some lines ...]
00:03:e3:d9:26:c0 207.166.87.53
00:03:e3:d9:26:c0 207.166.95.105
00:03:e3:d9:26:c0 207.166.98.123
Obviously, all computers in the subnet 207.166.0.0/16 can be reached
through the mac address 00:03:e3:d9:26:c0, all other addresses are
connected to 00:00:0c:04:b2:33. The fact that computers in Parsippany,
NJ (2.11.133.5) and Tokyo, Japan (219.163.126.118) can be accessed
over the same mac address, belonging to CISCO, tells us, that this
device is a router or firewall connected to the Internet.
The local network seems to be behind a CISCO Device with the mac
address 00:03:e3:d9:26:c0. However, as this data has been sanitized by
SANS, it can be assumed that these addresses are not the original
ones. The device could be a router or a firewall, but we can not be
sure.
Important for an analysis is where and with what kind of method we are
capturing the network traffic. Can the dump tell us how the snort box
is sniffing? The IDS can be connected using a SPAN port, a Hub or an
Ethernet tap. All these methods do not influence the network,
therefore we do not gain any knowledge about the type of connection.
00:03:e3:d9:26:c0 00:00:0c:04:b2:33
+-+ +-+
207.166.0.0/16---|X|---------T----------|X|------Internet
+-+ | +-+
|
|
+-------+
| snort |
+-------+
Detect was generated by
-----------------------
The detect was generated by snort Version 2.2.0 (Build 30) using the
command line:
host> snort -c /etc/snort/snort.conf -k none -r 2002.10.13
Using the option -t was important as due to the sanitization the
header checksums are incorrect. Only with this option snort is willing
to analyze packets with bad checksums. The generated alerts had been
saved in a MySQL Database and were viewed with ACID v0.9.6b20-5.1. We
will analyze the following three detects in more detail:
Generated by ACID v0.9.6b20-5.1 on Sat, 11 Sep 2004 19:49:09
+0200
------------------------------------------------------------------------------
#(3 - 3780) [2002-11-13 01:21:55] url[snort/615] SCAN SOCKS Proxy attempt
IPv4: 66.159.18.49 -> 207.166.87.157
hlen=5 TOS=0 dlen=60 ID=49542 flags=0 offset=0 TTL=53 chksum=21100
TCP: port=48451 -> dport: 1080 flags=******S* seq=2275796995
ack=0 off=10 res=0 win=5840 urp=0 chksum=41682
Options:
#1 - MSS len=2 data=05B4
#2 - SACKOK len=0
#3 - TS len=8 data=01F1298500000000
#4 - NOP len=0
#5 - WS len=1 data=00
Payload:
none
------------------------------------------------------------------------------
#(3 - 3781) [2002-11-13 01:21:55] [snort/620] SCAN Proxy Port 8080 attempt
IPv4: 66.159.18.49 -> 207.166.87.157
hlen=5 TOS=0 dlen=60 ID=18547 flags=0 offset=0 TTL=53 chksum=52095
TCP: port=48452 -> dport: 8080 flags=******S* seq=2272616959
ack=0 off=10 res=0 win=5840 urp=0 chksum=3495
Options:
#1 - MSS len=2 data=05B4
#2 - SACKOK len=0
#3 - TS len=8 data=01F1298C00000000
#4 - NOP len=0
#5 - WS len=1 data=00
Payload:
none
------------------------------------------------------------------------------
#(3 - 3782) [2002-11-13 01:21:55] [snort/618] SCAN Squid Proxy attempt
IPv4: 66.159.18.49 -> 207.166.87.157
hlen=5 TOS=0 dlen=60 ID=3550 flags=0 offset=0 TTL=53 chksum=1557
TCP: port=48453 -> dport: 3128 flags=******S* seq=2282038346
ack=0 off=10 res=0 win=5840 urp=0 chksum=24091
Options:
#1 - MSS len=2 data=05B4
#2 - SACKOK len=0
#3 - TS len=8 data=01F1299400000000
#4 - NOP len=0
#5 - WS len=1 data=00
Payload: none
The notation of the output format is described in the analysis of the last
detect.
These above alerts had been triggered by the following snort signatures:
alert tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg:"SCAN Proxy Port
8080 attempt"; flags:S,12; flow:stateless; classtype:attempted-recon;
sid:620; rev:10;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 3128 (msg:"SCAN Squid Proxy
attempt"; flags:S,12; flow:stateless; classtype:attempted-recon;
sid:618; rev:9;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 1080 (msg:"SCAN SOCKS Proxy
attempt"; flags:S,12; flow:stateless;
reference:url,help.undernet.org/proxyscan/; classtype:attempted-recon;
sid:615; rev:9;)
The only functional difference between these three signatures is the
destination port.
Probability the source address was spoofed
------------------------------------------
The alert showed, that there were three attempts to connect to
different ports. Most probably, the attacker wanted to check whether
the ports are accessible. Spoofing the source address would be
useless, as in this case the scanner would get no answer. An
exception might be, if the sender was able to monitor the traffic
going to the forged source address. However, chances are high, that
the address was not spoofed.
Description of attack
---------------------
The three connects follow the same scheme. The attacker tried to
initiate a three way handshake to proxy services which should normally
be accessible only by users of the local network. Than, after he had
found a proxy accepting his requests, he had the following different
possibilities.
-- Attack hosts on the LAN in the hope to use some trusted relationships
-- Attack or connect hosts on the outside, hiding behind the proxies
IP-address
-- Attack the proxy service itself by using some exploits.
Attack mechanism and Correlations
---------------------------------
In the current case, all three connects came within 0.15 seconds. This
means the attacker was using an automated tool. Was the connect
successful? It is hard to decide this directly from the tcpdump file,
as we see no answer from 207.166.87.157 either accepting or rejecting
the connection. However, there is some evidence that this connect was
not successful:
-- We see no other packet originating from or going to the
attackers address (66.159.18.49).
-- No other traffic from outside the network is directed to port
3128 and 1080. There are only two other connects to port 8080. One
can assume, that an open proxy might have attracted much more traffic
which would have been recorded and reported by snort.
On the other hand, 207.166.87.157 might be the local proxy. Every
connection going to port 80 on the outside network is coming from
207.166.87.157.
What can we say about the tool that was used by the attacker? The
first guess would be that the connects had not been initiated by a
human attacker but by a Trojan, the well known Zero_Ring. Three
connects to port 1080, 8080, and 3128 are typical for this malware.
Everything we need to know about this Trojan was already described by
Steven Northcut [2] so I don't want to bother the reader by repeating
his words. However, also according to S. Northcut[3], some attackers
are hiding other attacks behind a typical Zero_Ring behavior.
A search of the CVE database for keywords like squid, proxy or socks
results in such a tremendous lot of entries that it might in fact be a
good idea to hide behind a well known pattern while attempting new
attacks.
What can we say about the attacker himself? Searching dnsstuff.com for
66.159.18.49 we get the following information:
OrgName: IIC Internet
OrgID: IICINT
Address: 17905 Vista Court
City: Santa Clarita
StateProv: CA
PostalCode: 91387
Country: US
NetRange: 66.159.16.0 - 66.159.20.255
CIDR: 66.159.16.0/22, 66.159.20.0/24
NetName: WLCO-TWC874610-IICINT
NetHandle: NET-66-159-16-0-1
Parent: NET-66-159-0-0-1
NetType: Reassigned
NameServer: STLDNS1.WCG.NET
NameServer: TULDNS1.WCG.NET
Comment:
RegDate: 2002-07-19
Updated: 2002-07-19
TechHandle: CH1236-ARIN
TechName: Herzig, Chris
TechPhone: +1-661-298-1438
TechEmail: chris at iicinternet.com
The company itself, according to their homepage, seems to work in the
web-hosting business. We searched dshield.org and mynetwatchman.com
to see if there is activity reported for 66.159.18.49. Both did not
return any hit.
The program p0f, a passive OS fingerprinting utility, tells us, that
the attacker is using Linux.
p0f - passive os fingerprinting utility, version 2.0.3
(C) M. Zalewski <lcamtuf at dione.cc>, W. Stearns <wstearns at pobox.com>
p0f: listening (SYN) on '2002.10.13', 207 sigs (12 generic), rule: 'host
66.159.18.49'.
66.159.18.49:48451 - Linux 2.4/2.6 (up: 90 hrs)
-> 207.166.87.157:1080 (distance 11, link: ethernet/modem)
66.159.18.49:48452 - Linux 2.4/2.6 (up: 90 hrs)
-> 207.166.87.157:8080 (distance 11, link: ethernet/modem)
66.159.18.49:48453 - Linux 2.4/2.6 (up: 90 hrs)
-> 207.166.87.157:3128 (distance 11, link: ethernet/modem)
As the Trojan is running on Windows systems but the source seems to be
a Linux box, the theory about the Zero_Ring attack might be improper.
Another piece of information is the link an URL [4] which we find in
the snort signature "Proxy attempt" (sid:615). According to this page
the UnderNet server is scanning everybody who is connecting to their
service:
Due to the overwhelming abuse of misconfigured Wingate, Socks and
Proxy servers being exploited daily, the UnderNet network is now
checking all users upon connection to any of the UnderNet IRC Servers.
This check is ONLY DONE if a user attempts to establish a connection
to an UnderNet IRC server.This should not be considered an attack on
your system. Be aware that this sort of connection to your system is
probably common if you use services such as free IRC networks, game
servers, etc...
Unfortunately, no connection to UnderNet IP-Address 209.198.2.21 was
made, which would have explained the detect. The last sentence in the
message taken from the URL [4] gives us a next hint for
our search. Maybe our target 207.166.87.157 had made connections which
might have triggered this traffic. ACID gives us the following alerts
for the host:
CHAT IRC nick change 718
SHELLCODE x86 NOOP 25
SCAN nmap TCP 18
CHAT MSN message 3
SCAN Proxy Port 8080 attempt 1
SCAN SOCKS Proxy attempt 1
SCAN Squid Proxy attempt 1
Great, there is IRC traffic, don't forget UnderNet is an IRC server,
too. And most of the traffic (680 packets) is going to
server.iicinternet.com (66.159.18.68). And this IP belongs to the same
range, the proxy scan came from. So this is a another strong evidence
that the origin was not a Zero_Ring but triggered by IRC traffic.
Unfortunately, we have a problem with the timestamps. The alerts based
on the IRC traffic appeared between 2002-11-13 20:26:49 and 2002-11-13
20:22:57, the proxy scan was 19 hours earlier, at 2002-11-13
01:21:55. The tcpdump does not tell us whether there was IRC traffic
before 20:26:49. The type of IRC traffic that we would need to proove
the above assumptions would normally not be registered by snort. The
registered IRC traffic, however, is suspicious in itself. 680 Nick
changes to R00teD would need another analysis not given here.
Everything points to the fact that the attack was not triggered by
Zero_Ring but by the target itself.
Evidence of active targeting
----------------------------
If we assume that the attacker was infected by the Zero_Ring Trojan,
targeting 209.198.2.21 was only a random hit. Alternatively, host
207.166.87.157 might have attracted this scan by entering some shady
areas of the Internet. The is no evidence from this data (ignoring the
nick changes) that 207.166.87.157 is under attack.
Severity
--------
Severity = (Criticality + Lethality) - (System Countermeasures +
Network Countermeasures)
Criticality
Host 207.166.87.157 seems to be in heavy use on the victims
network. However, without complete informations it is hard to decide
its criticality. So we will rate it a 3.
Lethality
Here we should differentiate between the two possible sources. If it
was a Zero_Ring, the severity would be quite high, maybe even a 5. If
it was the reaction of the IRC-server, there will be no harm to the
system, so maybe a 1. As chances are very high, we are not dealing
with Zero_Ring, we choose 3.
System Countermeasures
Judging from the other traffic of this host, there is no draconic
system administrator. It is hard to decide how well the network is
patched. So I choose 2.
Network Countermeasures
Due to the estimated network, it seems reasonable to assume, that
there is at least a packet filter firewall or ACLs on the
router. Therefore, maybe here another 2 might be reasonable.
Severity= $(3+3)-(2+2)=2 $
Defensive recommendation
------------------------
The first steps should be at least a stateful packet filter firewall
in front of the organizations network. Judging from the seen traffic,
there are no restrictions for the users, resulting in highly
suspicious traffic. The management of this organization must also face
the fact that users are surfing for hard core porn. Checking this and
the other log files with a patched {The original version of
driftnet cannot read tcpdump files. In this case, a combination of
driftnet and tcpreplay mostly works.} version of driftnet (driftnet is
comparable to dsniff, however, it sniffs for pictures and nor for
passwords), one sees pictures showing every detail of the human
anatomy striking very explicit poses.
Multiple choice test question
-----------------------------
According to some IDS specialists, the Trojan Zero_Ring tries to
connect the ports 1080, 8080 and 3128 of a possible victim in always
exactly this order.
In your log files, you found three connects in the following order:
8080, 1080 and 3128. Which statement is not correct?
a) Maybe it is a modified version of Zero_Ring
b) It can't be Zero_Ring, as this is the wrong order
c) It might be an original Zero_Ring, but the packets arrived in
another order than they had been sent.
d) Maybe someone is hiding behind a behavior very similar to Zero_Ring.
The correct answer is b)
a) This is possible, of course.
b) A wrong statement, see a) and c)
c) Today not very likely, but possible
d) This is possible, see http://www.sans.org/y2k/050300-1100.htm
References
----------
[1] http://www.incidents.org/logs/Raw/2002.10.13
[2] http://www.sans.org/resources/idfaq/ring\_zero.php
[3] http://www.sans.org/y2k/050300-1100.htm
[4] http://help.undernet.org/proxyscan/
More information about the Intrusions
mailing list