Ricerche IT

Se si gestisce un server Dell con installato Windows Server OEM (preinstallato da Dell), si potrà notare che nella fase precedente il logon viene caricato uno sfondo personalizzato di Dell. Il file di sfondo è un file BMP (dellwall.bmp) di quasi 2MB di dimensione presente all’interno della cartella “%systemroot%\system32\”. La cosa in sé non è fastidiosa, ma lo diventa se ci si connette tramite Remote Desktop su una linea lenta, come può essere una connessione VPN su linea ADSL; in questo caso, prima che compaia la finestra di logon, il nostro sistema dovrà “scaricare” quasi 2MB di immagine rappresentante un frontale di un server Dell, ed a parer mio, il sistemista che gestisce il server sa già che sta lavorando su un server Dell e non ha la minima intenzione di sprecare tempo e banda in questo modo.

Per risolvere il problema, basta modificare una voce di registro, e più precisamente impostare il valore della voce “Wallpaper” all’interno della chiave

HKEY_USERS\.DEFAULT\Control Panel\Desktop

sostituendo il percorso dello sfondo con una stringa vuota, in altre parole, basta cancellare il valore della voce “Wallpaper”.

Così facendo, elimineremo questo fastidioso contrattempo che nasce quando ci si connette ad un server Dell via RDP.

Leggendo questo post di Andrea Beggi, e proseguendo la lettura dei relativi commenti, viene descritta una situazione in cui si ha una rete che esce verso Internet tramite un router, e contestualmente si ha una VPN con un’altra sede che esce tramite un router separato, per cui bisogna lavorare bene con l’instradamento del traffico, facendo in modo che il traffico verso la VPN non esca tramite il router Internet, ma tramite il router VPN. Andrea Beggi propone una soluzione che consiste nel creare una route statica sul default gateway della rete locale, che sia in grado di reinstradare il traffico verso la VPN in modo trasparente all’utente; il problema potrebbe porsi nel traffico dalla sede remota ad un host della rete locale e ritorno, se infatti l’host non ha una valida configurazione di routing, la sede remota potrebbe comunque non comunicare con gli host della rete locale. In realtà normalmente ciò non accade, poiché il router, una volta configurato, utilizza il meccanismo chiamato ICMP Redirect Message per mandare messaggi ICMP ai vari host con le informazioni necessarie ad aggiornare la tabella di routing degli host, informandoli sul percorso più corretto da seguire per raggiungere la sottorete corrispondente alla sede remota connessa in VPN.

Nei commenti al post di Andrea Beggi, c’è chi ha proposto soluzioni alternative per raggiungere lo stesso fine, tra cui mi ha colpito la tecnica di distribuire una (o più) route statiche ai client della rete locale tramite server DHCP; il motivo principale per cui mi ha colpito è che ignoravo quest’opzione di DHCP. Al momento ho testato la soluzione solamente su un server Windows Server 2003 R2 SP1 e su un client Windows XP Professional SP2, e devo dire funziona senza problemi. In sostanza, l’obiettivo che vogliamo ottenere è fare in modo che i client della rete 172.16.1.0/24 possano raggiungere la rete 192.168.1.0/24 tramite il router 172.16.1.253; per raggiungere lo scopo, è necessario configurare nelle opzioni dell’ambito DHCP precedentemente configurato l’opzione “249 Classless Static Routes”, in cui indicare (tramite il tasto Add Route) la rete di destinazione, la subnet mask e il router tramite il quale raggiungere la sottorete in questione, come visibile dalla figura 1:

Fatto questo, dare conferma, riavviare il servizio DHCP e infine verificare che la distribuzione delle route statiche avvenga correttamente. Tenere presente che esiste un’altra opzione di DHCP che si occupa di distribuire route statiche ai client, la “033 Static Route Option”, che però non è applicabile nella nostra situazione, in quanto con questa route è possibile specificare solamente un host come destinazione e non un’intera sottorete.

Quando su un PC siamo in presenza di sintomi chiari di un’infezione da malware, e riusciamo a salvarci un file che riteniamo veicolo dell’infezione, possiamo utilizzarlo per poter fare con calma alcune indagini, allo scopo di cercare di capire il più possibile su come funziona il malware in questione. La prima preoccupazione dev’essere quella per testare il file infetto in sicurezza, senza quindi intaccare i dati ed i programmi che utilizziamo normalmente. Per evitare problemi, il modo migliore sarebbe quello di utilizzare uno o più PC dedicati proprio a sperimentazioni di vario tipo, altrimenti, se non si dispone dei mezzi/spazi/risorse per avere un ambiente di test, è possibile utilizzare un software di virtualizzazione come VMWare o Virtual PC, con cui creare una o più macchine virtuali a scopi di testing.

Nella mia prova, utilizzerò VMWare, in cui prima di ogni altra cosa utilizzerò la funzione di snapshot, che mi permetterà di tornare alla situazione pre-test su quelle macchine virtuali che utilizzerò per le operazioni di testing. Il passo successivo consiste nel copiare il presunto file infetto nella macchina virtuale per fare un primo esame, che consiste nell’esaminare il file col servizio VirusTotal, che permette di fare una scansione antivirus con una pletora di motori di scansione di diversi produttori, in modo da identificare il tipo di malware con cui abbiamo a che fare. Com’è possibile vedere dall’immagine, il malware in questione è il trojan Win32.Dialer.tl, di cui, dopo una ricerca con Google, possiamo trovare alcune informazioni sul suo funzionamento sul sito ThreatExpert.

Figura 1

Ora sappiamo quindi che il file in esame è un trojan e conosciamo alcune caratteristiche peculiari di questo malware, per cui abbiamo già un’idea di cosa ci aspetta; in particolare, essendo anche un dialer, il trojan andrà a modificare il file rasphone.pbk per creare una nuova connessione di rete (comportamento appunto tipico di un dialer), quindi creerà un nuovo processo in memoria, modificherà alcune voci di registro legate ad Internet Explorer ed infine creerà un mutex che impedirà che il processo infetto sia attivo più volte in memoria.

Raccolte informazioni sul malware, possiamo passare alla parte "pratica". Per prima cosa, scarichiamo alcuni software che ci possono essere utili per capire il comportamento del trojan in questione una volta entrato in azione:

Process Monitor: software di Sysinternals (ora acquisita da Microsoft) che ci permette di vedere in tempo reale ciò che avviene sulla nostra macchina, in particolare controlla quali processi sono in esecuzione e le variazioni effettuate sul registro di sistema;

TCPView: altra utility Sysinternals che consente di verificare le connessioni di rete attive ed in ascolto, in pratica, un’interfaccia grafica per il comando netstat;

Wireshark: sniffer di rete che permette di monitorare e registrare il traffico di rete in entrata ed in uscita da un PC.

Installate o copiate queste utilità sulle due macchine virtuali, cambiamo indirizzo IP ad entrambe in modo tale che non comunichino con la rete del nostro sistema principale e che non possano uscire verso Internet, dopodiché facciamo partire Process Monitor e TCPView e lanciamo il file infetto (cosa DA NON FARE se non a scopi di testing ed avendo cura di non infettare le proprie macchine di produzione e soprattutto di non creare traffico inutile e potenzialmente dannoso sulla rete Internet). Una volta lanciato l’eseguibile infetto dal disco E:, lasciamo fare al PC, dando ogni tanto un’occhiata a TCPView, e dopo qualche minuto, possiamo salvare il log relativo a Process Monitor per osservarlo con calma; per salvare il log, dalla finestra di Process Monitor cliccare su File, quindi su Save e comparirà la finestra illustrata in Figura 2:

Figura 2

La cosa più evidente è una certa attività relativa al file infetto 9268125.exe, che va a creare una connessione di rete ad un numero internazionale andando a modificare il file %CommonAppData%\Microsoft\Network\Connections\Pbk\rasphone.pbk, ed inoltre si può notare dalla Figura 3 che il file in questione va a ricercare diverse librerie nella stessa directory da cui è stato lanciato (E:\), non trovandole poiché queste librerie si trovano nella cartella di sistema C:\Windows\System32, quindi per fare in modo che il dialer agisca nel pieno delle proprie facoltà (dannose), probabilmente dovrei far partire il file dalla cartella System32.

Figura 3

Forse per il fatto di aver "sbagliato" la posizione del file infetto da eseguire, gli effetti sono stati piuttosto limitati, infatti, per quanto ho potuto constatare, di fatto l’infezione consiste semplicemente nella creazione del dialer di nome "Internet", inutile e causa di scarsi problemi se in presenza di un collegamento ad Internet di tipo xDSL o in fibra. Questa è una prima analisi superficiale fatta solamente con lo strumento File Monitor, più avanti proverò ad analizzare un worm, file maligno per cui saranno utili le utilità TCPView e Wireshark.