:Linux Kernel-Level Trojan - Kernel Intrusion System (KIS)
Linux Kernel-Level Trojan - Kernel Intrusion System (KIS) Jul 23, 2001, 19 :15 UTC (36 Talkback[s]) (11562 reads)
Subject: Linux Kernel-Level Trojan - Kernel Intrusion System (KIS)
Date: Sun, 22 Jul 2001 15:53:32 -0400 (EDT)
From: Timothy Lawless <lawless@netdoor.com>
This document describes the Kernel Intrusion System (KIS) trojan that
affects Linux 2.2 and 2.4 systems. The specific version of the KIS
trojan analyzed is labeled 0.9.
1. Introduction
At the Defcon Conference in Las Vegas, NV at 10:00am PST on July 14th
2001, the KIS trojan was published by an individual who is identified
as Optyx. The trojan is designed to automate the loading of a kernel
module. Once loaded the kernel module will attempt to conceal its
presence, and listen to the network for instructions.
2. Description
The KIS trojan is a hybrid between zombie daemons which came to light
as a result of DDOS attacks on major sites at the beginning of 2000
and kernel level rootkits that are used by hostile entities to
conceal their presence on a system after a successful compromise.
In its remote control client, the KIS trojan delivers a similar look
and feel as is associated with Back Orifice or SubSeven.
By issuing commands from a remote KIS client, an individual is
capable of executing processes on a victim host while hiding
arbitrary files, child processes and network connections.
The KIS trojan is introduced into a system in the form of a regular
executable binary that contains the KIS kernel module and the trojan.
3. Operation
The KIS trojan is inserted on a victim host by executing a binary
that installs the trojan, and loads the KIS trojan kernel module.
The trojan is installed into the system by replacing the /sbin/init
binary with the trojan. Upon bootup, the trojaned /sbin/init will
load the KIS kernel module and subsequently call the original "init"
binary that has been moved to a hidden directory. This ensures that
the KIS trojan is the first kernel module loaded on the system.
In the testing of the KIS system, it appears it was designed only to
load from init. Multiple runs of the trojan binary, such as what
would occur if it were to replace /bin/sh or another binary that
runs often, can cause the system to hang, generate "Out of Memory"
messages or become unstable.
During loading, the KIS kernel module performs several tasks:
-- Conceals the Modules Presence by Removing the Module
from the modules_list structure.
-- Replaces key system calls.
-- Replaces portions of the vfs structures for the net/tcp,
net/udp, and net/raw files in the procfs.
-- Spawns a kernel_thread to process incoming commands from
the network.
-- Replaces the ip_packet_type structure with a new
structure to allow KIS to monitor all ip based
network traffic and add observed commands to queue.
Commands are sent to the KIS trojaned system from a KIS client
console. The commands are sent via directed IP packets with a
specific length to match a modulus and remainder defined in the KIS
module upon compile.
If the packet matches the length requirements and decrypts into a
valid command packet, then the command is added to a queue for
processing.
The queue manager takes a queued command off of the queue and
performs the directed command.
Valid commands include:
-- Execution of A Process
-- Hiding a running process
-- Revealing a hidden process
-- Hiding a file
-- Revealing a file
-- Hiding a connection
-- Revealing a connection
-- Ping
-- Shutdown and Removal of the Trojan
The queue manager is always running, monitoring the incoming queue of
commands. As a result, the load on a victim system will never fall
below a load of 0.80.
Additionally, as a result of the replaced systemcalls and the
requirements to manage hidden files and processes, filesystem
operations such as listing or even compiling a kernel consume up to
30% more system time then the victim system would consume in a
non-trojaned state.
4. Risk
The KIS system permits a remote execution of processes on a victim
system. Combined with its ability to conceal such executions, files,
and network activity from normal processes, the KIS system provides
a prime platform from which attacks against the integrity and
availability of other compromised systems may be launched.
Despite the need to compile a KIS trojan for each kernel, a
pre-compiled KIS trojan could be packaged and distributed to victim
hosts that are running stock kernels.
If such a pre-compiled binaries were to be included into a RPM or DEB
package, a KIS trojan could be introduced to victim systems by
administrators installing a new or updated package.
5. Detection
The KIS system can be detected on initial load by the StMichael 0.05
Linux Kernel Module. The StMichael Linux kernel module is a
integrity monitor for the 2.2 and 2.4 Linux kernels.
On systems not running StMichael, or that are suspected of being
infected by the KIS trojan, the following observations can be made
to determine if the system is actually infected:
During normal operations (ie, runlevel 3 or 5)
-- "ps -auwx | grep init" will reveal two "init" processes.
-- The system load will be high, not falling below 0.8 even
when all observable processes are idle or sleeping.
-- Repeated runs of "init", such as switching between runlevels
or rebooting will cause the system to hang, generate error
messages or crash.
-- Portscans on the system reveal open and listening ports that
are not reflected in a netstat.
Alternatively, if the system can be safely brought down and booted
off of a clean or rescue media, search the filesystem for a file
called "ht" with mode 000. This is the hidden file table used by KIS
to list hidden files.
find / -name ht -mode 000 -print
Also, the trojaned init process is copied to a file in the same
directory as the original init binary, but named "init."
find / -name init\. -print
Additionally, to determine if files are hidden by KIS or any other
trojan the following method may be applied:
1. Boot the system normally. Generate a file list via:
find / -type f -print > listing.1
2. Boot the system into single user mode using 'clean'
media such as a rescue disk. Mount all the filesystems
(ie, on /mnt)
find /mnt -type f -print | sed -e "/\/mnt//g" > listing.2
3. Diff the two listings to determine the hidden files
diff -u listing.1 listing.2
6. Cleaning
To remove KIS, the trojaned init binary needs to be replaced with a
clean init binary or the original init binary.
The original init binary is stored in the same directory that the ht
file is stored in. There are two files that are named simularly:
"init." and "init" .
"init" is the original init binary.
"init." is a copy of the trojan.
Copy the "init" file over the trojaned init file:
cp init /sbin/init
The "ht" file will contain files and directories that are hidden.
These files may contain information about the attack and what the
trojaned system was used for.
If the source for KIS is recovered, the server.h file will contain
the keys, modulus, and remainder needed to communicate with the KIS
server. Using this information it may be possible to sniff the
network, identifying packets that are sent in attempts to contact
the KIS server. In some circumstances, such as with the PING
command, the origin IP address will likely not be spoofed.
Tim Lawless
lawless@netdoor.com
