Security

Hunting for Rootkits

Administrators like to know what processes are running on their machines, with good reason as they are responsible for ensuring that no unwanted or malicious software is present. Rootkits are a means of evading administrators, hiding the presence and the execution of certain programs. Probably the most famous rootkit is the one that Sony so helpfully installed on Windows boxes when their owners tried to play a copy-protected audio CD, but they exist for Linux as well. It is critical for administrators to understand what rootkits can do and how they do it in order to protect their systems against this kind of attack.

Rootkits come in multiple flavors, depending on what level of the system they subvert. The simplest just replace binaries of various programs to hide; for example, running a backdoor shell server masquerading as a standard long-running service (like httpd or ntpd) and patching netstat and other tools so that the listening socket is not reported. System libraries are another likely place for rootkits.. If a rootkit can replace glibc, it can intercept system calls made by any of the standard tools allowing it to hide anything that it chooses from those tools.

Kernel and boot rootkits are the most difficult to detect. Loadable kernel modules can change the kernel's behavior in very intrusive ways and allow all manner of malware to run undetected. The lowest level rootkit changes the Master Boot Record (MBR) of the system to load itself before the kernel at boot time. After that the rootkit can run the kernel in a virtual machine and intercept every instruction that it executes. This is the ultimate in rootkits and can be made undetectable from within the running kernel.

Trying to detect a rootkit installation while running the potentially infected system is a dodgy prospect at best. Because the rootkit is specifically designed to avoid detection it could be subverting any technique used to look for it. The important thing to notice is that in order to operate, the rootkit must change things about the system and in order to persist across reboots, it must write those changes to the disk. This provides the means to detect them.

To avoid running afoul of the rootkit while trying to detect it, one should boot from a live CD and run a rootkit detector from there. There are a number of distributions specifically targeted for this kind of analysis; Helix and Aghesa for example. Both of those distributions contain the two leading Linux rootkit detecting programs: chkrootkit and Rootkit Hunter. These programs look for things in the filesystem that correspond to rootkit signatures: hidden files and directories, logfile changes, non-standard kernel modules, etc. In addition they look for the signature of various 'in the wild' rootkits.

Another helpful tool in recognizing the presence of rootkits are programs that track changes to critical files and directories. The most well known is probably Tripwire, but others such as AIDE and Samhain are available as well. These programs keep a record of each file in the system (using a digest like MD5 or SHA-1) and can alert the administrator when one of them changes. They also keep track of files and directories that get added or deleted. Prudent administrators will, of course, keep the records on a separate machine or on read-only media so that they cannot be tampered with by rootkits that infect the machine. The biggest problem with these kinds of programs is false positives each time a new package is installed, but for relatively static systems, an alert email from those checkers is an enormous red flag.

A very interesting sounding rootkit detection toolkit called Rootkit Profiler LX was recently announced on the Bugtraq mailing list. It is a linux kernel module that gets loaded into the running kernel of a machine suspected of harboring a rootkit and has an impressive sounding list of capabilities. It is not available in source form which makes it of dubious utility; it could after all, be a rootkit itself. One could argue that using binaries from the live CDs is no different, and in some ways that is true, but one could in principle inspect the code and build their own version rather than trusting the distributor (of course they have to trust their compiler and other components; security paranoia can run deep).

Once a rootkit has been detected, it is probably a waste of time to try and remove it. Reinstalling the operating system is the safest course. The time spent trying to remove every last piece of the rootkit and the malware it hides would be better spent determining how the rootkit was installed to begin with. If there is a vulnerability in one of the programs that run on that machine, it is pretty likely the rootkit (or some other) will return. Of course, the rootkit, in and of itself, is not a huge problem; it is the malware that it hides that makes all the trouble.

Comments (25 posted)

chmlib: remote execution of arbitrary code

Comments (none posted)

enigmail: memory allocation errors

Comments (none posted)

kernel: denial of service

Comments (none posted)

Mozilla: multiple vulnerabilities

Comments (1 posted)

nexuiz: arbitrary code execution, denial of service

Comments (none posted)

slocate: information disclosure

Comments (none posted)

ufo2000: multiple vulnerabilities

Comments (none posted)