Andrea Lora CNR Istituto di Cristallografia Area della Ricerca RM1, via Salaria Km. 29,300-00015 Monterotondo scalo (RM) email andrea.lora@ic.cnr.it Giuseppe Nantista CNR Istituto di Cristallografia Area della Ricerca RM1, via Salaria Km. 29,300-00015 Monterotondo scalo (RM) email giuseppe.nantista@ic.cnr.it Augusto Pifferi CNR Istituto di Cristallografia, Area della Ricerca RM1, via Salaria Km. 29,300-00015 Monterotondo scalo (RM) email augusto.pifferi@ic.cnr.it 2
Sommario Sommario... 3 Abstract... 4 Keywords... 4 Premessa... 5 Prime azioni intraprese: arginare gli effetti... 5 Una soluzione completa... 5 Conclusioni... 7 3
Abstract Nella giornata di martedì 22/01/2013 venivano rilevati dagli utenti dell'area della Ricerca RM1 disservizi nell accesso alla rete internet. Il problema era limitato alle macchine con sistema operativo Windows, che andavano ad interrogare server DNS diversi da quelli stabiliti dai parametri DHCP forniti ai client. Era risultata subito evidente la presenza di un malware che andava ad agire sui parametri di configurazione rete dei singoli client. In questo documento verranno descritte le operazioni messe in atto dal servizio reti dell'adr RM1 al fine di arginare i possibili danni che avrebbero potuto essere causati dal malware. Keywords ADWARE BOTNET MALWARE SPOOFING VIRUS INFORMATICI 4
Premessa Nelle prime ore lavorative del 22 Gennaio 2013 è emersa, su molti PC dell AdR RM1, l impossibilità di navigare in internet, con la visualizzazione di messaggi di errore che indicavano un malfunzionamento del servizio di risoluzione dei nomi a dominio. Eseguiti i test di routine su alcuni PC affetti e notando che non erano coinvolti tutti gli utenti dell AdR, ma solo una fetta (seppur grossa), è stato evidente che si trattasse di un virus informatico che interferiva con la corretta risoluzione dei nomi a dominio. L'effetto dell'infezione era di modificare la configurazione DNS del PC, forzando l'uso di due server esterni, localizzati in Francia presso il provider OVH. A posteriori è emerso che la diffusione del malware era partita tempo prima, ma solo il 22/01 è esplosa mostrando i suoi effetti. Prime azioni intraprese: arginare gli effetti Da una rapida osservazione non sembrava che il software fosse maligno, le richieste DNS venivano soddisfatte correttamente, tuttavia il rischio potenziale era che i DNS potessero dirottare le connessioni verso server malevoli al fine di catturare informazioni o diffondere altri virus. Già dalla prima mattinata però i server malevoli sono andati in sovraccarico e hanno iniziato a rispondere a una richiesta su 10, con l'effetto di rallentare e spesso bloccare la navigazione dei PC. I software antivirus (di diversi vendors) non rilevavano alcuna minaccia. La prima azione messa in atto dal servizio reti è stata quella di dirottare le richieste DNS inviate ai suddetti IP verso i server DNS dell'adr RM1, così da garantire la legittimità delle risposte fornite e al tempo stesso permettere agli utenti di continuare la normale attività. Contemporaneamente sono stati attivati meccanismi di logging al fine di compilare una lista di macchine (identificate come coppie ip - mac address) che avessero subito l'infezione; i referenti informatici dei singoli istituti avrebbero poi svolto le necessarie operazioni di pulizia del malware. E' stato poi inviato un postmaster interno a tutti gli utenti dell'adr con lo scopo di rassicurare l'utenza che il problema fosse stato circoscritto e in risoluzione. Una soluzione completa 5
Una volta escluso il fatto che il problema fosse centralizzato, e cioè che non fossero stati compromessi i server DHCP e DNS dell'adr, l'attenzione è stata spostata sui singoli client. È stato preso un PC infetto sul quale effettuare le verifiche del caso, trattandolo a tutti gli effetti come "paziente zero" dell'infezione in corso. È stato constatato che successive modifiche alla configurazione DNS delle schede di rete dei client infetti (per esempio cambiando le impostazioni da manuali ad automatiche) potevano essere annullate dal malware stesso, che in alcuni casi, accorgendosi del timeout delle risposte DNS dei server malevoli, impostava come server DNS quelli di Google ( 8.8.8.8 e 8.8.4.4 ), evitando che il disservizio da server DNS sovraccarichi potesse insospettire l'utente e proteggendo il malware stesso da possibili individuazioni. Conoscendo i sintomi del problema, ma non le cause, e constatato che i log del firewall mostravano un gran numero di utenze che facevano ricorso ai server esterni (oltre 50.000 connessioni in meno di 4 ore), è stato ritenuto necessario classificare l'incidente come alta priorità. id Timestamp Source Destination Protocol src-port dst-port 1 22/01/2013 10:00 192.167.XXX.246 176.31.229.25 DNS (UDP) 11844 53 2 22/01/2013 10:00 192.167.XXX.215 176.31.229.25 DNS (UDP) 64197 53 3 22/01/2013 10:00 192.167.XXX.70 176.31.229.25 DNS (UDP) 62332 53 4 22/01/2013 10:00 192.167.XXX.25 176.31.229.24 DNS (UDP) 65301 53 52042 22/01/2013 12:19 192.167.XXX.61 176.31.229.24 DNS (UDP) 64226 53 52043 22/01/2013 12:19 192.167.XXX.56 176.31.229.24 DNS (UDP) 58176 53 52044 22/01/2013 13:45 192.167.XXX.195 176.31.229.24 DNS (TCP) 50762 53 52045 22/01/2013 13:47 192.167.XXX.123 176.31.229.24 DNS (TCP) 50762 53 Figura 1 - Log del firewall L'utilizzo di uno dei più comuni software per l'individuazione di malware (HijackThis) ha consentito di individuare le possibili cause del problema. C'era la consapevolezza che il cambio dei DNS sui client venisse eseguito da un software presente sui client stessi, quello che non si riusciva a spiegare era perché una simile azione non venisse percepita dai diversi antivirus come altamente invasiva. Temendo di aver a che fare con un problema di tipo 0-Day, nei confronti del quale è sempre molto difficile difendersi, non si è dunque esitato a contattare esperti del settore. Ci si è rivolti al Dott. Marco Ugolini, Channel Account Manager di Kaspersky Lab, che in brevissimo tempo ha fornito un contatto diretto con il Dott. Stefano Ortolani, Security Researcher sempre presso Kaspersky Lab. A seguito di un fitto scambio di email sono stati forniti a Kaspersky Lab i log HijackThis del "paziente zero" e, sempre prelevando i file da quel computer compromesso, diversi file eseguibili. Il pc, isolato dalla rete dell'adr, è stato riavviato per effettuare il dump, attraverso wireshark, del traffico dati da esso generato. Il file pcap risultante è stato anche esso inviato a Kaspersky Lab. Nell'arco di qualche ora il Dott. Ortolani individuava in un programma chiamato "Power Offer" il vettore del malware. 6
Appena connesso alla rete il pc infetto contatta il sito web di Power Offer, prova dapprima un ping, poi accede in http e si autentica, infine scarica una modesta quantità di dati (payload) e chiude la comunicazione. Figura 2 - Dump delle attività di rete del pc infetto Una volta localizzato il programma, che aveva tra l'altro una corretta voce di Installazione/Disinstallazione all'interno del pannello di controllo, si è rinvenuto all'interno della cartella dell'eseguibile anche un file contenente un database Sqlite. Quest'ultimo conteneva varie keyword italiane tipiche dei meccanismi di SEO. La data della creazione directory contenente il programma è risultata essere il 16/12/2011, ma alcune sotto directory riportavano una data di creazione molto più recente. Si è pertanto arrivati alla conclusione che il software era stato installato molto prima dell'effettiva attuazione del cambio DNS. Kaspersky ha suggerito i possibili scenari che potevano essere compatibili con queste condizioni: o il software era già a lavoro da prima, ma eseguiva il suo compito senza causare disservizi al client finale, o un aggiornamento ha cambiato la destinazione d'uso del programma stesso. In ogni caso ci si trovava di fronte ad un adware che si comportava come malware. Una volta disinstallato il Power Offer il "patient zero" è tornato a funzionare normalmente, senza presentare nuovamente il problema del cambio di DNS server. Conclusioni I compiti del servizio reti, in questo caso specifico, sono stati essenzialmente due. Il primo è stato quello di individuare la minaccia e fornire una risposta rapida alla stessa. Una volta compreso che i client venivano forzati ad utilizzare server DNS diversi da quelli legittimi e che una modifica alle impostazioni sul client non era sufficiente a garantire che la stessa resistesse nel tempo, è risultato naturale forzare l'utilizzo dei server DNS dell AdR RM1 tramite un'apposita regola sul firewall che ridirigesse le query dai server malevoli. In questo frangente l attenzione non era diretta alle problematiche dei client quanto alla capacità degli utenti di continuare a lavorare senza disservizi e senza rischi legati ad attacchi di tipo DNS spoofing. La questione non sarebbe potuta essere affrontata in questa maniera se non ci fosse stata la certezza che i computer infetti in quel momento non partecipassero ad una botnet. L'assenza di connessioni persistenti sui pc infetti verso host ambigui e il volume di traffico regolare verso l'esterno ha permesso di escludere questa possibilità. 7
Accertato che i servizi di rete fossero erogati normalmente, gli sforzi sono stati direzionati verso l individuazione della causa del problema. La possibilità di interloquire con dei professionisti del settore, e cioè i tecnici specializzati di Kaspersky Lab, ha permesso di circoscrivere il problema ad uno specifico software. Una volta rimosso questo i computer che erano infetti hanno ripreso il loro corretto funzionamento. I file analizzati da Kaspersky Lab riconducibili a questa problematica sono stati inseriti nel loro database dopo meno di 24 ore dalla scoperta dell'incidente. Ringraziamenti Si ringrazia Kaspersky Lab per il supporto fornito all'istituto di Cristallografia, in particolare il Dott. Marco Ugolini e il Dott. Stefano Ortolani per l'estrema competenza, professionalità e gentilezza mostrata nell'affrontare questa problematica. 8