Rootkits Avoiding detection Tillmann Werner wernerbonn edu Seminar

Rootkits – Avoiding detection Tillmann Werner, werner@bonn. edu Seminar Computer Security, B-IT 2006 -11 -27

Agenda Motivation and definition, short history of rootkits Entering the kernel: Hiding and starting Operating system internals: How things get executed Modern rootkit techniques Covert channels for stealth communication Countermeasures against rootkits © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 2

Motivation Hackers want to keep access to a successfully compromized box. At the same time, they want to remain undetected and thus need to hide their presence and traces. Using conventional ways to remotely access a hacked box is often much too noisy. Once a system is under control, an intruder normally wants to install his own invisible backdoor. All hacker activities and data related to those activities shall be invisible to legitimate users. Any permanent trace should be avoided, if possible. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 3

Definition „A rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer. “ Source: G. Hoglund, J. Butler: „Rootkits“, ISBN 0 -321 -29431 -9 „A rootkit is a set of software tools intended to conceal running processes, files or system data from the operating system. “ Source: Wikipedia Encyclopedia, http: //en. wikipedia. org/wiki/Rootkit © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 4

Privileged access and stealth In a nutshell: It‘s all about permanent access and stealth. Once a hacker has administrative privileges, assuring permanent access is only a matter of her creativity. User Program This presentation focusses on how to stay stealthy. Operating System Filtering I/O between two layers could conceal the presence of a rootkit. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Hardware Silde No. 5

From early rootkits… First rootkits came up in the late eighties. They were written for UNIX-like operating systems (Windows was not yet around). Early versions consisted of a bunch of modified programs that replaced the original instances on a compromized box. Typical candidates are programs that are used to examine the current system status, like ls, ps, who, netstat, etc. Also, the login program was often modified to accept login attempts for a specially crafted user. Invoked by telnet, it enabled attackers to come back at any time they wanted. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 6

… to modern rootkits The early rootkits were easily detectable: modified binaries differ in size or cryptographic hashes from the original versions. There are 1001 ways to explore the system status – one could even write own programs. Comparing their results reveals the presence of rootkit binaries. Modern rootkits step into a lower layer, the kernel. If they run in kernel mode, any userland program is under their control as well. User input to a program and its output can then already be filtered on the kernel level. Patching binaries is not necessary at all. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 7

A rootkit design example User Space Kernel Space Keyboard Sniffer Usermode Program Kernel Driver Packet Sniffer Stealth Protection Main OS Kernel Modifications TCP port for remote control © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 8

Entering the kernel: Hiding rootkit resources A common approach for hiding a rootkit is prefix-based filtering: A resource whose name matches a given prefix is considered to belong to the rootkit and is lurked to other programs. Such a prefix can be prepended to file names, directory names or program names (which are inherited by corresponding processes). A similar method allows for hiding network traffic from other processes. Relevant packets are equipped with a magic value in their payload. This simple technique enables an attacker to hide most of his activities quite successful. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 9

Entering the kernel: Starting a rootkit A common technique is to implement the rootkit as kernel module or driver that can be loaded during runtime. Modification of a present driver is also possible. The kernel code itself can be altered to start a rootkit. Both the on-disk image and the running kernel must be changed (e. g. by altering /dev/kmem on Linux). A rootkit program can also get hooked into the system to load automatically during operating system startup, e. g. by patching /sbin/init or by using. ini files. The boot loader can be modified to apply patches to the kernel just before the start phase. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 10

i 386 architecture The i 386 architecture provides four different protection domains in hierarchical order, so called „rings“. This allows for enforcing a security model on the hardware layer. 3 2 1 0 Most operating systems only use the rings 0 and 3 for compatibility reasons. Ring 0 is also known als „protected mode“ oder „kernel mode“. On modern operating systems only the kernel is allowed to enter it. Ring 3 is generally called „user mode“ and is used to execute code in an unprivileged level, i. e. with memory protection. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 11

Entering 0 So, how can a program execute privileged instructions? The operating system provides system calls to a userland process. Common examples are functions like read(), write(), or open(). System calls are not used directly. Instead, they are encapsulated in libraries that can be used in high level languages. Examples are the libc or glibc on UNIX-like systems. Some platforms, like Microsoft Windows, do not want a program to use the low-level libraries directly. They provide API functions that simplify common programming tasks, like controlling a GUI. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 12

: flow of execution : memory pointer Kernel Space User Space Program Import Address Table Operating system internals – how things get executed Interrupt Descriptor Table © Tillmann Werner, University of Bonn System Call Table Rootkits - Staying Stealth. Silde No. 13

API Function Library Function : flow of execution : memory pointer Kernel Space User Space Program Import Address Table Operating system internals – how things get executed Interrupt Descriptor Table © Tillmann Werner, University of Bonn System Call Table Rootkits - Staying Stealth. Silde No. 14

API Function Library Function : flow of execution : memory pointer Choose IH from IDT Kernel Space User Space Program Import Address Table Operating system internals – how things get executed Interrupt Descriptor Table © Tillmann Werner, University of Bonn System Call Table Rootkits - Staying Stealth. Silde No. 15

API Function Library Function Choose IH from IDT Kernel Space User Space Program Interrupt Descriptor Table © Tillmann Werner, University of Bonn Import Address Table Operating system internals – how things get executed : flow of execution : memory pointer Choose Syscall from SCT System Call Table Rootkits - Staying Stealth. Silde No. 16

API Function Library Function Choose IH from IDT Kernel Space User Space Program Interrupt Descriptor Table © Tillmann Werner, University of Bonn Import Address Table Operating system internals – how things get executed Choose Syscall from SCT : flow of execution : memory pointer System Call Table Rootkits - Staying Stealth. Silde No. 17

API Function Library Function Choose IH from IDT Kernel Space User Space Program Interrupt Descriptor Table © Tillmann Werner, University of Bonn Import Address Table Operating system internals – how things get executed Choose Syscall from SCT : flow of execution : memory pointer Return System Call Table Rootkits - Staying Stealth. Silde No. 18

User Space Program API Function Library Function Import Address Table Possible locations for intervention 1 Return Kernel Space 4 Choose IH from IDT Choose Syscall from SCT System Call 5 2 Interrupt Descriptor Table © Tillmann Werner, University of Bonn System Call Table Rootkits - Staying Stealth. 3 Silde No. 19

IAT Hooking On Windows platforms, the import address table (IAT) of a program contains pointers to API or library functions. Import Address Table 1 Program API Function A rootkit can modify the table to make a pointer reference a modified function. Rootkit Function This function at first execute hostile instructions and then eventually calls the original API function if revelation is not feared. But: Every application has ist own import address table and the rootkit has to place a DLL with its wrapper functions in the filesystem. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 20

2 Modifying System Calls Return Specially crafted system calls affect all calling programs. ? The system call could check given arguments in order to decide how to operate. Patched Syscall If a detection of the rootkit is feared, an alternative routine is executed that returns a different, harmless value. Modification of system call code requires runtime kernel patching on multiple locations. This is dangerous as one single error could crash the operating system. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 21

3 System Call Table Hooking Altering the system call table is the most common rootkit technique. Choose Syscall from SCT System Call ? System Call Table Some system calls are Rootkit Function replaced with modified versions by changing the corresponding pointers in the syscall table. A rootkit system call can behave different depending on the calling process, e. g. an open() fails if the argument is a rootkit resource. Problem: System call tables are backed up multiple times. Integrity checks could easily reveal a rootkit‘s presence. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 22

4 Altering the System Call Selector Choose Syscall from SCT Instead of altering the syscall table, use your own! The kernel must know where to find the rootkit‘s syscall table. System Call Table Rootkit System Call Table This can easily be done by changing the code of the system call chooser routine such that it consults the rootkit‘s table instead of the original one. But again, altering kernel functions during runtime would be necessary. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 23

5 Interrupt Descriptor Table Hooking The pointer to the syscall selector code in the IDT can be changed to point to a modified instance. Choose IH from IDT Syscall Selector Rootkit Syscall Selector Interrupt Descriptor Table This function basically behaves like the original syscall selector but uses a modified instance of the system call table which references certain hostile syscalls. Modification of the original system call selector is not necessary. In theory, one could even go further and use an alternative IDT. The address in the Interrupt Descriptor Table Register (IDTR) must then be set to the location of the rootkit table. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 24

… and without execution flow modification? 6 Hiding processes is also possible: Unlinking a rootkit from lists used by the kernel to manage active processes can fool tools like ps or top. Rootkit Process Files can be camouflaged by placing data in the file system‘s slack space. While this is not totally safe, studies show that chances are good for such data to survive a very long time. File System © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 25

Stealth communication: Covert channels (1) A rootkit is only of value if it allows remote access. To hide remote logins, covert channels are used. This method abuses another legitimate communication channel in order to transmit commands and their responses by manipulating certain properties. Timing channels use the relative timing of events to code information. Storage channels code information into existing data. The information transmitted via a covert channel can also be cryptographically encoded or obfuscated using steganography. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 26

Stealth communication: Covert channels (2) Information can be stored in the identification field of IP packets. DNS queries can also contain information that can be interpreted differently. The protocol does not even require a direct connection. Timing channels can be formed by representing bits by the duration of a session, the interval between two arriving packets, … Information theory teaches that the possibility of covert channels cannot be completely eliminated. However, a statistical analysis leads to detection in many cases. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 27

Countermeasures against Rootkits Mandatory access control can be implemented to reduce the danger of a system level compromize. Anti rootkits can control kernel data and the execution flow process themselves. Regular checks could detect modifications. Host-based intrusion detection and prevention systems can check system integrity by maintaining a list of cryptographic hashes for important resources. Integrity checks are only trusted when executed offline, that means from a trusted media while the suspect system is not running. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 28

The Future of Rootkits Operating systems like Windows Vista and up-to-date Linux versions make use ring -1 on modern hardware to implement virtualization. A recent area of research is the development of so-called virtual machine based rootkits. The projects Blue Pill and Sub. Virt published working proof-of-concept methods that move a running operating system into a virtual environment. This environment is controlled from the outside. Hence, it is impossible to detect the rootkit from within the compromized operating system instance. © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 29

References Greg Hoglund, James Butler, Rootkits – Subverting the Windows Kernel Addison-Wesley, 2006, ISBN 0 -321 -29431 -9 Andreas Bunten, Rootkits – Techniken und Abwehr, Proceedings of 10. DFN-CERT/PCA-Workshop, 2003, ISBN 3 -8330 -0097 -X Andrew S. Tanenbaum, Modern Operating Systems, Second Edition, Prentice Hall, 2001, ISBN 0 -13 -031358 -0 Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel, O'Reilly, 2002, ISBN 0 -596 -00213 -0 Greg Hoglund, A *REAL* NT Rootkit, patching the NT Kernel, Phrack 55 -05, 1999 Black Tie Affair, Hiding out under Unix, Phrack 25 -06, 1989 Halflife, Abuse of the Linux Kernel for Fun and Profit, Phrack 50 -05, 1997 Invisible Things, http: //invisiblethings. org Rootkit – Share your old stuff, keep your good stuff, http: //rootkit. com US Do. D, Covert Channel Analysis of Trusted Systems (Light Pink Book), Rainbow Series, 1993 Craig H. Rowland, Covert Channels in the TCP/IP protocol suite, 1997, First Monday 05/97 © Tillmann Werner, University of Bonn Rootkits - Staying Stealth. Silde No. 30