Rootkits

(Bad) Hackers' Tools: rootkits

Un rootkit è una collezione di tool che permette ad un cracker di cancellare le proprie tracce e assicurarsi la possibilità di rientrare sul sistema bucato, senza dover riutilizzare il buco di sicurezza con cui originariamente ha preso possesso della macchina.

I rootkit non servono per violare un sistema, vengono utilizzati solo quando è stato già compromesso e nella gran parte dei casi possono essere installati solo dall'utente root.
Generalmente un rootkit comprende:
- Un network sniffer, per registrare login e password utilizzate sulla o dalla macchina violata, in modo da estendere il raggio d'azione dell'intrusore e la qualità e quantità di informazioni in suo possesso;
- Un keystroke logger, che registra quanto digitato dall'utente direttamente in console;
- Dei log wipers, script che cancellano automaticamente le tracce dell'intrusione dai log di sistema;
- Versioni modificate (trojans) di comandi di sistema comunemente utilizzati che possono rivelare l'esistenza del rootkit: ls, netstat, ifconfig, ps, killall, find, top.
- Una backdoor che accetta connessioni remote sia appoggiandosi ad una porta locale (nascosta dal netstat modificato) che modificando le versioni sul sistema di server telnet, ssh o analoghi.

Esistono diversi tipi di rootkit con diverse peculiarità, in genere, quelli per Linux, si possono inquadrare in due grandi famiglie:
- Quelli che lavorano in user space, sostituendo comandi ed eseguendo processi estranei;
- Quelli che lavorano in kernel space, presentandosi come moduli del kernel stesso. Una evoluzione di questi ultimi sono i rootkit che scrivono direttamente in memoria tramite /dev/kmem e funzionano anche su kernel non modulari.

I primi sono generalmente più semplici da trovare: per un system administrator basta verificare se l'output di un ps (che in presenza di un rootkit è stato sicuramente trojanato) mostra meno processi, con relativo PID, di quanti vengono visualizzati nel /proc file system (dove esiste una directory con nome del PID per ogni processo in esecuzione sul sistema). Utilizzando inoltre versioni "sicure" di comandi tipo ps, find, ls, netstat (che si è certi essere integre e non modificate, perchè, per esempio, compilate staticamente ed eseguite da un file system che può essere montato solo in read mode (per esempio un CDROM)) la presenza di simili rootkit verrebbe smascherata senza particolari problemi.
I secondi sono invece molto più subdoli e complessi. Lavorando direttamente come moduli del kernel intercettano le chiamate di sistema di qualsiasi processo e modificano il risultato secondo quanto definito dall'intrusore. In questo modo possono nascondere anche directory nel /proc filesystem e modificare l'output di comandi integri.
In questi casi può essere utile uno strumento come chkrootkit per trovare l'esistenza di un rootkit nel sistema.

Per poter risiedere in memoria anche dopo un riavvio, l'esecuzione del servizio del rootkit che permette l'accesso remoto deve essere lanciata da qualche script o comando di avvio.
Una volta in memoria, tipicamente, il processo maligno non viene visualizzato tramite l'uso di comandi tipo ps e top, la cartella dove fisicamente risiede viene nascosta a comandi come ls, find e cat e le porte su cui ascolta non vengono visualizzate con netstat.

Come prevenire / intercettare l'installazione di un rootkit

Fra i metodi per difendersi dall'installazione sul proprio sistema di un rootkit ci sono:
- Innanzitutto impedire che un utente possa bucare il proprio sistema utilizzando security bug noti sui servizi in produzione, quindi mantenere il proprio sistema protetto e aggiornato;
- Utilizzare tool come TRIPWIRE che eseguono un check costante dell'integrità dei file di sistema;
- Utilizzare, su macchine in produzione, un kernel monolitico non modulare, che renderebbe impossibile l'installazione di un rootkit basato su un modulo del kernel (non basta con rootkit dell'ultima generazione che si basano su /dev/kmem);
- Utilizzare strumenti come LIDS che limitano permessi e accesso alle risorse del sistema a livello di singoli processi (se ben configurato LIDS appare come la soluzione estrema e più efficace);
- Usare un demone come RKDET, che si accorge quando un interfaccia di rete entra in promiscous mode e invia mail, disattiva il networking o esegue altre operazioni di conseguenza;
- Garantirsi l'integrità dei log: stampandoli direttamente su carta o inviandoli ad un syslog server remoto (protetto);
- Avere un sistema che non può montare in write mode le directory /sbin, /usr/sbin, /bin e /usr/bin, impedendo che i comandi ivi contenuti possano essere modificati. Contestualmente è necessario verificare che la $PATH della shell non venga modificata.

Individuare l'installazione di un rootkit

Una volta installato, un buon rootkit è, per natura, difficile da individuare proprio perchè tende a nascondere le tracce della propria esistenza.
Esistono tuttavia diversi metodi per individuarne la presenza che possono essere più o meno efficaci a seconda della natura del root kit:
- Il primo, più semplice, e piuttosto efficace è l'utilizzo di CHKROOTKIT, che è in grado di individuare sul sistema un numero sempre maggiore di rootkit.
- Verificare se il numero dei processi e i relativi PID che si visualizzano con ps è diverso da quello che si vede in /proc. Questa procedura, relativamente veloce, non funziona con rootkit basati su un modulo del kernel.
- Verificare con un port scanning da una macchina esterna, se sul sistema indagato sono aperte porte che non dovrebbero essere aperte e non vengono visualizzate con un netstat locale. Questo sistema non funziona con rootkit che modificano demoni esistenti come telnetd o sshd e tramite loro (e quindi tramite le rispettive porte) permettono accessi remoti non autorizzati.
- Indagare sempre quando un server si riavvia o si blocca senza apparente motivo o un servizio cade o comunque si riscontrano anomalie nel suo funzionamento: possono essere tutti indici di DOS attack o tentativi di intrusione o tentativi di installazione di un rootkit.
- Eseguire comandi come ls, ps, find da una fonte sicura (CDROM, NFS in read mode ecc.) e verificare se il loro output da risultati diversi dai rispettivi comandi di sistema. Questo metodo non funziona con rootkit kernel based.
- Verificare in /dev se esistono nomi di device sospetti, in particolare device pty senza numeri successivi (es: /dev/ptyr).
- Verificare negli script di startup del sistema se vengono lanciati comandi non noti: ogni rootkit deve garantirsi l'esecuzione in memoria al riavvio.
- Monitorare la banda utilizzata da ogni singolo server (MRTG è lo strumento ideale) e indagare quando si notano picchi di traffico anomali: non di fado una macchina compromessa viene utilizzata come repository di warez.
- Verificare su www.incidents.org se il proprio IP risulta nel database degli attackers: se lo è o siamo hacker maldestri o qualcuno sta usando la nostra macchina per lanciare attacchi altrove.

Breve analisi del rootkit SuckIT

Breve analisi del rootkit SuckIT

Su un sistema Linux RedHat 7.3 è stato installato il rootkit SuckIT, uno dei più evoluti in quanto agisce direttamente su /dev/kmem e non ha bisogno di un kernel modulare, cancella le proprie tracce dal /proc file system e modifica /sbin/init con una versione trojan.
Di default si installa nella directory /usr/share/locale/sk/.sk12/ che ovviamente non è visibile all'amministratore del sistema violato.

Un lsof, come tutti gli altri comandi di visualizzazione di file e processi, normalmente non ne rileva l'esistenza, ma nella shell remota dell'intrusore il processo è normalmente visibile:

[root@95 .sk12]# lsof | grep sk (dalla shell del rootkit)
sk        5878  root  cwd    DIR        3,6    4096         2 /
sk        5878  root  rtd    DIR        3,6    4096         2 /
sk        5878  root  txt    REG        3,6   29220    211267 /usr/share/locale/sk/.sk12/sk
sk        5878  root    0u   CHR        1,3             33485 /dev/null
sk        5878  root    1u   CHR        1,3             33485 /dev/null
sk        5878  root    2u   CHR        1,3             33485 /dev/null
sk        5878  root    3u   CHR        1,2             33250 /dev/kmem
sk        5878  root    4u   raw                      2791354 00000000:0006->00000000:0000 st=07
sk        5878  root    5u  IPv4    2960357               TCP 95.intranet:32954->95.intranet:32947 (ESTABLISHED)
sk        5878  root    6u   CHR        2,0             33702 /dev/ptyp0

[root@95 .sk12]# ps -adef (evidenziati i processi normalmente nascosti)
root      5040     1  0 11:25 ?        00:00:00 ./sk
root      5878  5040  0 11:32 ?        00:00:00 ./sk
root      5879  5878  0 11:32 ttyp0    00:00:00 sh -i

Fortunatamente l'ultima versione al momento disponibile di chkrootkit si accorge che qualcosa sul sistema è anomalo:

[root@95 chkrootkit-pre-0.36]# ./chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not infected
Checking `grep'... not infected
Checking `hdparm'... not infected
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not tested
Checking `inetdconf'... not found
Checking `identd'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not infected
Checking `mail'... not infected
Checking `mingetty'... not infected
Checking `netstat'... not infected
Checking `named'... not found
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not infected
Checking `rlogind'... not found
Checking `rshd'... not found
Checking `slogin'... not infected
Checking `sendmail'... not infected
Checking `sshd'... not infected
Checking `syslogd'... not infected
Checking `tar'... not infected
Checking `tcpd'... not infected
Checking `top'... not infected
Checking `telnetd'... not infected
Checking `timed'... not found
Checking `traceroute'... not infected
Checking `w'... not infected
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl5/5.6.1/i386-linux/.packlist

Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... You have     3 process hidden for readdir command
You have     3 process hidden for ps command
Warning: Possible LKM Trojan installed
Checking `rexedcs'... not found
Checking `sniffer'...
eth0 is not promisc
Checking `wted'... nothing deleted
Checking `z2'...
nothing deleted

In particolare è lo script che controlla ad uno ad uno tutti i possibili PID (da 1 a 65535) che si accorge che alcune righe di ps e alcune directory (che sono comunque accessibili, se si conosce il nome, ma non vengono visualizzate) in /proc/ vengono nascoste:

[root@95 chkrootkit-pre-0.36]# ./chkproc -v
PID  5040: not in readdir output
PID  5040: not in ps output
PID  5878: not in readdir output
PID  5878: not in ps output
PID  5879: not in readdir output
PID  5879: not in ps output
You have     3 process hidden for readdir command
You have     3 process hidden for ps command

A questo punto anche da una shell normale è possibile visualizzare il contenuto delle rispettive directory in proc, anche se un ls non le visualizza:
cat /proc/5040/cmdline
./sk

Dalla shell dell'intrusore si visualizza sia /sbin/init sia /sbin/initsk12 (questo è l'init originario, che viene rinominato, sostituito con una versione modificata, e nascosto (come tutti i file che finiscono con sk12 (suffisso configurabile in fase di compilazione del rootkit)
-rwxr-xr-x    1 root     root        26920 Jul  5 11:16 init
-rwxr-xr-x    1 root     root        37617 Apr 19 18:35 initlog
-rwxr-xr-x    1 root     root        26920 Jul  5 11:16 initsk12

Un controllo sull'integrità dei file modificati ci rende evidente che il rootkit non altera il checksum md5, rendendo difficle, per tool come Tripwire, l'individuazione dello stesso.
[root@95 chkrootkit-pre-0.36]# md5sum /sbin/init
a44b4fe49763349af054000b8565618a  /sbin/init

[root@95 chkrootkit-pre-0.36]# md5sum /sbin/initsk12
a44b4fe49763349af054000b8565618a  /sbin/initsk12

find / -mtime -4 -print

Visualizza in tutto il file system i file modificati negli ultimi 4 giorni (sostituire con il numero di giorni passati da quando si ritiene essere stata fatta l'instrusione). Può essere utile per individuare tracce lasciate dall'intrusore non coperte. Quando viene modificato un comando come ps, tipicamente la data di modifica viene lasciata inalterata, tuttavia altre tracce di attività illegittima (compilazione del rootkit, modifica di file dove non si è corretta la data ecc.) possono essere rivelate.

rpm -V -a

Visualizza per tutti i file installati tramite RPM se sono stati in qualche modo modificati rispetto all'RPM originale. E' E' un comodo metodo per determinare se qualcosa di strano è successo a dei file sul proprio sistema utilizzando le funzionalità di integrity checksum di RPM.
Un output piuttosto verboso su effettive modifiche è normale, ma se si riferisce a file che non dovrebbero essere stati modificati dovrebbe suonare un campanello d'allarme.

Installazione CHKROOTKIT

La compilazione e l'uso di chkrootkit sono molto semplici.
Qui viene riportata la procedura di download, compilazione, esecuzione su una macchina SENZA rootkit identificati da CHKROOTKIT.

[macno@95 macno]$ wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
--13:08:30--  ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
           => `chkrootkit.tar.gz'
Resolving ftp.pangeia.com.br... done.
Connecting to ftp.pangeia.com.br[200.239.53.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /pub/seg/pac ... done.
==> PORT ... done.    ==> RETR chkrootkit.tar.gz ... done.
Length: 24,478 (unauthoritative)

100%[===============================================================================================>] 24,478         6.91K/s    ETA 00:00

13:08:38 (6.91 KB/s) - `chkrootkit.tar.gz' saved [24478]

[macno@95 macno]$ tar -zxvf chkrootkit.tar.gz
chkrootkit-pre-0.36
chkrootkit-pre-0.36/COPYRIGHT
chkrootkit-pre-0.36/Makefile
chkrootkit-pre-0.36/README
chkrootkit-pre-0.36/README.chklastlog
chkrootkit-pre-0.36/README.chkwtmp
chkrootkit-pre-0.36/check_wtmpx.c
chkrootkit-pre-0.36/chklastlog.c
chkrootkit-pre-0.36/chkproc.c
chkrootkit-pre-0.36/chkrootkit
chkrootkit-pre-0.36/chkrootkit.lsm
chkrootkit-pre-0.36/chkwtmp.c
chkrootkit-pre-0.36/ifpromisc.c
chkrootkit-pre-0.36/strings.c
[macno@95 macno]$ cd chkrootkit-pre-0.36/
[macno@95 chkrootkit-pre-0.36]$ cat README
                             chkrootkit V. 0.36

          Nelson Murilo (main author)
            Klaus Steding-Jessen (co-author)

          This program locally checks for signs of a rootkit.
         chkrootkit is available at: http://www.chkrootkit.org/


                 No illegal activities are encouraged!
         I'm not responsible for anything you may do with it.

           This tool includes software developed by the
           DFN-CERT, Univ. of Hamburg (chklastlog and chkwtmp),
           and small portions of ifconfig developed by
           Fred N. van Kempen, .


1. What's chkrootkit?
---------------------

chkrootkit is a tool to locally check for signs of a rootkit.  It
contains:

* chkrootkit: a shell script that checks system binaries for
   rootkit modification.  The following tests are made:

   aliens asp bindshell lkm rexedcs sniffer wted z2 amd basename biff
   chfn chsh cron date du dirname echo egrep env find fingerd gpm grep
   hdparm su ifconfig inetd inetdconf identd killall ldsopreload login
   ls lsof mail mingetty netstat named passwd pidof pop2 pop3 ps
   pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd
   top telnetd timed traceroute write

* ifpromisc.c: checks if the network interface is in promiscuous
   mode.

* chklastlog.c: checks for lastlog deletions.

* chkwtmp.c: checks for wtmp deletions.

* check_wtmpx.c: checks for wtmpx deletions.  (Solaris only)

* chkproc.c: checks for signs of LKM trojans.

* strings.c: quick and dirty strings replacement.

chkwtmp and chklastlog *try* to check for deleted entries in the wtmp
and lastlog files, but it is *not* guaranteed that any modification
will be detected.

Aliens tries to find sniffer logs and rootkit config files.  It looks
for some default file locations -- so it is also not guaranteed it
will succeed in all cases.

chkproc checks if /proc entries are hidden from ps and the readdir
system call.  This could be the indication of a LKM trojan.  You can
also run this command with the -v option (verbose).


2. Rootkits, Worms and LKMs detected
------------------------------------

The following rootkits, worms and LKMs are currently detected:
Solaris rootkit, FreeBSD rootkit, lrk3, lrk4, lrk5, lrk6, t0rn (and
t0rn v8), some lrk variants, Ambient's Rootkit for Linux (ARK), Ramen
Worm, rh[67]-shaper, RSHA, Romanian rootkit, RK17, Lion Worm, Adore
Worm, LPD Worm, kenny-rk, Adore LKM, ShitC Worm, Omega Worm, Wormkit
Worm, dsc-rootkit, RST.b, duarawkz, knark LKM, Monkit, Hidrootkit,
Bobkit, Pizdakit, t0rn (v8.0 variant), Showtee, Optickit, T.R.K,
MithRa's Rootkit, George and SucKIT.


3. Supported Systems
--------------------

chkrootkit has been tested on: Linux 2.0.x, 2.2.x and 2.4.x, FreeBSD
2.2.x, 3.x and 4.x, Solaris 2.5.1, OpenBSD 2.x and 3.x.


4. Package Contents
-------------------

README
README.chklastlog
README.chkwtmp
COPYRIGHT
chkrootkit.lsm

Makefile
chklastlog.c
chkproc.c
chkwtmp.c
check_wtmpx.c
ifpromisc.c
strings.c

chkrootkit


5. Installation
---------------

To compile the C programs type:

# make sense

After that it is ready to use and you can simply type:

# ./chkrootkit


6. Usage
--------

chkrootkit must run as root.  The simplest way is:

# ./chkrootkit

This will perform all tests.  You can also specify only the tests you
want, as shown below:

Usage: ./chkrootkit [options] [testname ...]
Options:
         -h                show this help and exit
         -V                show version information and exit
         -l                show available tests
         -d                debug
         -q                quiet mode
         -x                expert mode
         -r dir            use dir as the root directory
         -p dir1:dir2:dirN path for the external commands used by chkrootkit

Where testname stands for one or more from the following list:

aliens asp bindshell lkm rexedcs sniffer wted z2 amd basename biff
chfn chsh cron date du dirname echo egrep env find fingerd gpm grep
hdparm su ifconfig inetd inetdconf identd killall ldsopreload login
ls lsof mail mingetty netstat named passwd pidof pop2 pop3 ps
pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd
top telnetd timed traceroute write

For example, the following command checks for trojaned ps and ls
binaries and also checks if the network interface is in promiscuous
mode.

   # ./chkrootkit ps ls sniffer

The `-q' option can be used to put chkrootkit in quiet mode -- in
this mode only output messages with `infected' status are shown.

With the `-x' option the user can examine suspicious strings in the
binary programs that may indicate a trojan -- all the analysis is
left to the user.

Lots of data can be seen with:

   # ./chkrootkit -x | more

Pathnames inside system commands:

   # ./chkrootkit -x | egrep '^/'

chkrootkit uses the following commands to make its tests: awk, cut,
egrep, find, head, id, ls, netstat, ps, strings, sed, uname.  It is
possible, with the `-p' option, to supply an alternate path to
chkrootkit so it won't use the system's (possibly) compromised
binaries to make its tests.

To use, for example, binaries in /cdrom/bin:

   # ./chkrootkit -p /cdrom/bin

It is possible to add more paths with a `:'

   # ./chkrootkit -p /cdrom/bin:/floppy/mybin

Sometimes is a good idea to mount the disk from a compromised machine
on a machine you trust.  Just mount the disk and specify a new
rootdir with the `-r' option.

For example, suppose the disk you want to check is mounted under
/mnt, then:

   # ./chkrootkit -r /mnt


7. Output Messages
------------------

The following messages are printed by chkrootkit (except with the -x
and -q command options) during its tests:

   "INFECTED": the test has identified a command probably modified by
   a known rootkit;

   "not infected": the test didn't find any known rootkit signature.

   "not tested": the test was not performed -- this could happen in
   the following situations:
     a) the test is OS specific;
     b) the test depends on an external program that is not available;
     c) some specific command line options are given. (e.g. -r ).

   "not found": the command to be tested is not available;

   "Vulnerable but disabled": the command is infected but not in use.
   (not running or commented in inetd.conf)


8. A trojaned command has been found.  What should I do now?
------------------------------------------------------------

Your biggest problem is that your machine has been compromised and
this bad guy has root privileges.

Maybe you can solve the problem by just replacing the trojaned
command -- the best way is to reinstall the machine from a safe media
and to follow your vendor's security recommendations.


9. Reports and questions
------------------------

Please send comments, questions and bug reports to
[email protected] and [email protected].

A simple FAQ and Related information about rootkits and security can
be found at chkrootkit's homepage, http://www.chkrootkit.org.


10. Acknowledgments
-------------------

Agustin Navarro, [email protected] (debug help)
Alberto Courrege Gomide, [email protected] (debug help)
Andre Gustavo de Carvalho Albuquerque, [email protected]
(debug help, performance and Solaris patches)
Dave Ansalvish, [email protected] (Solaris debug help)
Bruno Lopes, [email protected] (debug help)
Daniel Lafraia, [email protected] (source code addition)
Josh Karp, [email protected] (debug help for Solaris 8)
Klaus Steding-Jessen, [email protected] (debug help, lots of good
suggestions and Perl code for LKM checks)
Paulo C. Marques F., [email protected] (debug help)
Pedro Vazquez, [email protected] (lots of good suggestions)
Richard Eisenman, [email protected] (Red Hat support)
Manfred Bartz, [email protected] (debug help)
Luiz E. R. Cordeiro, [email protected] (debug help)
Vince Hillier, [email protected] (debug help)
Steve Campbell, [email protected] (Solaris bug fixes)
Strashimir Mihnev, [email protected] (new rootkit)
Patrick Duane Dunston, [email protected] (Adore LKM detection)
Rudolf Leitgeb, [email protected] (chklastlog bug fix)
Marcos Aguinaldo Forquesato, [email protected] (Solaris debug)
scz, [email protected] (check_wtmpx code)
Yaroslav Polyakov, [email protected] (inetdconf function)
Andreas Tirok, [email protected] (chklastlog patch)
Sean D. True (strings.c)
Leif Neland, [email protected] (duarawkz rootkit)
Kaveh Goudarzi (Pizdakit rootkit)
m0xx (monkit and Bobkit rootkits)
Bob Grabowsky and Mihai Sandu (t0rn v8.0 variant)
Razvan Cosma (new rootkit)
Kostya Kortchinsky (chkproc patch)
Frank Haverkamp (new rookit)
Ludovic Drolez (new rootkit)
Dan Irwin (new rootkit)
Anton Chuvakin (new rootkit)
Steve Collins (new rootkit)
Indra Kusuma (new rootkit)
Mark Newby (new rootkit)
anonymous (new rootkit)


11. ChangeLog
-------------

02/20/1997 - Initial release
02/25/1997 - Version 0.4, formal testing.
03/30/1997 - Version 0.5, suspect files routine added.
06/11/1997 - Version 0.6, minor fixes and Debian compatibility.
06/24/1997 - Version 0.7, FreeBSD compatibility fixed.
08/07/1997 - Version 0.8, yet another FreeBSD compatibility and
                           RedHat PAM fixed.
04/02/1998 - Version 0.9, new r00tkits versions support.
07/03/1998 - Version 0.10, another types of r00tkits supported.
10/15/1998 - Version 0.11, bug found by Alberto Courrege Gomide fixed.
11/30/1998 - Version 0.12, lrk4 support added.
12/26/1998 - Version 0.13, minor fixes for Red Hat and glibc users.
06/14/1999 - Version 0.14, Sun/Solaris initial support added.
04/29/2000 - Version 0.15, lrk5 features added and minor fixes.
07/09/2000 - Version 0.16, new r00tkits types support and contrib patches.
09/16/2000 - Version 0.17, more contrib patches, rootkit types and
                            Loadable Kernel Modules (LKM) trojan checking
                            added.
10/08/2000 - Version 0.18, new rookits types support and many bug fixes.
12/24/2000 - Version 0.19, -r, -p, -l options added.  ARK support
                            added.  Some bug fixes.
01/18/2001 - Version 0.20, Ramen Worm and latest t0rnkit detection,
                            temporay check for promisc mode disabled
                            on Solaris boxes.
01/19/2001 - Version 0.21, Corrects a bug in the Ramen Worm detection.
01/26/2001 - Version 0.22, chklastlog core dump bug fixed, login and
                            bindshell false positives fixed, cron test
                            improvement.
03/12/2001 - Version 0.23, lrk6, rh[67]-shaper, RSHA and Romanian
                            rootkit detection.  Test for shell history
                            file anomalies.  More ports added to the
                            bindshell test.
03/15/2001 - Version 0.23a fixes a bug found in the cron and
                            bindshell tests.

03/22/2001 - Version 0.30  lots of new tests added.  RK17 and Lion
                            Worm detection.
04/07/2001 - Version 0.31  new tests: gpm, rlogind, mgetty.  Adore
                            Worm detection.  Some bug fixes.
05/07/2001 - Version 0.32  t0rn v8, LPD Worm, kenny-rk and Adore LKM
                            detection. Some Solaris bug fixes.
06/02/2001 - Version 0.33  new tests added.  ShitC, Omega and Wormkit
                            Worm detection.  dsc-rootkit detection.
                            Some bug fixes.
09/19/2001 - Version 0.34  new tests added.  check_wtmpx.c added.
                            Ducoci rootkit and x.c Worm detection.
                            `-q' option added.
01/17/2002 - Version 0.35  tests added: lsof and ldsopreload.
                            strings.c added.  Ports added to the
                            bindshell test.  RST.b, duarawkz, knark
                            LKM, Monkit, Hidrootkit, Bobkit, Pizdakit,
                            t0rn v8.0 (variant) detection.
06/15/2002 - Version 0.36  test added: w.  chkproc.c additions.
                            Showtee, Optickit, T.R.K, MithRa's
                            Rootkit, George and SucKIT detection.

-------------- Thx for using chkrootkit ----------------
[macno@95 chkrootkit-pre-0.36]$ make sense
gcc -DHAVE_LASTLOG_H   -o chklastlog chklastlog.c
gcc -DHAVE_LASTLOG_H   -o chkwtmp chkwtmp.c
gcc -DHAVE_LASTLOG_H    -o ifpromisc ifpromisc.c
gcc  -o chkproc chkproc.c
gcc  -o check_wtmpx check_wtmpx.c
gcc -static  -o strings strings.c
[macno@95 chkrootkit-pre-0.36]$ ./chkrootkit
./chkrootkit need root privileges
[macno@95 chkrootkit-pre-0.36]$ su
Password:
[root@95 chkrootkit-pre-0.36]# ./chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not infected
Checking `grep'... not infected
Checking `hdparm'... not infected
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not tested
Checking `inetdconf'... not found
Checking `identd'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not infected
Checking `mail'... not infected
Checking `mingetty'... not infected
Checking `netstat'... not infected
Checking `named'... not found
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not infected
Checking `rlogind'... not found
Checking `rshd'... not found
Checking `slogin'... not infected
Checking `sendmail'... not infected
Checking `sshd'... not infected
Checking `tcpd'... not infected
Checking `top'... not infected
Checking `telnetd'... not infected
Checking `timed'... not found
Checking `traceroute'... not infected
Checking `w'... not infected
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl5/5.6.1/i386-linux/.packlist

Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... nothing detected
Checking `rexedcs'... not found
Checking `sniffer'...
eth0 is not promisc
Checking `wted'... nothing deleted
Checking `z2'...
nothing deleted