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.