Implementing Rootkits to Identify Vulnerabilities
Total Page:16
File Type:pdf, Size:1020Kb
Implementing Rootkits to Address Operating System Vulnerabilities Manuel Corregedor and Sebastiaan Von Solms Academy of Computer Science and Software Engineering, University of Johannesburg Johannesburg, South Africa {mrcorregedor, basievs}@uj.ac.za Abstract—Statistics show that although malware detection A rootkit is a malicious program or set of programs that techniques are detecting and preventing malware, they do not tries to hide its existence on an infected computer by attacking guarantee a 100% detection and / or prevention of malware. the Operating System (OS) by using one or a combination of This is especially the case when it comes to rootkits that can the following: modifying program binaries, hooking call tables manipulate the operating system such that it can distribute other such as the System Service Descriptor Table (SSDT) and the malware, hide existing malware, steal information, hide itself, Interrupt Descriptor Table (IDT) to hijack the kernel's control disable anti-malware software etc all without the knowledge of flow, modifying legitimate code to force a call to rootkit code the user. This paper will demonstrate the steps required in order or by using DKOM (Direct Kernel Object Manipulation) [9] to create two rootkits. We will demonstrate that by [10][11][12][13]. Rootkits are designed to fundamentally implementing rootkits or any other type of malware a researcher subvert the OS kernel and are capable of obtaining and will be able to better understand the techniques and maintaining unrestricted control and access within the vulnerabilities used by an attacker. Such information could then compromised system without even being detected by anti- be useful when implementing anti-malware techniques. malware software [14]. Rootkits can also hide other malicious software or activities such as open network connections, Keywords: Rootkits; vulnerabilities; malware; security running processes and files on disk [10][11][12]. Long life time rootkits are most likely to attempt to hide [11]. I. INTRODUCTION This paper will demonstrate the steps required in order to Anyone who uses a computer for work or recreational implement two rootkits. The first rootkit can sabotage a purposes has come across one or all of the following problems Windows OS by causing it to blue screen or to generate an directly or indirectly (knowingly or not): viruses, worms, error after each reboot. The second rootkit can disable anti- trojans, rootkits and botnets. This is especially the case if the malware programs and log the keys pressed by the user. The computer is connected to the Internet. The current commercial target OS environment is Windows XP Professional 32 bit and products used by home users to detect and prevent malware are Windows 7 Professional 32-bit, we will use OS to refer to these either signature based or heuristic based [1][2][3]. two environments. The home user is the target of our rootkits. The rationale for this paper is that in order to prevent attacks The statistics in [4] show that although malware detection from rootkits a researcher must first understand how rootkits techniques are detecting and preventing malware, they do not work and what vulnerabilities they expose. Once this is done guarantee a 100% detection and / or prevention of malware. counter measures can be identified for the vulnerabilities. To The reason for not being able to achieve a 100% detection and / our knowledge no other papers exist that cover how rootkits are or prevention of malware is because malware authors make use implemented. We hope this paper will assist other security of sophisticated hiding techniques in order to prevent malware researchers in understanding how rootkits work and what from being detected by means of signature based techniques. vulnerabilities they exploit. Such information could then be Such techniques are either entirely or partially based on code useful when implementing anti-rootkit techniques. obfuscation [5][2][6]. This has resulted in the emergence of malware known as polymorphic and metamorphic malware. The remainder of this paper will be structured as follows: in Metamorphic malware makes use of code obfuscation in order section 2 we will briefly discuss the tools required to to change its code structure in such a way that very little bytes implement rootkits, sections 3, 4 and 5 will look at how to get remain that can be used as a signature [7][8]. Polymorphic into the kernel, install the rootkits and manipulate the kernel. malware encrypts its payload using different keys each time to Sections 6 and 7 will discuss our Sabotager and Evader rootkits make it undetectable. The polymorphic malware then makes and their functions after which in section 8 we will discuss the use of a decryptor to decrypt its malicious payload in order to vulnerabilities of the OS that our rootkits exploit. Sections 9 execute it. Polymorphic malware however can be identified by and 10 will discuss how the vulnerabilities can be addressed. the signature of its decryptor [7][8] which is why it makes use of metamorphic decryptors to avoid being detected. II. TOOLS Metamorphic and polymorphic malware poses serious challenges for anti-malware software specifically signature A list of the tools used to develop the rootkits discussed in based techniques, however rootkits are a more serious malware this paper can be found in the table 1. It should be noted that threat. all tools are freely available from Microsoft. The rootkits we TABLE I. DEVELOPMENT TOOLS memory which means the memory manager may write your code onto disk. This will cause a bug check if the rootkit Name Description requires the code that has been paged to disk to handle Windows Tools and documentation necessary to develop kernel interrupts, acquire spin locks, or hook system calls [15]. Driver Kit mode drivers. Another disadvantage of using this approach is that you are not Windows Tools and documentation necessary to develop user mode able to easily manage your rootkit as in the case of using SCM. SDK applications. Lastly this approach does not work in Windows Vista and later [15]. Another possible way to load a rootkit into the kernel is Sysinternals Contains useful tools such as Debug view that allows one to inject code into the kernel. Suite to view output from the kernel and other useful tools [16]. Windows Contains a set of tools you can use to debug drivers, C. Injecting Code into the Kernel Debugging applications and services. Tools Injecting code into the kernel can be done by modifying implemented are both hybrid rootkits because they consist driver code paged to disk or by leveraging an exploit in the of user mode and kernel mode components. This allows us to kernel [15]. Leveraging an exploit in the kernel can either be have access to all of the kernel's data structures and procedures done by finding a vulnerability in the kernel itself or other while still having access to the user mode Windows API. We kernel mode drivers. Both techniques have the advantage that also make use of a user mode component to communicate with the rootkit can be loaded without any traces being visible in the the kernel mode component. The rootkits are implemented as registry. The disadvantages are that you will not be able to kernel-mode drivers. A kernel-mode driver is a loadable easily manage the rootkit and the vulnerability you relying on kernel-mode module that is intended to act as middleware could be patched. The next section will discuss what method between the hardware and the OS's I/O manager [15]. It we chose to install our rootkits. communicates with the I/O Manager by making use of I/O request packets (IRPs). The IRPs are created by the I/O D. Chosen Method Manager on behalf of a user-mode application that wants to Our implementation which is targeted at the average home communicate with the kernel-mode driver. There are three user our rootkits make programmatic use of the Service ways to get the rootkits into the kernel [15], we will discuss Control Manager. We also gave the service the misleading each in the next section. description of "SDDL subsystem for Windows USB Resource – Microsoft(C)" this coupled with our driver name msusb.sys III. GETTING INTO THE KERNEL would be in our opinion enough to mislead an average home user should they (although very unlikely) discover our rootkit. The first possible way of getting into the kernel is to use the It is also important to decide where you going to store the Service Control Manager (SCM). actual rootkit file. Although the file can be stored anywhere it should be stored in %windir%\system32\Drivers directory in A. Using The SCM order reduce possible suspicion as this is the directory where This is the easiest and most supported way to load a rootkit. the majority of driver files are stored. The rootkit is registered in the SCM database and as such Once you have decided on what method you will use to get allows you to use the SCM to manage your rootkit by allowing your rootkit into the kernel the next step is to decide how your you to start, stop, restart, load, unload or delete the rootkit. rootkit will be installed and executed. You can also specify when you want your rootkit to be loaded i.e. on demand, auto (load when computer restarts), boot (load by system boot loader), system (load during kernel IV. INSTALLING THE ROOTKIT initialization) or disabled [17]. Using the SCM to load the We packaged our rootkits as an installer for a popular first rootkit is also the most easily detectable by an administrator as person shooter game. The installation displays a fake installer it leaves a lot of evidence in the registry as well as showing the window which remains open while the installation is taking rootkit as a running service on the system.