Re: cron exploit?

[Jeremy Hanmer <jeremy () hq newdream net>]

What pointed me to cron were some entries in a .viminfo file located in
the home directory for the Suckit rootkit that was installed. 
Unfortunately, that isn't very substantial to say the least.  While I
didn't find any evidence of the rest of that script being executed, we
*did* find an exact copy of the source code mentioned in that script
that'd been uploaded to /tmp shortly before init had been overwritten.

What I know for certain is that a user who was running the mantis bug
tracking system had his account compromised.  The attackers then
uploaded a binary simply named ".r2" to /tmp, and shortly thereafter had
spawned a root backdoor.  After digging through the logs, I saw that
both ssh and proftpd restarted about 7-10 minutes before the breach
(although I've verified that neither were trojaned).  Proftpd runs as
"nobody", and ssh has privilege separation turned on.  All packages on
this machine were up-to-date.

Right now, I'm still curious to find out why they were poking around
cron stuff so much if it wasn't related to their entry, but I'm
generally in the dark as to exactly what happened since they obviously
cleaned up most of the logs.

On Mon, 2003-09-29 at 14:06, Barry Fitzgerald wrote:
> I'm assuming you found evidence of this script on the system, otherwise 
> you wouldn't have brought it up.  The set of commands in the list 
> definately setup a root shell backdoor, but the attacker would need root 
> level access first and foremost.  I see no exploitation of cron here 
> except that they wanted the binary to run, I believe, as a cron job.  
> But, cron runs scripts and programs - that's what cron does.  Cron's 
> just doing what cron does.  There's no exploit code listed as being run, 
> I just don't see how any of this would be useful unless the attacker had 
> root access in the first place, or - for some unknown reason - the 
> kernel would allow you to overwrite a file with the SUID root binary.  
> But, again, that's not a cron issue at all.  The '/sbin/init' 
> modification is troubling, but again has nothing to do with cron nor is 
> it mentioned anywhere in the link you provided. 
>
>        -Barry
>
>
> Jeremy Hanmer wrote:
>
> > Unfortunately, the permissions were all fine.  The user apparently poked
> > around cron.daily, but there isn't any evidence that they were ever able
> > to successfully modify anything in there.  All files (and the directory
> > itself) were owned by root.root, and all were 755.  The *only* file
> > found modified by tripwire was /sbin/init.  Nothing else in any library
> > paths, bin paths, or /etc had been touched.
> >
> > On Mon, 2003-09-29 at 10:30, Matt Zimmerman wrote:
> >  
> >
> > > On Sun, Sep 28, 2003 at 03:09:01PM -0700, Jeremy Hanmer wrote:
> > >
> > >    
> > >
> > > > We just had a Debian (Woody) box get rooted, apparently by a cron
> > > > exploit mentioned here:  http://www.codon.org.uk/~mjg59/kern/jmb73bash
> > > >
> > > > We've contacted the package maintainer, but has anybody else seen
> > > > anything like this floating around yet?  It's pretty worrisome since we
> > > > have a couple hundred linux boxes that must run cron for various
> > > > reasons.
> > > >      
> > > As I said before, there is no evidence here of a cron exploit, and it raises
> > > unnecessary alarm to claim that there is one.  It looks like you had a
> > > world-writable script (or a script owned by the unprivileged user who was
> > > exploited) in /etc/cron.daily, and so the intruder modified that script in
> > > order to execute commands as root.
> > >
> > > All signs point to a local configuration error.
> > >
> > >    
> > >
> > > > echo chown root:root /tmp/rmsd >> mkwebuserlist
> > > > echo chmod 4755 /tmp/rmsd >> mkwebuserlist
> >
> >

Attachment: signature.asc
Description: This is a digitally signed message part