Nuclear Elephant: Creating Root-Kit Proof Saferooms

Security Papers

Creating root-kit proof saferooms
Last Update: Saturday, October 20, 2001 12:00PM
Please notify me of any corrections or suggested additions

Jonathan A. Zdziarski
jonathan@nuclearelephant.com

Table of Contents
Part I: Introduction to Saferooms

1.1 What is a root-kit?
1.2 How can I protect myself?
1.3 What is a saferoom?
1.4 Is a saferoom unbreakable?
1.5 What is entailed in creating a saferoom?

Part II: Creating a saferoom

2.1 Configuring your saferoom's disk
2.2 Populating your saferoom
2.3 Setting up your path
2.4 Locking your saferoom
2.5 Monitoring your saferoom

Part I

If you're going to allow someone to come in and hack your system, at least make them work for it.

1.1 What is a root-kit?
A root-kit is a package hackers use to manipulate the machine they've hacked to make it more difficult for a systems administrator to detect that the system has been compromised. Root kits commonly also include tools creating back-doors to allow hackers back into a system they've hacked. Many different hacker's websites contain "stock" root kits that can be downloaded. Once a system is hacked, the hacker simply builds and installs the rootkit. The rootkit overwrites several system tools such as find, netstat, ps, and etecetera. The hacked versions of these tools purposely hide the hacker's activity, so they cannot be detected by a systems administrator. What's so dangerous about this is that the systems administrator is often given no reason to suspect the system is hacked, and therefore doesn't make any additional attempts to examine the system.

1.2 How can I protect myself?
There are several tools available to detect root-kits. A web search will bring up several different available tools. Another way to protect yourself from a root-kit is by keeping track of the checksums of all your system binaries. This can be done using tools such as 'tripwire' or 'md5sum'. Both packages are available to the general public, and create "fingerprints" of each file, allowing a systems administrator to detect when a file has been changed. This is very useful in both detection of a system compromise and recovering from one later without having to reinstall the system from scratch. The scope of this article, however, is to cover a non-conventional method of protection called a saferoom.

1.3 What is a saferoom?
If you've ever installed a high-tech security system in your house, the consultant (if he's any good) will put a set of locks and possibly a reinforced door on one room in the house (commonly a bathroom). If you are broken into, you are supposed to put your family in the saferoom until the proper authorities arrive. The saferoom protects your family from physical harm by denying the burglar access to them.

A saferoom, in security terms, is an impenetrable "room" on your system containing the critical tools necessary for your systems administrators to perform necessary fuctions. Saferooms are commonly placed in front of any other conventional path in the system administrator's .login or .profile, and are the tools used to carry out day-to-day operations. A saferoom, used effectively, will provide systems administrators with a separate set of tools for detecting compromises, and help insure their ability to perform tracing functions if they do get compromised.

1.4 Is a saferoom unbreakable?
That depends on the kind of saferoom you create. If you are successful in creating a saferoom that cannot be written to, even as root, you still have to take into concern the ability of a hacker to go and change your path or dismount the room altogether. The good news is that hackers are not "looking" for saferooms. When a hacker breaks into your system, they realize they have a very limited amount of time to secure their access and therefore many just install an out-of-the-box rootkit. In order for a hacker to disable a saferoom, they first have to know its there, and then the risk of dismounting a saferoom provides enough risk of detection for most hackers to become dumbfounded and make mistakes leading to their detection.

1.5 What is entailed in creating a saferoom?
There are two kinds of saferooms: physical saferooms, logical saferooms. The ideal saferoom consists of a separate disk that is physically write protected by setting a write-protect jumper. Due to cost issues, however, some people choose to simply create a hidden directory on a writable partition (a logical saferoom). Doing this makes it very easy to disable the saferoom, but is still effective as psychologically the average hacker is not going to be looking for a hidden directory. It does have some advantages, also, in that the saferoom will not show up by examining the system's mountpoints. The hacker will have to search the entire system for system binaries, or find the system adminsitrator accounts on the system and examine their .login or .profile files to be able to detect a hidden-directory saferoom. Assuming they do find it, they still have to worry about detection concerns. If I'm logged in using my saferoom in my path and someone deletes the saferoom, I'll get "file not found" errors suddenly. There are many other considerations as well. A good system administrator could write a cron job to monitor the saferoom and send an email out if the saferoom changed, or disappeared. All of these different non-conventional system protections will take a hacker by surprise, and significantly increase the risk that they'll be detected.

If you really want to insure the security of your systems, we recommend two saferooms (one of each type). If a hacker does look for a saferoom and disables one, there's a very slim chance they're going to look for a second one. And if they do, the amount of activity it would take to hunt down and terminate two saferooms poses a huge detection risk.

The basic steps to creating a saferoom are:

Preparing a disk (or directory) to act as a saferoom
Populating the saferoom with critical binaries
Adding the saferooms to the SA's paths, or the default path
Locking the saferoom

2.1 Configuring your saferoom's disk
If you are creating a physical saferoom, you'll need to find a disk that has a read-only jumper. These are fairly common. Since a saferoom will be particularly small (unless you want to get elaborate), the smaller the disk the better. Once you have located and attached the disk in read/write mode, decide on a mountpoint (try not to be too obvious) and then you're ready to move onto populating the room. If you are creating a logical saferoom, find a place to create a directory for the room. Many people use a populated directory such as /usr/local/lib/perl5 or /usr/include/sys. Wherever you create it, try not to be too obvious in the filename (e.g. "saferoom" is a bad choice for a filename).

2.2 Populating your saferoom
Once you've created your initial saferoom, you'll want to create a bin directory inside and start copying critical files. Some of the files you'll want to get are:

top

Any other tools your sysadmins commonly use to work with other users should be copied into this bin as well. Once you've copied them over, the next thing you should do is copy over any dynamic libraries these tools use. In the event that a hacker puts in tainted libraries, you'll want to be using the originals. Create a lib/ directory in your safehouse, then do an 'ldd' on all of the binaries you copied over. For example:

ldd /mysaferoom/bin/* | awk '{print $3}'|sort|uniq

Should produce useful output. Copy all the libs listed into your saferoom library directory.

2.3 Setting up your path
Once you've got your saferoom created, you'll want to make the tools and libraries the default tools and libraries used by your systems administrators. What good is a saferoom if you're still using the original tools, and a hacker hacks you? You'll never detect that you've been hacked if you don't use the new tools. Some sysadmins prefer to set the library path up but not the tools path. This makes it harder for a hacker to detect a saferoom since it's not in the user's .login or .profile, but forces systems admins to use direct paths. Whatever floats your boat, you'll need to make that library directory come before /usr/lib. Some operating systems have an ld.so.conf which can be modified to include the library path while others prefer to set the correct environment variables to do so. The LD_LIBRARY_PATH environment variable is commonly used for this purpose, although some systems administrators have chosen to change the path for the entire system. Consult your operating system documentation to find the best way to do this.

2.4 Locking your saferoom
Once you've created and tested your saferoom, you're ready to lock it. If you have a physical disk, set the read-only jumper. Nobody will be able to over write any of the files on a jumpered disk.

2.5 Monitoring your saferoom
Since saferooms can be disabled, it's a good idea to monitor your saferoom. Periodic checks by looking at the mountpoints, or examining the directory is a start. The best way to monitor your saferoom, however, is to write a script to check it. Generating md5 checksums on read/write saferooms, and checking the mountpoints of read-only saferooms in your script will provide a good warning if a hacker should try to dismount your room. As we said most hackers aren't even looking for a saferoom.

Reproduction prohibited without permission