What if the very code of the operating system itself came under the control of the at- tacker? The idea of doing just that came of age on UNIX platforms where compiling the kernel is sometimes a weekly occurrence for those on the cutting edge. Naturally, soft- ware suites that substituted Trojans for commonly used operating system binaries as- sumed the name rootkits since they typically required compromise of the UNIX root account on the target machine. Chapter 8 discusses UNIX rootkits, and Chapter 14 dis- cusses rootkits in general.
] The NT/2000 Rootkit
Popularity: 5
Simplicity: 7
Impact: 10
Risk Rating: 7
Not to be outdone, Windows NT/2000 acquired its own rootkit in 1999, courtesy of Greg Hoglund’s team at http://www.rootkit.com. Greg has kept the Windows commu- nity on its toes by demonstrating a working prototype of a Windows rootkit that can per- form Registry key hiding and EXE redirection, which can be used to Trojan executable
files without altering their content. All of the tricks performed by the rootkit are based upon the technique of “function hooking.” By actually patching the NT kernel such that system calls can be usurped, the rootkit can hide a process, Registry key, or file, or it can redirect calls to Trojan functions. The result is even more insidious than a Trojan-style rootkit—the user can never be sure of the integrity of the code being executed.
The NT/2000 rootkit was still in alpha release at the time of this writing and was pri- marily targeted at demonstrating key features rather than all-out subterfuge. The distri- bution consists of two files: _root_.sys and deploy.exe. Launching deploy.exe installs and starts the rootkit.
Once deployed, Registry hiding is in effect: any value or key that begins with the six letters “_root_” should be hidden from view using either regedit.exe or regedt32.exe.
Any executable that begins with “_root_” will be exempt from subterfuge—that is, a copy of regedit.exe renamed “_root_regedit.exe” will be able to see all of the hidden keys. This provides a neat little back door for attackers to survey their handiwork without turning off the rootkit’s cloak of invisibility.
EXE redirection in the alpha release will detect the execution of the filename that starts with “_root_” and redirect it to “C:\calc.exe” (this is hard-coded in the alpha re- lease and thus won’t prove of immediate value to intruders, but the wickedness of EXE redirection should be evident by now).
Greg also distributes a remote rootkit management console called RogueX that has a pretty slick interface. It is still under development and has limited functionality (it can spawn port scans from the remote rootkitted system).
U Rootkit Countermeasures
When you can’t even trust thedircommand, it’s time to throw in the towel: back up criti- cal data (not binaries!), wipe everything clean, and reinstall from trusted sources. Don’t rely on backups, as you never know when the attacker gained control of the system—you could be restoring the same Trojaned software.
It is important to emphasize at this point one of the golden rules of security and disas- ter recovery: known states and repeatability. Production systems often need to be rede- ployed rapidly, so a well-documented and highly automated installation procedure is a lifesaver. The ready availability to trusted restoration media is also important—burning a CD-ROM image of a web server, completely configured, is a huge timesaver. Another good thing to script is configuring production mode versus staging mode—during the process of building a system or during maintenance, security compromises may have to be made (enabling file sharing, and so on). Make sure there is a checklist or automated script for the return to production mode.
Code checksumming is another good defense against tactics like rootkits, but there has to be a pristine original state (that is, this is apreventativedefense and does no good af- ter the fact). Tools like the freeware MD5sum can fingerprint files and note integrity vio- lations when changes occur. A Windows binary of MD5sum is available within the
Cygwin environment from http://sourceware.cygnus.com/cygwin/. MD5sum can compute or verify the 128-bitmessage digestof a file using the popular MD5 algorithm written by Ron Rivest of the MIT Laboratory for Computer Science and RSA Security. It is described in RFC 1321. The following example shows MD5sum at work generating a checksum for a file and then verifying it:
D:\Toolbox>md5sum d:\test.txt > d:\test.md5 D:\Toolbox>cat d:\test.md5
efd3907b04b037774d831596f2c1b14a d:\\test.txt D:\Toolbox>md5sum --check d:\test.md5
d:\\test.txt: OK
MD5sum only works one file at a time, unfortunately (scripting can allay some of the pain here, of course).
More robust tools for file-system intrusion detection include the venerable Tripwire, which is available at http://www.tripwire.com. It performs a similar checksumming function on a systemwide basis.
Executable redirection performed by the NT/2000 rootkit theoretically can defeat checksumming coun- termeasures, however, since the code in question isn’t altered but rather hooked and channeled through another executable.
A couple of indispensable utilities for examining the contents of binary files deserve mention here. They include the venerable UNIXstringsutility ported to Windows (also available from Cygnus), BinText for Windows from Robin Keir at http://www.keir.net, and the great text/hex editor UltraEdit32 for Windows from http://www.ultraedit.com.
We like to put BinText in the Send To folder so that it pops up when right-clicking files in the Windows Explorer; UltraEdit inserts its own custom menu entry for this.
Finally, with regard to this specific alpha release of Greg’s NT/2000 rootkit, the pres- ence of the files deploy.exe and _root_.sys are sure indicators of treachery (or at least a cu- rious system owner). Fortunately, starting and stopping the rootkit can be performed using the net command:
net start _root_
net stop _root_
Windows 2000 introduces Windows File Protection (WFP), which protects system files that were in- stalled by the Windows 2000 setup program from being overwritten (this includes roughly 600 files un- der %systemroot%). Recent posts to NTBugtraq suggest that WFP can be circumvented, however, especially if Administrator privilege is already compromised.