Re: Exodus: this is bad

["Lon R. Stockton, Jr." <lon () moonstar com>]

On Tue, 17 Nov 1998, Alex P. Rudnev wrote:

> 'Linux Root Kit' hidding all hacker's activity. If anyone have some tools 
> to detect this rootkit (it include more than 200 files changed in the 
> system), point it, please - all my attempts to contact RedHat and other 
> Linux developers caused nothing.

If you're using Red Hat (or other distributions which use RPM), RPM itself
can help.  The command 'rpm -Va' performs checksum, MD5, ownership, 
permissions, and create_time checks against all packages installed on
your system. For a shorter list, I use "rpm -Va | grep -v ' c '", which
will exclude config files (which are generally always changed, and need
to be reviewed...and in my case, unauthorized changes are caught by
tripwire). The vulnerability here is the rpm databases, which could be
mangled by the attacker (outright modification, or the simple use of
the rpm system to install the hacked binaries).

For other *ix distributions, there's always tripwire to detect what
has been changed. I also use it to keep an eye on my config files and
the various parts/dependencies of the rpm system (rpm executable, 
databases, glibc, etc). Like RPM, however, it also has a vulnerability
of intentional corruption of the executable and databases.

To safeguard the databases and executables like tripwire, I use the
tried-and-true 'copy on a write-protected floppy' method. One could
also pgp sign the individual files and just keep your keyrings and
pgp executable on a write-protected floppy (as well as proper safeguards
for your private keyring used to sign 'em).

One technique that stops older rootkits cold is to mount /usr as
read-only. BUT, it seems that newer rootkits know how to remount 'em,
so it's no real protection unless the media itself is read-only like
a cdrom.

I also keep copies of some critical binaries on a protected floppy.
Things like ifconfig, netstat, ps, and file.

Of course, all of the above is pro-active, steps must have been taken
prior to the break-in. And in some cases, troublesome and time-consuming
steps must be followed pedantically following system configuration
changes. As another poster so astutely noted that the sysadmins of
hacked machines rarely pay attention to forums such as these, it is
also true that they also don't pay attention to proper security measures
at all. (generally in the realm of 'watching the watchers'...tripwire
is useless against an advanced hacker if you've not properly safeguarded
its databases).

Hope in detecting the presence of a rootkit isn't totally lost if you
haven't done these things (although if the test is positive, you'll be
spending a lot of time with that machine for the next few days).

If your 'file' command isn't corrupted, a simple
             'file /dev/* |grep  [Tt]ext'
command will typically reveal the presence of most current and older
rootkits, as they (so far) tend to hide their config files in /dev. In
text.

As a side note, I've seen a rootkit attack where the attacker had a c
program to compile locally (I assume to link against my shared libs;
why it wasn't just a statically linked binary I dunno). The brick wall
here was that my production machines don't have any compilers on 'em.
[although I do have perl, so my mileage will vary here].


> The excellent (-:)) set of exploits and troyans is stored at 
> ftp://ftp.technotronic.com/ (this is the place where russion hackers have 
> got this toolkits first from), but I saw some self-changed toolkits from 
> other places.
>
> The only advice I can provide. First, compare MD5 checksums if you can. 
> If you can not, make
>
>  find /dev -type f -print
>
> and
>
>  ls -ld /dev
>
> and, if you see some FILES like 'ptyp' or 'fmpd1' or directory ..., it's 
> no doubt the traces of the hacker (if not, this means NOTHING - anyone 
> can use another configuration).
>
> I did not saw real usages of this mountd exploits, but they does exist. 
> What I have seen was -
>  imapd, qpopper exploits to get root access withouth user account;
>  lprm, ufsrestore (not in linux), X11 exploits to get root access from 
> the user's account.
>
> But... if you have not this exploits, this means nothing.  
>
>
> On Tue, 17 Nov 1998, Michael Freeman wrote:
>
> > Date: Tue, 17 Nov 1998 12:26:42 +0000 (Local time zone must be set--see zic manual page)
> > From: Michael Freeman <mikef () boris talentsoft com>
> > To: "William S. Duncanson" <caesar () starkreality com>
> > Cc: Adam Rothschild <asr () millburn net>,
> >     "Edward S. Marshall" <emarshal () logic net>,
> >     Richard Irving <rirving () onecall net>, nanog () merit edu
> > Subject: Re: Exodus: this is bad
> >
> > You guys might be overlooking a very major security hole with linux,
> > besides bind. Rpc.Mountd. If you haven't patched yet, do so now, because
> > exploits have been publically available for a while now and this is a
> > remote attack that will compromise root. The easiest thing to do if you
> > don't have time to sit and upgrade every linux box on your network with
> > the latest rpc.mountd, or kill it off, or whatever you plan on doing,
> > might be to just go on your router and put up an access-list denying all
> > inbound connections on port 111 (the rpc portmapper). Even though its
> > pretty trivial to guess what port rpc.mountd is on (2049) instead of using
> > the portmapper, the exploits aren't configured to do so (at least not ot
> > my knowledge). And if you're still worried you could firewall both 111 and
> > 2049. Well good luck. 8)
> >
> > On Mon, 16 Nov 1998, William S. Duncanson wrote:
> >
> > > I think he meant the compromised hosts, or the hosts that the attacks were
> > > coming from, were all RH 5.1 with an old rev of BIND.  My 3.0-current box
> > > with 8.1.2 handled it fine, as well.
> > >
> > > At 22:30 11/16/98 -0500, Adam Rothschild wrote:
> > > > On Mon, 16 Nov 1998, Edward S. Marshall wrote:
> > > >
> > > > > The attacked hosts have all exhibited the same characteristics: stock Red
> > > > > Hat 5.1 install, running (probably) the stock named that came with it,
> > > >
> > > > Not entirely true.  I watched a FreeBSD 2.2.x/BIND 8.1.2 box get tickled
> > > > harmlessy...
> > > >
> > > > Go to bed, porscanning twit kiddies.  It's late now, and Teletubbies ain't
> > > > on. 8-)
> > >
> > >
> > > William S. Duncanson                      caesar () starkreality com
> > > The driving force behind the NC is the belief that the companies who brought us
> > > things like Unix, relational databases, and Windows can make an appliance that
> > > is inexpensive and easy to use if they choose to do that.  -- Scott Adams 
>
> Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)