Hijacking System calls with Loadable kernel modules.

In this post I will be outlining the various steps involved in hijacking a system call. This is fundamental to the underlying operation of a rootkit.  I will do this using a loadable kernel module (LKM).  Before diving straight into our hijack function,  it’s import to understand how kernel modules work and how they are loaded into your Linux operating system environment.

The code for this demonstrative post is located here https://github.com/maK-/Syscall-table-hijack-LKM

 

Understanding loadable kernel modules.

LKMs extend the functionality of the base-kernel of the Linux operating system.  They are simply loaded in using insmod which loads a kernel object (.ko) into the kernel. They can be removed using rmmod. Using a process called kbuild we can build our kernel object file. This is similar to a regular elf object file (.o) that is normally generated when compiling user-land conventional C code. The additional k lets us know that this code was compiled with additional required kernel specific sections (such as .modinfo).

Once our Kernel module is loaded in, you can see it listed in /proc/modules. Sometimes it is important to test your module before inserting it into a live system. This can be achieved using modprobe. It can very simply test load a kernel object.  It is more safe to install our modules using modprobe. You can view a list of installed modules using lsmod. You can also view info on any of these modules by running modinfo.

 

Building our System call hijack module.

In order to compile and create our module, we must use a Makefile. Here you will see the Makefile that corresponds with our system call hijacking module below.


#If KERNELRELEASE is defined, we've been invoked #from the kernel build system and can use its #language.


ifneq ($(KERNELRELEASE),)
obj-m := maK_it.o


# Otherwise we were called directly from the command
# line; invoke the kernel build system.
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)


default:
sh scripts/lets_maK_it.sh
make -C $(KERNELDIR) M=$(PWD) modules
endif

You will notice above that this should build our module with our current kernel (uname  -r). The script “lets_mak_it.sh” takes a template.c file and generates the file to be used in building. This file will then contain the needed addresses for our module to work.


#!/bin/bash
 #used to insert the memory addresses of:
 #sys_call_table
 
KERN=$(uname -r)
IN="template.c"
OUT="maK_it.c"
BREAK="----------------------------"


echo "Finding Kernel System Call Table Address..."
echo $BREAK
GET_SC_TABLE=$(grep sys_call_table /boot/System.map-$KERN | (awk '{print $1}'))
SYSCALL_TABLE="SYSCALL_TABLE 0x"$GET_SC_TABLE
echo $SYSCALL_TABLE

#Templates to be replaced
SCT="SYSCALL_TABLE_TEMPLATE"

echo $BREAK
echo "Building '$OUT' File..."
sed -e "s/$SCT/$SYSCALL_TABLE/g;" < $IN > $OUT
echo "Done."

Running the following line from above

grep sys_call_table /boot/System.map-`uname -r`

We can see that the location of our system call table is printed out. This is inserted into the SYSCALL_TABLE_TEMPLATE location in template file and mak_it.c is created. This is the final code that is then built into our kernel object. It is very important that we acquire the address of our system call table into our module. Notice the output above has an R. This symbolizes that the System call table is read-only.

What is happening inside the kernel?

In my 3rd functional specification post I described the following scenario. Our loadable kernel module is loaded into the kernel space. This module must replace the address of the write system call with the address of it’s own evil write system call in the system call table.

syscall2

 

In order to achieve this, we need to ensure the system call table is writable so we can overwrite the address of our function. By default in many 2.6* Linux kernels the System call table is set to read-only mode. We confirmed this above.  Through investigation I discovered we also can’t change the system call table page to write mode because it is write-protected. We can confirm this by running the following.

cat /proc/cpuinfo | grep wp

WP is write-protected mode. In order to overwrite our System call table addresses we need this set to off. WP is part of control register. This is a processor register which changes or controls the general behavior of a CPU. Common tasks performed by control registers include interrupt control, switching the addressing mode, paging control, and coprocessor control. We need to directly deal with CR0 register.

Looking up WP in the CR0 we can see the following information.

16 WP Write protect Determines whether the CPU can write to pages marked read-only.

If we flip this 16th bit to 0, we should have full write access to all of the pages. This means our System-call table address space can be overwritten. Giving us full access to all of the system calls, allowing us overwrite their locations in the table with our own evil addresses.

Flipping the 16bit can be achieved with the following

write_cr0 (read_cr0 () & (~ 0x10000));

Then flipped back with

write_cr0 (read_cr0 () | 0x10000);

We must then do this before and after we want to edit our system call table addresses. Hopefully this is made very clear in the following code.  https://github.com/maK-/Syscall-table-hijack-LKM/blob/master/template.c

Note that the address of our system call table needs to be replaced by the .sh script above. This kernel module doesn’t do anything at the moment. It simply demonstrates the replacement of the write system call. You can confirm this by placing a kernel warning message in the evil write system call function. Then you can run the following to read the evil messages as the write system call is called.

tail -f /var/log/messages

Appendices

http://vulnfactory.org/blog/2011/08/12/wp-safe-or-not/

http://en.wikipedia.org/wiki/Control_register#CR0

http://memset.wordpress.com/2010/12/03/syscall-hijacking-kernel-2-6-systems/

http://www.tldp.org/HOWTO/html_single/Module-HOWTO/

http://en.wikipedia.org/wiki/Loadable_kernel_module

Functional Specification (part 3)

Section 5:                                System Architecture

5.1 Simple Use-Case

  1. Attacker gains unauthorized root access to victim host machine.

  2. Installs rootkit and removes evidence of attack.

  3. Administrator or owner of victim host continues activity on machine as normal. Assuming they haven’t detected the attack or found the rootkit. They carry out their regular usage (Example: Distributing Illegal movies).

  4. After a week of collecting evidence, our attacker sends a crafted packet to the victim machine. In response of this crafted packet being detected, a remote shell is returned to the attacker. Victim owner is still left unaware.

  5. Attacker retrieves all the evidence collected and either uninstalls the rootkit, or furthers the attack, based on the data they received. Victim is still clueless.

Below you will find some context diagrams based on this use case.

Step 1:

Step1

Step 2:

Step2

Step 3:

Step3

Step 4:

Step4

Step 5:

Step5

Section 5:                                System Architecture

5.2 Rootkit and OS Architecture

The Rootkit and Operating system have an interesting architectural layout when combined. I feel this is important to include in the functional specification as it demonstrates how our Rootkit module and Operating system entities interact with each other from an easy to understand higher level view. This interaction is critical to the project and without it, the method of implementing a rootkit I am investigating would not be possible. I will be developing this rootkit on a 32bit linux kernel architecture of the 2.6* variety. I will also investigate how I could possibly extend this to other newer kernels.

In the first diagram below you will see how the operating system separates our user space from the kernel space. This diagram outlines the regular functionality of how our operating system eventually progresses to making system calls from a process. This initial high-level view will be investigated to a much greater extent in future documentation. Our process needs to call the write system call. Through an interface this request is handled, the location of the write function is found in the system call table and we can see that write is then executed.

syscall

In the following diagram you will notice you can see our loadable kernel module (the rootkit). Hopefully it should be clear that the kernel module needs to first store the original address of the write system call, then it needs to overwrite the address with an evil function. This evil function would then pass the value it received to the regular system call after carrying out it’s evil task. Basically the rootkit allows us to intercept any system call.

syscall2

This sequence is a fundamental concept in understanding how a LKM rootkit works. We can see from this example that it is possible to intercept the write system call. The same is true for any of the other system calls. There are a few issues such as the system call table not being writeable and other such protections put in place to mitigate rootkits. Methods to bypass these restrictions do exist and will  be demoed at a later stage.

Section 5:                                System Architecture

5.3 Systemtap Architecture

Systemtap has a very interesting architecture. It translates the systemtap language into raw kernel level C code and then into a compiled kernel object (.ko). It also has the ability to insert raw C code directly into the kernel using its “Guru-mode”. All of this takes place on-the-fly or during runtime. This is possible thanks to the kprobe debugging interface.

kprobes

Above we can see the architectural layout of the kprobe interface. Most of the work is done in the architecture dependant layer. Each different architecture has it’s own debug symbols and must be dealt with individually. We place a pre-handler kprobe before the position we want to debug, then one straight after. The pre-handler executes, then the probed instruction, then the post-handler. These handlers carry out functions in our higher layers.

The architecture independent layer in the middle is our kprobe manager, this manages the registering and unregistering of kprobes. The user can then provide handlers for the kprobes within their kernel module. They use the middle layer to register these handlers.

Systemtap provides a Higher layer above this again. It translates it’s own language and libraries into kprobe compliant code to carry out many different functions within the kernel.

Section 6:                                High-Level Design

6.1 Data Flow Diagram: kprobe execution

kprobe-high

6.2 Data Flow Diagram: Systemtap flow

Dataflow-stap

Section 7:                                Schedule

7.1 Simple Schedule

The schedule for this project can be found here http://blogs.computing.dcu.ie/wordpress/mak0/schedule

 

Section 8:                                    Appendices

Below you will find a collection of Links relating to my project & research areas. It is possible more will be included in later documentation or added to my blog posts as I need them. This should not be considered the full list of appendices. I will also properly reference these articles/books in later documentation.

 

I will keep them in the format:

LINK    :    Brief description

https://sourceware.org/systemtap/langref/    :

The Systemtap language reference

 

http://tldp.org/LDP/lkmpg/2.4/html/book1.htm

The Linux Kernel Programming book

 

http://www.phrack.org/            :

An E-zine containing many useful techniques for many of the areas I’ll be investigating.

 

http://memset.wordpress.com/        :

Many relevant techniques (Author wrote some related phrack articles)

 

http://kernelnewbies.org/            :     Some useful information

 

http://www.redbooks.ibm.com/abstracts/redp4469.html:

“Systemtap: Instrumenting the Linux Kernel for analysing performance and functional problems”. A very useful guide full of tips for using Systemtap.

 

http://man7.org/tlpi/                :

The Linux Programming Interface. This has a lot of detailed information about how the linux kernel works.

 

http://c.learncodethehardway.org/book/    :

Additional help with C programming.

Functional Specification (part 2)

Section 3:                            Functional Requirements

Rootkit Functional Requirements

3.1 Installation Procedure of Rootkit Module

  • Description:

This is the initial and most critical step of the software. It involves setting various system critical options and variables and ensuring that our Host operating system is fully compatible with the software. This will most likely take the form of a Makefile.

  • Criticality:

This script is possibly the most important step of our software. It ensures that the system is compatible and suited to work with our loadable kernel module. The criticality lies in the fact that a large amount of damage could be done to a host Operating System if the module is loaded into a non compatible kernel.

  • Technical Issues:

There are many iterations of the Linux kernel. I will do my best to ensure compatibility across a few different versions. I will mainly focusing on the 2.6* variety of the kernel however.

      • Different names/locations of critical address space.

      • Differently named Kernel functions.

      • Different methods in securing the System call table from modification.

      • Newer kernel versions have less documentation with regards to attack/manipulation techniques.

  • Dependencies:

The Installer must have root privileges and the script needs to find correct address locations of functional critical elements such as the System call table.

3.2 Rootkit: Hijacking System Calls and modifying the syscall Table.

  • Description:

This functionality is necessary for the rootkit to intercept and modify the operating system calls. We can find the location of the various system calls one we have the base address of the system call table.

  • Criticality:

The ability to intercept system calls and modify the system call table is critical to the operation of the rootkit, it ensures we can exert greater control over the operating system at a very low level. Without being able to locate and modify the system call table, the other functionality of our rootkit would not be possible.

  • Technical Issues:

The operating system usually sets the system call table to read-only mode, it is important to find away around this restriction in order to exert full control.

  • Dependencies:

Ability to write and modify the system call table.

3.3 Rootkit: Hiding the rootkit module.

  • Description:

This functionality is important as it demonstrates that our rootkit can be hidden from the regular more simple methods of detection. It is also largely a functional requirement of a  typical rootkit.

  • Criticality:

This is quite an important element in terms of the overall goals of the software. In most use cases, the more hidden the rootkit, the better and more efficient it is.

  • Technical Issues:

There are many ways an administrator can list the currently installed modules. It will be worthwhile investigating many of these and deciding which detection methods would be the best to hide from. I will also possibly need to look into hiding other files.

  • Dependencies:

In order to avoid detection it is important to also investigate the different methods to detect loadable kernel modules. I will attempt to hide the module from many of these different avenues of discovery. I am expecting System tap to greatly help me with this along with strace.

3.4 Rootkit: Keylogger.

  • Description:

The keylogger component of the rootkit will capture pressed keys into a file that can later be exfiltrated.

  • Criticality:

This is an important function of the software as it is one of the most useful elements. It demonstrates how data can be retrieved in a secretive way. This type of functionality is commonly found in rootkits.

  • Technical Issues:

There are different ways of keylogging. We could intercept the key presses at a system call level or instead try to capture them at tty session level.

3.5 Rootkit: Network packet sniffer.

  • Description:

In order to take advantage of our rootkit, it is important to allow remote access to our compromised machine. The network sniffer will monitor network traffic and packets and allow a connection from a machine that meets certain criteria. It could also store network information for exfiltration by our attacker or rootkit user.

  • Criticality:

The ability to remotely access the rootkit is of vital criticality to the software. It ensures access is maintained to the host machine. It also ensures the user can take advantage of the other rootkit functionality.

  • Technical Issues:

Generally a large amount of packets travel in and out of a networked computer, this means if our sniffer is slow or performs too many functions, it could affect the perceived speed of operations in the OS. It could also hinder network efficiency. Packets can come in many different forms or sizes which could possibly add unnecessary complexity to the sniffer.

The second technical issue of concern is that there may not be a need to store the network data. Most operating systems will already have log files and methods of logging this information. The attacker could simply view this when they get remote access.

  • Dependencies:

    Monitoring the network traffic isn’t too costly for performance. The development of this functionality also depends on whether or not better alternatives exist.

3.6 Rootkit: Data Exfiltration

  • Description:

There needs to be a method for our attacker or user to retrieve information that was collected in the time the attacker wasn’t actively logged in. This could be done in a few different ways, I will investigate the different approaches to this functionality.

  • Criticality:

This is part of our project is of medium importance as it is not critical to the working of the project as a whole. If the user of our rootkit can remotely access the machine simply reading the material that is secretly captured could be considered information exfiltration.

  • Technical Issues:

Log files can become extremely large, I will need to decide what critical elements should be captured and prepared for exfiltration. Writing to files within a kernel module is considered bad practice  or non-standard so I may look at other methods of logging.

3.7 Rootkit: Control Interface.

  • Description:

There may possibly need to be a hidden way of interacting and controlling our rootkit. Such as hiding/unhiding specified files. It would also be useful in the scenario that we want to hide the rootkit module on a machine we currently have a regular user account on. Possibly a way of elevating privileges of a regular user. The more obfuscated the control interface the better.

  • Criticality:

This is not critical to the rootkits functionality but could be considered an important feature. It could be possible to simply have a rootkit that provides a means of maintained access. I’ would however like to investigate a means of controlling the rootkit as a normal user also.

  • Technical Issues:

Ensuring the interface is obfuscated appropriately so that activation of certain functions couldn’t happen by accident.

  • Dependencies:

This greatly depends on whether I have enough time to investigate this possibility and also as to whether I can come up with some tricks to activate the kit without detection.

3.8 Rootkit: Uninstall and removal options.

  • Description:

There should be an easy way of uninstalling the rootkit software, removing it from our host machine. I would like this to also clean up any possible areas of detection. This includes uninstalling the kernel module, resetting the modified memory addresses, removal of all associated files and deletion of any possible evidence or logs that may have been generated.

  • Criticality:

This is of vital criticality to the software as we need to ensure our rootkit can be removed without damaging the host OS. It is also important in the overall scope of deploying and using a rootkit that is to remain undetected.

  • Technical Issues:

I will need to keep track of any files created and the original memory address of our syscall table.

  • Dependencies:

I must clear and exit cleanly from every operation the rootkit carries out.

3.9 Rootkit: Investigating other possible functions.

  • Description:

I would like to investigate other mischievous things I could possibly carry out with my rootkit module. This would maybe include some techniques or ideas of my own. I’d like to look at methods of making the rootkit more stealthy, alternative methods of maintaining access, Investigate triggers such as a timed attack or hidden cronjobs. I would also like to investigate the possibility of providing false chkrootkit data to an admin.

  • Criticality:

This isn’t critical to the baseline of my project and is simply a few ideas of other items I could possibly add to the project if I have enough time.

  • Technical Issues:

If I don’t implement these items as a LKM I’d like to possibly look into them in Systemtap.

  • Dependencies:

I complete the main project specified and have the time to research other areas of interest.

Section 4:                                System Tap

SystemTap Scripts

 

4.1 Rootkit Functionality.

Ideally I’d like to investigate the various functional components of the rootkit through various Systemtap scripts. The simple format of the scripting language provides flexibility in probing different areas of the Operating system. I will most definitely use it to investigate many of the areas affected by the rootkit. I will also more than likely implement most if not all of the functionality of the rootkit in Systemtap scripts. It allows me to break down what is happening inside the OS into nice smaller snippets of code. It would also allow the deep probing of system calls and would result in me collecting very useful information and system data.

I feel having a collection of systemtap scripts that carry out the same functionality as the rootkit, would greatly increase the research potential. I could view various elements of the OS in real time as the script affects them. I could also simply edit the scripts and play around with the values and functions easier than writing the equivalent functions in C code. I am hoping the investigation of each proposed rootkit function with systemtap will greatly help my understanding of the functional operations at hand and will greatly ease the development of said functions, once I move onto developing the loadable kernel module.

4.2 Deeper Inspection of functions.

Systemtap has a set of prebuilt library functions called tap sets. These will provide very helpful probing examples and are a useful resource in regards to developing interesting scripts. Systemtap takes advantage of kprobes, this allows the setting of breakpoints at almost any point within the kernel source code.

Using the framework we can also return any variable data from any kernel function or system call into our systemtap scripts. This means we can investigate real time data exchanging within the various OS components. kprobes use a software design pattern similar to the observer pattern; each probe has a corresponding handler. The probe event handlers run as an extension of the system breakpoint interrupt handler system. This means they have almost no dependence on system facilities, ensuring they don’t skew the operating systems performance enough to affect our collected data.

Systemtap provides very useful lookup or search functionality. You can define a kernel function name or system call with a regular expression type pattern and it will return the name of any kernel functions with that name or system calls with a matching pattern. It also returns the variables these functions accept. This will prove immensely useful when looking into new areas I am unfamiliar with inside the operating system.

4.3 Statistical Data.

Systemtap has interesting statistic building functionality allowing the use of aggregate data. It has many useful mathematical functions built in and a simple format for generating histogram charts. This could prove useful for collecting time or load based statistics. I would like to take advantage of this and hopefully incorporate this functionality into some of my systemtap scripts. Viewing a simple graph is a lot nicer than reading the raw data.

Throughout my research and investigation into rootkit development, I hope to generate various different forms of statistical data charts. This will give me a base level of data from which I can launch useful analysis and diagnostic tests from, hopefully improving the quality of the various functional components of the software, or at the very least improve my own understanding while justifying my design choices.

4.4 Experimentation of ideas

Using the systemtap scripts I can experiment and try different approaches to problems during runtime. I should also be able to draw some useful conclusions about what works and what doesn’t before I go ahead and try implement these functions in my kernel module. I am expecting to learn a great deal about how a rootkit leverages elements of the Linux operating system and uses the operating systems design against itself.

There are many techniques available online of how to implement various elements of a rootkit. I would like to try a variety of these techniques and possibly compare them using systemtap scripts. I would also be interesting to see if I could contribute something new or anything at all useful, to the area of rootkits. Systemtap should give me additional flexibility in testing ideas. This may of course be very ambitious but I’d like to gain a deep understanding of the processes at play, so aiming high is a good idea in my opinion.

Time is the biggest concern with regards to experimenting with additional functionality but I thought I’d include this section as a possibility for my project. Especially if I find I’ve completed the basic functional components before the deadline.

Functional Specification (part 1)

Section 1:                                    Introduction

1.1 Overview

Rootkits are typically any software that subverts the Kernel of an operating system. They are normally used by malicious parties to maintain privileged access once a system has been compromised. They can be used to carry out stealthy operations, leaving the owner of the breached system completely unaware of its presence. The operations rootkits carry out are generally malicious in nature, with the overall goal of remaining undetected. Many rootkits are installed as Linux Kernel Modules.

Using Systemtap, I would like to investigate the various elements involved in the development of a rootkit. I would also like to investigate how they carry out the common functionality normally associated with them. Systemtap allows the deep probing and tracing of the Linux operating system internals. This will ensure the gathering of very useful operating system information. It is also possible to inject additional operations on a live OS environment during runtime via Systemtap scripting engine.

I would like to implement a variety of rootkit functionality using Systemtap and then demonstrate how this can contribute to the development of a Linux Kernel Module Rootkit.

Some of the components and functionality I hope to Investigate and develop:

  • Installation of a rootkit

  • Accessing the System call table

  • Modifying System calls

  • Hiding the rootkit module

  • Implementing a Keylogger

  • Network traffic sniffing

  • Data Exfiltration

  • Remote Hidden Access

  • Affecting User space functions

  • Detection / Mitigation

The overall goal of this project is to gain a deeper understanding of the various elements of a rootkit through development and investigative research. Gaining familiarity with Systemtap will also prove very useful in understanding the workings of the Linux operating system. Systemtap will aid in systems testing and the debugging of future Development projects.

Section 1:                                    Introduction

1.2 Glossary

OS: Operating System. In this project this will most likely refer to the Linux operating system.

Kernel:  This is a fundamental part of an operating system. It provides a bridge between applications that run on an OS and the actual data processing done in the lower hardware levels. The kernel manages system resources and connects the components of a pc via various inter-process communication mechanisms and system calls.

Monolithic Kernel:  An operating system architecture in which the entire OS works in kernel space. It uses a set of system calls to implement all system services.

System Calls:  These provide an interface between a process and the operating system. It is how a program requests service from the kernel; providing a communication layer.

Systemtap: a tool that allows developers deeply examine a running Linux system. It uses probing mechanisms to allow breakpoints or tap points be set anywhere within the operating system.

Tapset: Reusable scripts provided with the systemtap framework/language. Equivalent to a library of already developed functions.

Keylogger:  Utility that logs keystrokes to a file normally as the person typing is unaware of its presence.

LKM:  Linux/loadable Kernel module. This is an object file that is used to extend functionality of the base Linux kernel. They are usually used to add support for new hardware or File Systems.

Black-Hat: Security conscious malicious party who leverages bugs in computer systems for personal gain or a malicious goal.

Malware: Software that only serves malicious intent.

Botnet: Internet-connected robotic software, used to carry out tasks on a large scale. They normally have a command and control station that pushes tasks to the “bots”. A Bot in an evil case is normally a malware infected computer system or device.

Section 2:                                General Description

2.1 Software/System Functions

Listed below is a breakdown of the expected functionality each component of this project will possess.

Installation of Rootkit / Systemtap setup

  • Build Script for Systemtap to install environment

  • Makefile to build Rootkit Loadable Kernel Module

Systemtap scripts

These will be created throughout the development process to complement each developed component of our rootkit. Providing testing data and deep analysis at every step.

  • To investigate each component of the kernel I interact with

  • Testing the System call table & System calls

  • Looking up Kernel functions

  • Implementation of Keylogger

  • Implementation of Traffic capture/sniffing

  • User-space probing

  • Allowing Remote access

  • Data Exfiltration

  • Demonstrating each component at system level (including “hidden” elements)

The Rootkit

It is possible the different functionality below may be spread over multiple files but Ideally I’d like to keep everything in the one file.

  • Hijack System call table

  • Modify system calls

    • read/write etc.

    • Implement attacks

    • provide control interface

  • Hide Module from Module/File listings

  • Hide Files

    • log files

  • Keylogger

  • Network Packet sniffing

  • Remote Access

    • through network

    • remote code execution

    • possibly provide a hidden shell

  • Data Exfiltration

 

Other areas of Investigation…

  • Detection

    • chkrootkit & rkhunter.

    • Having a look at how detection occurs

    • Probing the above processes with systemtap

  • Avoidance

    • Examining possibilities of avoiding common detection methods

  • Mitigation

    • Ways to guarantee detection

    • Tactics to avoid rootkit infection/installation

 

Section 2:                                General Description

2.2 User Characteristics and Project Objectives

A major goal of this project is to document with code (via Systemtap scripts) the various methods employed by modern rootkits. Hopefully gaining a much deeper understanding of the Linux operating system in the process and how rootkits can leverage this operating system. The final tool/rootkit at the end of the development process could be used by amateur or professional security enthusiasts.

Although normally associated with malicious intent and rightfully so, there are some legitimate uses of rootkits. Rootkits can and are used by law-enforcement agencies to collect evidence. This of course only applies to suited cases where the crime is technologically based. A few examples of such cases are mass fraud, network/system trespassing, distribution of underage pornography, software/media piracy and other associated copyright violations.

Also in more recent times malicious rootkit type software has and is being used in Military applications as Military forces of course rely heavily on technology. Spying and Security Intelligence is a massive industry and an area that could and does benefit from this “sneaky” software.

Regrettably most rootkits are used maliciously; having their attributes leveraged for profit by “Black-Hat” individuals. They are commonly part of and associated with, Illegal Botnets or Malware. I believe understanding how rootkits are created and how they operate will greatly benefit myself as I intend on pursuing work in the Information security field. I would hope the fundamentals of this project could be used by anyone hoping to gain insight into rootkits. In the same way that I do throughout the development process.

By the end of the project, I hope to have developed a fully functional rootkit that demonstrates most if not all of the functionality mentioned in the previous section (2.1). I would also like to be able to demonstrate a deep understanding of the various components it interacts with inside the Linux Kernel using Systemtap or otherwise.

Section 2:                                General Description

2.3 Operational Scenarios

Rootkits can be and are deployed in a variety of different ways. The kernel module variety I will be developing requires that our installer already has root privileges before deploying. I will explore a few different methods commonly used by Law-enforcement or Security personnel, Military Officials or Black-hats to install rootkits.

Viral infection

Sometimes rootkit technology is combined with a self-propagating virus. A Virus normally spreads and distributes itself without the aid or interaction of a human attacker. They are also normally more detectable and out of control. Rootkits are used in a sanctioned or precision attack and are under strict control of an attacker. The combination of the two, results in a very powerful and dangerous piece of software. Recently this technique has been employed in military operations and due to its almost wild nature infected a lot more targets than was probably intended. This is a very ethically questionable creation and method of installation.

Used in combination with a software exploit

The rootkit is installed after a security professional acquires root privileges through a software exploit. There are many different kinds of privilege escalation bug that could result in this scenario. The attacker could take advantage of an out-of-date kernel and escalate their privileges or via exploiting higher privileged network facing software. There is an abundance of software exploits, this ensures rootkits are still a threat.

Patching & Code Modification

Sometimes rootkits can be included as a patch or modification to legitimate software that goes unnoticed by the person installing it. This is a very real threat as nobody is going to read all of the code of the software they are installing or can’t because of licensing protections.

Once installed it is assumed our attacker or malicious party will maintain access to the compromised machine. A normal operational scenario involves the attacker gaining remote access to the rootkit infected system via a backdoor, then abuses his privileged powers for either legal or malicious purposes without detection. The attacker could exfiltrate private data or acquire legal evidence depending on the scenario of usage.

In military operations, rootkits have been used to gain a tactical advantage by collection mission critical Intelligence data or allowed the shutting down of enemy operations.

Section 2:                                General Description

2.4 Constraints

  • Attacker needs root privileges before installation

In order to install a Loadable kernel module it is necessary for the attacker to already have root privileges. There are user-space rootkits but they don’t have as many options or exert as much control over the OS as an LKM based rootkit.

  • Definite methods of detection

There are a lot of different concrete methods to detect rootkits. It is very possible one of these methods could be overlooked during development and as a result many rootkits don’t fully evade detection. It’s quite difficult to fully hide a rootkit from a person fully aware of how they normally operate. On the other hand,  if an attacker managed to gain root access on a machine they don’t own, it is completely possible the administrator may already be negligent of securing their machine/server.

  • Slight hit on operating system performance

As the rootkit operates deep within the operating system is is quite possible there would be a slight hit on OS performance. I would like to measure this using Systemtap as this could be interesting data. I would also like to see where I can cut down on this.

  • File writing within the kernel

There are many articles describing the dangers of reading/writing to a file within the kernel and how it is against common Policy. I will have to investigate different methods of possibly getting around this. I would like to see if I can take advantage of already existing kernel logging avenues that I could hide instead of managing this aspect myself.

  • Time

This Project involves a lot of research into new areas and techniques that I am unfamiliar with. As there will be a lot of reading and research involved, I will need to manage my time very carefully. I do hope the rootkit I develop, at the very minimal, will contain a keylogger, a network sniffer and a method of capture exfiltration. If I manage my time appropriately I should be able to complete and look into all areas of my proposed project and not only my minimal requirements.

  • Tools & Languages

The tools I’ll be using throughout development are new to me. I hope to gain good knowledge of how to best wield them. Systemtap seems like a very useful framework for me to learn as I can see how good knowledge of it will greatly improve my ability to diagnose and inspect issues deep within the OS. I am also unfamiliar with regular conventions of the C programming language used in LKMs as I have only had brief encounters with them, I expect this will take a bit of time to adjust to.