Re: Rooted through in.identd on Red Hat 6.0

[sec () ORGONE NEGATION NET (jms)]

On Fri, 21 Apr 2000, Del Elson wrote:

> J.J. Horner wrote:
>
> > > Hi,
> > >
> > > A client was hacked last week by what looked like a
> buffer
> > > overflow through in.identd.  This was on a Red Hat 6.0
> > > box.
> > >
> > > RH don't have any current security notices or fixes for
> > > in.identd on their servers, and I haven't seen other
> > > boxes hacked through in.identd recently.
>
> > Well, he could have gotten in somewhere else and just put
> > the backdoor in
> > identd.  I've had people get in on nameservers with old
> versions of BIND,
> > then backdoor another service.
>
> > Jon
>
> This is the most likely suggestion I've seen to date.
> I didn't have access to the box before the hack (otherwise
> I would have darn well patched it) but it's conceivable
> that it got rooted ages ago and the most recent attack
> was through a previous backdoor put into inetd or
> identd.
>
> It wasn't running BIND (note to all of the dozen or so
> people who e-mailed me dead certain that it was ... it's
> rather hard to use the ADMROCKS worm to get in to BIND
> on a machine that it's not even installed on, let alone
> running on ... I deleted a pile of mail on this without
> replying, not my usual style, but then there has been a
> flood of junk on this topic).  It wasn't running FTPD,
> it wasn't running anything else with open ports.
>
> I don't know what else to suspect.  It's conceivable that
> a trojan inetd/identd had been on the system for some time.
>
> Del

of course, if the user ssh's in from a compromised box, he has probably
given up local access via trojaned ssh binary.

-jason storm
 jms () negation net

/* hard work never killed noboby,
   but i aint takin no chances. */