Detecting Rootkits In GNU/Linux

An anonymous reader sends note of a blog post on rootkit detection in GNU/Linux. The article mentions only two utilities for ferreting out rootkits — the first comment to the blog post lists three additional ones — but it could be useful for those who haven't thought about the problem much. From the article: "A rootkit... is a collection of tools that a cracker installs on a victim's computer after gaining initial access. It generally consists of log cleaning scripts and trojaned replacements of core system utilities such as ps, top, ifconfig and so on."

Re:ifl

[computational super]

You know, one of the things I'd like to do if I had more time and knew how to do it would be to create a bootable "system scan" disk. A rootkit could hide itself from tripwire et al, but it couldn't hide from a bootable CD. I guess you can sort of achieve the same effect with Knoppix with a bit of work, but it would be nice to have something that I could use to scan a machine for vulnerabilities without using the hard drive to boot at all.

Re:Compiler is Irrelevant

[profplump]

First, let me introduce you to the file command, which can tell me all about your arch. Or failing that, less, or any other program than can read any binary on your system. Your binary executables necessarily include information about their format, including their architecture.

spaceheater ~ 0$ file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped

Second, why are you worried about compilers and version numbers if you're so sure people can't load modules anyway? What exactly are you trying to protect? There's something to be said for a minimalistic system, but you've yet to explain how having a compiler installed poses any sort of realistic security threat.

Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel? Even if you disable all the ways to do this without rebooting -- kexec() and /proc/kcore, probably among others -- they could always reboot the machine. Sure, you'd notice the reboot, but would you be able to detect their change after the reboot?

I'd also like to mention that OS-enforced append-only files are a poor substitute to logging to a hardware-enforced WORM drive, particularly if we're talking about rootkits. You're still fundamentally relaying on the OS to provide protection, which isn't reasonable when a rootkit has been installed.

Re:trojan the detector

[sfjoe]

They can do that but, if you're like me, chkrootkit runs from a mounted CD-ROM. It's a little harder for them to trojan it that way.

Re:Read Only Drives

[throx]

I'm not assuming anything is on a read-write disk. If the attacker is able to load arbitrary code into the kernel then it doesn't matter where /etc/fstab is - they can just rewrite the kernel at runtime to mount a disk without worrying about /etc/fstab.

Yes - your machine will be "clean" after a reboot, but because you've made it read only it will be vulnerable to whatever attack gave them root in the first place.

Any system - read/write or read only root drive can be reset to a known configuration with little effort (it's usually called "restoring from a backup"), but the point of the rootkit is to give you no reason to do this. Your system looks like it's running just fine and your security theater of making the root drive read-only is giving you a warm fuzzy feeling about how safe you are, but in reality an attacker owns your box and you have no idea.

The answer is to spend less time thinking about what if an attacker gets root and more time preventing them. Once they have root it's pretty simple: nothing is trustworthy on the box any more because you have hard empirical evidence that it's weak to an attack.

Re:Read Only Drives

[noahm]

Impractical, because it requires you to dedicate a drive to the stuff that can be mounted RO. Just mount the PARTITION read-only, instead.

# mount -o remount,rw /readonly/partition

So that won't help you...

You could also built a monolithic kernel and not allow modules at all. Kind of hard to insert a corrupt module if the kernel isn't modular!

That won't help either: http://doc.bughunter.net/rootkit-backdoor/kmem-pat ching.html [bughunter.net] Most modern kernel-level rootkits do not depend on the ability to dynamically load modules.

noah

This would have been more appropriate:

[Anonymous Coward]

52 65 61 6C 20 6D 65 6E 20 61 6E 64 20 72 65 61 6C 20 68 61 63 6B 65 72 73 20 77 72 69 74 65 20 74 68 65 69 72 20 70 72 6F 67 72 61 6D 73 20 69 6E 20 62 69 6E 61 72 79 20 63 6F 64 65 2C 20 6E 6F 74 20 69 6E 20 73 74 75 70 69 64 20 61 6E 64 20 62 6C 6F 61 74 65 64 20 61 73 73 65 6D 62 6C 65 72 2E

Re:Why not just detect changed files?

[banerjek]

There is always a way to break in. But many crude security methods are reasonably effective.

A rootkit has to be pretty good to return the "correct" response. It needs to retain all previous file attributes, modify md5sum to return the correct hash, fake disk usage statistics, and do it all without causing any glitches on the system.

It is impossible to modify the environment without leaving some sort of trace. A rootkit needs to succeed before it can mask itself. The problem a rootkit faces is it cannot know the particulars of a machine in advance so it will not necessarily plan to most efficient attack. All it has to do is trip one alarm and it will be discovered. If programs scan sufficiently frequently, you can discover things quickly.

Logs on other systems cannot be erased -- only new entries can be screwed up (which is itself a clue). Communications with other machines can give clues. Manual monitoring is also very useful. The trick is to use a wide variety of tools to maintain security. While any one of them can be broken, it's hard to get them all.

Re:This is...

[gmack]

Point well taken, but I do wonder how often these kind of exploits actually happen in the wild on linux or on commercial unixen.

Often enough. Exploits will be written for any OS that has a decent return on investment time wise. These days that means both Windows and Linux. You could actually see this in when the better architected OpenSSH became the standard for most Linux distros the move to Linux brought a bunch of new eyes to go over the code and a bunch of exploits got discovered in a really short time.

Linux isn't the only one of course a couple of years back I left a new FreeBSD install over night without locking it down and discovered a root kit waiting for me in the morning.

I used to get more calls than I get now though. The Linux vendors have improved a lot and removed crap like WuFTPd, sendmail and moved to the rewritten bind9. Those moves a have cut the attack vector and instead of system daemons being the main focus it's badly written web apps being used to gain a shell and then a local root exploit used to gain root.

The really fascinating thing is that I've seen custom PHP scripts get scanned for common programming mistakes and exploited

So all that to say basically Linux gets hit too it is better than Windows by a long shot but it's not perfect. Keep your distro patched.