UNI-FIX Computer

Use chkrootkit to determine the extent of a compromise.

If you suspect that you have a compromised system, it is a good idea to check for root kits that the intruder may have installed. In short, a root kit is a collection of programs that intruders often install after they have compromised the root account of a system. These programs will help the intruders clean up their tracks, as well as provide access back into the system. Because of this, root kits will sometimes leave processes running so that the intruder can come back easily and without the system administrator’s knowledge. This means that some of the system’s binaries (like ps, ls, and netstat) will need to be modified by the root kit in order to not give away the backdoor processes that the intruder has put in place. Unfortunately, there are so many different root kits that it would be far too time-consuming to learn the intricacies of each one and look for them manually. Scripts like chkrootkit (http://www.chkrootkit.org) will do the job for you automatically.

In addition to detecting over 50 different root kits, chkrootkit will also detect network interfaces that are in promiscuous mode, altered lastlog files, and altered wtmp files. These files contain times and dates of when users have logged on and off the system, so if they have been altered, this is evidence of an intruder. In addition, chkrootkit will perform tests in order to detect kernel module-based root kits. C programs that are called by the main chkrootkit script perform all of these tests.

It isn’t a good idea to install chkrootkit on your system and simply run it periodically, since an attacker may simply find the installation and change it so that it doesn’t detect his presence. A better idea may be to compile it and put it on removable or read-only media. To compile chrootkit, download the source package and extract it. Then go into the directory that it created and type make sense.

Running chkrootkit is as simple as just typing ./chkrootkit from the directory it was built in. When you do this, it will print each test that it performs and the result of the test:

# ./chrootkit

ROOTDIR is `/’

Checking `amd’… not found

Checking `basename’… not infected

Checking `biff’… not found

Checking `chfn’… not infected

Checking `chsh’… not infected

Checking `cron’… not infected

Checking `date’… not infected

Checking `du’… not infected

Checking `dirname’… not infected

Checking `echo’… not infected

Checking `egrep’… not infected

Checking `env’… not infected

Checking `find’… not infected

Checking `fingerd’… not found

Checking `gpm’… not infected

Checking `grep’… not infected

Checking `hdparm’… not infected

Checking `su’… not infected

That’s not very interesting, since the machine hasn’t been infected (yet). chrootkit can also be run on disks mounted in another machine; just specify the mount point for the partition with the -r option, like this:

# ./chrootkit -r /mnt/hda2_image

Also, since chrootkit depends on several system binaries, you may want to verify them before running the script (using the Tripwire [Hack #97] or RPM [Hack #98] methods). These binaries are awk, cut, egrep, find, head, id, ls, netstat, ps, strings, sed, and uname. However, if you have known good backup copies of these, you can specify the path to them by using the -p option. For instance, if you copied them to a CD-ROM and then mounted it under /mnt/cdrom, you would use a command like this:

# ./chrootkit -p /mnt/cdrom

You can also add multiple paths by separating each one with a :. Instead of maintaining a separate copy of each of these binaries, you could simply keep a statically compiled copy of BusyBox handy (http://www.busybox.net). Intended for embedded systems, BusyBox can perform the functions of over 200 common binaries, and does so using a very tiny binary with symlinks. A floppy, CD, or USB keychain (with the read-only switch enabled) with chkrootkit and a static BusyBox installed can be a quick and handy tool for checking the integrity of your system.

Verify operating system installed files in an RPM-based distribution.

So you’ve had a compromise and need to figure out which files (if any) were modified by the intruder, but you didn’t install Tripwire? Well, all is not lost if your distribution uses RPM for its package management system. While not as powerful as Tripwire, RPM can be useful for finding to what degree a system has been compromised. RPM keeps MD5 signatures for all the files it has ever installed. We can use this functionality to check the packages on a system against its signature database. In addition to MD5 checksums, you can also check a file’s size, user, group, mode, and modification time against that which is stored in the system’s RPM database.

To verify a single package, run this:

rpm -V
package

If the intruder modified any binaries, it’s very likely that the ps command was one of them. Let’s check its signature:

# which ps

/bin/ps

# rpm -V `rpm -qf /bin/ps`

S.5….T /bin/ps

Here we see from the S, 5, and T that the file’s size, checksum, and modification time has changed from when it was installed—not good at all. Note that only files that do not match the information contained in the package database will result in output.

If we want to verify all packages on the system, we can use the usual rpm option that specifies all packages, -a:

# rpm -Va

S.5….T /bin/ps

S.5….T c /etc/pam.d/system-auth

S.5….T c /etc/security/access.conf

S.5….T c /etc/pam.d/login

S.5….T c /etc/rc.d/rc.local

S.5….T c /etc/sysconfig/pcmcia

…….T c /etc/libuser.conf

S.5….T c /etc/ldap.conf

…….T c /etc/mail/sendmail.cf

S.5….T c /etc/sysconfig/rhn/up2date-uuid

…….T c /etc/yp.conf

S.5….T /usr/bin/md5sum

…….T c /etc/krb5.conf

There are other options that can be used to limit what gets checked on each file. Some of the more useful ones are -nouser, -nogroup, -nomtime, and -nomode. These can be used to eliminate a lot of the output that results from configuration files that you’ve modified.

Note that you’ll probably want to redirect the output to a file, unless you narrow down what gets checked by using the command-line options. Running rpm -Va without any options can result in quite a lot of output resulting from modified configuration files and such.

This is all well and good, but ignores the possibility that someone has compromised key system binaries and that they may have compromised the RPM database as well. If this is the case, we can still use RPM, but we’ll need to obtain the file the package was installed from in order to verify the installed files against it.

The worst-case scenario is that the rpm binary itself has been compromised. It can be difficult to be certain of this unless you boot from an alternate media, as mentioned earlier. If this is the case, you should locate a safe rpm binary to use for verifying the packages.

First find the name of the package that owns the file. You can do this by running:

rpm -qf
filename

Then you can locate that package from your distribution media, or download it from the Internet. After doing so, you can verify the installed files against what’s in the package using this command:

rpm -Vp

package file

RPM can be used for quite a number of useful things, including verifying the integrity of system binaries. However, it should not be relied on for this purpose. If at all possible, something like Tripwire [Hack #97] or AIDE (http://sourceforge.net/projects/aide) should be used instead.