[ Pobierz całość w formacie PDF ]
A Methodology to Detect and Characterize Kernel Level Rootkit Exploits
Involving Redirection of the System Call Table
John Levine, Julian Grizzard, Henry Owen
School of Electrical and Computer Engineering
Georgia Institute of Technology
E-mail: levine@ece.gatech.edu
Abstract
Techniques currently exist for a system administrator
to monitor the status of systems. Intrusion detection
systems operate at numerous levels throughout the
network to detect malicious activity by hackers. At the
system or host level, a file integrity checker program can
be run on the computer system in question.
These methods may not be able to detect the presence
of a kernel level rootkit. In this paper we present a
preliminary mathematical framework to classify rootkit
exploits and discuss a methodology for determining if a
system has been infected by a kernel level rootkit. New
signatures can then be created for these kernel level
rootkits in order to detect them. We have conducted our
research on a Red Hat Linux based system using the stock
Red Hat kernel 2.4.18-14 and the standard Linux kernel
2.4.18 but this methodology will apply to other Linux
distributions that are based on the standard Linux kernel.
Also we believe our methodology should extend to other
Unix based systems
.
1.1.
Definition of a Rootkit
There is no standardized methodology at present to
characterize rootkits that compromise the security of
computer systems. The ability to characterize rootkits
will provide system administrators with information so
that they can take the best possible recovery actions and
may also help to detect additional instances and prevent
the further installation of the rootkit allowing the security
community to react faster to new rootkit exploits. There
are limited capabilities at present to detect rootkits, but in
most cases these capabilities only indicate that a system is
infected without identifying the specific rootkit. We
propose a mathematical framework for classifying rootkit
exploits as existing, modifications to existing, or entirely
new. An in-depth analysis of a particular type of kernel
rootkit is conducted in order to develop a
characterization. As a result of this characterization and
analysis, we propose some new methods to detect this
particular class of rootkit exploit.
1. Introduction
A rootkit can be considered as a “Trojan Horse”
introduced into a computer operating system. According
to Thimbleby, Anderson, and Cairns, there are four
categories of trojans. They are:
direct masquerades
, i.e.
pretending to be normal programs;
simple masquerades
,
i.e. not masquerading as existing programs but
masquerading as possible programs that are other than
what they really are;
slip masquerades
, i.e. programs with
names approximating existing names; and
environmental
masquerades
, i.e. already running programs not easily
identified by the user [1]. We are primarily interested in
the first category of Trojans, that of direct masquerades.
A hacker must already have root level access on a
computer system before he can install a rootkit. Rootkits
do not allow an attacker to gain access to a system.
Instead, they enable the attacker to get back into the
system with root level permissions [2]. Once a hacker
has gained root level access on a system, a trojan
program that can masquerade as an existing system
function can then be installed on the compromised system.
Computers on today’s Internet are vulnerable to a
variety of exploits that can compromise their intended
operations. Systems can be subject to Denial of Service
Attacks that prevent other computers from connecting to
them for their provided service (e.g. web server) or
prevent them from connecting to other computers on the
Internet. They can be subject to attacks that cause them to
cease operations either temporary or permanently. A
hacker may be able to compromise a system and gain root
level access, i.e. the ability to control that system as if the
hacker was the system administrator. A hacker who gains
root access on a computer system may want to maintain
that access for the foreseeable future. One way for the
hacker to do this is by the use of a rootkit. A rootkit
enables the hacker to access the compromised computer
system at a later time with root level privileges. System
administrators have a continuing need for techniques in
order to determine if a hacker has installed a rootkit on
their systems.
Rootkits are a fairly recent phenomenon. Systems used
to have utilities that could be trusted to provide a system
administrator with accurate information. Modern hackers
have developed methods to conceal their activities and
programs to assist in this concealment [3].
1.2. Kernel Level Rootkits
1.2.1 Kernel Level Rootkits that modify the System
Call Table.
This type of kernel level rootkit modifies selected
sys_call addresses that are stored in the system call table.
A kernel level rootkit can use the capability of loadable
kernel modules (LKMs). LKMs are a feature that is
available in Linux [6]. A LKM can be developed that will
modify the sys_call to hide files and processes as well as
provide backdoors for a hacker to return to the system.
These LKM’s also modify the address table of sys_calls
stored in the system call table. They replace the addresses
of the legitimate sys_calls with the addresses of the
sys_calls that are installed by the hacker’s LKM [9].
A sys_call in a system that has a kernel level rootkit
installed may be redirected away from the legitimate
sys_call to the kernel level rootkit’s replacement sys_call.
The Loadable Kernel Module capability is also available
Kernel level rootkits are one of the most recent
developments in the area of computer system exploitation
by the hacker community [4]. The kernel is recognized
as the most fundamental part of most modern operating
systems. The kernel can be considered the lowest level in
the operating system. The file system, scheduling of the
CPU, management of memory, and system call related
operating system functions are all provided by the kernel
[5]. User interface to the kernel is accomplished through
Figure 1-System
Call Table
the use of a system call, or sys_call. The application
performs a sys_call passing control to the kernel which
performs the requested work and provides the output to
the requesting application. The addresses of these system
calls in kernel memory are maintained in the system call
table data structure stored in kernel memory. Unlike a
traditional binary rootkit that modifies critical system
level programs, a kernel level rootkit may replace or
modify the system call table within the kernel itself. This
allows the hacker to control the system without others
being aware of this. Kernel level rootkits usually cannot
be detected by traditional means available to a system
administrator.
in various UNIX based operating systems [6]. Anexample
of this type of rootkit is the KNARK rootkit developed by
CREED and released in 2001. Figure 1 shows how
redirection of the sys_calls is handled by a rootkit such as
KNARK.
1.2.2 Kernel Level Rootkits that redirect the system
call table.
This type of kernel level rootkit redirects references to
the entire system call table to a new location in kernel
memory. A new system call table is installed at this
memory location. This new system call table may contain
the addresses of malicious sys_call functions as well as
the original address to any unmodified sys_call functions.
One way to accomplish this is by writing to /dev/kmem
within the Linux Operating System. The device
/dev/kmem provides access to the memory region of the
currently running kernel. It is possible to overwrite
portions of the kernel memory at runtime if the proper
memory location can be found. Kernel level rootkits that
redirect the system call table accomplish this by
overwriting the pointer to the original system call table
with the address of a new system call table that is created
by the hacker within kernel memory [6]. Unlike the
previous method that was discussed, this method does not
modify the original System Call Table and as a result, will
still pass current consistency checks.
its CRC checksum is both faster and requires less memory
than comparing a file by its contents [8]. The results of
this comparison will only tell you that a current program
file differs from its original program file. Using this
check to detect rootkits would not tell you if this rootkit
is an existing, modification to existing, or entirely new
rootkit exploit. It is also recognized that Trojan Horse
type programs can be detected by comparing them to the
original program file that they are intended to replace [8].
The approach we choose to follow is that rootkits can be
classified comparing their
against previously
identified
’s of known rootkits.
For our framework we assume that we have already
identified a program as being part of a potential rootkit.
In addition, we have a copy of the original programs that
the rootkit replaced. From our definition of a true rootkit
we can assume that these two programs are
indistinguishable in execution since they will produce
similar results for most inputs. Therefore, these two
programs are similar to each other. From [1], we
recognize that similarity is not equality, i.e. we may not be
able to recognize that the programs differ in the amount of
time that we have available to analyze them. Two
programs are indistinguishable when they reproduce
similar results for most inputs. A true rootkit should
therefore be indistinguishable from what it is intended to
replace since it should have the same functionality as the
original programs it is to replace in addition to the new
capabilities that were added by the rootkit developer.
We also use the quantifiers,
similarity
2. A framework for classifying rootkit
exploits
We have studied the work that has been done by
Thimbleby, Anderson and Cairns [1] in developing a
framework for modeling Trojans and computer virus
infection. This work dealt with the general case of
viruses and Trojans. We have used some of the ideas
presented in this work to develop a mathematical
framework in order for us to be able to classify rootkit
exploits. The focus of our work is more specific in that
we are trying to develop a method to classify rootkits as
existing, modification to existing, or entirely new.
A computer virus has been defined as a computer
program that is able to replicate all or part of itself and
attach this replication to another program [7]. The type of
rootkits that we wish to classify does not normally have
this capability so this is not a method that we could use to
detect or classify rootkits. A true rootkit program that is
intended to replace an existing program on the target
system must have the same functionality as the original
program plus some increased functionality that has been
inserted by the rootkit developer in order to allow
backdoor root level access and/or the ability to hide
specified files, processes, and network connections on to
the target system. This increased functionality is provided
by added elements contained within the rootkit program.
The increased functionality of the rootkit, with its
associated elements, provides a method that can be
utilized in order to detect and classify rootkit exploits.
Rootkits can be characterized by using a variety of
methods to compare the original program to the rootkit
program and identify the difference, or delta (
(~),
indistinguishable (
), and the meaning of a program
[[
]] that was presented in [1] and define them in a
similar manner.
•
~ (similarity) – a poly log computable relation on
all possible representations (defined as R) of a
computer to include the full state of the machine
consisting of memory, screens, registers, inputs,
etc. A single representation of R is defined as r.
Poly log computable is defined as a function that
can be computed in less than linear time meaning
a representation can be evaluated without having
to examine the entire computer representation.
(indistinguishable) – two programs that
produce similar results for most inputs.
]] (the meaning of a program) – what a
program does when it is run
We presume to have two programs: p1, the original
program, and p2, identified as malicious version of
program p1 that provides rootkit capabilities on the target
system. If p2 is part of a true rootkit then p1 and p2 are
indistinguishable from each other. These two programs
will produce similar outputs for most inputs. In a
[[
) in
functionality between the two programs. This
can
serve as a potential signature for identifying the rootkit.
It has been recognized that evaluating a program file by
manner similar to [1] we can state that p1 is
indistinguishable from p2 if and only if
3.
Existing Methodologies to detect rootkits
3.1
Methods to Detect Binary Rootkits
for most
r
R
:
[[
p
1
]]
r
~
[[
p
2
]]
r
⇒
p
1
p
2
meaning for most representations of a machine out of all
possible representations the results of program p1 are
similar to the results of program p2 which implies that p1
is indistinguishable from p2.
We will now apply set theory to show a method to
characterize rootkit exploits. We assume to have the
following programs:
Programs exist to check the integrity of critical system
files. There are several host based IDS tools that look at
changes to the system files. These programs take a
snapshot of the trusted file system state and use this
snapshot as a basis for future scans. The system
administrator must tune this system so that only relative
files are considered in the snapshot. Two such candidate
systems are TRIPWIRE and AIDE (Advanced Intrusion
Detection Environment) [10]. AIDE is a General Public
License (GPL) program that is available for free on the
Internet. This program operates by creating a database of
specified files. This database contains attributes such as:
permissions, inode number, user, group, file size, creation
time (ctime), modification time (mtime), access time
(atime), growing size and number of links [11].
However, a program like AIDE does have shortcomings.
Rami Lehti, in the Aide manual, states ”Unfortunately,
Aide cannot provide absolute sureness about changes in
files. Like any other system files, Aide’s binary files
and/or database can be altered” [11]. There is another
free program that checks a system for rootkit detection.
This program is known as chkrootkit [12].
The chkrootkit program runs a shell script that checks
specific system binaries to determine if a rootkit has been
installed on the system. This program also checks to see
if the network interfaces on the computer have been set to
promiscuous mode, which is a common ploy used by
hackers in order to capture network traffic. The program
also checks the system logs. The shell script is signature
based, therefore the signature must be known in order to
detect if a rootkit has been installed on a system.
Programs such as chkrootkit may not detect a new rootkit,
as well as modifications to existing rootkits.
3.2 Methods to Detect Kernel Level Rootkits
p1 – original set of programs
p2 – malicious version of programs that replace p1
programs
If p2 is a true rootkit of p1 then we can state that p1 is a
subset of p2 since all of the elements that exist in p1 must
exist in p2. Then p1 is a proper subset of since all
elements of p1 exist in p2 but p1 is not equal to p2, This
can be written as:
meaning p2 has
at least one element that does not belong to p1.
p
1
p
2
, since
p
1
p
2
and
p
1
p
2
We will now identify the difference between p1 and p2.
is the difference between p2 and p1
containing only those elements belonging to p2. This is
the
p
2
\
p
1
p
'
that we have previously discussed.
We assume we have identified another rootkit of p1 and
call this p3. We can identify this collection of programs
as a rootkit of type p2 as follows:
then p3 contains the same
elements as program p2 and is the same rootkit.
If
p
3
(
p
'
p
3
p
1
If the preceding statement is not true but elements of p’
are contained in p3, written as
, than we can
assume that p3 may be a modification of rootkit p2. If
there are no elements of p’ in p3, written as
p
'
p
3
Samhain Labs [9] has developed a small command-line
utility to detect the presence of a kernel level rootkit. As
we have previously explained, the kernel controls any
application that is running on the computer. If the
application wants to access some system resource, such as
reading to or writing from the disk, then the application
must request this service from the kernel. The application
performs a sys_call passing control to the kernel which
performs the requested work and provides the output to
the requesting application. A kernel level rootkit can
modify these system calls to perform some type of
, than
we may assume that p3 is an entirely new rootkit. We will
follow these steps in order to classify the example kernel
level rootkit that we will be examining. We are
examining numerous rootkits as a part of our research,
however we only present the details of a few example
rootkits in this paper.
p
'
p
3
malicious activity. A sys_call in a system that has a
kernel level rootkit installed may be redirected away from
the legitimate sys_call to the rootkit’s replacement
sys_call.
It may be possible to detect the presence of a kernel
level rootkit by comparing the sys_call addresses in the
current system call table with the original map of kernel
symbols that is generated when compiling the Linux
kernel. A difference between these two tables will
indicate that something has modified the system call table
[9]. It must be noted that each new installation of the
kernel as well as the loading of a kernel module will result
in a new mapping of kernel symbols. The following
figure (figure 2) shows the output of running the
kern_check program on a system infected with the
KNARK kernel level rootkit.
table address. This may also be the case for other Linux
distributions. As a result, the
query_module
command
will no longer be able to retrieve the address of the system
call table for some newer distributions of Linux utilizing
the 2.4 kernel as well as in the Linux 2.6 kernel [13].
In addition, the kern_check program developed by
Samhain Labs is unable to detect kernel level rootkits that
redirect the system call table. We have modified the
kern_check program, which is released under the GPL
license, so that it is able to work even if the
query_module
capability is disabled as well as detect kernel level rootkits
that redirect the system call table. We will subsequently
address the details of these modifications.
Figure 2-kern_check output of KNARKed system
4. An Analysis of the SuckIT kernel level
rootkit
The output indicates that the addresses of 8 sys_calls
currently listed in the system call table currently stored in
kernel memory (/dev/kmem) do not match the addresses
for those sys_calls in the original map of the kernel
symbols. This map of kernel systems is available on the
system we examined as /boot/System.map. If the
/boot/System.map file is up to date, then the system call
table has most likely been modified by a kernel level
rootkit. A similar file should be available on other Linux
systems.
The kern_check program however, does not work with
later versions of the Linux kernel. The Linux 2.6 Kernel
will no longer export the system call table address. This
was done to prevent race conditions from occurring with
the dynamic replacement of system call addresses by
loadable modules. Red Hat has back ported this feature
into later versions of the Linux 2.4 kernel available for
Red Hat releases so that it does not export the system call
4.1 The SuckIT kernel level rootkit.
The SuckIT rootkit was developed by sd and devik
based on the article they wrote in PHRACK vol. 58,
article 7, titled “Linux–on-the-fly kernel patching without
LKM”. This article discusses a methodology for
modifying the system calls within the Linux kernel
without the use of LKM support or the /boot/System.map
file [14]. Unlike kernel level rootkits that modify the
system call table, this type of rootkit keeps the system call
table intact. An examination of the original system call
table will not indicate that the system has been
compromised by a kernel level rootkit. The SuckIT
kernel level rootkit accomplishes this by modifying the
System Call Interrupt (system_call() function) that is
[ Pobierz całość w formacie PDF ]