Sorry is this is too far off topic, but it seems to me the
kernel may be helping in this break in or maybe some magic
aspect of the filesystem.
I noted in an ls that
-rwxr-xr-x 1 root root 36784 Jul 17 05:06 rpc.mountd*
-rwxr-xr-x 1 root root 3368 Jul 17 05:06 rpc.nfsd*
-rwxr-xr-x 1 root ftp 22 Sep 8 22:15 rpc.rcmd*
-rwxr-xr-x 1 root root 9872 Jul 17 05:06 rpc.rquotad*
-rwxr-xr-x 1 root root 13936 Feb 9 2000 rpc.rstatd*
-rwxr-xr-x 1 root root 7952 Feb 9 2000 rpc.rusersd*
-rwxr-xr-x 1 root root 6512 Feb 11 2000 rpc.rwalld*
-rwxr-xr-x 1 root root 17624 Mar 7 2000 rpc.yppasswdd*
-rwxr-xr-x 1 root root 23984 Mar 7 2000 rpc.ypxfrd*
-rwxr-xr-x 1 root root 10692 Sep 5 16:03 rpcinfo*
rpc.rcmd look a little suspicious?
And guess what it contains?
%cat /usr/sbin/rpc.rcmd
/usr/include/strlib.h
Hmmmm.
%ls -l /usr/include/strlib.h
-rwxr-xr-x 1 root root 16768 Sep 16 09:55 /usr/include/strlib.h*
%file /usr/include/strlib.h
/usr/include/strlib.h: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped
%/usr/include/strlib.h
bind: Address already in use
Now watch this magic trick:
%mkdir foo
%cd foo
%touch strlib.h
%ls
%find . -print
.
./strlib.h
%
Get it? strlib.h never appears in the file system via ls whereever
it may be created.
More fun:
%echo hello >strlib.h
%ls
%cat strlib.h
hello
%
Pretty cool huh?
Let me know if you would like a copy of the code.
A quick strace shows that it binds to port 24000.
It also contains a list of 5 IP addrs. I suspect it doesn't
broadcast, but allows people in from those IPs.
Anyone know what has happened? I religiously install the redhat
updates, and am subscribed to the CERT advistors and install
the fixes the moment I get them.
The system was RedHat 6.2, linux 2.2.17pre14 at the time the
breakin occured.
I've been running firewalled with only services I provide turned
on for access, and in /etc/inetd.conf.
What is keeping strlib.h from appearing ls's? A hacked ls command?
--
Brian Litzinger <[email protected]>
Copyright (c) 2000 By Brian Litzinger, All Rights Reserved
On Thu, Dec 14, 2000 at 12:53:46AM -0800, [email protected] wrote:
> Sorry is this is too far off topic, but it seems to me the
> kernel may be helping in this break in or maybe some magic
> aspect of the filesystem.
I doubt that.... from this description, you've been hacked. Even if your
/etc/inetd.conf is in good shape, it looks like someone got in.
I'm guessing that your ls was also hijacked. You're using RedHat, so try
the rpm -V command to verify that the ls binary is the same as what should
be in the package. While you're at it, verify the package is the right one
(compare to a CD or distr ftp site).
Out of curiosity, are you running portmap? Perhaps BIND? There are lots
of potential culprits here -- but I suggest you verify all of your binaries
and go back and upgrade everything on your system, as well as re-visit the
issue of what daemons are started up at boot time.
Matt Dharm
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
C: They kicked your ass, didn't they?
S: They were cheating!
-- The Chief and Stef
User Friendly, 11/19/1997
> Pretty cool huh?
>
> Let me know if you would like a copy of the code.
>
> A quick strace shows that it binds to port 24000.
>
> It also contains a list of 5 IP addrs. I suspect it doesn't
> broadcast, but allows people in from those IPs.
>
> Anyone know what has happened? I religiously install the redhat
> updates, and am subscribed to the CERT advistors and install
> the fixes the moment I get them.
>
> The system was RedHat 6.2, linux 2.2.17pre14 at the time the
> breakin occured.
>
> I've been running firewalled with only services I provide turned
> on for access, and in /etc/inetd.conf.
>
> What is keeping strlib.h from appearing ls's? A hacked ls command?
Yep. Looks like a rootkit to me.
Igmar
It looks like you've been r00ted, dude!
Someone installed a r00tk1t and you are now seeing the after-effects of
it. What I'd do, in your case:
back up /usr/local, /home, /etc, then reload the system clean, and replace
teh backups. The system should be in a close state (read: no root kit) to
before you reloaded it.
Good luck!
On Thu, 14 Dec 2000 [email protected] wrote:
> Sorry is this is too far off topic, but it seems to me the
> kernel may be helping in this break in or maybe some magic
> aspect of the filesystem.
>
> I noted in an ls that
>
> -rwxr-xr-x 1 root root 36784 Jul 17 05:06 rpc.mountd*
> -rwxr-xr-x 1 root root 3368 Jul 17 05:06 rpc.nfsd*
> -rwxr-xr-x 1 root ftp 22 Sep 8 22:15 rpc.rcmd*
> -rwxr-xr-x 1 root root 9872 Jul 17 05:06 rpc.rquotad*
> -rwxr-xr-x 1 root root 13936 Feb 9 2000 rpc.rstatd*
> -rwxr-xr-x 1 root root 7952 Feb 9 2000 rpc.rusersd*
> -rwxr-xr-x 1 root root 6512 Feb 11 2000 rpc.rwalld*
> -rwxr-xr-x 1 root root 17624 Mar 7 2000 rpc.yppasswdd*
> -rwxr-xr-x 1 root root 23984 Mar 7 2000 rpc.ypxfrd*
> -rwxr-xr-x 1 root root 10692 Sep 5 16:03 rpcinfo*
>
> rpc.rcmd look a little suspicious?
>
> And guess what it contains?
>
> %cat /usr/sbin/rpc.rcmd
> /usr/include/strlib.h
>
> Hmmmm.
>
> %ls -l /usr/include/strlib.h
> -rwxr-xr-x 1 root root 16768 Sep 16 09:55 /usr/include/strlib.h*
>
> %file /usr/include/strlib.h
> /usr/include/strlib.h: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped
>
> %/usr/include/strlib.h
> bind: Address already in use
>
> Now watch this magic trick:
>
> %mkdir foo
> %cd foo
> %touch strlib.h
> %ls
> %find . -print
> .
> ./strlib.h
> %
>
> Get it? strlib.h never appears in the file system via ls whereever
> it may be created.
>
> More fun:
>
> %echo hello >strlib.h
> %ls
> %cat strlib.h
> hello
> %
>
> Pretty cool huh?
>
> Let me know if you would like a copy of the code.
>
> A quick strace shows that it binds to port 24000.
>
> It also contains a list of 5 IP addrs. I suspect it doesn't
> broadcast, but allows people in from those IPs.
>
> Anyone know what has happened? I religiously install the redhat
> updates, and am subscribed to the CERT advistors and install
> the fixes the moment I get them.
>
> The system was RedHat 6.2, linux 2.2.17pre14 at the time the
> breakin occured.
>
> I've been running firewalled with only services I provide turned
> on for access, and in /etc/inetd.conf.
>
> What is keeping strlib.h from appearing ls's? A hacked ls command?
>
>
--
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
On Thu, Dec 14, 2000 at 12:58:26AM -0800, Matthew Dharm wrote:
>
> I doubt that.... from this description, you've been hacked. Even if your
> /etc/inetd.conf is in good shape, it looks like someone got in.
>
> I'm guessing that your ls was also hijacked. You're using RedHat, so try
> the rpm -V command
Once hacked you can't trust anything. A malicious person might just
install RPMs for example.
Re-install is the only option.
Restore backups only after verifying that they do not re-install the
backdoors as well. This is where your current hacked system may be
useful. Something like the coroners toolkit (?) written by Wietse Venema
(and others?) might help you determining at what date your system has
been hacked. Don't be suprised if you find multiple break-ins accumulated
over the years.
If you have (had) a network: attached systems may have been compromised
as well.
--
Frank
> > I'm guessing that your ls was also hijacked. You're using RedHat, so try
> > the rpm -V command
> Once hacked you can't trust anything. A malicious person might just
> install RPMs for example.
There is a proper way to do this. You boot the rescue CD, then do the rpm
verify of each package with the rpm binary on the CD (static) agains the
package on the CD.
> Re-install is the only option.
I would advise this however it is not 'only' but 'very good idea'
> Restore backups only after verifying that they do not re-install the
(popular one is roots .login)
Alan
Thanks for all the reponses.
I happened to have /home in its own partition, so I reinstalled from
scratch via CD and installed all the security updates, among a
myriad of other security measures.
I decided not to restore /usr/local from backups, but instead to
rebuild everything in /usr/local from fresh sources.
All those executables and shared libraries in /usr/local just seemed
to risky.
--
Brian Litzinger <[email protected]>
Copyright (c) 2000 By Brian Litzinger, All Rights Reserved