A framework for prototyping and testing data-only rootkit attacks
Introduction
Rootkits are advanced attacks designed to prevent an attacker from being discovered after compromising a system. Over the years they have evolved from simple replacements to key system binaries into complex programs capable of modifying an operating system kernel on the fly.
Research into defense techniques against such advanced threats frequently involves building a defense system prototype that is designed to protect a specific version of an operating system. The sample attacks and real-world rootkits that a researcher may want to test with; however, are frequently hard coded to function on a different version of the OS. As such, in order to test the effectiveness of a research prototype, the researcher is frequently required to “port” those attacks to operate on the same version of the OS used in the prototype. These changes are rarely publicly released, and even if they were they would be unlikely to be helpful to other researchers who would likely be using a different version of the OS for their testing. In addition, if a researcher is unable to get a specific attack to function, it is frequently just left out of testing. This methodology produces unrepeatable results that do not allow for direct comparisons between various defense techniques.
As an example of this problem, consider the variety of experiments performed in research focused on code injection based rootkits for Linux. In (Petroni and Hicks, 2007), the authors build a corpus of 25 rootkit attacks to test with, but end up stating, “Of the 25 that we acquired, we were able to install 18 in our virtual test infrastructure. The remainder either did not support our test kernel version or would not install in a virtualized environment.” In (Riley et al., 2008), the authors test with 16 Linux rootkits, but only 12 of them overlap with (Petroni and Hicks, 2007). In (Seshadri et al., 2007), the authors give no results that involved testing with rootkit attacks.
As another example, in our own work involving kernel rootkit defense (Riley et al., 2008, 2009; Rhee et al., 2009; Riley et al., 2009; Rhee et al., 2010) we found ourselves locked in to an older version of Linux due to the rootkits we planned to test with. We have a corpus of rootkits which use a variety of attack mechanisms and techniques that we were using to test a variety of defense techniques. Our rootkits, however, were designed to run against a specific version of Linux (Redhat 8.0) and despite multiple attempts at porting them to more up-to-date versions of Linux, in the end we always ended up porting our new defense technique to Redhat 8.0 instead. It was simply less work.
Given the state of experimentation for research into code injection based rootkits, the goal of this work is to improve the quality and ease of testing research into a newer class of attack called data-only rootkits. Advances in kernel rootkit defense (Riley et al., 2008; Seshadri et al., 2007) have created an environment where a rootkit is unable to inject and execute new code, effectively stopping the vast majority of rootkits. A rootkit attack which relies only on the modification of kernel data structures and not the execution of new code is called a “data-only rootkit attack”. For example, a code injection based rootkit would hide a process by bypassing the readdir( ) system call and instead calling a malicious version that filters process entries from the/proc filesystem. A data-only attack, by contrast, would remove the target process from the linked list of all tasks located in kernel memory.
In this work we present DORF, the Data-Only Rootkit Framework, an object-oriented framework designed to allow for rapid prototyping and testing of data-only rootkit attacks on Linux. We demonstrate the usefulness of DORF by using it to implement four data-only attacks. We also show the portability of DORF by porting it to a total of 6 different Linux distributions/kernel versions. DORF has two primary goals: First, it allows researchers to focus on developing and testing data-only attacks without being concerned with the layout of kernel data structures or the mechanism used to access kernel memory. Second, it allows them to test new defense systems with a variety of data-only attacks supplied by other researchers, without needing to re-implement those attacks to function against a different version of the Linux kernel. Instead, the researcher simply ports DORF (if a port is not already available) and then the attacks will “just work.” It is our hope that researchers will use and contribute back to DORF in order to further facilitate research into detecting and preventing advanced data-only rootkit threats.
The contributions of this work are as follows:
- 1.
We provide a definition of data-only rootkit attacks and further sub-divide such attacks into control-flow altering and non-control attacks depending on how they influence the control-flow of the kernel. These definitions can be used to help clarify the types of attacks and defenses needed for future work.
- 2.
We present a new data-only attack that allows for file hiding. To our knowledge, this is the first release of such an attack. This attack demonstrates the potential power of data-only rootkit attacks.
- 3.
We present (and release) DORF, the Data-Only Rootkit Framework. The purpose of the framework is to enable researchers to quickly prototype new data-only attacks as well as to allow them to test attacks against new defense systems they may develop.
- 4.
We provide an outline for future research in the area in light of recent research results, including those in this paper. We emphasize four main areas: better semantic specification of kernel data structures, an investigation into the applicability of control- and data-flow integrity, kernel design that does not assume trusted data structures, and better testing of defense systems using a framework such as DORF.
Section snippets
History
In this section we will give a brief overview of the history of rootkit attacks.
Data only attacks
A rootkit attack that modifies kernel data structures without injecting new code is called a “data-only rootkit attack.” Under a data-only attack the attacker has full access to read and write all kernel memory, but is unable to add new code or modify existing code that will be executed with the kernel's privilege level.
Inspired by prior work at the user-level (Chen et al., 2005), we will further classify data-only rootkit attacks into two types: Control-flow altering data-only rootkit attacks
Experimental framework
As can be seen in Section 3.2, NC data-only attacks have the potential to be powerful. In addition, the related work of Section 3.1 reveals that there is very little research into more advanced attacks.
In order to promote further research into this area, we have created DORF, an object-oriented, extensible framework which allows for rapid prototyping and validation of these data-only attacks against Linux systems. DORF is written in Python and is available for download (Riley).
The goal of DORF
Discussion
In this section we will discuss the limitations of DORF, give an overview of the existing work in defense against data-only attacks, and give our recommendations for future work in the area.
Dr. Ryan Riley is an Assistant Professor of Computer Science and Engineering at Qatar University in the Department of Computer Science and Engineering. He received his Ph.D. in Computer Science from Purdue University in 2009. He is currently involved in research grants worth over $3 million. His research interests include operating systems, malware defense, secure hypervisors, and wireless sensor networks. After a brief stall in research productivity, he is finally settled into his new position
References (32)
- et al.
Control-flow integrity: principles, implementations, and applications
Paranoid Penguin: an introduction to Novell AppArmor
Linux Journale
(2006)- et al.
Jump-oriented programming: a new class of code-reuse attack
- et al.
When good instructions go bad: generalizing return-oriented programming to RISC
- et al.
Securing software by enforcing data-flow integrity
- et al.
Return-oriented programming without returns
- et al.
Non-control-data attacks are realistic threats
- et al.
Digging for data structures
Getting around non-executable stack (and fix)
Bugtraq Mailing List
(August 10, 1997)- et al.
Robust signatures for kernel data structures
A virtual machine introspection based architecture for intrusion detection
Ensuring operating system kernel integrity with OSck
Return-oriented rootkits: bypassing kernel code integrity protection mechanisms
Countering lifetime kernel code integrity protections
Operating system kernel data disambiguation to support security analysis
Stealthy malware detection through VMM-based “Out-of-the-Box” semantic view reconstruction
Cited by (10)
Virtual Wall: Filtering Rootkit Attacks to Protect Linux Kernel Functions
2021, IEEE Transactions on ComputersA Real-Time Monitoring Method of Virtual Machine Process Based on Self-Adaptive Mechanism
2019, Jisuanji Xuebao/Chinese Journal of ComputersMonitoring of root privilege escalation in android kernel
2018, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)HPDBF: A forensics method for hidden process based on memory analysis
2017, Proceedings of 2016 5th International Conference on Computer Science and Network Technology, ICCSNT 2016On the detection of Kernel-level rootkits using hardware performance counters
2017, ASIA CCS 2017 - Proceedings of the 2017 ACM Asia Conference on Computer and Communications Security
Dr. Ryan Riley is an Assistant Professor of Computer Science and Engineering at Qatar University in the Department of Computer Science and Engineering. He received his Ph.D. in Computer Science from Purdue University in 2009. He is currently involved in research grants worth over $3 million. His research interests include operating systems, malware defense, secure hypervisors, and wireless sensor networks. After a brief stall in research productivity, he is finally settled into his new position and now re-embarking on his research career.