OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: /tmp/bob on compromised system
From: Russell Fulton (r.fultonAUCKLAND.AC.NZ)
Date: Thu Jul 27 2000 - 18:19:22 CDT

On Wed, 26 Jul 2000 12:58:51 -0700 "Granquist, Lamont"
<lamontICOPYRIGHT.COM> wrote:

> Actually, the original poster responded privately that /tmp/bob was a suid
> binary and not an inetd.conf file, and that the exploit was probably the
> ff.core bug:
>
> http://www2.merton.ox.ac.uk/~security/archive-199901/0187.html
>

Greeting All, I am the original poster ;-)

Firstly, a hearty thank you to all who responded.

Just to confirm: In my case the file /tmp/bob was a suid root binary
-- that much was noted before it was deleted (I should have included
that info in my original post, apologies). The box was running solaris
2.7 with a full set of security patches so we were very puzzled when
they managed to break root.

I now believe that they did use the ff.core exploit referenced above by
Lamont. More info at

http://www.securityfocus.com/bid/327

This article says that SUN have not yet issued a patch for this and
suggests a work around (thanks to Casper Dik) which simply removes suid
bit from the suspect file.

The exploit leaves a suid copy of /bin/sh in /tmp/bob which is
consistent with what we observed.

Lastly, an observation on search engines. Most don't handle searching
for things like /tmp/bob properly. I tried security focus, altavista
and at least one other before resorting to posting. I knew that it was
the finger print of a common exploit but I still could not track it
down.

It turns out that google.com does correctly index strings like /tmp/bob
and turned up references to both the ff.core and various rpc.xxx
exploits. I'm a convert to Google!

Cheers, Russell