Checking for Rootkits

What are rootkits? You can ask Wikipedia, or take this over-simplification:

The Windows flock has to worry about various security concerns – viruses, worms, trojans, bots. So may, in fact, they had been categorized into AdWare (unwanted commercial content), SpyWare (compromise of personal information) and Viruses (generally malicious code).

Linux folks, on the other hand, have to fear only one thing – a rootkit. Because Windows vulnerabilities allow exploiting a machine without administrative access for specific goals, a diversity of exploits was invented, while properly setup Linux can only be compromised with root (Administrator) access. However, once that had been achieved, the machine is fully compromised along with the network it’s on. Namely, there are very few things an attacker will not be able to do with a rooted Linux machine.

Periodic scans are a good measure to stay clean, similar to scheduled anti-virus scans in Windows PCs. chkrootkit is such an implementation, and appears to be the most popular today, for good reasons: it’s easy to build, easy to run, and easy to understand. A good idea might be to run it periodically and email the output to a system administrator.

Great, until you realize the catch22 of checking for root-kits: Once a machine had been infected with a rootkit (usually through an badly secured SSH account), there’s virtually no way to determine that is was compromised, unless a reference set of binaries can be used to compare the infected binaries to “clean” ones. This means that you may not use a machine to check itself for rootkits, because if it was already compromised at the time it was checked, the check would be useless.

There is, of course, a hack. Namely, Network Security Hack #99 from O’Reilly suggests we can run chkrootkit in Busybox! Right, Busybox has some 200 programs built into its binary, and we could use those instead of the host’s own suspected ones. Unfortunately, it does not show how.

Let’s think about this: We assume the machine might be compromised when we scan it. We would not want to use the machine’s own binaries (that could also be compromised). We would not want to use software that had been lying around on the machine while it was compromised, for the same reason, including Busybox or chkrootkit. Ideally, then, we would use a fresh copy of Busybox to download a fresh copy of chkrootkit, run one in the other and dump both (that way, one cannot compromise something that is not there).

I ended up with the (almost entirely self-sufficient) solution below. It will run on any machine that has internet access, GNU wget (to download Busybox and chkrootkit). Other than wget, the script makes use of Busybox applets instead of the system installed binaries, for extra safety đŸ˜‰


# Temporary folder path. (It's a good idea to use a random name):

# A URL from which Busybox binaries can be downloaded

# A URL from which the chkrootkit source can be downloaded:

# Download and prepare the Busybox binary in the temporary folder:
/usr/bin/mkdir -p $TEMPORARY_FOLDER
/usr/bin/wget $BUSYBOX_URL/busybox-"`uname -m`"
/usr/bin/chmod +x $TEMPORARY_FOLDER/busybox-"`uname -m`"
BUSYBOX_BIN=$TEMPORARY_FOLDER/busybox-"`uname -m`"

# Download, confirm the MD5 sum, and extract the chkrootkit source using Busybox:
$BUSYBOX_BIN wget $CHKROOTKIT_URL/chkrootkit.tar.gz
$BUSYBOX_BIN wget $CHKROOTKIT_URL/chkrootkit.md5
if [ "`$BUSYBOX_BIN cat chkrootkit.md5`" != "`$BUSYBOX_BIN md5sum chkrootkit.tar.gz`" ]; then
  $BUSYBOX_BIN echo " !!! MD5 SUM check FAILED !!! "
  $BUSYBOX_BIN echo "MD5 checksum for chkrootkit source passed..."
$BUSYBOX_BIN tar vxf $TEMPORARY_FOLDER/chkrootkit.tar.gz

# Run the newly built chkrootkit in the just downloaded Busybox:
$BUSYBOX_BIN sh $TEMPORARY_FOLDER/chkrootkit*/chkrootkit

# Clean up:
cd /
$BUSYBOX_BIN echo "Done."


Filed under #!

2 responses to “Checking for Rootkits

  1. Max

    I use ckrootkit from time to time. I have difficulty in understanding some of the output, especially those “suspecting files and directories” listed during the scanning. It is quite difficult to know if they are really dangerous files or only false positives. At any rate, I don’t know what to do; do I delete them? what if I break something important? To delete or not to delete, that is the question. And we need criteria to decide what really is important or essential, from just “information” lying around.

    • Ernest Kugel

      The key here is to understand why chkrootkit warns you about something. Often, it could be harmless. I can give you one such example of the top of my head: chkrootkit looks to see if basic binaries (such as “ls”) had been replaced by malicious software. However, it will flag “ls” even if it was replaced by legitimate software, such as busybox’s “ls”. There is no way to know if “ls” should be deleted unless you know if it was replaced maliciously or intentionally. I wish I could get a simple green/red light from chkrootkit like one gets in Windows AntiVirus software, but I can’t see a way around such annoyances as false positives.

      My last word of advice is to use a baseline. Regardless of what chkrootkit says, if you know your machine is not rootkitted (because its a fresh install or for another reason), use the chkrootkit output you get from a run you know to be clean – and compare that to future runs. Then, you can only worry about *new* false positives which appear as time goes on. If you cannot explain *new* false positives as they are occurring, you are very likely to have a real problem.

      Hope this helped!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s