[Outofthebox] riflessioni forensi
Angelo Dell'Aera
buffer at olografix.org
Wed Aug 31 16:46:11 CEST 2005
Ultimamente mi sta appassionando l'analisi forense. Adoro l'idea di
ripercorrere i percorsi mentali di un attaccante. Se poi e' molto
preparato e' ancora piu' divertente.
Stamattina pensavo a una conversazione avuta con un ragazzo che conosco
di una forense che ha fatto di recente. Mi diceva che, di solito in
questo tipo di attivita', dopo aver provveduto ad isolare dalla rete
l'host compromesso, tira via brutalmente l'alimentazione per ridurre al
minimo le operazioni sul disco e poi effettua un dump del disco montato
in read-only. Da quello che ho visto e' un modo piuttosto classico di
procedere per salvaguardare mtime, atime e ctime di file e directory.
Mi sono chiesto se fosse davvero la maniera migliore per procedere e la
risposta che mi sono dato e' no. Non so perche' va a sempre a finire
cosi' ma forse e' l'eta' che avanza che mi rende insofferente nei
confronti di tutto e tutti... :)
Mi sono detto "vediamo cosa possiamo perderci spegnendo l'host". E qui
e' cominciato il gioco.
Ho puntato la mia attenzione su syslog perche' i log sono sempre un
obiettivo primario di un attaccante che abbia compromesso una macchina.
Per le mie elucubrazioni mentali mi sono servito di The Coroner's
Toolkit di Farmer e Venema. Lo so che esiste sleuthkit ma TCT e' altra
cosa ne converrete.
Ho cominciato a tirare fuori il pid del mio syslog-ng
root a alnitak:~ # ps aux | grep syslog
root 12798 0.0 0.0 1676 664 ? Ss 15:35 0:00
/usr/sbin/syslog-ng
A quel punto ho sfruttato logger(1) per iniettare un messaggio nel mio
/var/log/messages. Mi sono sempre chiesto quale fosse lo scopo ultimo di
logger(1) ma questa e' un'altra storia.
root a alnitak:~ # logger Aieeee!
root a alnitak:~ # tail -n 3 /var/log/messages
Aug 31 15:35:42 alnitak syslog-ng[12798]: syslog-ng version 1.6.8
starting
Aug 31 15:35:42 alnitak syslog-ng[12798]: Changing permissions
on special file /dev/tty12
Aug 31 15:35:53 alnitak buffer: Aieeee!
Bene. A questo punto, non avendo mai visto i sorgenti di syslog-ng,
posso immaginare come avvenga la fase di scrittura. Nel codice si fara'
uso di un buffer probabilmente circolare in modo da poter evitare una
scrittura su disco ogni qualvolta qualcuno ne faccia richiesta. Ma se
cosi' fosse dovrei trovarne traccia nella memoria del processo. E qui ho
sfoderato TCT...
NAME
pcat - copy process memory
root a alnitak:~ # pcat 12798 | strings | grep Aie
<13>Aug 31 15:35:53 buffer: Aieeee!
buffer: Aieeee!
Aug 31 15:35:53 alnitak buffer: Aieeee!
Aug 31 15:35:53 alnitak buffer: Aieeee!
Aug 31 15:35:53 alnitak buffer: Aieeee!
Forse non mi ero sbagliato allora. Decido di editare /var/log/messages
e di cancellare la riga iniettata.
root a alnitak:# vi /var/log/messages
root a alnitak:~ # tail -n 3 /var/log/messages
Aug 31 13:20:01 alnitak cron[11504]: (root) CMD (test -x
/usr/sbin/run-crons && /usr/sbin/run-crons )
Aug 31 15:35:42 alnitak syslog-ng[12798]: syslog-ng version 1.6.8
starting
Aug 31 15:35:42 alnitak syslog-ng[12798]: Changing permissions on
special file /dev/tty12
Controlliamo di nuovo...
root a alnitak:~ # pcat 12798 | strings | grep Aie
<13>Aug 31 15:35:53 buffer: Aieeee!
buffer: Aieeee!
Aug 31 15:35:53 alnitak buffer: Aieeee!
Aug 31 15:35:53 alnitak buffer: Aieeee!
Aug 31 15:35:53 alnitak buffer: Aieeee!
Uhm e' ancora tutto li' a quanto pare...
Vediamo che succede se faccio ripartire syslog-ng
root a alnitak:~ # /etc/init.d/syslog-ng restart
* Stopping syslog-ng ... [ ok ]
* Starting syslog-ng ... [ ok ]
root a alnitak:~ # ps aux | grep syslog
root 13000 0.0 0.0 1676 636 ? Ss 15:58 0:00
/usr/sbin/syslog-ng
root a alnitak:~ # /usr/lib/tct/bin/pcat 13000 |strings | grep Aie
root a alnitak:~ #
Tutto andato come era facile immaginare. A questo punto ho gia'
giustificato la mia insofferenza senile ma non voglio fermarmi qui.
Qualche tempo fa mi capito' di leggere la descrizione degli internals di
inotify che dovrebbe essere il naturale sostituto di dnotify. Per chi
non sapesse di cosa si parla, inotify e' un file change notification
system. Se avete mai usato un filesystem manager che sfrutti una GUI
sapete gia' di che si tratta. Quando un file viene ad esempio cancellato
il vedere la sua icona che scompare e amenita' del genere sono esempi di
sistemi di questo tipo.
Dnotify era vecchio come concetto perche' per monitorare lo stato del
file lo apriva e faceva polling sui suoi attributi per vedere se
qualcosa fosse cambiato. E questo, parlando in termini forensi, e' una
fregnaccia senza eguali perche' modifica l'atime del file.
Di contro, inotify sfrutta la char device /dev/inotify che viene usata
per lo stesso scopo. Quando un file viene registrato la char device
notifica eventuali cambiamenti al processo che ha registrato l'inotify.
In termini piu' tecnici il processo non deve fare polling sul file
descriptor del file da monitorare ma sul file descriptor della char
device. Chi ha usato la select(2) una volta nella vita sa che il suo
comportamento di default e' bloccante e quindi i vantaggi sono evidenti.
Inoltre inotify non accede al file e quindi non modifica l'atime.
Dove voglio arrivare?
Mi sto chiedendo come mai nessuno abbia mai pensato di integrare un
meccanismo di sicurezza in syslog e affini del tipo
1. registro il file di log in inotify
2. quando viene notificato a syslog un cambiamento sul file di log se il
cambiamento non e' causato da syslog stesso dumpo tutto quello che c'e'
nel buffer (gli ultimi eventi sono di sicuro i piu' "scottanti") ed
effettuo un'azione potenzialmente definita dall'amministratore.
Che ne pensate?
Regards.
--
Angelo Dell'Aera 'buffer'
Antifork Research, Inc. http://buffer.antifork.org
Metro Olografix
PGP information in e-mail header
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome: non disponibile
Tipo: application/pgp-signature
Dimensione: 189 bytes
Descrizione: non disponibile
Url: https://www.olografix.org/pipermail/outofthebox/attachments/20050831/beff40d6/attachment.bin
More information about the Outofthebox
mailing list