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."

ifl

I think that there is room to mention the well known tools such as AIDA and TripWire and LogCheck.

Re:ifl

Most modern rootkits are kernel level and Trip Wire can not readily detect them. Nevertheless it is still useful to have at hand.

Re:ifl

i have no idea. i've never used any of them. this is a joke gone completely wrong. i just copied and pasted the comment from over at tfa. hence my subject: ifl (it's funny laugh). i figured it'd end up troll, over-rated, but i got such a laugh out of doing it (sorry i'm easily amused) that i figured it was worth it. in what is a horrid twist of fate, i now feel bad for getting modded up.

Re:ifl

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.

This is...

For starters, why you do NOT keep any sort of compiler on your machine.

It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.

It'd be even better if you could make every program execute only (no reading) and hide /proc through something like NSASecurity setup. What they dont know, they cant do much with. Obfuscation, THEN security. Keep em guessing.

Re:This is...

It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.

I'll tell you a little secret: if you know the kernel version number and target architecture, you can build a module on another, totally different machine. Wow! 2007 technology man!

Re:This is...

Does root have access to /proc/kcore? If yes then an attacker with root access can modify the kernel in memory as needed. Heck there's even projects to bring this into the mainstream for carrier grade Linux (no need for those pesky reboots after a kernel upgrade): http://pannus.sourceforge.net/ [sourceforge.net]

Re:This is...

That may have been true 30 years ago when a compiler license cost thousands. If a person has write access to your system, they can just copy a compiler binary over.

Compiler is Irrelevant

It's pretty trivial to just deduce what kernel the machine is running and build working binaries wherever you want. In fact it would be preferred, since a sysadmin is far more likely to notice a rogue gcc process sucking up CPU than a file transfer while the rootkit is being loaded.

Anyway - if the person has root on the box (which they need to install the rootkit anyway), then they can just ship up THEIR OWN COMPILER if they want to regardless.

Re:Compiler is Irrelevant

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:This is...

Real men and real hackers write their programs in binary code, not in stupid and bloated assembler.

Ah! No need for rootkit detector...

... with the Internet Freedom Disk [slashdot.org]!

OSSEC HIDS

I PREFFER OSSEC HIDS to do this. look www.ossec.net i think this is the most powerfull agent ever :)

Pish Posh

It's GNU/Linux. Any hacker worth his salt doesn't want to bother with archaic OSes based on Unix. He wants the 1337 stylings of Windows Vista. No sense in rootkitting a *nix box. You can't do anything with a *nix box. But an army of zombie Vista PCs, now THAT is ULTIMATE POWER!

Yes, but...

You have your l33t ninja with his army of zombie Windows boxes... ...but how do they stack up to the *nix pirates, and their FTPs on the seven seas of the intarwebs? It's the classic clashes, modernized. Who has the REAL Ultimate Power?

Read Only Drives

I run Gentoo Linux servers for hosting email and websites, and have wanted a way to really secure the boxes.

Many hard drives have jumpers that make them read only.

I thought it would be great to have all of the rarely changed portions of the operating system on a separate drive set to read only.

The only time you would move the jumper to read-write would be when you were installing updates.

Things like: /tmp /var/log
etc

Would have to always be on a read-write drive.

But having things like /usr/bin on a read-only drive seems like an effective way to protect against many, many different root-kits, worms, etc.

What do you think? Feasible or impractical?

Re:Read Only Drives

Right, but now if you want to install a program or security update you have to power off, change jumper, power on, install, power off, reset jumper, power back on. This may or may not be worth it, particularily in the case of a security update.

Amazingly enough, I can draw on 25 year old experience on this one, sort of. Back in the early 1980s, I ran a BBS on a dialup TRS-80. The floppy drives, I put toggle switches on the front of so the read-only setting could be changed on the fly. So worst case, it'd be something you might be able to put an external switch for that jumper, outside the drive case. Maybe. Might blow up but at the time it worked great.

Re:Read Only Drives

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

If you have more than one machine, get a dedicated syslog server and send the logs from the other machines over to it. This way logs aren't on the main machines and it is much harder to compromise the audit trail.

For businesses, get something like a Trigeo appliance [trigeo.com] and keep an eye on the behavior of everything.

Make sure all your permissions/rules are based off the concept of "default deny, explicit allow".

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!

  Charles

Re:Read Only Drives

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

I like to leave this up to the FBI

When the dark suits turn up on my doorstep with an arrest warrant on charges of attempting to crack confidential government sites I can be pretty sure my machine has been rooted.

Is rooting Linux

... just .. un-cool?

Tinfoil Hat Time...

A well done rootkit is hard to detect... if you can't find a rootkit on your system then it's probably too late.

Go here now. [openbsd.org]

linuix rootkits?

That's easy. Are you running VMWare with a Windows virtual install on this Linux box? Delete that virtual machine. Rootkit eliminated.

trojan the detector

Wouldn't the first step for a rootkit developer be to add rkhunter and chkrootkit to their list of trojaned programs so that they give a "no rootkit" output? Maybe there's some protection from this, but I don't see it in the article.

Re:trojan the detector

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.

I've always wondered...

How hard is it to build a basic but worthwhile rootkit detection tool with common tools? Like run `md5 /bin/*` and then ship the output of that to another machine every day for comparison to yesterday's output of that command? (Looking at other directories as well, of course.) My understanding is that many rootkits come with hacked versions of tools like 'ps' to hide themselves.

On the one hand, yeah, let's not reinvent the wheel, but on the other hand, there are advantages to building your own tools:
- you know exactly what they're doing--more complicated pre-existing tools might do more, but if you don't understand their output, they're no good.
- you don't have to trust*/audit someone else's code
- they don't do more than you need
- they don't have features that you don't know about or might misuse
- at the very least, it's a great way to learn

* yes, I know about this. [acm.org] but there are reasonable limits--I do trust that my distro came with a clean copy of gcc. OTOH, I'd rather write my own 20-line script that download someone else's that says it does the same thing as what I would write myself but that I'd have to audit for even the smallest things, like sneaking in an
if ($rooted="no")
instead of
if ($rooted=="no")

Meh, I don't trust those tools

I just eyeball /proc/kcore for anything suspicious every day or so.

You keep using that word...

"His passwd program has the same name as the real passwd program and works flawlessly in all respects except for the fact that it will also gather data residing on your machine such as the user details each time it is run and transmit it to a remote location or it will open a back door for outsiders by providing easy root access and all the time, you will be impervious about its actions."

...I don't think it means what you think it means.

http://www.answers.com/impervious&r=67 [answers.com]

chkrootkit

chkrootkit is good, I like it anyway, you can get it in Fedora Core 6 through yum (although you don't seem to be able to get rkhunter through yum any more). you have to run it as root, maybe its something about what it needs to access... anywho, you can get issues with false possitives, I just ran it and got;

Searching for OBSD rk v1... /usr/lib/security
/usr/lib/security/classpath.security
....
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/.pack list

so I wouldn't worry too much if you see something that looks iffy before you check it out (I'd have been annoyed if I just reinstalled my OS just to find the same thing happening again). It will also show your ethnet port as being in "sniffer". Anywho, best practices can minimize the risk to pretty much 0... oh, but for God's sake PLEASE switch off remote root access on ssh over default ports, ideally switch it off altogether (If you need it please learn how to use it). Ssh coupled with an easily broken root password is the single biggest cause of rootkits... and a huge /var/log/secure!

Bigger list

If you want a bigger list of such tools, type ls /usr/portage/app-forensics/ on any gentoo machine.

Linux rootkits

I can't help but point out on FreeBSD you can use CVSup to force your sources to match the master site, and then "cd /usr/src ; make world". Around an hour later (depending on your machine) you will have completely new binaries for the kernel, kernel modules, binaries, docs, etc.

Bye bye rootkits, viruses, back doors and the like.

The tables have turned, Mr. Bond...

Joke's on you, Linux boys (and girls?)!

I don't have to worry about this. I use Windows!

Oh wait...

- RG>

Use the hash, Luke!

The best way to detect a rootkit: post-install, hash the installed file-system files and kernel and save the results on a CD-R. Periodically, check to see if the hashes have changed. If so, you know where the problem lies.

Re:Why not just detect changed files?

Isn't the point of a rootkit is to take over the file system to such an extent that virus activity is hidden from programs like scripts running on the kernel.

Re:Why not just detect changed files?

What is the point of a script that asks a compromised operating system about the files that compose it? One of the first things that a rootkit should do when it modifies the environment is ensure that whenever system files are queried, the response is the 'correct' one.