|< Day Day Up >|
This segment deals with rootkits , automated software packages that set up and maintain your environment on a compromised machine. Rootkits occupy an important place in a hacking tool chest. Originally, rootkits were simply tar archives of several popular binaries (likely to be run by system administrators of the compromised machines), along with several other support programs, such as log cleaners. For example, /bin/ps , /bin/login , and /bin/ls were often Trojaned in order to hide files and maintain access. Here is a list of binaries often replaced (from http://www. chkrootkit .org): aliens , asp, bindshell, lkm, rexedcs, sniffer, wted, scalper, slapper, z2, amd, basename, biff, chfn, chsh, cron, date, du, dirname , echo, egrep, env, find, fingerd, gpm, grep, hdparm, su, ifconfig, inetd, inetdconf, identd, killall, ldsopreload, login, ls, lsof, mail, mingetty, netstat, named, passwd, pidof, pop2, pop3, ps, pstree , rpcinfo, rlogind , rshd, slogin , sendmail, sshd, syslogd, tar, tcpd, top, telnetd, timed, traceroute, w, and write.
This list demonstrates that almost nothing is immune from Trojaning by rootkits and also emphasizes that "fixing" after the intrusion is nearly futile. A rebuild is in order.
Unix rootkits were first mentioned in 1994, after being discovered on a SunOS system. However, many tools that later became part of rootkits were known as long ago as 1989. There are three main classes of rookits available today: binary kits, kernel kits, and library kits. However, rootkits found in the wild often combine Trojaned binaries with the higher "security" provided by the kernel and library components .
Let's examine some rootkits. After gaining access, an attacker typically downloads the kit from his site or a dead drop box ,  unpacks it, and runs the installation script. As a result, many system binaries are replaced with Trojaned versions. These Trojans usually serve two distinct purposes: hiding tracks and providing access. The installation script often creates a directory and deploys some of the support tools (log cleaners, etc.) in the new directory. This same directory is often used to store the original system binaries so that they're available to the attacker. After the kit is installed, the system administrator inadvertently runs Trojaned binaries that will not show the attacker's files, processes, or network connections. A Trojaned /bin/login (or one of the network daemons) binary provides remote access to a machine based on a "magic" password. This is the style of operation employed by the famous login Trojan , which looked for the value of the $ TERM environment variable. If the value matched a hardcoded string, the login let the attacker through; if the value did not match the control, it was handed to the original login binary and the authentication process continued as usual.
The level of rootkit sophistication has grown over the years . More and more binaries have been subverted by attackers and included in rootkits. Local backdoors, such as "root on demand," have been placed in many otherwise innocuous programs. If a program executes SUID root, it can be used as a local backdoor to provide root access. For example, a backdoored ping utility is often seen in Linux rootkits. In fact, one rootkit author sincerely apologizes in the kit's README file for not including top (a program to show running processes) in the previous version and for delaying the release of this popular "customer- requested " feature.
A lot of development went into creating better and more user -friendly (should we say hacker-friendly?) installation scripts. Colors, menus , and automated OS version detection and configuration began showing up in kits as they matured through the late 1990s. Installation scripts became able to automatically clean logs, look for dangerous configuration options (like enabled remote logging), seek and destroy competing rootkits (ironically, by borrowing components from the antirootkit tool, chkrootkit, from http://www.chkrootkit.org), and perform decent system hardening, complete with plugging the hole used to attack the system. One of the rootkits refers to "unsupported" versions of RedHat Linux and offers limited email installation support for the kit itself.
Another area where great progress has occurred is in rootkit stealth properties. Kernel-level or LKM (Loadable Kernel Module) kits rule in this area. Unlike regular kits that replace system files, LKM kits ( publicly available for Linux, Free/OpenBSD, and Solaris) hook into the system kernel and replace ( remap ) or modify ( intercept ) some of the kernel calls. In this case, the very core of the operating system becomes untrusted. Consequently, all of the system components that use the corrupted kernel call can fool both the user and whatever security software is installed.
Rootkits have also increased in size due to the amazing wealth of bundled tools, such as attack scanners . Typical rootkit tools are reviewed in the following sections.
Let's analyze how rootkits accomplish the goal of hiding your tracks. First, the rootkit hides its own presence, the presence of other intruders' files, and evidence of access. Here is an excerpt from a recent Linux rootkit installation file:
unset HISTFILE unset HISTSAVE export HISTFILE=/dev/null ... killall -9 syslogd chattr +i /root/.bash_history ...
The kit disables history file generation via two different methods . First of all, the kit disables HISTORY. This works for the current session and makes the existing root history saved file "immutable" ”i.e., not editable by any program on the system, even root. In addition, the kit warns about remote logging and suggests that its user "go hack the syslog aggregation box" ”a feat that might well be beyond the ability of an average script kiddie .
The kit referenced above did not perform automated log cleaning; instead, it included the appropriate tools and some tips on how to use them. Killing syslog seems like a way to draw attention, but further in the installation script a "new" (i.e., Trojaned) version of syslogd software is deployed and executed. This one ignores some IP addresses, some processes, and some users. Any message containing any of the above will not be recorded. For example, if user "evil" logs in via FTP, none of her FTP accesses are logged in the system files, provided that the malicious syslogd was configured to prevent this. Likewise, if any user connects from 126.96.36.199 (the evil IP address), nothing is logged.
Rootkits often take measures to hide their own files and other attackers' files. The oldest trick in the book is for the rootkit to obscure its own location on the disk. Even expert system administrators might not look at the entire disk every day. However, understanding the functionality of every piece of your system clearly helps to avoid some surprises . In general, only integrity checking software (such as Tripwire) can find these malicious files. Unfortunately, there are tricks that kernel rootkits play that can even defeat them.
Here are some of the locations used by the kits:
/dev/.hdd /etc/rc.d/arch/alpha/lib/.lib /usr/src/.poop /usr/lib/.egcs /dev/.lib /usr/src/linux/arch/alpha/lib/.lib/.1proc /usr/src/.puta /usr/info/.t0rn /etc/rc.d/rsha
There are many others. In fact, it is just too easy to change the default location. The above list demonstrates the pattern of thinking manifested by rootkit authors: hiding files in /etc (where they might look like system files of unclear purpose), rarely used locations (such as /usr/src or /usr/info ), or /dev ( where no user-utilized programs reside).
Here is an excerpt from a rootkit configuration file that shows parameters hiding, apparently based on K2's Universal Root Kit (URK):
[file] file_filters=rookit,evilfile1 [ps] ps_filters=nedit,bash [netstat] net_filters=hackersrus.ro
The rootkit components refer to the above file and hide the references files and connections from Unix binary tools. URK is an old, multiplatform kit that replaces several system binaries with Trojaned versions.
LKM kits take the art of hiding to the next level. Using the loadable kernel module (a piece of software injected into a running Unix kernel), the kits are able to achieve near-total control over the system. See Section 10.5 for the analysis of the well-known LKM kit Knark.
Library Trojan kits, of which Torn 8 is the most famous representative, use a somewhat different method to elude detection. They add a special system library (called libproc.so by default) that is loaded before other system libraries. The library has copies of many library calls that are redirected in a manner similar to the kernel module. It's the user-space equivalent of kernel module-based redirection.
However scary this LKM rootkit technology might be, it is not on the bleeding edge of system hiding. Simply disabling the loading of modules within the Unix/Linux kernel can defeat most LKM kits; it's usually a compile-time option for open source Unix variants. Silvio Cesare, in his paper "runtime-kernel-kmem-patching.txt," showed that loadable modules are not required for intruding upon the Unix kernel. Several kits have since turned this research advance into production code. For example, SucKit is a user-friendly package that installs in the kernel and allows covert remote login, all without the need to insert any modules. The technique invented by Silvio Cesare works for both the 2.2 and 2.4 kernels .
Rootkits also help attackers to regain ground in case the system administrator locates and removes part of the attackers' tools. However many times it has been advised that a compromised system should be rebuilt, real life dictates otherwise. While the rootkits might make the system more difficult to hack from the outside, the kits often "weaken" the Unix system from the inside. Thus, if an attacker loses ground, and even a little CGI-based backdoor remains, all is not lost and the "root" can be regained.
Other items commonly seen in rootkits assist with the game of hide-and-seek on the compromised system. For instance, multiple Trojaned binaries allow attackers to regain root control even if the main method (such as a login Trojan with a magic password) is located and eliminated. Similarly, a seemingly innocuous ping (often SUID root) can hide a five-line code modification that spawns a root shell.
Hiding becomes complicated if some other "guest" is hiding on the same system as well. Some rootkits contain advanced antirootkit tools that can seek and destroy other kits, DDoS zombies , or worms that have previously taken over the system.
10.4.2 Hidden Access
It's also important for an attacker to covertly access the compromised system. Let us review some of the methods used for this purpose by attackers. The methods are as follows (approximately from least to most covert):
The above list demonstrates that even though hiding on a network is complicated, there are many tricks that interested parties can employ to keep their presence hidden, even under intrusion detection systems. However, the more tightly controlled the network is, the less likely it is that a covert channel will sneak through.
|< Day Day Up >|