Rootkit
By: Serafin
Sanchez (04/14/08)
A rootkit is a
program or combination of several programs designed to take fundamental control
in Unix terms root access, in Windows terms Administrator access of a computer
system, without authorization by the system owners. Access to the hardware is
rarely required as a rootkit is intended to seize
control of the operating system running on the hardware. Typically, rootkits act to obscure their presence on the system
through subversion or evasion of standard operating system security mechanisms.
Often, they are also Trojans as well, thus fooling users into believing they
are safe to run on their systems. Techniques used to accomplish this can
include concealing running processes from monitoring programs, or hiding files
or system data from the operating system.
Rootkits may have
originated as regular, though emergency, applications, intended to take control
of an unresponsive system, but in recent years have been largely malware to
help intruders gain access to systems while avoiding detection. Rootkits exist for a variety of operating systems, such as
Microsoft Windows, Mac OS X, Linux and Solaris. Rootkits
often modify parts of the operating system or install themselves as drivers or
kernel modules, depending on the internal details of an operating system's
mechanisms.
The term rootkit or root kit
originally referred to a maliciously modified set of administrative tools for a
Unix-like operating system. If an intruder could replace the standard
administrative tools on a system with a rootkit, the
modified tools would give the intruder administrative control over the system
while concealing his activities from the legitimate system administrator. Rootkits were so named because they allowed an intruder to
become a root user (system administrator) of a Unix
system.
A successfully
installed rootkit allows unauthorized users to act as
system administrators, and thus to take full control of the rootkitted
system. Secondary to this purpose, most rootkits
typically hide files, network connections, blocks of memory, or registry entries on Windows
systems from other programs used by system administrators to detect specially
privileged accesses to computer system resources. However, a rootkit may masquerade as or be intertwined with other
files, programs, or libraries with other purposes. It is important to note that
while the utilities bundled with a rootkit may be
maliciously intended, not every rootkit is always
malicious. Rootkits may be used for both productive
and destructive purposes.
There are at
least five kinds of rootkits: firmware, virtualized,
kernel, library, and application level kits.
Firmware -A firmware rootkit
uses device or platform firmware to create a persistent malware image. The rootkit can successfully hide in firmware because firmware
is not often inspected for code integrity. John Heasman
demonstrated the viability of firmware rootkits in
both ACPI firmware routines and in a PCI expansion card
Virtualized - T-hese rootkits work by modifying the boot sequence of the machine
to load themselves instead of the original operating
system. Once loaded into memory, a virtualized rootkit
then loads the original operating system as a Virtual Machine, thereby enabling
the rootkit to intercept all hardware calls made by
the guest OS. The SubVirt
laboratory rootkit, developed jointly by Microsoft
and
Kernel level - Kernel
level rootkits add additional code and/or replace
portions of an operating system, including both the kernel and associated
device drivers. Most operating systems don't enforce any security distinctions
between the kernel and device drivers. As such, many kernel mode rootkits are developed as device drivers or loadable
modules, such as Loadable Kernel Modules in Linux or device drivers in
Microsoft Windows. This class of rootkit is perceived
as dangerous simply because of the unrestricted security access the code has
obtained, regardless of the features the rootkit may
employ. Any code operating at the kernel level may have serious impacts on
entire system stability if mistakes are present in the code. The first and
original rootkits did not operate at the kernel
level, but were simple replacements of standard programs at the user level.
Although traditionally security advances were made first on Unix
systems, the first kernel rootkit was developed for
Windows NT 4.0 and released in the mid-1990's by Greg Hoglund.
Kernel rootkits can be especially dangerous
because they can be difficult to detect. The reason they can be difficult to
detect is because they operate at the same level as the operating system, thus
they can modify or subvert any request made by software on the running system.
In a situation such as this, the system itself cannot be trusted. An accepted
proper response in such a case is to perform system analysis offline using a
second 'trusted' system and mounting the hard drive of the infected system as a
resource.
Library level - Library rootkits commonly patch, hook, or replace
system calls with versions that hide information about the attacker. They can
be found, at least theoretically, by examining code libraries under Windows the
term is usually DLL for changes or against the originally distributed (and so
presumably rootkit free) library package. In
practice, the variety of modified libraries distributed with applications and ServicePacks makes this harder than it should have been.
Application level - Application level rootkits may replace regular
application binaries with trojanized fakes, or they
may modify the behavior of existing applications using hooks, patches, injected
code, or other means.
Rootkit binaries can often be detected by signature or
heuristics based antivirus programs, at least until they're run by a user and
are able to attempt to conceal themselves. There are inherent limitations for
any program that attempts to detect rootkits while
the program is running under the suspect system. Rootkits
are suites of programs that modify many of the tools and libraries upon which
all programs on the system depend. Some rootkits
attempt to modify the running kernel via loadable modules on Linux and, and
through VxDs, virtual external drivers, on MS Windows platforms. The
fundamental problem with rootkit detection is that if
the operating system currently running has been subverted, it cannot be
trusted, including to find unauthorized modifications to itself or its
components. In other words, actions such as requesting a list of all running
processes, or a list of all files in a directory, cannot be trusted to behave
as intended by the original designers. Rootkit
detectors running on live systems currently only work because the rootkits they can detect have not yet been developed to
hide themselves fully.
The best, and
most reliable, method for rootkit detection is to
shut down the computer suspected of infection, and then check its storage by
booting from an alternative medium a rescue CD-ROM or USB flash drive. A
non-running rootkit cannot (ideally) hide its presence,
and most established antivirus programs will identify rootkits
armed via standard OS calls (which are often tampered with by the rootkit) and lower level queries, which ought to remain
reliable. If there is a difference, the presence of a rootkit
infection should be assumed. Running rootkits attempt
to protect themselves by monitoring running processes and suspending their
activity until the scanning has finished; this is more difficult if the rootkit is not allowed to run.