Fwd: Linux Kernel-Level Trojan - Kernel Intrusion System (KIS)

[beesond001 at hawaii.rr.com]

To all,

	I found this today on the security focus mailing list and thought I'd 
pass it along. It appears that someone has too much time on their 
hands...

VR,

Ben 

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 7/22/01, 9:53:32 AM, Timothy Lawless <lawless at netdoor.com> wrote 
regarding Linux Kernel-Level Trojan - Kernel Intrusion System (KIS):


> 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 at netdoor.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freesoftwarehawaii.org/pipermail/luau-freesoftwarehawaii.org/attachments/20010724/88337ace/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/rtf
Size: 13836 bytes
Desc: filename="text1.rtf"
URL: <http://lists.freesoftwarehawaii.org/pipermail/luau-freesoftwarehawaii.org/attachments/20010724/88337ace/attachment-0001.rtf>