Computer e network forensics, esercizio
gennaio 19th, 2008
Lance Mueller, curatore di Computer Forensics, Malware Analysis & Digital Investigations, propone una prova pratica. Scenario:
“Un utente aziendale si accorge del comportamento anomalo della propria workstation con Win Xp Home, segnala il fatto allo staff IT che, intervenuto, si accorge che dal pc vengono attivate centinaia di connessioni.
Il personale dello staff IT allerta quello della sicurezza di rete, che effettua un dump (tcpdump) dei dati in transito (230 kb) , quindi l’host viene scollegato dalla rete e ne viene fatta l’immagine in EnCase evidence format(400 Mb).
Le vostre valutazioni e soluzioni sono ben accette.
*************************************************************************************
Update 21 gennaio 2008:
Dopo due giorni l’articolo ha collezionato solo il commento di “pippo”, quindi provo a scrivere qualche cosa, almeno stimolerò qualche lettore a dire la sua, giusto per il gusto di bastonarmi un poco evidenziando le mie lacune di networking! 
Dopo aver scaricato i file forniti da Lance Mueller ho subito dato un’occhiata al dump di rete.
Si nota che dall’host 192.168.126.128 partono una gran quantità di connessioni, o come ha fatto notare “pippo” di SYN, verso altri host.
Seguendo il flusso TCP con Wireshark possiamo notare che l’host compromesso avvia l’handshake a tre vie, verso gli altri host, vi è infatti l’invio del pacchetto con il SYN=1, il destinatario risponde con l’ACK=1 ma, contrariamente a quanto troviamo nelle descrizioni dell’handeshake (paragrafo 1.2.2), non è presente il flag di SYN=1.
La cosa mi ha incuriosito. Non so se dipenda dalla virtualizzazione degli host, ma mi è parsa anomala. La documentazione spiega che al SYN dell’host A (immagine sottostante “1″), l’host B può rispondere con:
-ACK=1 e SYN=1 se il servizio è disponibile (immagine sottostante “2″). A questo punto l’host A risponde con un altro ACK, incrementando il numero di sequenza (immagine sottostante “3″), dopodiché la comunicazione può cominciare;
-RESET=1 se il servizio non è disponibile e l’host B rifiuta la connessione.
Altra anomalia è, appunto, che l’host compromesso non risponde con l’ACK=1, ma ripete il SYN.
L’host B interpretando il secondo SYN di A come una perdita di pacchetto, risultante nella mancata ricezione del 2 punto dell’handshake, duplica il pacchetto di ACK, come mostrato nell’immagine sottostante, a cui tuttavia l’host
compromesso non risponde più, interrompendo la fase preparatorio per la connessione.
Questo comportamento farebbe pensare ad un tentativo da parte dell’host compromesso di verificare se sugli altri host sono aperte determinate porte.
Relativamente a ciò, analizzando il dump ci si accorge che l’host compromesso volge la propria attenzione alle porte mostrate nell’immagine seguente,
ma non su ogni host, bensì una sola per host, non ho francamente compreso con quale criterio.
Tutto il dump è composto in questo modo, non compare alcuno scambio di dati, e la mia striminzita analisi dello stesso è così terminata.
Ho quindi rivolto l’attenzione all’immagine forense, realizzata nel formato di Encase.
Usando Autopsy con Linux non esistevano problemi ad anlizzare l’immagine fornita da Mueller, in quanto Autopsy è in grado di accedervi, tuttavia preferivo trasformarla in un formato più facilmente utilizzabile sul mio pinguino, così da poterla montare quale device, per potervi fare una scansione con gli anti-virus e, montandola sotto Windows, con i tool di anti-rootkit per la piattafroma specifica.
Per ottenere dall’immagine di Encase un file raw (tipo dd per intenderci) ho usato FTK Imager, che ho installato con successo su Linux con Wine.
Ogni mio dubbio sul corretto funzionamento è svanito quando ho verificato che l’hash calcolato sull’immagine dd coincideva con quello immagazzinato all’interno del file di Encase, che avevo già verificato con FTK Imager.
Non avevo mai manipolato immagini realizzate nel formato di Encase e devo dire di essere rimasto favorevolmente colpito dal grado di compressione consentito! Il file da 387 Mb fornito da Mueller, si è infatti trasformato in un immagine dd di ben 2 giga!! Spettacolare!! 
A questo punto ho montato l’immagine dd e ho usato Avast (per Linux workstation) ed F-prot per verificare la presenza di virus.
Avast ha individuato in /tmp/test/WINDOWS/system32/inetsrv/rpcall.exe un trojan, nello specifico Win32:Rizo-E, identificazione di Virus Total.
F-prot, all’ultima versione presente sul sito della casa madre, non ha individuato nulla nel file appena citato, riconoscendo comunque due differenti minacce:
[Found possible security risk]
identificazione di Virus Total
[Found downloader]
identificazione di Virus Total
Non contento dei risultati contrastanti, ho montato l’immagine sotto Helix v.1.9 ed ho aggiornato e lanciato ClamAv che…non ha individuato alcuna minaccia 
Il passo successivo è stato analizzare i file di log di Windows, attività per la quale ho utilizzato Event Log Explorer da Windows, sotto Wine non dava alcun risultato, i log apparivano vuoti.
L’analisi, superficiale lo ammetto (come scrive “pippo”: il tempo è tiranno), non ha evidenziato anomalie di rilievo.
Qui mi sono fermato, per ora.
In un caso reale si potrebbe controllare la presenza di rootkit, i siti visitati dall’utente al fine di comprendere se abbia frequentato siti a rischio, noti per diffondere malware, e successivamente compromettere una macchina virtuale, creata identica a quella in esame, con i malware individuati per comprendere se effettivamente l’anomalo comportamento in rete fosse ascrivibile a quanto individuato.
Se trovo il tempo eseguirò una scansione alla ricerca di rootkit e un’esame della cronologia..se trovo il tempo, nel qual caso seguirà un secondo update.
Il gioco con la macchina virtuale lo lascio ad altri.
Mi farebbe piacere se qualcuno, più esperto del sottoscritto, avesse voglia di spendere qualche minuto in questa piccola sfida, almeno ad illustrare altre possibili e più approfondite condotte di analisi.
*************************************************************************************
Update 2 febbraio 2008:
Ecco le soluzioni postate direttamente dall’autore.
Riferimenti:
-Packet forensics using TCP
-Il software di rete;
-TCP (Transmission Control Protocol)
-TCP Analysis – Section 4: TCP Flag Options
-TCP Analysis Based on Flags;
-Introduzione alle reti di calcolatori;
-TCP: Transport Control Protocol – Ottimizzazioni del protocollo;
-Programmazione in rete;
-Honeypots: inganno o realtà?
Leave a Reply