Challenge 2: General Windows Security

Malware is a broad category of malicious software intended to intercept or take partial control of a computer's operation without the user's informed consent. In many cases, the software surreptitiously monitors the user and subverts the computer's operation for the benefit of a third party. A rootkit is a general description of a set of programs which work to subvert control of an operating system from its legitimate operators. Often, a rootkit will obscure its installation and attempt to prevent its removal through a subversion of standard system security. Rootkits differ from viruses and worms in that they do not usually self-replicate.

Challenge 2 aims to show you how rootkits generally work and to raise awareness about this threat. If you are investigating a computer break-in, always keep in mind that a good attacker will probably have installed a rootkit. As a result, you cannot trust any output that the computer gives you.

Your task is to write a rootkit that runs under Windows XP and hides certain directories from a user who is calling the dir command (in a command shell). That is, your rootkit should hide from the user (that is, not display) all directories that begin with the string _inetsec_ in their names. For example, without your rootkit, calling dir in a directory called HackMeIfYouCan could deliver a listing such as this:

C:\HackMeIfYouCan>dir
 Volume in drive C has no label.
 Volume Serial Number is 0C97-763F

 Directory of C:\HackMeIfYouCan

30.10.2007  13:55    <DIR>      .
30.10.2007  13:55    <DIR>          ..
30.10.2007  13:55    <DIR>          directory
30.10.2007  13:55    <DIR>          harmless
30.10.2007  13:51    <DIR>          _inetsec_
               0 File(s)              0 bytes
               5 Dir(s)   5.767.086.080 bytes free

C:\HackMeIfYouCan>dir _inetsec_
 Volume in drive C has no label.
 Volume Serial Number is 0C97-763F

 Directory of C:\HackMeIfYouCan\_inetsec_

30.10.2007  13:51    <DIR>          .
30.10.2007  13:51    <DIR>          ..
30.10.2007  13:51                 9 attackfile.txt
               1 File(s)              9 bytes
               2 Dir(s)   5.767.086.080 bytes free
    

However, after your rootkit is installed, calling dir would yield the following output:

C:\HackMeIfYouCan>dir
 Volume in drive C has no label.
 Volume Serial Number is 0C97-763F

 Directory of C:\HackMeIfYouCan

30.10.2007  13:55    <DIR>      .
30.10.2007  13:55    <DIR>          ..
30.10.2007  13:55    <DIR>          directory
30.10.2007  13:55    <DIR>          harmless
               0 File(s)              0 bytes
               5 Dir(s)   5.767.086.080 bytes free
    

As you can clearly see, the directory _inetsec_ is successfully filtered and thus, hidden from the user. Interestingly, the behavior we are seeing here is very similar to what the Sony BMG copy protection mechanism did to hide certain directories from users. Hence, you can imagine the resulting negative excitement and discussions, and why some people found this to be an unacceptable, rootkit-like behavior for benign software.

Your rootkit is supposed to be written as a device driver that is loaded by Windows. On load, the device driver (which is running in the context of the OS) has to gain control of the system call that is responsible for getting the directory listings. Under Windows, this system call is called ZwQueryDirectoryFile.

To get control of a system call, the straightforward way is to hook the Windows system call table (called System Service Dispatch Table - SSDT). Hooking the system call table means that the rootkit replaces the address of the actual system call handler function with the address of one of its own functions. This function is now invoked whenever a program requests the directory listing from the Windows OS. Of course, you want to return some useful results, so the usual way is to call the original system call handler function from your own code first. Then, you can filter the results appropriately. Also, make sure that your rootkit cleans up nicely when unloaded. That is, when the device driver is unloaded, all directories should show up as before the rootkit was loaded, and the OS should survive the unloading of your code.

To write a Windows device driver, you are required to use the Microsoft Windows Driver Development Toolkit (DDK). The DDK is now part of the Windows Driver Kit (WDK), which you can download here (by following the link to the Microsoft Download Center). This toolkit is a freely available consolidated driver development kit that provides a build environment, tools, driver samples, and documentation to support driver development for the Windows family of operating systems. Once installed, you will want to select the build environment (either checked or free) for Windows XP.

You are required to develop your rootkit for Windows XP (SP2 and SP3 should both work fine). Why are we specifying a development environment for you? This is because your submission will be automatically tested and graded. It is therefore important to follow the directions given here exactly.

Please follow these (simple) steps carefully:

1. Make sure that you have Windows XP, which is needed to install the Windows WDK (and DDK) as well as to develop this challenge. If you do not have Windows XP, you can get it through the CS department, courtesy of the Microsoft Software Developer Network - Academic Alliance. Please send mail to support@cs when you do not have an account that let's you access the software.
2. Download the MyRootkit.zip MS DDK project that we have created for you.
3. Uncompress the file in any directory of your choice (preferably in one without spaces in its path name; otherwise, the build might break later).
4. Develop your rootkit by writing your code into the template file MyRootkit.c. This file and the makefile in the package provide a basic driver (a rootkit in this case) that you should use as a starting point. Put all of your code into the MyRootkit.c file, and make sure that you do not modify the build files (since they are what our grading system will use).
5. Since it is possible that your development crashes the OS, make use of a virtual machine (that can store snapshots and allows you to quickly recover from a blue screen of death). For example, you can get a free version of VMware Server 2 (you need to create an account before you can download the software).

• Subverting the Windows Kernel: Rootkits by Greg Hoglund and James Butler is a great book that contains very important and useful information to solve this challenge. I have put a PDF version of this book (book.pdf) into the /tmp directory on bandit. Please do not distribute this copy and only use it for solving your challenge.
• Here is a tool you can use to install your driver.
• This program is useful for reading debug messages that your kernel driver might print.
• Windows uses wide-chars (2 byte) for the strings that represent the directory names.
• All data structures and types you need are found in the MSDN online documentation. In addition, you can obtain the definitions of many relevant file-system-related structures here.
• The SSDT table is write-protected. You first need to make it writable. Check the book (Chapter 4 - Kernel Hooks) for more information.

To submit your challenge solution to us, you need to follow these steps:

1. Copy your MyRootkit.c file to your lab account.
2. In the directory where your MyRootkit.c file is located, call /usr/local/bin/submit2
3. Read any error or success messages. Then, wait a couple of minutes and read your e-mails on bandit to view the results of the automatic grading program.

This is an individual project. The project is due on Tuesday, 26.04.2011, 23:59:59 PST.