
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
Archivio: Novembre 2004 ml@sikurezza.org Soggetto: Re: [ml] processi nascosti e compagni bella Mittente: Alessandro Barenghi Data: Fri, 19 Nov 2004 17:57:17 +0100 (CET)
On Wednesday 17 November 2004 18:10, koba@xxxxxxxxxxxxx wrote:
> http://www.expita.com/nomime.html
> Configuring Mail Clients to Send Plain ASCII Text
>
> ----- Forwarded message from Daniel Marzini
> <lazzaro.marzini(at)fastwebnet.it> ----- From: "Daniel Marzini"
> <lazzaro.marzini(at)fastwebnet.it>
> Subject: processi nascosti e compagni bella
>
> Buongiorno Signori,
> mi trovo, almeno per me, una situazione abbastanza strana;
> ho una macchina con slackware 9.1, httpd (1.3.33 l' ultima versione
> fornita da swaret e aggiornato non appena possibile ogni volta) e
> proftpd. a parte i vari sorgenti c che cercano di essere compilati
> dalla /tmp con privilegi di apache che non vanno mai a buon fine perche'
> non c'e' alcun compilatore; mi trovo con due processi (un finto
> /usr/sbin/httpd e un finto proftpd (accepting connection).
>
> dapprima chkrootkit mi diceva di trovare 9 processi nascosti;
> ho parato il colpo con un nuovo kernel compilato da zero e senza
> supporto dei moduli, a distanza di tempo, i processi sono diventati 14
> di cui 2 sono quelli sopra. come e' possibile?
è possibile che , se hai ricompilato il kernel sulla macchina compromessa, il
kernel sia comunque stato modificato o tramite patching dei sorgenti o
tramite infezione dei simboli dei binari già compilati....nel caso tu abbia
compilato su un' altra macchina sicura , allora dimentica quello che ho
detto.
> guardando le descrizione dei due pid nel /proc non riesco ad arrivare a
> capire dove si trovano gli eseguibili. potrei fare l' upgrade della
> versione d da 9.1 a 10.0 ma rischio di perdermi la macchina; so che una
> volta bucata, il modo piu' sicuro e piallarla ma in questo momento
> proprio non posso.
un trucchetto interessante potrebbe essere dumpare l' immagine del processo in
running , controllare che stringhe testuali ci sono presenti , (strings
<nomedeldumpdelprocesso> ) e usare fgrep per trovare le stringhe più insolite
( il nome del rootkit per esempio) nei file visibili.
Nel caso questo non rivelasse nulla , allora è probabile che il rootkit chiami
una unlink() su sè stesso non appena parte in modo da farsi sparire dal
filesystem.A questo punto , se proprio ci tieni a vedere da dove diavolo è
stato lanciato puoi sempre usare grep sull' intera partizione (meglio su un'
immagine copiata in modo sicuro su un' altra macchina) e vedere dove si trova
il file (che è ancora vivo dato che essendo il rootkit in running ha ancora
un fd aperto) oppure puoi darti all' analisi direttamente del dump.
Ovviamente qualunque analisi tu conduca sulla macchina va fatta con strumenti
compilati staticamente su una macchina sicura onde evitare di incorrere in
tool modificati facenti parte del rootkit.
Ciao
Alessandro
--
--------------------------------------------------------------------------------
The only secure computer is one that is turned off, locked in a safe
and buried 20 feet down in a secret location, and I'm not completely confident
of that either.
-- Bruce Schneier
--------------------------------------------------------------------------------
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005