Uwaga – trojan!

Back Orfice dla Linuksa? Czemu nie… Tomasz Wendlandt podesłał nam maila, który pojawił się niedawno na łamach listy focus-linux. Mail dotyczy pojawienia się trojana o nazwie Kernel Intrusion System, który ma możliwości podobne do windowsowego Back Orfice. W szczególności umożliwia zdalnemu crackerowi uruchamiać i ukrywać procesy, ukrywać aktywne połączenia, pingownać i zarządzać samym trojanem. Aktualną wersję – 0.9 – bardzo prosto wykryć w momencie, kiedy zostanie zainstalowana w systemie.

Pierwszym śladem obecności trojana jest wysoki load systemu. Drugim – obecność otwartych portów wykrywanych skanerem, a nie pokazywanych przez netstata. Trzecim – najważniejszym – dwa pracujące procesy init. Dokładne informacje o sposobach wykrywania i usuwania – poniżej…

  Date: Sun, 22 Jul 2001 15:53:32 -0400 (EDT)  From: Timothy Lawless   Subject: Linux Kernel-Level Trojan - Kernel Intrusion System (KIS)  To:         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  

Archiwalny news dodany przez użytkownika: honey.
Kliknij tutaj by zobaczyć archiwalne komentarze.