Chapter 10. Digging into a Computer with Rootkits
Breaking into a computer isn’t easy, so once a hacker gets in, his first goal is generally to make sure he can get back into that computer easily at any time. The best way to do this is to control a system administrator account on the computer, otherwise known as a root account or just plain root.
To gain and maintain root access, hackers have created special tools called rootkits, which are programs, or groups of programs, designed to punch holes through a computer’s defenses. That way, if a system administrator finds and blocks the first route the hacker used to access the computer, the rootkit will have created several alternate ways for the hacker to get back inside. Some rootkits, such as Hacker Defender (www.hxdef.org), even have their own websites where you can learn about their latest advances.
Some of the more common rootkit tools include sniffers and keystroke loggers (for snaring additional passwords), log-cleaning tools (for hiding the hacker’s presence on the system), programs for finding common exploitable flaws (for taking advantage of vulnerabilities in the operating system or server software), and Trojan horses (for opening backdoors into the computer and masking the intruder’s activities). Once a hacker has installed a rootkit on a computer, he can sneak back in at any time without worrying about being detected.
How Operating Systems Work
Rootkits directly manipulate the operating system, which can be likened to probing the computer’s brain with a sharp needle and a pair of forceps. To understand how rootkits work, you need to understand how operating systems work.
At the most basic level, an operating system controls all the different parts of a computer. A computer may have a hard disk, memory, a keyboard, and a mouse, but none of this equipment knows how to work with the other components without an operating system.
Older operating systems, such as MS-DOS and CP/M-80, could run only one program at a time, but modern systems such as Linux, Windows, and Mac OS X can run multiple programs at once. So, the operating system also needs to manage which programs get loaded into memory and which programs can use the CPU, while it simultaneously checks for input from the keyboard or mouse and sends output to the computer screen.
On top of all this work recognizing and managing hardware resources, the operating system may also load additional programs called device drivers, which are simple programs that tell the operating system how to work with external equipment, such as a printer or scanner. When a program such as a word processor needs to print data, it sends this information to the operating system, which uses the device driver to send it to the printer.
Finally, an operating system runs other programs and isolates them so they can’t manipulate the computer’s hardware themselves. Programs, whether databases or games, send information to the operating system, which then saves this information to the hard disk. Figure 10-1 shows the different tasks of an operating system and how applications and device drivers work together.
The Evolution of Rootkits
Rootkits have been around for years, perhaps even longer than viruses and worms. What makes rootkits particularly dangerous is how they’ve managed to evolve, getting stealthier and trickier to better avoid detection.
This stealth by itself is alarming, since once a hacker plants a rootkit on a computer, it’s nearly impossible to clean it off the system without reformatting the hard disk and reinstalling the operating system. The biggest danger from rootkits is their use as a combined Trojan horse/worm/spyware infection tool. Ordinarily, when malware infects a computer, it’s fairly easy to find and remove. But by combining rootkit technology with Trojan horses and worms, malware creators can develop programs that not only infect a computer, but also hide from any detection programs.
Even more frightening than that is the application of rootkit technology to so-called legitimate business uses. In late 2005, in an effort to copy-protect its audio CDs, Sony used digital rights management (DRM) technology created by First 4 Internet (www.first4internet.com). This copy-protection method borrows from rootkit techniques by installing itself on a computer and then hiding in memory, even when the copy-protected CD is no longer in the computer. Removing this software can be difficult and, even if successful, it can disable the computer’s CD player, making it impossible to play legally purchased CDs. Needless to say, Sony took a lot of heated criticism for this.
Both Kaspersky Lab (www.kaspersky.com) and Sophos (www.sophos.com) have classified Sony’s copy-protection scheme as “spyware” since it can crash a computer and weaken its security by allowing hackers to tuck away Trojan horses, viruses, and their own rootkits in the same hidden area where Sony’s rootkit resides. Following the backlash against the company, Sony quickly released a patch to make it easier to remove their rootkit. However, this patch actually made computers more prone to crashing. If so-called legitimate companies such as Sony can use rootkit technology “legally,” then perhaps hackers aren’t really doing anything wrong after all. They’re just not doing the “wrong” things for the right people.
Modifying log files
Rootkits can delete or modify a computer’s log files. To avoid detection, they try to hide their presence from the prying eyes of a system administrator. Log files keep track of who used a computer, what they did, and for how long they used the computer. This information was particularly crucial back when computers were expensive and companies sold spare time on their computer to others (known as time-sharing), but, equally important, log files could also identify what a computer was doing right before it crashed. When hackers started to invade computers, log files served another purpose: They kept track of when the hacker arrived, what the hacker did, and how long the hacker stayed on the computer—much like a surveillance camera can record a burglar breaking into a store. In many cases, the log file could also track which computer the hacker used to gain access to another computer, which could help the authorities track down the perpetrator.
Therefore, hackers look for the log files that recorded their entry as soon as they gain access to a computer. Among the information a log file might contain that may help a computer’s owner track the hacker down are the following:
The IP address of the machine that performed an action or “request” on the target computer
The user name, which simply identifies the account being used (a perfectly valid user name could mask the presence of a hacker who has secretly hijacked that user’s account)
The date and time of a particular action
The exact command or “request” that the user gave the target computer
The HTTP status code (which shows what action the target computer performed in response to the user’s command or “request”) that the target computer returned to the user
The number of bytes transferred to the user
Armed with this information, system administrators can often determine not only when a hacker invaded their system, but can also deduce how the hacker invaded their system.
Script kiddies (novice hackers who are often unfamiliar with different operating systems) often delete log files to prevent the administrator from seeing exactly what they did. Unfortunately, deleting the log file announces the presence of an intruder as blatantly as would using a stick of dynamite to blow away a surveillance camera. The moment an administrator notices that someone has deleted the log file, he or she immediately knows that a hacker must be on the system.
Rather than announce their presence by deleting entire log files, the smarter and more technically skilled hackers selectively remove only their own activities and leave the rest of the log files intact. At a cursory glance, a system administrator would find the log files seemingly untouched.
In many cases, just editing the log files can hide a hacker’s tracks, but system administrators have their own techniques for ensuring the integrity of their log files. One of the simplest involves printing out the log files as they’re generated. That way, if a hacker does delete or modify the log files at some point, the printed copy will still reveal his or her presence. If the system administrator suspects something is wrong, he or she can compare the log file on the hard disk with the log file printout.
Another technique is to study the time stamp of the log file. If a hacker modifes the log file, the computer will time stamp the modified log file with the time and date of the modification, which can pinpoint the precise time the hacker was on the computer.
Another way for administrators to preserve log files and protect themselves is to create duplicate copies. The original log file appears where hackers expect to find it, while a duplicate copy gets stored on another computer, preferably one that no one else can modify or delete, including anyone with a root or administrator account. The moment a hacker modifies the first log file, the system administrator can use log file analysis programs to detect any discrepancies.
While it’s possible that hackers could stop a computer from copying its log file to another machine, the lack of a duplicate log file on the other machine would signal an obvious hacker attempt. Hackers could still try to modify both copies of the log file, but that’s assuming the hacker knows the log file is being copied to another machine and that the hacker can even access this other machine.
To learn about the capabilities of various log file analysis programs, visit one or more of the following: Analog (www.analog.cx), Sawmill (www.sawmill.net), and Webalizer (www.mrunix.net/webalizer).
Trojaned binaries
Modifying the log files can hide what a hacker has done in the past, but hackers still need to hide their presence while they’re active on a computer. So, after the log files, the second target that hackers go after are the programs that help system administrators notice any changes.
On Windows computers, rootkits use something called registry DLL injection. Rather than one massive file, the Windows operating system actually consists of multiple DLL (Dynamic Link Library) files that work together.
When you install a program on a computer running Windows, the program stores information it needs to run in a database called the registry. Each time the program runs, it checks the registry to find the location of additional DLL files it may need to use.
So registry DLL injection simply adds a Trojaned binary file of a legitimate DLL file to the computer, while leaving the original Windows DLL file alone. Then it modifies the registry so that when the program tries to use the orignal Windows DLL file, it’s redirected to the Trojaned binary version instead.
Since the original DLL file was untouched, any file integrity checker will conclude that nothing is awry, hence no rootkit is present. Unless a system administrator discovers the existence of the Trojaned binary DLL files or the altered registry that points to a Trojaned DLL file, the hacker can have his way with the computer.
In the world of Unix/Linux, the most common commands that hackers try to alter include:
| Looks for groups of files |
| Lists the contents of the current directory |
| Shows the network status, including information about ports |
| Displays the current processes that are running |
| Displays the names of all the users currently logged on |
| Prints system usage, currently logged-in users, and what each user is doing |
Hackers simply substitute the computer’s current programs (also called binaries) with their own hacked or Trojaned versions. Then, if an unsuspecting system administrator uses these hacked programs, the commands may appear to work normally but they secretly hide the hacker’s activities from view. This buys the hacker extra time to cause damage or open additional backdoors so he can return at a later time.
Of course, when a hacker replaces the original programs or binaries with his own deceptive versions, he risks giving away his presence in another way. The problem occurs because every file contains two unique properties: a creation date and time, and a file size. If a system administrator notices that a program’s creation date was yesterday, which is a sure sign that the program has been altered, she is likely to know that a hacker has infiltrated the system.
To protect their files from alterations, system administrators use file integrity programs that calculate a number, called a checksum, based on the file’s size. The moment someone changes a file’s size, even by a small amount, the checksum changes.
To avoid detection, a skilled hacker may run the file integrity checker program and recalculate new checksums for all the files, including the modified ones. If the system administrator didn’t keep track of the old checksum values, the file integrity checker won’t notice any differences.
With a little bit of tweaking, hackers can make their altered versions the exact same size as the files they’re replacing. If they also change the date and time of this altered file to match that of the real file, checksum comparisons won’t detect the substitution.
For a file integrity checker to be effective, the system administrator must run the check right after setting up a computer. The longer the system administrator waits to do this, the more opportunity a hacker has to change files.
Even more importantly, system administrators need to calculate a cryptographic checksum using an algorithm such as MD5 (Message Digest algorithm 5) or SHA-1 (Secure Hashing Algorithm). Unlike ordinary checksums, a cryptographic checksum can be difficult to fake, which means that hackers can’t modify checksum values.
Hackers can, of course, crack the encryption and peek inside any files encrypted with MD5 or SHA-1. Even more revealing is a paper by security researcher Dan Kaminsky (www.doxpara.com/md5_someday.pdf) that explains how to use a tool called StripWire to create a file with identical checksums but different content, which can be used to fool file integrity checkers.
To learn more about the various file integrity programs that system administrators use, visit Samhain (www.la-samhna.de), TripWire (www.tripwiresecurity.com), GFI LANguard (www.gfi.com), or AIDE (Advanced Intrusion Detection Environment)—http://sourceforge.net/projects/aide.
Hooking program calls
Every program needs a way to communicate with the operating system in order to perform commands such as saving data or sending data to the printer. So operating systems provide a library of functions (called the application programming interface or API) that all programs can use to send commands. To help programmers create and debug their applications, special functions monitor what the operating system is doing at any given time, for example, receiving data from the keyboard or a modem.
Functions that allow another program to peek at the inner workings of an operating system are known as hooks. Hooks can be handy for writing diagnostic or troubleshooting utilities, but they can also be used by rootkits to subvert the operating system. This is known as hooking. Keystroke logging programs (see Chapter 9) work by hooking into the operating system to intercept keystrokes and record them before sending them on their way to their intended destination, as shown in Figure 10-2. Keystroke loggers also hook into the operating system to avoid being detected as running or even existing anywhere in memory or the hard disk.
Rootkits use the same principles to mask their presence on a computer. When a program tries to list all currently running applications, the rootkit hooks into the operating system, intercepts the function call, and substitutes another one that reports all currently running applications except the rootkit. This is like having the mailman deliver a substituted letter in place of what the sender put in the mailbox originally. Neither the sender nor the recipient will ever know the difference.
Rootkits can use local or global hooks. A local hook intercepts function calls from a specific program, such as an email program. Global hooks intercept function calls from any currently running program.
To guard against rootkit infection, there are programs to monitor and protect the operating system, such as Anti Hook (www.infoprocess.com.au) or Process Guard (www.diamondcs.com.au/processguard), shown in Figure 10-3. (Of course, there’s always a chance a rootkit infected your computer before you could install one of these operating system monitoring programs, which means the rootkit could just feed these monitoring programs false information . . . )
For even greater security, Novell offers an open-source program called AppArmor (http://en.opensuse.org/Apparmor), which lets you configure what every part of your Linux operating system can and cannot do. By forcing the operating system to behave in specific ways, administrators can prevent hackers from tricking the operating system into doing something it’s not supposed to do.
Loadable kernel module (LKM) rootkits
The simplest way a system administrator can defeat an altered or Trojaned program is by storing unaltered copies of the programs that hackers commonly try to modify and recopying them back onto the computer. Using clean copies of various monitoring programs, a system administrator can hunt around the computer and find new traces of the hacker that his Trojaned versions hid from sight.
To get around this problem, hackers have started exploiting loadable kernel modules (LKMs), commonly found in Unix based systems such as Linux. In the old days, if you wanted to add a feature to Linux, you had to modify and recompile the entire source code for the operating system. LKMs eliminate this requirement by letting you attach new commands to the Linux kernel (the heart of the operating system) without recompiling the source code, which is where errors can occur. If you modify code as an LKM, the Linux kernel can still load and your entire operating system won’t crash, even if the code in your LKM fails.
So rather than replace existing programs and risk detection, LKM rootkits simply load their own programs into memory so that, if a system administrator checks the file integrity of the various monitoring tools, they look untouched (because they are). But if he tries to run these seemingly untouched programs, the hacker’s LKM module intercepts the command and runs its own, which masks the hacker’s presence. Some popular LKM rootkits sport odd names like SuckIT, Knark, Rial, Adore, and Tuxkit.
Opening a Backdoor
The most common way to open a backdoor in a computer is by opening a port, usually one of the more obscure ports that is unlikely to already be in use (unless another hacker has gotten there first). If the hacker took the time to insert Trojan versions of monitoring programs before connecting to the computer, those programs will ignore the open port (reporting it as still being closed) along with any activity coming from this backdoor.
Since a system administrator might still discover this open port during a routine scan of her system, hackers can create special “open sesame” backdoors that remain shut until the hacker transmits a certain command to the computer. When the computer receives this seemingly innocuous command, the backdoor opens a port and the hacker slides right through.
Sniffing for More Passwords
Another component of a rootkit is a sniffer, which the hacker can plant on a system to snare passwords, credit card numbers, or other valuable information transmitted across a network. A sniffer offers more flexibility than a keystroke logger, since a hacker only needs to install it on one computer and then set that computer’s network interface card (NIC) to promiscuous mode. Normally, each computer on the network only peeks at traffic specifically addressed to it, but when set in promiscuous mode, the computer peeks at any data passing through.
To defeat network sniffers, some administrators create switched networks. In a non-switched network, data gets passed from one computer to another and each computer checks to see if it’s supposed to receive that data. In a switched network, one computer sends data to a switch, which then routes that data to the computer that’s supposed to receive it.
To defeat switched networks, hackers may also use a technique called arp spoofing, which tricks computers into sending their data to a hijacked computer instead of the switch. The hijacked computer, controlled by the hacker, mimics the switch, but can now peek at all data on the network.
Once the sniffer retrieves one or more valid passwords, the hacker can use them to hijack a legitimate user’s account and enter the system any time he wants. As a seemingly legitimate user, a hacker can leisurely browse a computer to better understand the software being used and the configuration of the network.
If the sniffer happens to snare the password of a system administrator, the hacker will gain root access, allowing him to create additional accounts, even accounts with system administrator privileges, for accessing the computer later.
To learn more about the capabilities of sniffers, visit WinDump (www.winpcap.org/windump), Ethereal (www.ethereal.com), Sniffer (www.networkgeneral.com), EtherPeek (www.wildpackets.com), Analyzer (http://analyzer.polito.it), tcpdump (www.tcpdump.org), or Sniffit (www.tengu.be).
Sniffers do have legitimate uses for analyzing and fixing a network, but few people want a total stranger running a sniffer on their network. Rather than check to see if a computer’s NIC card may be running in promiscuous mode, system administrators can run a variety of tools to help them find any rogue sniffers running on their network.
To find out if someone has installed a sniffer on your network without your knowledge, download one of the following programs: AntiSniff (http://packetstormsecurity.nl/sniffers/antisniff), PromiscDetect (http://ntsecurity.nu), PromiScan (www.securityfriday.com), or The Sentinel Project (www.packetfactory.net/Projects/sentinel).
Killing Rootkits
It may be impossible to keep a computer hacker-free. A system administrator may diligently wipe out all rootkits and shut down all backdoors, but there’s still no guarantee that there still isn’t something the system administrator may have missed. The only sure way to remove hackers from a computer is by erasing and reinstalling everything from scratch, but this is a drastic, time-consuming, and likely only temporarily successful measure.
Despite their best efforts, system administrators can’t be perfect, and hackers only need one lucky break to slip into a computer undetected. However, dedicated rootkit detectors help tilt the balance in favor of the system administrators by scanning a computer for signs that betray the existence of a rootkit. Microsoft has developed its own rootkit detector, dubbed Strider GhostBuster (http://research.microsoft.com/rootkit). F-Secure has developed a similar rootkit detector called BlackLight (www.f-secure.com/blacklight), shown in Figure 10-4. For a list of various tools to help detect rootkits, visit the home page of security researcher Joanna Rutkowska (www.invisiblethings.org), the Dutch rootkit.nl site (www.rootkit.nl), chkrootkit (www.chkrootkit.org), or SysInternals (www.sysinternals.com) to grab a copy of RootkitRevealer.
If you happen to be able to read Chinese, try downloading the highly-regarded Chinese rootkit detector called IceSword (http://xfocus.net/tools/200505/1032.html), which has gotten rave reviews even from rootkit creators.
System administrators should also run a scanner to detect any open ports—a sign of sloppy administration or a backdoor left behind by a hacker.
And, when first setting up a computer, any system administrator should create cryptographic checksums of all the important files and store these checksums in a separate location, such as on a CD that can only be written to one time. System administrators should also save spare copies of crucial program utilities on the CD as well. Now if a hacker breaks into a computer, the system administrator can at least trust the integrity of the files stored on the CD.
Finally, system administrators need to keep up with the latest security flaws and vulnerabilities so they can patch them or watch out for hackers who may exploit them. To learn more about different rootkits, visit Rootkit (www.rootkit.com), as shown in Figure 10-5.
No matter what a system administrator does, there will always be a chance that a hacker is lurking in any given computer at any given time. Some system administrators leave hackers alone as long as the hackers leave their important data alone, but most system administrators constantly try to throw hackers off their system even while the hackers keep coming back with new techniques, new tools, and new ideas again and again and again.