A free software Linux rootkit has been announced with a number of
interesting features. Its availability may, unfortunately, help lower the bar
for "script kiddies" and others, but it also provides a nice look into what
makes up a rootkit. The rootkit, called DR for Debug Register, uses some
new techniques to evade
detection, such that even a change recently proposed for inclusion in the
kernel would have missed it.
A rootkit is malware that typically hooks into the kernel to hide its
presence from administrators. Usually, rootkits can hide their processes
from /proc, which in turn means ps won't see them, but
sophisticated rootkits do much more than that. DR can also hide network
sockets and files in the filesystem that are associated with rootkit processes.
There are some benefits to this approach as
the announcement describes:
The major benefit of the DR rootkit is that all this happens
transparently to the end user. The children of a hidden process are also
automatically hidden. The sockets a hidden process creates are also
hidden. But if you are a hidden process, you can see hidden resources.
This makes the DR rootkit nicely manageable.
Unlike many rootkits, DR does not alter the system call table directly.
Instead it sets a hardware breakpoint for the syscall_call()
function which gets called whenever a system call is made. When that
breakpoint is reached, a handler is set up to watch for an access to the
memory location where the specific system call's function pointer lives
(i.e. syscall_table[__NR_syscall]). When the address is retrieved
from that location, the breakpoint substitutes the address of the code the
rootkit wants to run—the system call hook.
The system call hooks is where the work is done to evade detection. By
hooking less than a dozen different calls, DR can hide its processes,
files, and sockets. By creating a program that does an exec()
of a special filename—one that starts with
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"—one can set the "hidden" bit on the
process; spawning a shell or running some malware after the exec()
fails will cause those processes to no longer be visible to the rest of the
There are some limitations outlined in the announcement, the biggest of
which is that DR is implemented as a kernel module without any attempt to
hide its presence. Doing an lsmod will show it clearly, but there
are other ways to detect it as well. Fixing those are all are on the "to
do" list and
won't take a very large effort to complete.
DR was created by Immunity, Inc. as part of their
penetration testing efforts and has been released under the GPLv2. It
contains roughly 1200 lines of well-documented code that should be of
interest to anyone curious about rootkits. It is not the first rootkit
available with source code, Adore predates it by several
years and there are probably others, but it is an interesting—if a
to post comments)