July 23, 2001

Linux kernel-level trojan - Kernel Intrusion System

Author: JT Smith

In an e-mail message, Timothy Lawless documents the Kernel Intrusion System (KIS) trojan, unveiled about a week ago at the DefCon Conference in Las Vegas. The trojan affects Linux systems running the 2.2 or 2.4 kernels. Read on for the complete message:
                  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

                  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


  • Linux
Click Here!