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)