Rootkit installation is the phase that divides a compromised computer from an "owned" computer. This article will focus on the development of a rootkit for the 2.6 series of the Linux Kernel. Techniques and methods of hiding the attacker actions within the system will be the primary target, along with discussing how to detect rootkits in the owned box: know your enemy, know thyself.

Knowledge about the internals of rootkits has an enormous value from different points of view; an attacker doesn't really own a system until a proper way to control the entire system has been taken care, a system administrator needs to know how they work in order to be able to evaluate if a system has been compromised.

This article will describe the most important techniques used in a real life extensible LKM rootkit called SIDE, built for the current 2.6 series of the Linux Kernel. In next articles more features will be added to the rootkit.

Hiding the module

Since the rootkit will run within the system as a kernel module, proper care has to be taken so that it's not found with commands such as lsmod or through /proc/modules. Code in listing 1 takes care of this. In order to properly understand how this works, it's important to comprehend how modules are ordered within the kernel and the theory behind this hiding technique (see the Modules frame).

Listing 1. Hiding the module

 
 
lock_kernel(); /* Held the kernel lock to prevent faulting in SMP systems */ __this_module.list.prev->next = __this_module.list.next;
__this_module.list.next->prev = __this_module.list.prev;
__this_module.list.prev = LIST_POISON1; /* A common practice in kernel development */ __this_module.list.next = LIST_POISON2; /* to invalidate a list that shouldn't be used */ unlock_kernel();

Basically, through this code the module detaches itself from the kernel's internal circular double-linked list of loaded modules.

Hiding processes

The ability to hide processes from every user in the system (including root) is one of the basic futures a rootkit should implement.

User space tools (such as ps(1) or top(1)) know about tasks (processes) reading the /proc directory. Each task running in a system creates an entry in the form /proc/<PID>, where useful information about that process can be obtained. What user space tools do is open the /proc directory and query the existence of /proc/<n>, where 1 <= n <= pid_max, if the directory does not exist that PID is assumed to be free, whereas if the directory does exist information can be gathered from it.

With this assumption in mind and the knowledge about the internals of VFS (see VFS internals frame) it's possible to make user space tools believe existent PIDs are actually free. This is done by interrupting the readdir call in the VFS layer. To accomplish this, the table that contains the address of the readdir call has to be modified with the address of the new segment of code that reimplements this function. The porpoise of interrupting readdir is so the filldir argument can be modified to point to a different implementation of filldir, which will discard those directories that identify hidden PIDs.

Listing 2. Fragment of /proc's filldir reimplementation

if (!(process = _atoi(name, &process))); 
/* If this isn't a PID just call the original filldir */ 
else if (!process_is_authed(current) && process_is_hidden(process)) 
/* If process is hidden */      return 0;                                       
 /* don't show it (unless current is superroot) */  
 if (p_proc_filldir)      
return p_proc_filldir(buf, name, nlen, off, ino, x);

Rootkit detectors

Rootkit detectors use a technique to find hidden processes that consist in sending a SIGCONT signal to all possible processes.

Signals to processes are sent through the kill(2) system call. When a signal is sent to a process that doesn't exist, kill(2) returns the -1 value and errno is set to ESRCH, while when a process does exist kill(2) returns 0.

This way, rootkit detectors realize if processes exists or not without using /proc's data. After this, the list created is compared with the list of processes that /proc shows. If a difference is found between both lists it means that a process is hidden from user space.

From the rootkit point of view, fooling the rootkit detector that relies on this technique is a simple matter of extending the code. All that is required is that the rootkit intercepts the kill(2) system call (see frame System calls) and if a signal is sent from someone else that is not the superroot user (see Superroot frame) to a process which is in hidden state the new callback function should return ESRCH, but if that's the case the original kill(2) function should be called and it's return value returned.

A d v e r t i s e m e n t