Root kits are components or sets of components that allow a hacker to obtain and maintain root access in a computer system. In the UNIX world, root is the name commonly used for the user who has all rights or permissions in all modes, in other words, administrator or superuser access. Hence, a root kit is a toolkit that provides root-level access to a system. Not only does a root kit provide this access, it generally has the ability to cloak its very existence on the infected host. In short, a root kit can give a hacker “god” privileges on a system and hide itself from the real sysadmin. Pretty scary stuff…if it's real.

The history of root kits is interesting. They have been around for UNIX systems since the late '80s. Windows systems have been pretty well ignored until recently. That timeline probably is counterintuitive for most of us. We have come to expect Windows operating systems to be the target of more cracks and hacks than any others. Have root kits been ignored on Microsoft OSs because they are so vulnerable to attack that root kits are not necessary? Or was it simply because in the beginning (of the Internet, that is) most servers were running some variety of UNIX and were thus the obvious target? Or could it have been some 25 years ago most potential hackers knew their way around UNIX systems really well and MSDOS was being used only on stand-alone desktop PCs? Probably a combination of all the above. By the time Microsoft Internet server systems gained popularity with NT4, it was easy enough to find exploits that did not require sophisticated tools such as root kits.

Not Cracks but Hacks

Let's get one thing straight about root kits. They are not tools to gain access to a server or system. They do not exploit the well-publicized vulnerabilities we read about day in and out. A root kit is installed on a system after a user already has gained access to the machine. Did you notice I said user–not unauthorized user or hacker or evil person? The reason I said user is because I know you already have your systems so locked down unauthorized access from outside your organization would be impossible. You have applied every known service pack; your firewall is rock solid; you laugh at the mention of buffer overflows. No sniveling script kiddie is going to compromise your server farm. Maybe, maybe not. But we all know the biggest security risk in any organization is from within. Disgruntled employees are a force to be reckoned with. And you have no disgruntled employees?

I was speaking with a friend whose spouse works for a Fortune 100 company. This well-admired firm recently reduced the amount of flexible dollars allowed employees for their healthcare as well as decreasing the corporate contribution. It also decreased the corporate 401K match. I am not arguing with those policies, in fact, I even might come down on the side of management. Employee benefit and pension packages have brought down most rust-belt industries. But I am fairly certain–in fact, I have it from a reliable source–there are many thousands of disgruntled employees at that firm right now. Human nature being what it is, it is not outside of the realm of possibility such a person would load up a root kit on a server.

Most, if not all, viruses are detectable by AV software. They have “signatures”–they make modifications to the registry–and they install themselves as macros or executables that can be detected. A new file named iamavirus.exe can be tracked down and deleted. A system administrator can run “ls” (UNIX) or “dir” (MSDOS), compare the results to a correct system manifest, and determine the presence of an unwanted file. What root kits provide is a new corrupted “ls” that is designed to hide the presence of iamahiding.exe. That describes the state of root kits for most of their existence–replace system files or procedures with newly corrupted or hacked files. This “malware” appears to function just like the original file, only it has special features that either cover other malicious files or zap log files or hide network activity or mask a thousand other signs that would lead an administrator to suspect something is amiss. Take the netstat command: It displays active TCP connections, ports on which the computer is listening, Ethernet statistics, the IP routing table. A hacked netstat may show all active TCP connections except the one the root kit is using for a backdoor.

Good Malware

A good set of malware will install itself using the same date-time stamp as the original files. It will adjust file size to be the same as the original. It will monitor and adjust log files so no record of installation exists. It will hide from network monitoring tools by hiding a port or piggybacking on a legitimate TCP connection. Really good root kits will be detectable only by comparing CRC (cyclic redundancy check) hashes with known good components. A CRC is a type of hash function that produces a checksum from a block of data–in this case a file. A hash function is used to identify data. All hash functions return different results with different inputs. So, if we run a CRC on suspect_file.exe and real_file.exe
and the results are different, we know suspect_file.exe is not identical to real_file.exe and thus is suspect.

Of course, there are other ways to detect these things. A check of processes active in memory easily can flag unknown activity. Changes in drive space may signal a problem. Unusual processor activity may be a sign. If you have the time and energy to sit on a server 24/7, you probably can be so familiar with what is supposed to be happening on that box any change will be noticed. Or will it?

Really Good Malware

What if this stuff is really good? We only know about root kits and other malware because they have been detected. What about the really good stuff that has yet to be detected–code so good it even can spoof a CRC? Is it possible there exists an entire code base of malicious code that has been around so long it is accepted as the real McCoy? I don't know. What was the umbrella man up to? Was there a second or third shooter? Was Monica really a KGB operative? I am not a big fan of conspiracy theories, but it just might be possible. If an Easter Egg can be hidden in code, then I see no reason exploitive code can't be buried in an executable. And who is buried in Elvis's coffin?

The stuff we have been talking about so far operates on a user or application level, commonly known as user mode. User mode first refers to a level of rights at the CPU or processor level. User mode is a nonprivileged state where the code is forbidden from performing certain low-level system functions, for example, writing to memory that it has not been assigned or interacting directly with a hardware device. The root kits we have been discussing so far are executables and scripts and procedures that operate on a system with the same rights “normal” software does. And those rights are enough to do a lot of damage. Malicious software at the user level can open secret backdoors, it can log keystrokes, it can alter log files–in short, it can perform just about any kind of nastiness you can.

Open Source

I know the arguments about open source. If the source is there for examination, then it is theoretically more difficult to slip malicious code into the mix. That makes sense for public distributions of open source code. But what about the Linux build that has been customized for my organization? How many developers do you have with the time and skills necessary to step through hundreds of thousand of lines of code to ensure Mr. Still_Angry_About_My_401K didn't drop in a nice little backdoor? Most developers have enough attitude they are not above leaving a little personal code in some favorite modules.

The latest, greatest, and potentially most dangerous new players in the root-kit world operate at the kernel level. Kernel level = Operating system level, which spells trouble. Intel (x86) processor architectures have four privilege levels called rings. Ring 0 is kernel mode. Ring 3 is user mode. Ring 2 is a bad 2005 movie that is the sequel to the very successful and scary 2002 movie named The Ring. Actually, Ring 1 and Ring 2 modes rarely are used. Note these are CPU privilege levels–a superuser or administrator at the operating system level still is operating at user mode or Ring 3 at the processor level.

So, back to the scary part. As I said, the latest generation root kits–both UNIX and Windows version–operate in the kernel mode, meaning they have the same access rights to the CPU as the operating system kernel files. They are masquerading as kernel files, either as replacements for those files or as loadable kernel modules (LKMs), which are object files that extend the running kernel or base kernel. They function only if the base kernel has been compiled to allow the use of dynamic module, but since this is generally accepted practice, disallowing dynamic modules may affect desired operating system performance. Operating in kernel mode, malware now has the ability to make system calls directly and thus manipulate the kernel and the machine. Once you have lost control of the OS kernel, you have lost control of everything. In fact, it is worse than that. Even the suspicion a system has been compromised by a root kit makes the system questionable. And in my world, a questionable system is a worthless system.

So, What Does That Mean?

That means if you detect any root-kit compromise, whether it is old-school replace-system-instruction stuff or down- home kernel mode stuff, you need to rebuild. Simply replacing suspect files leaves you with no guarantee other files are not corrupt. And this then becomes the real problem with root kits. Chances are, you already have sophisticated enough systems in place to find these things before they do any harm. But once you find them, you can't ignore them. At least I don't think you should ignore them. The cost of rebuilding a server is not trivial. Then you will need to examine all other boxes on the network to make certain they haven't been compromised. This stuff is serious business. If you catch a macro or script virus on a server, you can clean the box (and fire the admin). Once you find a root kit, particularly kernel-level stuff, you are in deep trouble.

There are a few useful tools out there for detecting root-kit intrusions. Tripwire (http://www.tripwire.com/) monitors UNIX file systems and uses digital signatures to check for any changes. Microsoft has a tool named “Strider Ghostbuster” (http://research.microsoft.com/root kit/) that compares suspect OS files to known clean files. You even can boot a Windows PE CD, then do a comparison of the running OS with the files on the suspect machine. Old UNIX-based root kits can be detected by using known clean tools to run simple procedures such as ls on suspect machines. Better tools are needed–root kits largely have been ignored outside of the hacker communities–probably because it has been so easy to compromise Windows machines using known exploits. As Microsoft tightens down its operating systems, look for new and more sophisticated malware, particularly kernel mode root kits.

Depending on your level of paranoia, root kits are everywhere or nowhere. My guess is they are not all that prevalent, particularly on Windows systems. I also guess their use will become more widespread as terrorist groups and Internet gangsters become savvier–and find more disgruntled ex-employees to hire. Besides, writing kernel mode code is a lot more fun than writing user mode code. Any day.