analisi dei virus

Corso di Basi di Dati
Prof.ssa Anna Maria Carminelli Gregori
Università degli Studi di Trieste
Anno Accademico 2003-2004
REALIZZAZIONE DI UN
DATABASE PER
L’ANALISI DEI VIRUS
di
Martino Jerian
Michele Crevatin
Massimiliano Miani
Roberto Rodaro
Mitja Giaconi
SOMMARIO
1. Introduzione
2. I monitor di sistema
3. Utilizzo dei monitor
4. I convertitori
5. Realizzazione dei database
5.1 Le macro
5.3 Le query
6. Analisi dei virus
6.1 Il virus ColdApe
6.2 Il virus Msblast
6.3 Il virus Nimda
6.4 Un virus di tipo trojan
6.5 Un virus sconosciuto (“mah”)
7. Conclusioni e riferimenti
Appendice: Codice C dei convertitori
handle_converter.cpp
listdlls_converter.cpp
mon_converter.cpp
2
1. INTRODUZIONE
La diffusione dei virus è probabilmente uno dei problemi più gravi della sicurezza informatica
odierna; basta connettersi a un server amministrato con poca cautela, o scaricare un messaggio di
posta elettronica senza effettuare controlli accurati con un antivirus costantemente aggiornato, per
essere soggetti all’infezione di un virus sul proprio calcolatore.
Nel presente progetto si sono presi in esame cinque diversi virus, alcuni dei quali, come MSblast,
hanno recentemente creato problemi consistenti alla rete informatica mondiale; si è condotta
l’analisi osservando il comportamento del sistema infetto sia dal punto di vista macroscopico, cioè
prendendo nota degli effettivi problemi che un utente comune può riscontrare, sia da un punto di
vista più tecnico, monitorando con gli strumenti software appropriati quali siano le parti del sistema
che vengono intaccate.
A tale scopo si è utilizzato il software Vmware, che permette di lavorare con delle macchine
virtuali, evitando così di infettare il sistema reale e quindi di dover conseguentemente reinstallare il
sistema operativo dopo ogni prova. Lo stato della macchina e delle operazioni effettuate sulle sue
risorse prima e dopo l’inoculazione dei virus è stata effettuata tramite dei monitor freeware creati
dalla SysInternals.
Sono stati quindi creati dei semplici programmi in linguaggio C per convertire l’output di tali
monitor in file facilmente importabili da Microsoft Access 2002 in modo tale da poter creare vari
database contenenti le informazioni relative agli effetti che ciascun virus provoca sul sistema.
3
Sono di seguito riportati due diagrammi indicanti in maniera riassuntiva tutto il lavoro svolto.
Il primo diagramma, molto semplice, riassume il lavoro preparatorio allo sviluppo del progetto
vero e proprio, ossia capire quali monitor siano risultati effettivamente utili ed utilizzabili e quali
no.
monitor Sysinternals:
Diskmon
Filemon
Regmon
Portmon
TDImon
TCPview
ListDLLs
Handle
Netstat
ProcessExplorer
analisi:
quali sono
davvero utili?
Handle
ListDLLs
Filemon
Regmon
Il progetto vero e proprio è riassunto nel secondo diagramma; esso riassume infatti tutte le
operazioni fatte per analizzare l’influenza di un singolo virus sul sistema. Si intende quindi che il
grafico riguarda le operazioni fatte per analizzare un solo virus, tutto il procedimento è stati
infatti svolto per 5 volte, una per ogni virus inoculato nel sistema.
4
analisi "UMANA" dei
risultati
importazione in Access:
macro dlls_tables
macro handle_tables
macro filemon_tables
macro regmon_tables
esecuzione convertitori:
handle_converter.exe handlelog_clean.txt handlelog_clean.log
listdlls_converter.exe dllslog_clean.txt dllslog_clean.log
mon_converter.exe filemon_clean.txt filemon_clean.log
mon_converter.exe regmon_clean.txt regmon_clean.log
esecuzione convertitori:
handle_converter.exe handlelog_virus.txt handlelog_virus.log
listdlls_converter.exe dllslog_virus.txt dllslog_virus.log
mon_converter.exe filemon_virus.txt filemon_virus.log
mon_converter.exe regmon_virus.txt regmon_virus.log
esecuzione monitor:
Handle ListDLLS
Filemon Regmon
esecuzione monitor:
Handle ListDLLS
Filemon Regmon
sistema
"PULITO"
inoculazione del virus
tabelle in Access:
dllslog_clean
handlelog_clean
filemon_clean
regmon_clean
5
sistema
"INFETTO"
handlelog_clean.log
listdllslog_clean.log
filemon_clean.log
regmon_clean.log
handlelog_virus.log
listdllslog_virus.log
filemon_virus.log
regmon_virus.log
handlelog_clean.txt
listdllslog_clean.txt
filemon_clean.txt
regmon_clean.txt
handlelog_virus.txt
listdllslog_virus.txt
filemon_virus.txt
regmon_virus.txt
tabelle in Access:
dllslog_virus
handlelog_virus
filemon_virus
regmon_virus
analisi delle differenze con le query:
dlls_in_clean_not_virus
dlls_in_virus_not_clean
handle_in_clean_not_virus
handle_in_virus_not_clean
filemon_virus_events
regmon_virus_events
GOAL!
Informazioni sugli effetti provocati dal virus
2. I MONITOR DI SISTEMA
Gli strumenti software che sono stati utilizzati sono disponibili gratuitamente sul sito del
produttore, www.sysinternals.com.
Viene riportata la lista dei monitor di cui si è sperimentato l’utilizzo e le funzionalità.
•
•
•
•
•
•
•
•
•
•
Diskmon: visualizza l’attività del sistema sull’hard disk;
Filemon: visualizza l’attività del sistema sui file;
Regmon: visualizza l’attività del sistema sui registri;
Portmon: visualizza l’attività del sistema sulle porte seriali e parallele;
TDImon: visualizza l’attività UDP e TCP del sistema (a livello di trasporto);
TCPview: visualizza l’attività sulle porte aperte e i relativi processi che si appoggiano a TCP
e UDP;
ListDLLs: visualizza le librerie di sistema utilizzate (programma DOS);
Handle: visualizza tutti i puntatori ai file utilizzati dal sistema (programma DOS);
Netstat: visualizza lo stato delle porte di sistema (programma DOS);
ProcessExplorer: visualizza tutti i processi attivi del sistema e i dettagli sulla loro
esecuzione.
Non tutti i risultati forniti dai monitor sono pronti per un’analisi diretta o per l’inserimento in un
database; infatti, mentre i software in DOS visualizzano lo stato del sistema in un determinato
momento generando risultati pronti per essere confrontati (i record sono contemporanei), i software
che sono provvisti di un’interfaccia grafica mostrano sequenzialmente le operazioni fatte dal
sistema sulla risorsa monitorata e non sono quindi confrontabili in maniera immediata. Per fare un
esempio, da Diskmon non si raccoglierà materiale facilmente interpretabile: questo perchè le attività
sull’hard disk sono non deterministiche e non ripetibili, quindi, monitorando gli eventi che
avvengono in due istanti differenti, nonostante lo stato del sistema sembri essere lo stesso, si
avranno sempre e comunque esiti differenti (ad esempio a causa della scrittura su disco della
memoria virtuale).
Sebbene tutti i monitor siano stati testati a fondo per verificarne l’effettiva utilità, la maggior
parte del lavoro è stata delegata a ListDLLs e Handle per quanto riguarda il monitoraggio dello stato
del sistema e a Filemon e Regmon per visualizzare le operazioni effettuate dai virus sulle risorse del
sistema.
6
Per quanto concerne gli altri monitor essi non sono stati utili per vari motivi:
•
•
•
•
Diskmon, per quanto detto sopra, fornisce informazioni non facilmente interpretabili;
ProcessExplorer raccoglie per lo più informazioni sui processi che possono essere rilevate
anche dagli altri programmi; utilizza però una propria interfaccia e non un output testuale,
pertanto le informazioni da esso fornite non sono facilmente integrabili in un database;
Portmon visualizza l’attività sulle porte seriali e parallele, che normalmente non vengono
utilizzate dai virus (sarebbe tuttavia interessante avere a che fare con un virus che si serva
della stampante invece che del monitor come output);
Netstat, TDImon e TCPview sarebbero potuti essere veramente molto interessanti per il
nostro lavoro, in quanto visualizzano informazioni riguardanti la comunicazione del sistema
con l’esterno, gli IP address contattati, le porte locali e remote a cui si è connessi, e così via.
Tuttavia, per ovvi motivi di sicurezza, il calcolatore su cui sono state eseguite le prove di
inoculazione è stato mantenuto isolato dalla rete dell’università rendendo impossibile
rilevare attività di questo tipo; è stata così penalizzata gravemente l’analisi dell’infezione di
alcuni virus, specialmente quelli di tipo worm e trojan che fanno mass mailing o si collegano
a determinati indirizzi IP.
Ricordiamo che per ragioni di sicurezza si è utilizzato l’applicativo VMware, che permette di
lavorare in un sistema operativo virtuale: in tale maniera anche in caso di problemi il sistema reale
non viene compromesso; tale operazione non crea alcun tipo di restrizione nell’analisi: il sistema
virtuale si comporta esattamente come quello reale (eccetto per la velocità, ovviamente penalizzata).
Il sistema operativo installato sulla macchina reale è Microsoft Windows XP, mentre quello della
macchina virtuale è Microsoft Windows 2000.
Non potendo disporre di un accesso alla rete, si è tentato di ricreare anche un ambiente virtuale
per la posta elettronica, eseguendo sulla stessa macchina (virtuale) il programma client per la posta
(Outlook Express) e un programma che facesse fare al nostro computer anche la funzione di mail
server (ArGoSoft Mail Server).
Il server fittizio (prova1.com) è stato testato con degli utenti virtuali ([email protected],
[email protected], ...). I monitor Netstat, TDImon e TCPview sono stati utilizzati per rilevare
l’attività del sistema non infetto nell’invio e ricezione di mail e le prove hanno dato tutte esito
positivo. Purtroppo tale esito non si è ripetuto nell’inoculazione dei virus; non è stato possibile
ingannare alcun virus sull’esistenza di una rete e i monitor non hanno rilevato alcuna attività sulle
porte di comunicazione da parte di applicazioni sospette. Per visualizzare la completa attività dei
virus servirebbe avere una connessione a Internet completa e reale; i virus più potenti non si
accontentano più della posta elettronica ma sfruttano i bachi dei programmi di gestione dei server
web per diffondersi o direttamente tramite lan.
7
3. UTILIZZO DEI MONITOR DI SISTEMA
Verranno ora analizzati più in dettaglio i monitor che si sono dimostrati effettivamente utili al
fine dell’analisi.
Handle e ListDLLs sono dei programmi sviluppati per DOS che visualizzano in uscita
rispettivamente i puntatori ai file e le librerie utilizzate dal sistema nel momento in cui vengono
avviati. Il loro output può essere facilmente rediretto dallo schermo alla scrittura su file.
Sono stati creati dei semplici script con il linguaggio batch di MS-DOS per automatizzare l’avvio
di tali monitor, la redirezione del loro output dallo schermo a un file e la successiva conversione in
un formato facilmente importabile da Microsoft Access 2002 tramite dei programmi scritti in
linguaggio C.
La procedura seguita è l’avvio di questi monitor prima e dopo l’inserimento di un virus per
visualizzare le differenze che questo apporta al sistema. Si è cercato di lasciare lo condizioni di
background del sistema quanto più simili possibile fra il primo e il secondo lancio in modo da
potersi rendere effettivamente conto di quali parametri mutino in relazione alla presenza del virus e
non a causa di un ambiente di lavoro differente.
Filemon e Regmon sono invece dei programmi sviluppati per ambiente Windows e dotati quindi
di interfaccia grafica; come già accennato essi non visualizzano lo stato del sistema in un
determinato momento ma una lista sequenziale delle operazioni eseguite sui file (Filemon) o sui
registri di sistema (Regmon) dall’istante di avvio del programma fino a che non si interrompe il
monitoraggio. A questo punto l’output può essere salvato in un file, sempre tramite interfaccia
grafica. Vista la natura dei programmi non è stato possibile implementare in maniera immediata
un’automatizzazione di questa procedura, peraltro molto semplice, che è stata quindi effettuata
manualmente.
Non vengono analizzati in questa sede i dati forniti in output dai monitor. Essi sono infatti
consistenti (anche se in formato diverso) con quelli che verranno poi importati nei database. Questi
ultimi verranno analizzati a fondo successivamente.
8
4. I CONVERTITORI
Come già accennato, si è rivelato necessario scrivere dei semplici programmi in C atti a
convertire i file di log generati dai monitor in un formato che potesse essere facilmente importabile
in Access.
Sono stati creati tre programmi:
•
•
•
handle_converter.exe: relativo all’uscita del monitor Handle, funzionante in ambiente DOS;
listdlls_converter.exe: relativo all’uscita del monitor ListDLLs, funzionante in ambiente
DOS;
mon_converter.exe: relativo all’uscita dei due monitor regmon e filemon, entrambi
sviluppati per ambiente Windows.
Per automatizzare il lavoro di conversione sono stati generati dei file batch per DOS tali da
eseguire i monitor (almeno quelli sotto DOS) e convertirne direttamente il risultato. Si veda la fine
del paragrafo per il loro listato.
I programmi handle_converter.exe e listdlls_converter.exe funzionano in modo molto simile: di
seguito sono riportate da esempio alcune linee del file generato dal monitor Handle e le stesse dopo
l’applicazione di handle_converter.exe.
Handle v2.10
Copyright (C) 1997-2003 Mark Russinovich
Sysinternals - www.sysinternals.com
-----------------------------------------------------------------------------System pid: 4 NT AUTHORITY\SYSTEM
2e8: File
C:\WINDOWS\CSC\00000001
5b8: File
C:\pagefile.sys
5bc: File
C:\Documents and Settings\LocalService\NTUSER.DAT
5c8: File
C:\Documents and Settings\NetworkService\NTUSER.DAT
5d0: File
C:\WINDOWS\system32\config\SECURITY
5d4: File
C:\WINDOWS\system32\config\SECURITY.LOG
5dc: File
C:\WINDOWS\system32\config\software
5e0: File
C:\WINDOWS\system32\config\software.LOG
5e4: File
C:\hiberfil.sys
9
System|4|NT AUTHORITY\SYSTEM| 2e8|File|C:\WINDOWS\CSC\00000001
System|4|NT AUTHORITY\SYSTEM| 5b8|File|C:\pagefile.sys
System|4|NT AUTHORITY\SYSTEM| 5bc|File|C:\Documents and Settings\LocalService\NTUSER.DAT
System|4|NT AUTHORITY\SYSTEM| 5c8|File|C:\Documents and
Settings\NetworkService\NTUSER.DAT
System|4|NT AUTHORITY\SYSTEM| 5d0|File|C:\WINDOWS\system32\config\SECURITY
System|4|NT AUTHORITY\SYSTEM| 5d4|File|C:\WINDOWS\system32\config\SECURITY.LOG
System|4|NT AUTHORITY\SYSTEM| 5dc|File|C:\WINDOWS\system32\config\software
System|4|NT AUTHORITY\SYSTEM| 5e0|File|C:\WINDOWS\system32\config\software.LOG
System|4|NT AUTHORITY\SYSTEM| 5e4|File|C:\hiberfil.sys
Fondamentalmente il lavoro compiuto dagli script consiste nel copiare ogni gruppo di dati (ossia
il processo a cui essi si riferiscono, il process id e il proprietario del processo) all’inizio di ogni
linea.
Ogni linea, dopo l’importazione in Access, costituirà un record. I vari campi di ogni record sono
separati dal simbolo di pipe (“ | ”).
Il mon_converter.exe è utilizzato da entrambi i monitor Regmon e Filemon ed è notevolmente più
semplice. I due programmi forniscono dei file di log in cui i vari campi sono separati dal carattere
tab. L’unico problema è che il nome dei processi è separato dal rispettivo process id dal carattere
due punti (“ : “) invece che da tab. Tutto ciò che fa mon_converter.exe è sostituire il primo carattere
“:“ di ogni linea con il carattere TAB.
L’utilizzo dei tre convertitori è molto semplice, essi vengono lanciati da DOS chiamando il loro
nome seguito dal file che si vuole generare in uscita come primo parametro e dal file in ingresso
come secondo parametro. In pratica, dal prompt di DOS:
•
•
•
handle_converter fileoutput.txt fileinput.txt
listdlls_converter fileoutput.txt fileinput.txt
mon_converter fileoutput.txt fileinput.txt
Per chi fosse interessato in appendice sono riportati i listati dei tre programmi.
Segue ora il listato del file batch innesco.bat relativo all’avvio e conversione dei dati dei monitor
Handle e ListDLLs:
handle > c:\risulatati\handle.log
listdlls > c:\risulati\dlls.log
handle_converter c:\risultati\handlelog.txt c:\risultati\handle.log
listdlls_converter c:\risultati\dllslog.txt c:\risultati\dlls.log
10
Per quanto riguarda i monitor in ambiente Windows non è stato realizzato alcun file batch, in
quanto il loro avvio è stato seguito manualmente e separatamente e quindi anche la loro conversione
è stata effettuata separatamente e direttamente da linea di comando:
•
•
•
•
per Filemon, dopo aver salvato il file di log c:\risulati\filemon.log
mon_converter c:\risulatati\filemon.txt c:\risultati\filemon.log
per Regmon, dopo aver salvato il file di log c:\risulati\regmon.log
mon_converter c:\risulatati\regmon.txt c:\risultati\regmon.log
Vengono generate molte versioni di questi file, relative al sistema pulito e a quello che si ottiene
dopo l’innesco di ogni virus. Quindi sarà opprtuno rinominare i file e porre ognuno nella directory
in cui risiede il database relativo al virus preso in esame di volta in volta.
In particolare si è adottata la convenzione di aggiungere a ogni file di tipo txt il suffisso _clean o
_virus a seconda che sia relativo a un sistema pulito o infetto; ad esempio, i file handlelog.txt
generati prima e dopo l’inoculazione dei virus sono stati rinominati rispettivamente
handlelog_clean.txt e handlelog_virus.txt
11
5. REALIZZAZIONE DEI DATABASE
5.1 Organizzazione dei dati
I dati da importare in Access per l’analisi sono stati situati in cinque distinte directory, una per
ogni virus che è stato inoculato nel sistema. A ogni directory corrisponde un virus e
conseguentemente è stato realizzato un database diverso per ognuno dei virus.
Le directory presenti sono:
•
•
•
•
•
msblast: relativa al virus conosciuto come Msblast, W32/blast, Blasterworm o Lovsan;
nimda: relativa al virus Nimda;
coldape: relativa al virus ColdApe;
trojan: relativa a un virus di tipo trojan non meglio identificato;
mah: relativa a 4 file contenenti un virus non meglio identificato;
In ogni directory sono presenti i file:
•
•
•
•
•
general.mdb: il database di Access; in origine il file è identico in ogni directory: esso
contiene quattro macro e sei query; quando le macro vengono avviate esse importano nel
database i file di testo presenti nella directory corrente, contenenti le informazioni fornite dai
monitor;
dllslog_clean.txt e dllslog_virus.txt: file di testo relativi al monitor ListDLLs contenenti
rispettivamente i dati prima e dopo l’inoculazione del virus;
handlelog_clean.txt e handlelog_ virus.txt: file di testo relativi al monitor Handle contenenti
rispettivamente dati prima e dopo l’inoculazione del virus;
filemon_clean.txt e filemon_virus.txt: file di testo relativi al monitor Filemon contenenti
rispettivamente dati prima e durante l’inoculazione del virus;
regmon_clean.txt e regmon_virus.txt: file di testo relativi al monitor Regmon contenenti
rispettivamente dati prima e durante l’inoculazione del virus.
A partire dai file txt presenti nella directory verranno generate, tramite le macro, le tabelle il cui
contenuto sarà poi confrontato dalle query.
12
5.2 Le macro
Cliccando sulle varie macro i file di testo creati possono essere importati in Access.
Se le operazioni effettuate dalle macro sono andate a buon fine cliccando sul menù Tables si
possono vedere le seguenti tabelle. A volte possono comparire (come in questo caso) delle tabelle
relative a errori di importazione: ciò succede perchè l’importatore è soggetto ad alcuni limiti, ad
esempio la lunghezza di qualche campo di un record è più lunga del limite massimo di caratteri
accettato, tuttavia l’analisi successiva dei dati può essere fatta comunque senza alcun problema.
Segue un’analisi dettagliata di tutte le macro.
13
La macro dlls_tables
Genera due tabelle dllslog_clean e dlls_virus, importando rispettivamente i file
dllslog_clean.txt e dllslog_virus.txt che si trovano nella stessa directory del file general.mdb
corrente. I dettagli dell’importazione vengono definiti tramite il dllslog Import Specification
secondo le specifiche seguenti: a ogni riga del file di testo importato corrisponde un record
nella rispettiva tabella, mentre la separazione dei campi in ogni riga del file di testo è marcata
dal carattere “|” (pipe).
La tabelle create in Access saranno del tipo:
Descrizione dei campi:
file: nome del file che utilizza almeno una libreria
pid: Process ID che identifica il processo legato al file
command_line: linea di comando tramite cui il file viene caricato in memoria
base: indirizzo base di memoria in cui viene caricata la libreria
size: spazio in memoria allocato dalla libreria
version: versione della libreria
path: percorso in cui risiede la libreria
14
La macro dlls_tables è costituita da due comandi Transfer Text atti a importare i file di testo
secondo le specifiche previste:
Le specifiche di importazione dllslog Import Specification sono state create da un tool
accessibile cliccando sul menù File -> Get External Data e quindi Import. A questo punto è
possibile scegliere il file da importare; nel nostro caso non è necessario importare alcun file per il
momento ma sceglierne uno è indispensabile per andare alla finestra di dialogo successiva.
Scegliere quindi un file e procedere: a questo punto si è nell’Import Text Wizard: cliccando su
Advanced si giunge finalmente al punto in cui è posssibile definire le specifiche di importazione,
salvarle (con Save As...) o aprire le preesistenti per apporre eventuali modifiche.
15
La dllslog Import Specification ha le caratteristiche riportate nello screenshot seguente:
Come si può vedere il Field Delimiter impostato è il simbolo di pipe mentre i nomi dei campi e il
formato dei loro dati (tutti testo) sono definiti campo per campo nella tabella in basso.
16
La macro handle_tables
Genera due tabelle handlelog_clean e handlelog_virus, importando rispettivamente i file
handlelog_clean.txt e handlelog_virus.txt che si trovano nella stessa directory del file
general.mdb corrente. I dettagli dell’importazione vengono definiti tramite il handlelog
Import Specification secondo le specifiche seguenti: a ogni riga del file di testo importato
corrisponde un record nella rispettiva tabella, mentre la separazione dei campi in ogni riga del
file di testo è marcata dal carattere ‘|’ (pipe).
La tabelle create in Access saranno del tipo:
Descrizione dei campi:
file: nome del file relativo allo handle
pid: Process ID che identifica il processo legato al file
owner: proprietario del processo
address: indirizzo di memoria dell’handle
type: indica il tipo di handle (file o section di memoria)
path: percorso relativo all’handle
17
Il formato della macro e delle specifiche di importazione sono riportati negli screenshot seguenti:
18
La macro filemon_tables
Genera due tabelle filemon_clean e filemon_virus, importando rispettivamente i file
filemon_clean.txt e filemon_virus.txt che si trovano nella stessa directory del file general.mdb
corrente. I dettagli dell’importazione vengono definiti tramite il filemon Import Specification
secondo le specifiche seguenti: a ogni riga del file di testo importato corrisponde un record
nella rispettiva tabella, mentre la separazione dei campi in ogni riga del file di testo è marcata
da tab.
La tabelle create in Access saranno del tipo:
Descrizione dei campi:
op_id: indica l’ordine temporale di esecuzione dell’operazione
time: ora:minuti:secondi in cui è avvenuta l’operazione
process: processo che ha richiesto l’operazione
pid: Process ID che identifica il processo legato che ha richiesto l’operazione
operation: tipo di operazione (open, close, directory, read…)
path: percorso del file legato al processo
risultato: esito dell’operazione (success, file not found, …)
notes: informazioni addizionali sull’operazione
19
Il formato della macro e delle specifiche di importazione sono riportati negli screenshot seguenti:
20
La macro regmon_tables
Genera due tabelle regmon_clean e regmon_virus, importando rispettivamente i file
regmon_clean.txt e regmon_virus.txt che si trovano nella stessa directory del file general.mdb
corrente. I dettagli dell’importazione vengono definiti tramite il regmon Import Specification
secondo le specifiche seguenti: a ogni riga del file di testo importato corrisponde un record
nella rispettiva tabella, mentre la separazione dei campi in ogni riga del file di testo è marcata
da tab.
Le tabelle create in Access saranno del tipo:
Descrizione dei campi:
op_id: indica l’ordine temporale di esecuzione dell’operazione sul registro
time: momento in cui è avvenuta l’operazione (espresso in secondi con 8 cifre decimali)
process: processo che ha richiesto l’operazione
pid: Process ID che identifica il processo legato che ha richiesto l’operazione
request: operazione richiesta (query key, create key, …)
path: percorso in cui viene effettuata l’operazione
risultato: esito dell’operazione (success, notfound)
other: informazioni addizionali sull’operazione
21
22
5.3 Le query
Come già detto, i monitor ListDLLs e Handle visualizzano lo stato del sistema nel particolare
momento in cui vengono eseguiti, pertanto le informazioni raccolte costituiscono una sorta di
fotografia del sistema in un particolare istante. Viceversa i monitor Filemon e Regmon visualizzano
dettagli su operazioni eseguite in ordine sequenziale, quindi non si visualizza lo stato del sistema,
ma si prende in considerazione il suo comportamento in un certo intervallo di tempo. Proprio in
virtù di questa diversità l’analisi dei risultati sarà differente: per ListDLLs e Handle il confronto fra
le tabelle generate prima e dopo l’inoculazione del virus verrà effettuato record per record. Nel caso
di Filemon e Regmon le query visualizzano le operazioni eseguite dal sistema a partire dal momento
dell’inoculazione del virus escludendo le operazioni generate da processi presenti nel sistema anche
prima dell’inoculazione del virus.
Le query visualizzano il risultato sotto forma di tabelle aventi i medesimi campi delle tabelle
prese in esame, quindi per il formato e la descrizione dei campi si veda la sezione relativa alle
macro che generano le tabelle.
Sono riportate tutte le query con il proprio codice SQL e una spiegazione della loro funzione.
23
La query dlls_in_clean_not_virus
SELECT dllslog_clean.file, dllslog_clean.pid, dllslog_clean.command_line, dllslog_clean.base, dllslog_clean.size,
dllslog_clean.version, dllslog_clean.path
FROM dllslog_clean LEFT JOIN dllslog_virus ON (dllslog_clean.file=dllslog_virus.file) AND
(dllslog_clean.command_line=dllslog_virus.command_line) AND (dllslog_clean.size=dllslog_virus.size) AND
(dllslog_clean.path=dllslog_virus.path)
WHERE (((dllslog_virus.file) Is Null));
Confronta tutti i record della tabella dllslog_clean con quelli della tabella dllslog_virus e visualizza
i record che sono presenti nella dllslog_clean, ma non nella dllslog_virus. Due record vengono
considerati uguali se i campi file, command_line, size, path sono uguali. I campi pid, base e version
vengono trascurati (un pid diverso o una locazione in memoria differente non caratterizzano la
diversità di due processi).
La query dlls_in_virus_not_clean
SELECT dllslog_virus.file, dllslog_virus.pid, dllslog_virus.command_line, dllslog_virus.base, dllslog_virus.size,
dllslog_virus.version, dllslog_virus.path
FROM dllslog_virus LEFT JOIN dllslog_clean ON (dllslog_virus.file=dllslog_clean.file) AND
(dllslog_virus.command_line=dllslog_clean.command_line) AND (dllslog_virus.size=dllslog_clean.size) AND
(dllslog_virus.path=dllslog_clean.path)
WHERE (((dllslog_clean.file) Is Null));
Confronta tutti i record della tabella dllslog_clean con quelli della tabella dllslog_virus e visualizza
i record che sono presenti nella dllslog_virus, ma non nella dllslog_clean. Due record vengono
considerati uguali se i campi file, command_line, size, path sono uguali. Come nel caso precedente i
campi pid, base e version vengono trascurati.
La query handle_in_clean_not_virus
SELECT handlelog_clean.file, handlelog_clean.pid, handlelog_clean.owner, handlelog_clean.address,
handlelog_clean.type, handlelog_clean.path
FROM handlelog_clean LEFT JOIN handlelog_virus ON (handlelog_clean.file=handlelog_virus.file) AND
(handlelog_clean.owner=handlelog_virus.owner) AND (handlelog_clean.type=handlelog_virus.type) AND
(handlelog_clean.path=handlelog_virus.path)
WHERE (((handlelog_virus.file) Is Null));
Confronta tutti i record della tabella handlelog_clean con quelli della tabella handlelog_virus e
visualizza i record che sono presenti nella handlelog_clean, ma non nella handlelog_virus. Due
record vengono considerati uguali se i campi file, owner, type, path sono uguali. Gli altri campi non
sono significativi per il confronto.
24
La query handle_in_virus_not_clean
SELECT handlelog_virus.file, handlelog_virus.pid, handlelog_virus.owner, handlelog_virus.address,
handlelog_virus.type, handlelog_virus.path
FROM handlelog_virus LEFT JOIN handlelog_clean ON (handlelog_virus.file=handlelog_clean.file) AND
(handlelog_virus.owner=handlelog_clean.owner) AND (handlelog_virus.type=handlelog_clean.type) AND
(handlelog_virus.path=handlelog_clean.path)
WHERE (((handlelog_clean.file) Is Null));
Confronta tutti i record della tabella handlelog_clean con quelli della tabella handlelog_virus e
visualizza i record che sono presenti nella handlelog_virus, ma non nella handlelog_clean. Due
record vengono considerati uguali se i campi file, owner, type, path sono uguali. Gli altri campi non
sono significativi per il confronto.
La query filemon_ virus_events
SELECT filemon_virus.op_id, filemon_virus.time, filemon_virus.process, filemon_virus.pid,
filemon_virus.operation, filemon_virus.path, filemon_virus.result, filemon_virus.notes
FROM filemon_virus LEFT JOIN filemon_clean ON filemon_virus.process=filemon_clean.process
WHERE (((filemon_clean.process) Is Null));
La query visualizza la tabella filemon_virus escludendo i record in cui il campo process corrisponda
a quello di almeno un record della tabella filemon_clean. In questo modo vengono visualizzate
solamente le operazioni relative a processi solitamente non riscontrati prima dell’inoculazione del
virus.
La query regmon_ virus_events
SELECT regmon_virus.op_id, regmon_virus.time, regmon_virus.process, regmon_virus.pid, regmon_virus.request,
regmon_virus.path, regmon_virus.result, regmon_virus.other
FROM regmon_virus LEFT JOIN regmon_clean ON regmon_virus.process=regmon_clean.process
WHERE (((regmon_clean.process) Is Null));
La query visualizza la tabella regmon_virus escludendo i record in cui il campo process corrisponda
a quello di almeno un record della tabella regmon_clean. In questo modo vengono visualizzate
solamente le operazioni relative a processi solitamente non riscontrati prima dell’inoculazione del
virus.
25
6. ANALISI DEI VIRUS
6.1 Il virus ColdApe
Informazioni sul virus
Coldape è un virus scritto nel linguaggio delle macro di Microsoft Word 97 che avvia un
Windows script virus e intacca i documenti mentre sono ancora chiusi.
Coldape usa un nuovo metodo per replicarsi: invece di utilizzare il metodo tradizionale e copiare le
proprie macro in varie locazioni, si serve di una tecnica chiamata AddFromString che rende il virus
irriconoscibile a molti scanners.
Se Coldape viene lanciato in Windows 98, Windows 2000 o qualsiasi altro Windows che supporti
il WSH (Windows Scripting Host), il virus crea i seguenti file di script:
•
•
•
A4.VBS nella root
Happy.VBS nella root
AVM.VBS nella directory di Windows
A4.VBS non è un virus vero e proprio, se lo script viene eseguito esso invia un messaggio di email utilizzando Microsoft Outlook (se presente), diretto a un personaggio molto conosciuto
nell’industria degli antivirus.
Happy.VBS e AVM.VBS contengono lo script del virus. L’appending script virus infetta tutti i file
.VBS nelle directory di sistema e nella directory My Documents
Il virus script è indipendente dal Word Macro virus e continua a diffondersi anche se il macro
virus viene disinfettato.
26
Analisi del database
Una volta adoperate le macro per l’importazione dei dati nelle tabelle, si noti che, oltre a quelle
previste, vengono generate due ulteriori tabelle contenenti gli errori di importazione di
dllslog_clean e dllslog_virus; ciò accade perchè nell’importer di Access esiste un limite alla
lunghezza dei campi che viene talvolta superato dal campo command_line delle tabelle.
Segue un’analisi dei risultati relativamente a ciascuna query.
Dlls_in_clean_not_virus
Non vengono riscontrate differenze.
Dlls_in_virus_not_clean
Nella tabella dllslog_virus (596 record) compaiono due record non presenti nella dllslog_clean (594
record). Entrambi si riferiscono a librerie di sistema utilizzate dal file explorer.exe.
Intuitivamente le due librerie sono utilizzate per la gestione degli script che il virus va a modificare.
Handle_in_clean_not_virus
Non vengono riscontrate differenze.
Handle_in_virus_not_clean
Non vengono riscontrate differenze.
Filemon_virus_events
Per un limite legato alla funzione di import di Access, la tabella generata non contiene tutti i record
presenti nel file di testo a essa associata. Tuttavia la quantità di dati importati sembra sufficiente per
l’analisi dei risultati.
Come ci si aspettava, tutti i file si tipo VBS presenti nelle directory del sistema operativo vengono
modificati; in particolar modo i file presenti nella C:\WINNT e C:\WINNT\System32. Inoltre il virus
tenta di accedere a numerosi file eseguibili e di libreria presenti in tali directory.
Si noti che il processo che richiede le operazioni è sempre legato all’esecuzione del file wscript.exe
che si occupa della gestione degli script in Windows.
Regmon_virus_events
Come ci si aspettava, il virus compie un gran numero di operazioni sui registri di sistema (3807
record) non solo tramite wscript.exe, ma anche attraverso processi legati ai tool di videoscrittura
quali notepad.exe e wordpad.exe.
27
6.2 Il virus MSblast
Informazioni sul virus
6.2 Il virus MSblast
Informazioni sul virus
MSblast è uno dei vari nomi che possono identificare il virus Lovsan, conosciuto anche come
Blaster, W32/Msblast, Lovesun e Poza, presenti in varie verisoni.
Si tratta di un network worm che si diffonde tramite una vulnerabilità di Windows di tipo Buffer
Overrun in RPC Interface, conosciuta anche come DCOM/RPC o MS03-026, identificata il 16
Luglio del 2003.
In realtà le vulnerabilità del sistema prese di mira sono tre, due di tipo Buffer Overrun e una di
tipo Denial of Service. Le prime due vengono sfruttate per sovrascrivere con del codice eseguibile
arbitrario il codice presente nei buffer non controllati (unchecked) di un programma. Ciò permette a
un codice maligno di agire incontrastato all’interno del calcolatore, persino creando un Denial of
Service, ossia impedendo l’uso delle risorse del sistema. Tutto ciò è possibile in ragione del fatto
che WinRPCSS service, il quale gestisce le RPC (Remote Procedure Call), non controlla
adeguatamente gli input in determinate circostanze; così, all’apertura di una connessione,
l’attaccante può mandare uno speciale messaggio RPC per provocare l’underlying dell’infrastruttura
di attivazione del DCOM (Distributed Component Object Model) sul sistema remoto e permettere
così l’esecuzione del proprio codice.
Questa versione del worm si diffonde solo su macchine con sistema operativo Windows 2000 e
Windows XP; versioni più vecchie del sistema operativo non vengono intaccate. Su macchine che
utilizzano Windows XP il worm causa in molti casi il riavvio periodico del sistema con il
messaggio di errore: This system is being shut down in 60 seconds by NT Autority/System due to an
interrupted Remote Procedure Call (RPC). Appare poi un’altra finestra con il countdown che
precede il riavvio della macchina e un altro messaggio di errore. Le finestre di dialogo vengono da
Windows stesso, e mostrano il messaggio di errore nella lingua del sistema operativo.
In alcuni casi può succedere che il messaggio di errore venga visualizzato anche dopo aver
applicato la patch corretta per correggere la vulnerabilità del sistema; tuttavia ciò non significa che
la macchina è stata infettata ma solo riavviata. In ogni caso il timer di spegnimento non può essere
fermato.
In Windows 2000 gli utenti non vedranno il timer ma possono essere notati altri problemi nel
creare messaggi in Outlook, funzioni base del sistema come il copia/incolla o il drag’n’drop non più
operative, problemi con il pannello di controllo o con javascript, e l’impossibilità di effettuare il
salvataggio di file da alcuni programmi.
Per diffondersi nella rete MSblast utilizza un algoritmo di scanning degli host vulnerabili
utilizzando come punto di partenza un indirizzo IP base che può essere casuale o simile a quello
dell’host su cui risiede.
Per capire meglio come funziona l’algoritmo di scanning, si consideri la generica struttura di un
indirizzo IP: A . B . C . D.
Come prima cosa il worm genera un numero tra 1 e 20.
Se il numero è ≥ 12: prende l’IP dell’host e, se Chost > 20, l’IP base avrà Cbase = Chost – 20 e
Dbase = 0; se C ≤ 20 parte proprio dall’indirizzo IP dell’host, quindi IPbase = IPhost.
28
Se il numero è < 12: si avrà come IP base un “totally random IP”; l’algoritmo sceglie A
nell’intervallo [1, 254]; B e C nell’intervallo [0, 253]; D = 0.
A partire dall’indirizzo IP base, l’algoritmo sonda 20 host alla volta; cerca di connettersi alla
porta 135 su tutti i 20 host e controlla se la connessione ha avuto successo. In caso affermativo
MSblast sfrutta le vulnerabilità conosciute per infiltrarsi, altrimenti prova con un altro host. Una
volta infiltratosi, sulla macchina remota viene aperta una shell tramite cui il worm copia se stesso
sull’host utilizzando il TFTP (Trivial File Transfer Protocol). Il TFTP client è integrato nel sistema
operativo Windows 2000/XP mentre il TFTP server è implementato nel worm. Dopo che il worm è
stato copiato nell’host remoto, viene fatto partire tramite la shell. Quando MSblast penetra
all’interno di un sistema vulnerabile, è chiamato ‘msblast.exe’ e aggiunge al registro di Windows la
seguente linea:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\windows auto update
Così facendo il worm verrà fatto partire ad ogni avvio della macchina.
Il worm è stato progettato in modo che dal 16 agosto alla fine di ogni anno, le macchine infette
inviino sulla porta 80 un pacchetto di 40 byte ogni 20 millisecondi a windowsupdate.com allo scopo
di creare un attacco di tipo denial-of-service distribuito a questo sito. Si noti che i pacchetti inviati a
windowsupdate.com per attacco sono difficilmente filtrabili dal traffico normale.
29
Analisi del database
Una volta adoperate le macro per l’importazione dei dati nelle tabelle, si noti che, oltre a quelle
previste, vengono generate due ulteriori tabelle contenenti gli errori di importazione di
dllslog_clean e dllslog_virus; ciò accade perchè nell’importer di Access esiste un limite alla
lunghezza dei campi che viene talvolta superato dal campo command_line delle tabelle.
Segue un’analisi dei risultati relativamente a ciascuna query.
Dlls_in_clean_not_virus
Non vengono riscontrate differenze.
Dlls_in_virus_not_clean
Nella tabella dllslog_virus (616 record) compaiono 23 record non presenti nella dllslog_clean (593
record). Tre record sono relativi a librerie utilizzate da explorer.exe; tutti gli altri sono utilizzati da
msblast.exe.
Handle_in_clean_not_virus
Non vengono riscontrate differenze.
Handle_in_virus_not_clean
Sono presenti 8 record tutti relativi a msblast.exe. È interessante notare che tutti i file e le sezioni a
cui msblast.exe accede sono relative a informazioni sulla cronologia, sui cookies, sulla cache e sui
contenuti delle pagine internet visitate dall’utente corrente (in questo caso l’amministratore del
sistema).
Filemon_virus_events
Nei 134 record visualizzati notiamo nuovamente l’accesso di msblast.exe alle librerie di sistema e
alle seguenti directory relative al funzionamento del browser:
•
•
•
•
C:\Documents and Settings\Administrator\Impostazioni locali\Cronologia
C:\Documents and Settings\Administrator\Impostazioni locali\Temporary Internet Files\Content.IE5
C:\Documents and Settings\Administrator\Cookies
C:\Documents and Settings\Administrator\Impostazioni locali\History.IE5
Si noti che il file winlogon.exe richiama il file ding.wav, forse per generare il tipico suono che
avverte di un errore.
Regmon_virus_events
Sono presenti 36 record, tutti relativi alle azioni compiute da msblast.exe, che va a insinuarsi
all’interno dei registri di sistema.
In particolare HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\windows auto update
farà partire il worm a ogni riavvio della macchina.
30
6.3 Il virus Nimda
Informazioni sul virus
Il Nimda è un virus di tipo worm. Esso può essere nascosto in file dai nomi diversi, nel nostro
caso è all’interno di un file Readme.exe che può trarre facilmente in inganno. Infatti, nelle
impostazioni di default di Windows la visualizzazione delle estensioni dei file è disabilitata e inoltre
gli sviluppatori del virus hanno associato al file Readme.exe l’icona di una pagina visualizzabile con
Internet Explorer; in tale maniera l’utente crede intuitivamente che si tratti di una pagina web e se
cerca di visualizzarla provoca l’innesco del virus.
Il Nimda è stato trovato per la prima volta il 18 Settembre 2001 e si è diffuso rapidamente in tutto
il mondo. Esso è stato il primo worm in grado di infettare non solo i singoli utenti colpiti, ma anche
file presenti su server web e disponibili per il download; come il Blast, inoltre, è capace di usare le
macchine di utenti comuni per scannare host vulnerabili. Infine, un'
altra caratteristica che lo
presenta come uno dei più raffinati virus di sempre, è la capacità di infettare le reti locali LAN,
andando a cercare e successivamente ad infettare i file condivisi.
Per fare tutto ciò Nimda approfitta di due bachi nei moduli di Windows: uno presente nei Web
Server IIS e uno nell’implementazione del MIME (protocollo aggiuntivo di posta elettronica che
permette di allegare file); essi possono essere comunque corretti con le opportune patch.
Il ciclo di vita attuale del Nimda può essere diviso in quattro parti.
•
Infezione dei file: Nimda cerca file di tipo EXE, HTML, ASP sulla macchina locale e li
infetta assimilandoli al proprio interno e trattandoli come delle risorse. Questi file
diffondono quindi l’infezione quando la gente scambia tali programmi.
•
Mass mailing: Nimda cerca indirizzi e-mail tramite il MAPI del mail client e nei file HTML
locali per eventuali indirizzi aggiuntivi, quindi spedisce delle mail a ogni indirizzo. Ogni
mail contiene in attachment il file README.EXE, che può essere eseguito automaticamente
in alcuni sistemi.
•
Web worm: Nimda scanna internet cercando di trovare server web. Una volta che viene
trovato un server cerca di infettarlo utilizzando vari bachi della sicurezza già conosciuti. Se
ciò succede il worm cerca di modificare pagine web e file presenti sul sito aggiungendo
poche righe in coda ai file HTML che costituiscono uno script Java che carica il file infetto
README.EXE. Il risultato finale è che i navigatori web verranno automaticamente infettati
navigando sul sito colpito.
•
Propagazione su LAN: il worm cerca i file condivisi sulla network locale, sia dai file
servers che dagli utenti finali. Una volta trovati tali file inserisce dei file nascosti nelle
directory che causeranno infezione negli altri PC.
31
Analisi del database
Ci si accorge immediatamente della presenza del virus nel sistema perché vengono generati degli
errori nell’ explorer.exe rendendo necessario riavviare il sistema.
Una volta adoperate le macro per l’importazione dei dati nelle tabelle, si noti che, oltre a quelle
previste, vengono generate due ulteriori tabelle contenenti gli errori di importazione di
dllslog_clean e dllslog_virus; ciò accade perché nell’importer di Access esiste un limite alla
lunghezza dei campi che viene talvolta superato dal campo command_line delle tabelle.
Segue un’analisi dei risultati relativamente a ciascuna query.
Dlls_in_clean_not_virus
È presente un record relativo alla libreria actxprxy.dll.
Dlls_in_virus_not_clean
Sono presenti due record relativi a due librerie utilizzate da explorer.exe: jscript.dll e cfgmgr32.dll.
L’ accesso alla libreria jscript.dll, che è la libreria degli java scripts, può essere un indizio dell’
opera di Nimda che, come già sappiamo, attacca i file web aggiungendoci uno script java.
Handle_in_clean_not_virus
Non vengono riscontrate differenze.
Handle_in_virus_not_clean
Il numero dei record e quindi degli handle infettati sembra variare con il tempo: al primo
monitoraggio sono stati riscontrati 84 record, mentre al secondo monitoraggio (quello che si andrà
ad analizzare) sono presenti 120 record.
A parte quattro record relativi a informazioni sulla cronologia, sui collegamenti preferiti e al file
mshtml.tlb (libreria degli oggetti Microsoft Html), tutti gli altri record sono identici fatta eccezione
per il campo address; infatti la section \BaseNameObjects\d1kuikh viene ripetutamente caricata in
diverse locazioni di memoria dal file explorer.exe.
Filemon_virus_events
Nei 3623 record visualizzati notiamo che la maggior parte ha a che fare con il processo drwtsn.exe
relativo al Dr. Watson, un tool per il monitoraggio del sistema integrato in Windows 2000, che
viene attivato automaticamente qualora sia riscontrata qualche anomalia. La maggior parte dei
record descrive le operazioni effettuate e la scrittura del file di log a esse correlato. Questo evento
non è stato attribuito direttamente all’ opera di Nimda, ma è stato interpretato come un’ azione di
riflesso del sistema che si accorge di continui errori che sono un effetto secondario del virus. D’
altra parte, Dr. Watson si accorge degli errori ma non è in grado di individuare il virus.
I record rimanenti sono più interessanti e soprattutto legabili al “lavoro” di Nimda. Molti record
sono impegnati dal processo csrss.exe che utilizza driver e librerie di sistema. Questo processo è un
modulo di Windows dedicato alla comunicazione nelle LAN e rispecchia bene l’ intenzione del
virus di propagarsi attraverso questo mezzo. Informazioni interessanti provengono anche da
winlogon.exe che va a leggere le impostazioni locali dell’utente corrente e il file autoexec.bat.
Attraverso questo file molti virus configurano il sistema in modo da poter essere lanciati ad ogni
riavvio della macchina.
32
Regmon_virus_events
Sono presenti 1982 record: la metà relativi alle azioni compiute dal Dr. Watson (drwtsn.exe); è poi
presente una serie di record relativa al processo internat.exe ( international ) che agisce sulle
impostazioni della lingua presenti nel pannello di controllo; circa 900 record registrano le azioni del
processo mep3.tmp.exe che è una traccia tipica del virus Nimda. Infatti nei sistemi infetti è sempre
presente un processo, creato dal virus stesso, del tipo mep*.tmp.exe, dove al posto dell’ asterisco c’è
di volta in volta un numero diverso. Infine, alcuni record sono associati al processo readme.exe, che
è proprio quello del virus.
33
6.4 Un virus di tipo trojan
Informazioni sul virus
Il così detto trojan o cavallo di troia, non è propriamente un virus, è piuttosto un programma, uno
spezzone di codice subdolo che, all’ insaputa dell’ utente e spesso automaticamente, si insinua nella
macchina fungendo da Server. Se in remoto qualche malintenzionato sta facendo girare un
programma che si comporta da Client, egli è in grado di comunicare e soprattutto di eseguire codice
a piacimento sulla macchina nella quale è presente il trojan Server.
Il file da cui si avvia il nostro trojan è m3tsp8.exe. Sul web non si sono trovate informazioni
interessanti relative a un virus con questo eseguibile, ma si è trovato traccia in vari Thread di
discussione del fatto che questo trojan ha comunque colpito ignari utenti.
Per sua natura il virus è progettato per lavorare sulle comunicazioni relative ad una rete di
calcolatori, pertanto, non disponendo di una rete per monitorare il comportamento del virus, i
risultati ottenuti non tengono conto della parte probabilmente più consistente delle operazioni svolte
dal trojan.
Analisi del database
Una volta adoperate le macro per l’importazione dei dati nelle tabelle, si noti che, oltre a quelle
previste, vengono generate due ulteriori tabelle contenenti gli errori di importazione di
dllslog_clean e dllslog_virus; ciò accade perchè nell’importer di Access esiste un limite alla
lunghezza dei campi che viene talvolta superato dal campo command_line delle tabelle.
Segue un’analisi dei risultati relativamente a ciascuna query.
Dlls_in_clean_not_virus
Non vengono riscontrate differenze.
Dlls_in_virus_not_clean
È presente un solo record relativo a un’operazione svolta da explorer.exe sulla libreria thumbvw.dll.
Questa azione non è probabilmente opera del trojan, visto che la libreria thumbvw.dll è dedicata alle
thumbnails multiple e difficilmente può interessare a questo tipo di virus.
Handle_in_clean_not_virus
Non vengono riscontrate differenze.
Handle_in_virus_not_clean
Sono presenti due record relativi alla cronologia di Internet Explorer.
Filemon_virus_events
Nei 170 record presenti, ce ne sono alcuni davvero interessanti. Poco più della metà delle
operazioni è svolta dal file del virus m3tsp8.exe, che agisce sulle librerie di sistema e in particolare
crea una nuova libreria m3tsp8.dll nella directory C:\WINNT\System32 a cui poi accede più volte.
Il trojan, come si vede, carica poi il processo regsvr32.exe che in Windows è il modulo che
permette di “registrare” una libreria, cioè aggiunge le appropriate chiavi nel file di configurazione
permettendo così a tutti i processi di utilizzare i dati che si trovano in quella libreria.
34
Regmon_virus_events
Sono presenti 1654 record legati in parte al processo m3tsp8_exe.tro, che agisce sui registri relativi
alla comunicazione e ai suoi protocolli, in parte al processo notepad.exe e al processo regsvr32.exe
che agiscono su impostazioni per la gestione dei collegamenti di rete.
35
6.5 Un virus sconosciuto (“mah”)
Informazioni sul virus
Per l’inoculazione si sono eseguiti i seguenti file:
vir Upgrade62.exe
vir 2Patch77.exe
vir3 pack.exe
vir4 Update79.exe
Si noti che dopo l’inoculazione è stato visualizzato dal sistema l’errore “mapi32 exception: default
mail account has a damaged table of contents”, come se il virus avesse tentato di accedere alle
impostazioni locali per la posta.
Poichè probabilmente anche in questo caso i nomi sono stati generati casualmente, non è stato
possibile trovare documentazione ad essi relativa. Inoltre è possibile che i vari file contengano
versioni diverse dello stesso virus.
Comunque, esso è stato battezzato da noi come “mah” e pertanto il database a esso relativo risiede
nell’omonima directory.
Il fatto di non conoscere nulla di questo virus, soprattutto il fatto di non trovare descrizioni del suo
comportamento in rete, ci permette di mettere per così dire alla prova il nostro metodo di analisi.
Vedremo che questa prova avrà successo poichè troveremo azioni del virus che ci porteranno ad
accostarlo al recentemente famoso virus Sasser, permettendoci così di descrivere con sufficiente
sicurezza il nostro “mah” come un worm Sasser-like.
Analisi del database
Segue un’analisi dei risultati relativamente a ciascuna query.
Dlls_in_clean_not_virus
Si è verificato un evento insolito: gli otto record riportati dalla query sono presenti in entrambe le
tabelle. L’unica differenza consiste nel formato del path, nella dllslog_clean è di tipo Windows,
mentre nella dllslog_virus è di tipo DOS (8+3 caratteri): il campo
cmd /c ""C:\virus\syssinternals.com\INNESCO\AttivaMonitorsShell.bat" "
è diventato infatti
cmd /c ""C:\virus\SYSSIN~1.COM\INNESCO\ATTIVA~1.BAT" "
Non è stato per noi possibile dare significato a questo cambiamento, ne abbiamo comunque con
successo rilevato l’ accadimento.
Dlls_in_virus_not_clean
Vedi le considerazioni fatte in Dlls_in_virus_not_clean.
Dall’analisi dei restanti record sembra che il virus stia operando con WinZip su un file giabzqj.zip,
dal nome criptico e quindi sospetto, presumibilmente creato dal virus stesso. Sembra poi che il file
virUpgrade62.exe venga eseguito con il nome di virade62.exe per poi accedere a librerie di sistema.
Il fatto di nascondersi dietro nomi diversi, vedremo anche poi, sarà una costante del nostro “mah”.
36
Handle_in_clean_not_virus
Non vengono riscontrate differenze.
Handle_in_virus_not_clean
Sono presenti cinque record sempre relativi all’utilizzo di Winzip e del file virde62.exe. Si noti
come il virus compaia con nomi diversi a seconda del contesto.
Filemon_virus_events
E’ grazie ai risultati provenienti da questo monitor che possiamo catalogare il “mah” come un virus
Sasser-like. Infatti il database ci comunica che il virus lavora in gran parte sul processo lsass.exe. Il
Local Security Authority Service è un processo che può essere usato da un codice malizioso per
generare un errore di tipo buffer overflow e conseguentemente per far eseguire alla macchina
colpita codice arbitrario. Il Sasser si è diffuso in maniera così repentina e massiccia sfruttando
proprio questa falla, ora riparabile grazie alle opportune patch create “tempestivamente” da
Microsoft.
Sono presenti 106 record relativi al processo lsass.exe che modifica soprattutto le impostazioni per
la sicurezza in:
C:\WINNT\System32\config\SECURITY
C:\WINNT\System32\config\SECURITY.LOG
A parte il lsass.exe, sono presenti il processo vnck.exe (probabilmente creato dal virus, poiché non è
un modulo di Windows) che accede alle librerie psapi.dll e hook.dll, e i processi mstask.exe e
winlogon.exe.
Regmon_virus_events
Sono presenti 3064 record. Anche qui il processo sjgp.exe è probabilmente creato da “mah” e va a
modificare i registri relativi ai protocolli internet e altri parametri di sistema. Vir 2Patch77.exe, vir3
pa~1.exe, vir4up~1.exe compiono operazioni analoghe modificando i registri. Infine compare
nuovamente un cospicuo numero di operazioni svolte dal processo relativo a winzip32.exe.
37
7. CONCLUSIONI E RIFERIMENTI
Al di là dell’utilizzo di Microsoft Acces e della progettazione di un database, questa analisi ha
permesso di intravedere la complessità di un sistema operativo, la quantità di processi e di
operazioni in corso in ogni istante di tempo. Ha fatto inoltre capire quanto fragile possa essere il
sistema di fronte ad attacchi provenienti dall’esterno (ma anche dall’interno), e quanti parametri sia
possibile modificare a nostra insaputa.
Il lavoro è stato impegnativo, non tanto nella progettazione e realizzazione delle singole parti,
quanto nella definizione di un percorso che portasse a risultati concreti e quindi
nell’interconnessione dei vari passi che ci hanno portato dalla semplice inoculazione dei virus
all’analisi di ciò che essi realmente fanno nel sistema; ogni stadio del progetto è stato esaminato con
la massima cautela: dal capire quali monitor potevano essere utili e quali no, al riuscire a
confrontare e visualizzare in un database informazioni veramente rilevanti e non un semplice
insieme di dati.
Una volta creata la struttura base del procedimento (un lavoro più di logica che di realizzazione
concreta su calcolatore), gran parte del tempo è stata impiegata per l’inoculazione dei virus,
l’esecuzione di un monitor alla volta (in caso contrario i vari monitor avrebbero potuto interferire
l’uno con l’altro, eccetto Handle e ListDLLs) e il ripristino del sistema non infettato da virus; tale
lentezza è di certo imputabile alla non eccezionale potenza della macchina da noi utilizzata e
all’appesantimento causato dal lavoro in un ambiente virtuale.
Pur sentendo la profonda mancanza, come già detto, di un supporto di rete vero e proprio che ci
avrebbe consentito di allargare la prospettiva di lavoro, siamo riusciti ad ottenere un gran numero di
informazioni sull’operato dei virus presi in considerazione.
Per quanto riguarda il software utilizzato, esso è, come già detto:
• Microsoft Access 2002 per la realizzazione dei database;
• monitor prodotti dalla SysInternals e scaricabili gratuitamente dal sito
www.sysinternals.com;
• Microsoft Visual C++ per la programmazione dei convertitori;
• VMware per l’esecuzione di macchine virtuali;
• Microsoft Outlook Express e ArGO Soft Mail Server per la simulazione del meccanismo
client/server della posta elettronica (che tuttavia non ha dato i risultati sperati).
Le informazioni sui singoli virus sono reperibili sul sito www.f-secure.com.
38
APPENDICE
handle_converter.cpp
#include
#include
#include
#include
#include
"stdafx.h"
<conio.h>
<iostream.h>
<fstream.h>
<string.h>
#define byte unsigned char
bool DEBUG=0;
//Carica l'uscita del monitor Handle e la converte per essere salvata in un file che Access
//interpretera'
int find_str_in_text(char str[] , byte* buf, int bufDim); //trova la prima ricorrenza della
//stringa str nel buffer di dimensione bufDim
//se non lo trova ritorna -1
int main(int argc, char* argv[])
{
const char* strIn="handlelog.txt";
const char* strOut="prova.txt";
if(argc!=3)
{
printf("\n NO PARAMETRI? USO QUELLI DI DEFAULT!");
printf("\n Uso: handle_converter.exe out in");
}
else
{
strOut=argv[1];
strIn=argv[2];
printf("\nLeggo da %s",strIn);
printf("\nScrivo su %s",strOut);
}
if(DEBUG)getch();
printf("\nBenvenuto!");
ifstream f;
ofstream ouf;
char fff[1000];
char orgLine[2000];
f.open(strIn,ios::in);
ouf.open(strOut,ios::out);
//*************************************
//ELABORAZIONE PER EXPORTER IN ACCESS
char line[2048],newLine[2048];
for(int m=0;m<1000;m++){line[m]=' ';newLine[m]=' '; }
line[1000]=newLine[1000]='\0';
for(int i=0;i<5;i++)f.getline(line,1000);
int headerLenght=0;
while(!f.eof())
{
bool isHeader=0;
f.getline(line,1000); //leggi una riga dal file
memcpy(orgLine,line,1000); //salva una copia dell'originale
static char headerRow[810];
39
//ELABORAZIONE RIGA
if(line[0]=='-')continue;
isHeader= (line[0]!=' ');
if(isHeader)
{
//se la riga non inizia con lo spazio
//se la riga e' un HEADER
//is//Header=1;
//azzerra header
for( i=0;i<80;i++)headerRow[i]=' ';
memcpy(headerRow,line,80);
headerLenght=-1;
for(int y=0;y<80;y++)
{
if((int)headerRow[y]==0||headerRow[y]=='\n'){headerLenght=y;break;}
}//end for y
if(headerLenght==-1)
{
printf("\nERRORE NON TROVO IL CARATTERE DI FINE RIGA nell' HEADER ROW!!!!!!!!");
getch();return 1;
}
//trova la lunghezza dello header
//modifica header: se trovi spazio metti la pipe
int primoSpazio=-1,secondoSpazio=-1;
for(int l=0;l<80;l++)
{
if(headerRow[l]==' ')
{ if(primoSpazio==-1)primoSpazio=l; else secondoSpazio=l;}
}//end for int l
if(primoSpazio==-1)
{
printf("\nERRORE: NON TROVO LO SPAZIO NELL0 HEADEROW!!!!");getch();return 1;
}
//metti la pipe
headerRow[primoSpazio]='|';
for (int v=primoSpazio+1;v<80-5;v++)
headerRow[v]= headerRow[v+5];
headerLenght-=5; //accorcia
if(headerLenght<0)headerLenght=0;
if(headerLenght<0)
{
printf("\nDimensione negativa!!");getch();
}
//riempi gli ultimi 5 con spazio
for(int i=80-5;i<80;i++)headerRow[i]=' ';
//trova il primo spazio e sostituiscilo con la pipe:
for(int u=0;u<80;u++)
if(headerRow[u]==' ')
{headerRow[u]='|';break;}
}//end riga non inizia con spazio (e' un header)
memcpy(newLine,headerRow,headerLenght); //i primi 80 sono header
if(!isHeader)
{
line[0]='|';
40
//ELABORA LINE:
line[5]='|';
memcpy(&line[6],&line[7],1000);
memcpy(&newLine[headerLenght],&line[0],1000);
//cerca il primo spazio...
for(int ps=headerLenght+7;ps<1000;ps++)
if(newLine[ps]==' ')break;
if(ps==999){printf("\nNon trovo ps!!");getch();}
newLine[ps]='|';
memcpy(&newLine[ps+1], &orgLine[21],1000);
//FINE ELABORAZIONE RIGA
if(DEBUG)cout<<newLine<<"\n";
ouf<<newLine<<"\n";
}//end non e' un header
else newLine[headerLenght]='\0'; //se e' un header
}
if(f.bad()){printf("\nErrore in lettura!!");return 1;}
f.close();
ouf.close();
if(DEBUG)getch();
return 0;
} // end main
int find_str_in_text(char* str, byte* buf, int bufDim)
{
//trova la prima ricorrenza della stringa
int strDim=0;
//calcola la lunghezza della stringa:
while(str[strDim]!='\0')strDim++;
int p=0;
while(p<bufDim)
{
int q=0;
while(q<strDim)//cerca la stringa in buf[p]
{
if(buf[p+q]!=str[q])goto NIENTE_DA_FARE; //niente da fare!!
q++;
}//end while(q<strDim)
//ha trovato la prima ricorrenza!!!!
return p;
NIENTE_DA_FARE:
p++;
}//end while
return -1;
}//end find char in text
41
listdlls_converter.cpp
#include
#include
#include
#include
#include
#include
"stdafx.h"
<iostream.h>
<fstream.h>
<stdlib.h>
<string.h>
<conio.h>
bool DEBUG=0; //e' in fase di debug???
int main(int argc, char* argv[])
{
//USAGE: listdlls_converter fileout filein
int i;
const char* strIn="listdllsOut.txt";
const char* strOut="lprova.txt";
printf("\nBenvenuto in listdlls_converter");
if(argc!=3)
{
printf("\nNO PARAMETRI?");
printf("\nUSAGE: listdlls_converter [uscita]
printf("\nUsero' i parametri di default...");
}
else
{
strOut= argv[1];
strIn= argv[2];
}
[ingresso]");
if(DEBUG){
printf("\nLeggero' dal %s",strIn);
printf("\nE scrivero' su %s",strOut);
getch();
}
ifstream f;
ofstream ouf;
char line[2048],newLine[2048];
char headerRow[1024],headerRow2[1024];
f.open(strIn,ios::in);
ouf.open(strOut,ios::out);
//salta le prime 5 righe
for( i=0;i<5;i++)
f.getline(line,1000);
int nonHeaderRow=0;
while(!f.eof())
{
bool isHeader;
static int headerLenght=-1; //DEVE ESSERE STATICO!!!
static int header2Lenght=-3;
int lineLenght=-2;
f.getline(line,1000);
if(line[0]=='-')continue;
isHeader= (line[0]!=' ');
//trova lunghezza linea
for(i=0;i<1000;i++)if(line[i]=='\0'){lineLenght=i;break;}
if(isHeader)
{
headerLenght=lineLenght;
memcpy(headerRow,line,800);
//tira via il carattere di fine riga dall'header ROW!!!
//cerca il primo spazio:
int primospazio=0;
for(int i=0;i<80;i++)
if(headerRow[i]==' '){primospazio=i;break;}
headerRow[primospazio]='|';
//tronca i successivi 4 caratteri
42
for(int v=primospazio+1;v<80-4;v++)
headerRow[v]=headerRow[v+4];
headerLenght-=4;
//leggi la seconda:
f.getline(line,1000);
for(i=0;i<1000;i++)if(line[i]=='\0'){lineLenght=i;break;}
memcpy(headerRow2,line,800);
header2Lenght=lineLenght;
//tronca le header ROw (tira via i primi 14:
for(i=0;i<header2Lenght-13;i++)
headerRow2[i]=headerRow2[i+13];
header2Lenght-=13;
headerRow2[0]='|';
//salta le altre 2 linee se in questo campo ci sono dati
f.getline(line,1000);
//se questo carattere NON e' '-' allora salta la successiva, altrimenti torna indietro
if(line[0]=='-'){}//no! bisogna tornare indietro
else {f.getline(line,1000);}
}//end if is header
else
{
for(i=0;i<headerLenght;i++)
newLine[i]=headerRow[i];
newLine[headerLenght]='|';
for(i=0;i<header2Lenght;i++)
newLine[headerLenght+i]=headerRow2[i];
newLine[headerLenght+header2Lenght]='|';
//ELABORA LA LINEA: cerca lo spazio e sostituiscilo con pipe e shifta
int lastFound=0;
for(int k=0;k<3;k++)
for(i=lastFound+4;i<lineLenght;i++)
if(line[i]==' ')
{
line[i]='|';
lastFound=i;
{
//shifta a sinistra
for(int j=i+1;j<lineLenght-1;j++)
{
line[j]=line[j+1]; //shifta
}
lineLenght--;
}//end shifta a sinistra
break;
}
//attacca il resto della linea
for(i=0;i<lineLenght;i++)
newLine[headerLenght+header2Lenght+i]=line[i];
newLine[headerLenght + header2Lenght+lineLenght]='\0';
//metti una pipe alla fine del secondo header...
newLine[headerLenght+ header2Lenght]='|';
//sostituisci gli spazi alle pipes
if(DEBUG)printf("\n%s",newLine);
ouf<<newLine<<'\n';
}//end else NON e’ uno header
}//end while(!f.eof
f.close();
ouf.close();
if(DEBUG)getch();
return 0;
}
43
mon_converter.cpp
#include "stdafx.h"
#include <fstream.h>
#include <conio.h>
bool DEBUG =1;
int main(int argc, char* argv[])
{
printf("\nhello W\torld!\n");
const char* strIn="monitor.log";
const char* strOut="monitor.txt";
if(argc!=3)
{
printf("\n NO PARAMETRI? USO QUELLI DI DEFAULT!");
printf("\n Uso: mon_converter.exe out in");
}
else
{
strOut=argv[1];
strIn=argv[2];
}
printf("\nLeggo da %s",strIn);
printf("\nScrivo su %s",strOut);
if(DEBUG)getch();
printf("\nBenvenuto!");
ifstream f;
ofstream ouf;
f.open(strIn,ios::in); //apri il file per leggere
ouf.open(strOut,ios::out);//apri il file su cui scriverai
char newLine[2000];
if(f.bad())
{
printf("\n ERRORE IN LETTURA!!");
getch();
}
while(!f.eof())
{
int lineLenght;
f.getline(newLine,200); //leggi linea dal file
printf("%s",newLine); //stampala (giusto per assicurarci che funziona)
//cerca la fine linea
int i;
for( i=0;i<200;i++)
if(newLine[i]=='\0')break;
lineLenght=i;
if(DEBUG)
printf("\nlunghezza %i",lineLenght);
//trova il carattere ":"
bool firstFound=0;
for(int j=0;j<lineLenght;j++)
if(newLine[j]==':'&&!firstFound){newLine[j]='\t';firstFound=1;}
ouf<<newLine; //stampa la stringa sul file
ouf<<'\n'; //aggiungi il carattere di fine riga
}
printf("\nFine elaborazione!");
getch();
return 0;
}
44