Sean Walberg, 05/22/2003
A Solaris honeypot from the AT&T Mexico Honeynet was comprimised on or about November 29, 2002. The attacker used a well known exploit in the Solaris CDE Subprocess Control Service, publically known about since at least January of 2002. The attacker then gained ownership of the machine by closing up back doors, and installing cracker utilities such as rootkits. Logs indicate that this machine was used to access IRC, both on IPv4 and IPv6 networks.
First, grab the files, verify their MD5sums, and uncompress.
$ wget http://project.honeynet.org/scans/scan28/day1.log.gz
...
$ wget http://project.honeynet.org/scans/scan28/day3.log.gz
...
$ md5sum *.gz
79e5871791542c8f38dd9cee2b2bc317 day1.log.gz
af8ab95f41530fe3561b506b422ed636 day3.log.gz
$ gunzip *.gz
Next, a few utilities were run on the binary logfiles to make them easier to analyze:
TCPFlow[0] decodes a binary logfile as a series of TCP flows and dumps the output in ASCII. Nice and greppable.
$ tcpflow -r day1.log
TCPDump then was used to dump the whole logfile into an ASCII readable version, which allows a quick eyeballing of the data.
$ /usr/sbin/tcpdump -X -s 1500 -n -r day1.log
Most of the work was done in Ethereal. Colour filters were applied as such:
SYN & ACK - Red Background
SYN - Red Foreground
RST or FIN - Blue Foreground
Successful connections show up clearly with the red background, TCP portscans show up as alternate red/blue foregrounds, and so forth. As most of my analysis was in ethereal, this made searching for incidents much easier.
I then ran Snort on the output to see if it would trip any signatures:
$ /usr/sbin/snort -A full -c snort/snort.conf -l snortlogs/ -r day1.log
Looking at snortlogs/alert.log, I couldn't immediately see the the way the attacker got in, but I ended up finding it with Ethereal.
1. What is the operating system of the honeypot? How did you determine that?
The honeypot is running Solaris 8 (SunOS 5.8). The actual value returned from uname -a is
SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW, Ultra-5_10
This information was contained in packet 598, after the attacker exploited the machine and sent the uname -a command (among others, this was part of an automated exploit). Even before breaking into the system, the attacker learns the OS and architecture in packet 571 from port 6112, which is subsequently used to break into the system.
2. How did the attacker(s) break into the system?
The exploit used [2] was a buffer overflow in the CDE subprocess control service, TCP port 6112 (dtscpd). While [2] provides an excellent analysis of the exploit, in a nutshell:
o Exploit allows arbitrary commands to be executed by a buffer overflow attack
o Attacker exploits using a command that binds a root shell using inetd
o Write a file called /tmp/x that executes a shell for any connections to the ingreslock (TCP/1524) port
o Start an instance of inetd using that as a configuration file (/tmp/x)
o Delete the file
o Attacker uses the root shell to install a root kit with all sorts of fun inside
3. Which systems were used in this attack, and how?(see day1)
Looking at the flows generated by tcpflow, we can build a list of the machines that spoke TCP/IP:
$ ls | awk -F . '{ print $1"."$2"."$3"."$4 }' | sort | uniq -c
3 061.219.090.180
5 062.211.066.016
1 062.211.066.053
6 080.117.014.044
4 192.018.099.122
21 192.168.100.028
9 206.252.192.195
Initially, 61.219.90.180 attacks the system, making use of the dtscpd vulnerability.
He was the only one to connect to this port:
$ /usr/sbin/tcpdump -n -r day1.log tcp port 1524 | awk '$2 ~ /ingre/ {print $4}' | sort | uniq -c
1 61.219.90.180.56709:
1838 61.219.90.180.56712:
While connected to his root shell, the attacker grabs some files from 62.211.66.16 via FTP:
wget // Unix utility to get a url from the command line
dlp // A utility that deletes logs
solbnc // psybnc, an IRC Bouncer (http://www.psychoid.lam3rz.de/)
ipv6sun // Used later to set up IPv6
Using the wget binary just obtained, he then downloads a rootkit from 62.211.66.53.
http://62.211.66.53/bobzz/sol.tar.gz
Part of the rootkit downloads patches from SUNSolve (192.018.099.122) to close up some vulnerabilities on the system.
Finally, 80.117.14.44 is the machine from where the attacker connects to the IRC bouncer.
At the end, a secure shell is bound to TCP port 5001, and the IRC bouncer to TCP port 7000
4. Create a diagram that demonstrates the sequences involved in the attack. (see day1)
5. What is the purpose/reason of the ICMP packets with 'skillz' in them? (see day1)
These packets are Stacheldraht "agent to handler" packets. This program awaits signals from a handler, upon which it can perform denial of service attacks and such. The ICMP packets themselves identify the agent to the handler, presumably using ICMP echo-response packets to bypass packet filters. SANS has a good paper [3] on the topic. The two handlers appear to be "217.116.38.10" and "61.134.3.11".
6. Following the attack, the attacker(s) enabled a unique protocol that one would not expect to find on an IPv4 network. Can you identify that protocol and why it was used? (see day3)
The attacker enabled IPv6, and used it to connect to an IPv6 enabled IRC server (irc6.edisontel.it). The IPv6 stream was tunneled over IPv4 to Telecom Italia.
7. Can you identify the nationality of the attacker? (see day3)
Based on many references to Italian servers, and peering at IRC logs, I'm guessing the attacker is Italian.
* What are the implications of using the unusual IP protocol to the Intrusion Detection industry?
Most of our knowledge and research is based on IPv4, and our tools aren't designed to crack into the IPv6 packets. Snort does have a "show me any non TCP/UDP/ICMP packets", but the analysis isn't there yet. While answering the next question, I came across a post[4] by Lance Spitzner which seems appropriate to this situation :) Basically, if we jump outside the IPv4 realm, how much decoding does our IDS do when reading tunnels such as this? (And, as I type this, what would Snort do with an IP-IP or GRE tunnel?)
* What tools exist that can decode this protocol?
I used ethereal[5] to follow the streams. TCPDump can also inspect IPv6.
References:
[0] http://www.circlemud.org/~jelson/software/tcpflow/
[1] http://www.cert.org/advisories/CA-2002-01.html
[2] http://project.honeynet.org/scans/scan20/sol/13.html
[3] http://www.sans.org/resources/idfaq/stacheldraht.php
[4] http://lists.insecure.org/lists/honeypots/2002/Oct-Dec/0117.html
[5] http://ethereal.com/