A rootkit is a collection of tools an intruder
brings along to a victim computer after gaining initial access. A
rootkit generally contains network sniffers, log-cleaning scripts, and
trojaned replacements of core system utilities such as
killall. Although the intruders still need to break into a victim system before they can install their rootkits, the ease-of-use and the amount of destruction they cause make rootkits a big threat for system administrators.
The main purpose of a rootkit is to allow intruders to come back to the
compromised system later and access it without being
detected. A rootkit makes this very easy by installing a backdoor remote-access daemon, such as a modified version of
sshd. These will often run on a different port than the one that these daemons listen on by default.
Most rootkits also come with modified system binaries that replace the
existing ones on the target system. At a minimum, core binaries such as
find, and other binaries that can be used in
monitoring server activity, are replaced so intruders and the processes they run are invisible to an unsuspecting system administrator.
Because most rootkits will mimic the creation dates and file sizes of the original system binaries while replacing them with infected versions, keeping records of these file statistics is not sufficient. Thus, the best way to make an inventory of system file information that can be used to identify suspicious activities on the server is to calculate the cryptographic checksums of these files and store this information in a safe location, such as on a CD.
Third-party tools such as Tripwire or AIDE make this process much easier and more robust by automating the calculation of these file signatures.
Here's a quick explanation of Tripwire from the organization's web site:
"Tripwire is a tool that checks to see what has changed on your system. The program monitors key attributes of files that should not change, including binary signature, size, expected change of size, etc."
Obviously this process has to be repeated as you introduce more software and other files into your system. You can also use the RPM signatures on RPM-based systems such as Red Hat and SuSE to compare the current MD5 signatures of your files to those in the RPM installation database. Unfortunately, the RPM application itself and the local RPM database cannot be trusted to provide accurate information because intruders can potentially infect them too.
Some rootkits may also contain sniffer or keylogger applications that
are used to gather passwords for other systems and listen to traffic
for sensitive information. To do this, the rootkits set the
PROMISCIOUS mode on the target machine's network interface card (NIC). In
normal operation, a network interface card only listens to traffic that is specifically addressed to itself and traffic that is coming through the broadcast address that everyone listens to.
On a "non-promiscuous" network adapter, the packets that are addressed to other network interfaces are silently discarded without even looking at the actual data in them. However, when using directly connected computers or a network that uses basic, non-switching HUBs, your interface actually can listen to all traffic if it's in
If an intruder listens to this traffic on a relatively large network, the results may be catastrophic. To protect the whole network even when one of the machines is broken into, using direct cable connections and basic HUBs should be avoided. Switching-hubs and other more advanced networking equipment do not broadcast traffic to all the machines on the network, but only send it to the machine that is supposed to receive it, effectively protecting all the other machines on the network.
Because the first thing a system administrator does to monitor unusual activity is to check the system log files, it is very common for a rootkit to include a utility to modify the system logs. In some extreme cases, rootkits disable logging all together and discard all existing logs. Usually if the intruders intend to use the server for an extended period of time as a launch base for future intrusion activity, they will only remove those portions of logs that can reveal their presence. Because the absence of log files or stopped logging activity is a sign of suspicious activity itself, only attackers who have adopted the hit-and-run style will choose to blindly discard all logs.
One method administrators can use to maintain logs about an intrusion attempt -- successful or otherwise -- is to devise a system that detects network anomalies and alerts the system administrators by sending them notification email messages and/or log files. Obviously, the network intrusion detection and periodic log-file transfer methods cannot be trusted after the intruder gains access to the machine.
Arguably the most severe threat to system security that can be caused by a rootkit comes from those that deploy LKM (Loadable Kernel Module) trojans. Loadable Kernel Modules are a mechanism for adding functionality to an operating-system kernel on the fly -- without requiring a kernel recompilation. Although the benefits of using LKMs are universally recognized, they are also subject to abuse by intruders who use the kernel module-loading mechanism for malicious purposes. Even if you reboot a system that is infected by an LKM Trojan, the LKM process will reload it during boot-up just like any other kernel module. Loadable Kernel Modules are used by many operating systems including Linux, Solaris, and FreeBSD.According to SANS, "Kernel [LKM] rootkits do not replace system binaries, they subvert them through the kernel. For example,
psmay get process information from
procfs). A kernel rootkit may subvert the kernel to hide specific processes from
psor even a known good copy from vendor media will report false information."
Although it is thought to be possible to cryptographically sign kernel modules, the best mode of prevention against this security threat is to compile all functionality statically into the kernel and disable the LKM functionality -- especially on a server system which is not likely to need additional kernel functionality at a later time.
Knark, Adore, and Rtkit are just a few of many LKM rootkits available today.
The only way to avoid rootkit installations on your system is to stop them before they enter your system. Remember that a rootkit is not designed to help an intruder gain access to a system. A rootkit is designed to make the intruders feel at home and allow them work silently on your system without being disturbed. To install a rootkit, an intruder still must gain unauthorized access to your server using traditional methods, such as exploiting known vulnerabilities or even practicing social engineering to get the password information from a well-meaning person who happens to have it.
To avoid future headaches, you should always install firewalls on your machines that are accessible via some type of a network, apply all published patches to your software, and disable any services that are not absolutely necessary. Coupling these practices with strong passwords and secure protocols, such as SSL and SSh where applicable, you can be sure that your system will never be compromised.
Well ... not exactly. Even if you make the maximum effort possible to secure your system, given enough exposure, it is still very likely that someone will break into your system and install a rootkit or two.
In my next article, I'll discuss some of the tools that are at your disposal in your quest to detect the existence of a rootkit on your system. I will also talk about what you can do to clean up a rootkit after you discover it.
Oktay Altunergil works for a national web hosting company as a developer concentrating on web applications on the Unix platform.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.