A Framework for Prototyping and Testing Data-Only Rootkit Attacks

1 A Framework for Prototyping and Testing Data-Only Rootkit Attacks Ryan Riley [email protected] Qatar University Doha, Qatar Version 1.0 This is a preprint of the paper accepted in Elsevier Computers & Security Abstract—Kernel rootkits—attacks which modify a running of 25 rootkit attacks to test with, but end up stating, “Of operating system kernel in order to hide an attacker’s presence— the 25 that we acquired, we were able to install 18 in our are significant threats. Recent advances in rootkit defense tech- virtual test infrastructure. The remainder either did not support nology will force rootkit threats to rely on only modifying kernel data structures without injecting and executing any new our test kernel version or would not install in a virtualized code; however these data-only kernel rootkit attacks are still environment.” In [2], the authors test with 16 Linux rootkits, both realistic and powerful. In this work we present DORF, a but only 12 of them overlap with [1]. In [3], the authors give framework for prototyping and testing data-only rootkit attacks. no results that involved testing with rootkit attacks. DORF is an object-oriented framework that allows researchers to As another example, in our own work involving kernel construct attacks that can be easily ported between various Linux distributions and versions. The current implementation of DORF rootkit defense [2], [4], [5], [6] we found ourselves locked in contains a group of existing and new data-only attacks, and the to an older version of Linux due to the rootkits we planned to portability of DORF is demonstrated by porting it to 6 different test with. We have a corpus of rootkits which use a variety of Linux distributions. The goal of DORF is to allow researchers attack mechanisms and techniques that we were using to test to construct repeatable experiments with little effort, which will a variety of defense techniques. Our rootkits, however, were in turn advance research into data-only attacks and defenses. designed to run against a specific version of Linux (Redhat Index Terms—Malware, Rootkits, Data Attacks, Operating 8.0) and despite multiple attempts at porting them to more Systems, Security up-to-date versions of Linux, in the end we always ended up porting our new defense technique to Redhat 8.0 instead. It I. INTRODUCTION was simply less work. Rootkits are advanced attacks designed to prevent an at- Given the state of experimentation for research into code tacker from being discovered after compromising a system. injection based rootkits, the goal of this work is to improve Over the years they have evolved from simple replacements the quality and ease of testing research into a newer class to key system binaries into complex programs capable of of attack called data-only rootkits. Advances in kernel rootkit modifying an operating system kernel on the fly. defense [2], [3] have created an environment where a rootkit Research into defense techniques against such advanced is unable to inject and execute new code, effectively stopping threats frequently involves building a defense system prototype the vast majority of rootkits. A rootkit attack which relies that is designed to protect a specific version of an operating only on the modification of kernel data structures and not the system. The sample attacks and real-world rootkits that a execution of new code is called a “data-only rootkit attack”. researcher may want to test with; however, are frequently hard For example, a code injection based rootkit would hide a coded to function on a different version of the OS. As such, process by bypassing the readdir() system call and instead in order to test the effectiveness of a research prototype, the calling a malicious version that filters process entries from researcher is frequently required to ”port” those attacks to the /proc filesystem. A data-only attack, by contrast, would operate on the same version of the OS used in the prototype. remove the target process from the linked list of all tasks These changes are rarely publicly released, and even if they located in kernel memory. were they would be unlikely to be helpful to other researchers In this work we present DORF, the Data-Only Rootkit who would likely be using a different version of the OS for Framework, an object-oriented framework designed to allow their testing. In addition, if a researcher is unable to get a for rapid prototyping and testing of data-only rootkit attacks specific attack to function, it is frequently just left out of on Linux. We demonstrate the usefulness of DORF by using testing. This methodology produces unrepeatable results that it to implement four data-only attacks. We also show the do not allow for direct comparisons between various defense portability of DORF by porting it to a total of 6 different techniques. Linux distributions/kernel versions. DORF has two primary As an example of this problem, consider the variety of goals: First, it allows researchers to focus on developing and experiments performed in research focused on code injection testing data-only attacks without being concerned with the based rootkits for Linux. In [1], the authors build a corpus layout of kernel data structures or the mechanism used to 2 access kernel memory. Second, it allows them to test new B. Modifying Static Kernel Data defense systems with a variety of data-only attacks supplied Given that Tripwire was able to detect filesystem modifi- by other researchers, without needing to re-implement those cations, attackers needed to find a way to hide themselves attacks to function against a different version of the Linux without modifying core system files. This led to the creation kernel. Instead, the researcher simply ports DORF (if a port of rootkits that modified statically allocated data structures is not already available) and then the attacks will “just work.” in the operating system kernel itself. A common attack was It is our hope that researchers will use and contribute back to to inject custom code into kernel memory and modify the DORF in order to further facilitate research into detecting and system call table to cause it to be executed. For example, preventing advanced data-only rootkit threats. a modified version of the readdir system call could be The contributions of this work are as follows: created to remove references to specific files, hence making 1) We provide a definition of data-only rootkit attacks and them invisible to any system binary that uses the system call. further sub-divide such attacks into control-flow altering The system call table would then be modified to ensure the and non-control attacks depending on how they influence malicious system call was used instead of the original. the control-flow of the kernel. These definitions can be In response to this type of threat, a number of defense used to help clarify the types of attacks and defenses approaches were created. Some systems used rootkit like needed for future work. techniques to read and verify the integrity of the system 2) We present a new data-only attack that allows for file call table. These approaches relied on an application running hiding. To our knowledge, this is the first release of such on the compromised system to be able to reliably retrieve an attack. This attack demonstrates the potential power kernel memory information; however, there was no way ensure of data-only rootkit attacks. the rootkit would not tamper with the rootkit checker. A 3) We present (and release) DORF, the Data-Only Rootkit more resilient approach involved the use of external hardware Framework. The purpose of the framework is to enable devices to grab snapshots of memory over the hardware bus researchers to quickly prototype new data-only attacks as and verify the data that way. Copilot[8], for example, uses a well as to allow them to test attacks against new defense PCI card to inspect kernel memory over the PCI-bus. Given systems they may develop. that the integrity verifier runs on separate hardware, the rootkit 4) We provide an outline for future research in the area in is unable to tamper with it. Other works, such as virtual light of recent research results, including those in this machine introspection [9], [10], take a similar approach using paper. We emphasize four main areas: better semantic virtualization. specification of kernel data structures, an investigation into the applicability of control- and data-flow integrity, C. Modifying Dynamic Kernel Data kernel design that does not assume trusted data struc- Due to the fact that static kernel data rarely changes, it is tures, and better testing of defense systems using a trivial to verify its integrity. There are a large number of kernel framework such as DORF. data structures, however, which are dynamically allocated and subject to frequent change in both location and content at runtime. For example, the kernel filesystem code allocates II. HISTORY dynamic data structures containing function pointers. The kernel networking code also allocates dynamic data structures In this section we will give a brief overview of the history containing function pointers. Rootkits such as adore-ng inject of rootkit attacks. code into the kernel’s memory space and modify these dynamically allocated function pointers in order to call it. Because the function pointers are contained in dynamically allocated A. Early Years data structures, traditional integrity checking approaches were Early rootkit attacks against the integrity of the operating unable to detect the attack. system did not focus on the OS kernel, but instead modi- In response to this threat there are two major classes of fied key system binaries in order to mask the presence of defense techniques.

Load more