Analysis provided by Lance Spitzner, Sun Microsystems SunPS
The Honeynet Project
The Challenge:
The Analysis:
Packet extraction
ASCII cleartext extraction
We can now use the data extracted to
snort.txt
and ./log
directory to better analyze the attack. The first thing we will notice
is that our honeypot went on online at 15 March. This is why that
the honeypot does not respond to any connections before 12:30, because
there is honeypot to respond. At 12:34 the system is now online and
excutes whois to test online connectivity.
03/15-12:34:07.018434 172.16.1.108:1025 -> 216.168.224.69:43
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/15-12:34:07.189410 216.168.224.69:43 -> 172.16.1.108:1025
Now that we have determined when the system went online, we can begin
our analysis.
1. What modifications did they make to the break in process to both automate and
make the process faster?
03/15-20:21:23.840485 211.185.125.124:3493 -> 172.16.1.101:111
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/15-20:21:23.857472 211.185.125.124:3495 -> 172.16.1.103:111
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/15-20:21:23.863730 211.185.125.124:3494 -> 172.16.1.102:111
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
We then see our system scanned and exploited.
03/15-20:21:24.107053 211.185.125.124:3500 -> 172.16.1.108:111
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/15-20:21:24.452051 211.185.125.124:789 -> 172.16.1.103:111
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/15-20:21:24.730436 211.185.125.124:790 -> 172.16.1.103:32773
... followed by the tool confirming a successful exploit ...
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/15-20:21:36.539731 211.185.125.124:4450 -> 172.16.1.108:39168
Notice how this entire process is automated, from the scan, identification,
to explotation. The attacker is most likely scanning thousands, if
not millions, of systems using an autorooter.
Amost all the steps involved in attacking a system have been combined into
a single tool. This makes early
warning and prediction far more difficult.
2. What system/country did the badguys come in from?
3. What nationality are the badguys, and how were you able to determine this?
4. What do the answers to questions #1 and #2 tell us about the tactics the badguys
are using?
5. What did you learn from this challenge?
6. How long did this challenge take you?
Bonus Question:
On March 15, the honeypot 172.16.1.108 was compromised. Armed only with
a Snort binary capture of the attack, your mission is to accomplish the following.
Bonus Question:
Can you recover the blackhat's rootkit from the Snort binary log file?
If so, how?
The first step
is to download the file and confirm the MD5 Checksum, this validates the
integrity of the file. Then the analysis can begin. wget(1) is a Unix utility
that retrieves files from the World Wide Web.
$wget http://project.honeynet.org/scans/scan18/snort-0315@0005.log.tar.gz
Once we have downloaded
and confirmed the integrity of the file, we can begin analysis. However,
we like to first extract data from the binary file, as this will make the
data analysis easier. We extract two forms of data. First,
we will extract all the packets going to the system 172.16.1.108.
This will give us easy access to all the traffic to and from the compromised
system. Notice how exclude port 20, for packet review we will not need any
binary ftp downloads. Second, we will extract all the ASCII information from the
binary log file, including activity such as telnet, ftp and http sessions.
This will make it easier to extract any cleartext activity from the attacker.
At times, we will still want to reference the actual binary log file,
however this data extraction will make some analysis easier.
$md5 snort-0315@0005.log.tar.gz
9b68e8ffade74bbf5ce0296a1977d111 snort-0315@0005.log.tar.gz
$tar -zxvf snort-0315@0005.log.tar.gz
snort -vdr snort-0315@0005.log host 172.16.1.108 and not port 20 > snort.txt
mkdir log
snort -dr snort-0315@0005.log -c
snort.conf -l ./log
TCP TTL:63 TOS:0x0 ID:63 IpLen:20 DgmLen:60 DF
******S* Seq: 0x73088CB4 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 75198 0 NOP WS: 0
TCP TTL:240 TOS:0x0 ID:44765 IpLen:20 DgmLen:60
***A**S* Seq: 0xDC2B3D6C Ack: 0x73088CB5 Win: 0x2798 TcpLen: 40
TCP Options (6) => NOP NOP TS: 1214982934 75198 NOP WS: 0 MSS: 1460
We are dealing with an autorooter, an automated tool that scans, probes,
attacks and roots vulnerable systems. We can see this process in
the packet traces. First, we see the automated tool probe for vulnerable
systems. Once identified, the automated tool kicks in. Notice how the
tool scans every IP address in the network. When if finds someone running
rpc services (port 111) it queries for statd. If it gets confirmation that statd
is running, it immedaitely runs the exploit. Notice how no attempt is made
to determine the operating systems nor the architecture, the attack is
simply launched. This is confirmed when the tool attacks honeypot 172.16.1.103,
a Solaris SPARC system. So the tool has been created to scan all IPs
within a given range, identify ANYTHING running rpc.statd, then attack it.
If you put rpc.statd on a coffe pot, this tool would attack it. Lets
review the attack by looking at the Snort decode of the attack. We
begin with the initial network sweep on port 111.
TCP TTL:43 TOS:0x0 ID:28754 IpLen:20 DgmLen:60 DF
******S* Seq: 0x9B8A127C Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 23678607 0 NOP WS: 0
TCP TTL:43 TOS:0x0 ID:28756 IpLen:20 DgmLen:60 DF
******S* Seq: 0x9B6B33C0 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 23678607 0 NOP WS: 0
TCP TTL:43 TOS:0x0 ID:28755 IpLen:20 DgmLen:60 DF
******S* Seq: 0x9B6A9C03 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 23678607 0 NOP WS: 0
TCP TTL:43 TOS:0x0 ID:29726 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x9B6338C5 Ack: 0x5820ADD0 Win: 0x7D78 TcpLen: 32
TCP Options (3) => NOP NOP TS: 23678634 2878772
UDP TTL:43 TOS:0x0 ID:29733 IpLen:20 DgmLen:84
Len: 64
01 0A 8A 0A 00 00 00 00 00 00 00 02 00 01 86 A0 ................
00 00 00 02 00 00 00 03 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 01 86 B8 00 00 00 01 ................
00 00 00 11 00 00 00 00
........
UDP TTL:43 TOS:0x0 ID:29781 IpLen:20 DgmLen:1104
Len: 1084
47 F7 9F 63 00 00 00 00 00 00 00 02 00 01 86 B8 G..c............
00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20 ...............
3A B1 5E E5 00 00 00 09 6C 6F 63 61 6C 68 6F 73 :.^.....localhos
TCP TTL:43 TOS:0x0 ID:31660 IpLen:20 DgmLen:71 DF
***AP*** Seq: 0x9C6D2BFF Ack: 0x59606333 Win: 0x7D78 TcpLen: 32
TCP Options (3) => NOP NOP TS: 23679878 2880015
63 64 20 2F 3B 20 75 6E 61 6D 65 20 2D 61 3B 20 cd /; uname -a;
69 64 3B id;
The source IP address of the attack is 211.185.125.124. We look
up the IP address on ARIN and see the IP block belongs to Kyongsan Purim Elementary School,
a grade school located 171 puki-1ry jinrang-eup kyongsan-ci, Korea.
We determined this using
several whois lookups.
These attackers are most likely Romanian. We are able to determine this via
several factors. Upon gaining access to the system, they ftp'd out
to a Romanain system, which they had a shell account,
and retrieved the rootkit ,
lk.tgz, which has also elements written in Romanain. The Honeynet Project was able to
confirm the Romanian identify the following day, when they started up several
IRC channels and spoke in Romanian.
First, these attackers are most likely not interested in so much which systems they compromise,
just how many. They are going after number of systems. This
can be seen in the use of an automated tool scanning entire network blocks
and attacking anything that looks vaguley vulnerable.
Second, we see them coming from a foreign IP address. This implies
that the source attacking system has also been compromised, and is being
used by the attacker to relentlessy scan and attack as many systems as
possible. This makes it more difficult to identify and track down the
attacker.
The system (and system admin) that is attacking you may not be the one
responsible for the actual attack. In the case
of this challenge, it is most likely not Koreans that are attacking us, but
Romanians. This exercise gives me the opportunity to express a personal rant
of mine. Far to often I see administraters posting on maillists how elite they
are by retaliating against systems that attacked them. They express pride in taking
out the system that scanned them. I have serious concerns about this behavior.
For example, in the case of this challenge, we were attacked by an IP from
Korea. However, if we had retaliated against this site, we most likely would
have taken out some innocent 3rd graders, very 'elite' indeed. What if
the source IP had been a Hospital instead, and we attacked that? The
Honeynet Project urges administrators to refrain in attacking source IP
addresses. Instead, attempt to contact the admins of the compromised
systems and educate them, that way everyone benefits.
Four hours, with another two hours developing the documentation.
Can you recover the blackhat's rootkit from the Snort binary log file? If so, how?
Recovering the toolkit from the data stream
can easily be done using the outstanding tool
ethereal, it has a TCP recovery feature designed specifically for this. To recover
the data file, you open the binary log file in Ethereal, find one of the FTP packets,
right click on it, select TCP Stream from the options, then save the file (ASCII format)
to the file name you want. Once recovered, you will have the rootkit, called lk.tgz.
For some reason, I had an
invalid compressed data error, but was able to recover almost the entire rootkit.