Even Nastier: Traditional RootKits
- So, What Do Traditional RootKits Do?
- Defending Against Traditional RootKits
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Traditional RootKits are a very insidious form of Trojan horse back door. Traditional RootKits raise the ante by altering or replacing existing system components, as shown in Figure 1. Rather than running as a foreign application (such as Netcat or Back Orifice 2000), traditional RootKits replace critical operating system executables to let an attacker have back-door access and hide on the system. By replacing system components, RootKits can be far more powerful than application-level Trojan horse back doors.
){kind=link}
Figure 1 Comparing application-level Trojan horse back doors with traditional RootKits.
Traditional RootKits have been around for over a decade, with the first very powerful RootKits detected in the early 1990s. Many of the early RootKits were kept within the underground hacker community and distributed via Internet Relay Chat for a few years. Throughout the 1990s and into the new millennium, traditional RootKits have become more and more powerful and radically easier to use. Now, traditional RootKit variants are available that practically install themselves, allowing an attacker to "RootKit" a machine in less than 10 seconds.
Traditional RootKits are available for a variety of platforms but have traditionally focused on UNIX systems, such as Solaris, SunOS, Linux, AIX, HP-UX, and so on. While some Windows NT/2000 RootKits are available that replace Dynamic Link Libraries (DLLs) or otherwise alter the system, the vast majority of RootKits are focused on UNIX systems.
So, What Do Traditional RootKits do?
Contrary to what their name implies, RootKits do not allow an attacker to gain root access to a system. RootKits depend on the attacker already having root access, which was likely obtained using buffer overflows, taking advantage of programming errors, or performing other attacks. Once an attacker gets root access on a machine, a RootKit is a suite of tools that allows the attacker to maintain root-level access by implementing a back door and hiding evidence of a system compromise.
The Centerpiece of Traditional RootKits on UNIX: /bin/login Replacement
So, how do RootKits implement back doors? To understand RootKit backdoors, it's important to know what happens when you access a UNIX machine. When you log into a UNIX system, whether by typing at the local keyboard or accessing the system across a network using telnet or another application, the /bin/login program runs. The system uses the /bin/login program to gather and check the user's ID and password. The /bin/login program is one of the most fundamental security tools in UNIX, requiring users to provide their user ID and password to the system for authentication during login. /bin/login gathers the user ID and password typed by the user and consults the password file to determine whether the password was accurate. If the password was accurate, the /bin/login routine allows the user into the system.
A RootKit replaces /bin/login with a modified version that includes a back-door password for root access. If the attacker uses the back-door root password, the modified /bin/login program will give access to the system. Even if the sysadmin alters the legitimate root password for the system (or wipes the password file clean), the attacker can still log in as root using the back-door password. So, a RootKit's /bin/login routine is a back door because it can be used to bypass normal system security controls. Furthermore, it is a Trojan horse because, although it looks like a normal, happy login routine, it is really an evil back door.
Figure 2 shows a user logging onto a system before and after a traditional RootKit is installed. In this example, the /bin/login routine is replaced with a back-door version from the widely used Linux RootKit, lrk5. Note the subtle differences in behavior of the original login routine and the new back-door version.
){kind=link}
Figure 2 Behavior of /bin/login before and after installation of a generic RootKit.
In Figure 2, the first difference we notice in the before and after picture is the inclusion of the system name before the login prompt on the RootKitted system, which says bob login: instead of simply login:. Additionally, when we tried to log in as root, the original /bin/login requested our password. The system is configured to disallow incoming telnets as root, so it gathered the password and wouldn't allow the login. The original /bin/login just displayed the login: prompt again. The RootKitted /bin/login however, displayed a message saying, "root login refused on this terminal."
Of course, a more sophisticated attacker would first observe the behavior of the login routine and very carefully select (or even construct) a Trojan horse /bin/login routine to make sure that it properly mimics the behavior of the original /bin/login routine. However, if the behavior of your login routine ever changes, as shown in Figure 2, this could be a tip-off that something is awry with your system. You should investigate immediately if the behavior of your login routine changes. The difference could be due to a patch or system configuration change, or it could be a sign of something sinister.
To detect back doors like this, system administrators often run the /bin/login routine through strings, a UNIX program that shows all sequences of consecutive characters in a binary file. If an unfamiliar sequence of characters is found, it may be a back-door password. After all, the binary of /bin/login could have the back-door password in it, which it uses to compare to see if the attacker is trying to get in. A mysterious appearance of a string could indicate a back-door password.
The majority of RootKit developers knew of this strings technique and developed a clever means for foiling it. The back-door password is split up and distributed throughout the /bin/login binary and is not a sequence of consecutive characters. The password is assembled in real time only when the /bin/login routine is executed to check if the back-door password has been entered. Therefore, the strings routine will not find the password in the executable because it is not a sequence of characters.
Furthermore, when a user logs into a UNIX system, the /bin/login program records the login in the wtmp and utmp files. These accounting files are used by various programs, such as the who command, to show who is currently logged into the system. The RootKit version of /bin/login skips this critical step if the back-door root password is used. Therefore, a system administrator that runs the who command will not be able to see the attacker's root-level log in.
Traditional RootKits: Hide Everything Else!
RootKits go far beyond just replacing the /bin/login programs. The same techniques applied to /bin/login to hide critical evidence about an attacker's presence are also employed against numerous other programs used by a system administrator. Table 1 shows some of the programs that are commonly replaced by RootKits to mask the attacker's activities on the system.
Table 1 Programs Typically Replaced by RootKits
|
Program RootKit Replaces |
Program's Original Function |
Behavior of RootKit Version |
|
du |
Displays disk utilization, showing how much disk space is available |
Lies about available disk space, hiding the sectors taken up by attacker's tools and sniffer logs |
|
find |
Allows users to find files and directories, such as programs and recently modified files, in the file system |
Lies about presence of attacker's files, such as sniffer programs and other tools, hiding their presence |
|
ifconfig |
Shows status of interfaces, including an indication of which interfaces are in promiscuous mode |
Masks promiscuous mode so administrator cannot detect sniffer on the local system |
|
login |
Allows users to login to the system |
Allows users to log into the system, but also provides a backdoor root-level password for the attacker |
|
ls |
Shows the contents of a directory |
Lies about presence of RootKit files, hiding their presence |
|
netstat |
Can be used to show processes listening on various TCP and UDP ports |
Lies about specific ports used by the attacker, masking the fact that a process is listening there |
|
ps |
Displays a list of running processes on the system |
Lies about any processes the attacker wants to hide |