Re: linux rootkit problems

["H. Morrow Long" <morrow.long () YALE EDU>]

Kevin,

I've seen this particular attack in two variants on a number
of computers in combination with a unique
approach which doesn't require the installation of a rootkit
nor support for LKMs (loadable kernel modules) in the Linux
kernel.  This is known as the 'SuckIt' backdoor for Linux kit.
For info see: http://hysteria.sk/sd/f/suckit/readme and note that
Google can pull up several other references to 'suckit' (including
several you may not wish to see on your screen).

In this attack /sbin/init is really the only system file modified.
The original /sbin/init is usually renamed to /sbin/initpoiuy (the
"poiuy" variant) or /sbin/initro_US (in the ro_US variant).

The modified /sbin/init invokes the installed 'sk' binary which
runs and installs itself by writing a program into kernel addresspace
by opening up /dev/kmem and poking the code in.

The installed kernel mod the puts in hooks in the kernel so as to
trap and allow the hiding of certain files and directories as well
as processes.  It also has a list of applications for which it watches
the characters input to and from the terminal (tty) and logs to a log
file (usually named .sniffer).

As you say the .sniffer log file and 'sk' binary are often in either
/usr/include/security/poiuy/ (a directory which is 'hidden' if the
kernel mod is active) in the poiuy variant or in
/usr/share/locale/ro_US in the ro_US variant.  There is also supposed
to be (by looking at the code at http://hysteria.sk/sd/f/suckit as well
as running strings on 'sk') an .rc file in the directory also but I've
never found one.

We noticed this one on a number of systems because tripwire and AIDE
noticed that the link from /sbin/telinit to /sbin/init was broken.

Another method of detecting the two variants above is to try to 'cd'
into either of the two directories above (even if 'ls' insists they
do not exist).

If you get a 'permission denied' message, it is a bad sign
(you should really get 'No such file or directory' instead).

And sometimes the kernel mod creates a few problems (user shell session
commands start crashing with 'segmentation violation' errors).

You can supposedly completely remove (uninstall) the suckit kernel mod
from memory with the sk binary by running 'sk u' -- but of course you
should do a much more thorough job in searching for all signs of intrusion
and compromise as well as sanitizing and securing (most will recommend a
complete reformat and reinstall).

As to how the intruders got root on a Linux computer in the first place,
well, there are a lot of published buffer overflow vulnerabilities for
Red Hat Linux.  But in cases I've investigated often the intruders had
a password for a user whom they followed into the system.  Then they
either used a local exploit, or if the user had 'sudo' access (e.g.
and it didn't require a separate root password) they had root.

Many sites have SSH set up in 'password' authentication mode (doesn't
require public key auth) and set up sudo so that users don't have to
know the root password.  I recommend changing these practices whereever
possible (particularly on important computers and for IT admins).

You can pass along my email to your friend.  I'd be interested in hearing
from him and/or anyone else who has encountered the poiuy and ro_US intruders and
Linux 'suckit' backdoor.

H. Morrow Long
University Information Security Officer
Yale University, ITS, Dir. InfoSec Office


Kevin Shalla wrote:
> I've heard from a colleague about the following problem.  It turns out that
> the hacker somehow installs a rootkit, changes the init files, changes the
> kernel, and does keystroke logging and sniffing, searching for usernames
> and passwords on other systems.  Then he logs into those other systems and
> does the same thing.  It's unclear how as a regular user he obtains root,
> but that seems to be what's happening.  My colleague says that it's been
> reported at CERN, Argonne National Lab, and others.  Have any of you heard
> about this one?
>
> > The only signs the hacker was on the system are the existance of
> >    /sbin/initpoiuy which is the original /sbin/init file.
> >    /usr/include/security/poiuy/ a directory that contains a sniffer and
> > log file
> > These files are "hidden" by the kernel mods their init program load
> > when it starts.
>
>
>
> Kevin Shalla
> Manager, Student Information Systems
> Illinois Institute of Technology
> <mailto:Kevin.Shalla () iit edu>
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion
> Group discussion list can be found at http://www.educause.edu/memdir/cg/.

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/memdir/cg/.