Forwarded From: Timothy Lawless <[EMAIL PROTECTED]> > > > 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 > [EMAIL PROTECTED] > > -- -- Benjamin Story
