Re: Systems compromised with ShellBOT perl script - part 2

["Stephen J. Smoogen" <smooge () gmail com>]

On Wed, 20 Oct 2004 00:04:36 -0500, security () kemhosting com
<security () kemhosting com> wrote:
> This thread is a couple months old, but I'm having issues with this hack, found
> it in the archives and thought it'd be helpful if I 'resusitated' it. See
> bottom of email for rest of thread.
>
> Today, hackers used the ShellBOT perl script to bring down Apache and start up
> their IRC listener.  They (somehow) copied it into /tmp and executed it.  This
> confuses me because I have my /tmp directory mounted rw,noexec,nosuid. Does
> Perl somehow bypass this?
>
> While the script was running, I ran lsof and found that it had recursively
> accessed all my (virtual host) httpd logs (probably in an attempt to delete
> it's tracks = the reason I can't see how they copied the script into /tmp)
> which are owned by root.  this is also confusing since the process the script
> spawned was owned by user apache.
>
> Some info on my box:
> Redhat ES kernel 2.4.21-9.0.1.ELsmp
> httpd-2.0.46-32.ent
> php-4.3.2-11.ent
>
> Anyone have any ideas on how this can happen?  Mainly the executing of a script
> on a noexec mount!  Obviously I'm not a guru, so it's probably something simple
> - so please, share!

I think you may have other issues. As of 2004/10/18, the packages for
Red Hat Enterprise are the following:

kernel-2.4.21-20.EL
php-4.3.2-14.ent
httpd-2.0.46-40.ent
perl-5.8.0-88.7

There have been several security updates to php and httpd since the
versions you have installed. The attackers may have been able to use
this to say upload items into /var/tmp and execute it there. If you no
longer have a Red Hat Enterprise License you should be able to get
updates from WhiteBox and several other of the RHEL clones.

/var/tmp gets overlooked a lot. I have also seen some webcoders use it
as a default for their scripts because /tmp is too small/restricted
for some reason. I would check to make sure that none of the
PHP/perl/etc are defaulting to using /tmp as their "temp space" as
that would avoid the noexec,nosuid.

I would also check that some other listening service (ssh, etc) wasnt
initially used to get the compromise and they havent installed a
kernel root kit that silently ignores noexec,nosuid when it mounts
disks. That would be what I would do to make sure I could come back in
later :).

-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator