Al momento sto sostituendo i computer di un impianto per via di un cambio di piattaforma (si passa da PC a Mac). I PC, ancora perfettamente funzionanti e con una buona dotazione di hardware, vengono ripuliti dalle applicazioni inutili e riconfigurati per essere utilizzati in altre applicazioni.

Sono sistemati provvisoriamente nel mio ufficio, dove li libero delle schede non più necessarie e faccio una ricognizione generale per trovare ed eliminare roba inutile rimasta dal vecchio impiego. Non che ve ne sia molta, gli account erano tutti non amministrativi e gli utenti non potevano (e non dovevano) installare alcunché, visto che l’uso era strettamente professionale e limitato ad una sola applicazione.

Nonostante questo e nonostante il fatto che la rete fosse isolata dal resto del mondo, ho avuto la sorpresa di trovarvi annidato Conficker, in una delle tante varianti.

E’ la prima volta che mi capita di avere per le mani computer colpiti da Conficker, senza che nessun altro vi abbia prima pasticciato o che la macchina sia già talmente compromessa da non riuscire a capire quanto delle devastazioni sia colpa di Conficker e quanto invece delle varie inutility installate dall’esperto di turno.

Come mi sia accorto della presenza del simpatico ospite, è frutto praticamente del caso: sui computer era installato VNC per l’assistenza da remoto, ed avevo aperto le rispettive porte sul firewall di Windows, aggiungendo le necessarie eccezioni. Dato che nella nuova sistemazione VNC non serve più, lo stavo eliminando e per completare il tutto sono entrato nel pannello di gestione delle eccezioni del firewall per rimuovere le due relative a VNC. Notata una eccezione, il cui nome era di sette caratteri alfabetici a caso, ho subito pensato che ci fosse qualcosa di strano, forse causato da qualche malware partito da un pen drive, visto che questa funzione non era bloccata. Ho disabilitato l’eccezione, poi, dopo aver eliminato parte del software non più necessario, ho riavviato, e l’eccezione era di nuovo attivata.

A quel punto il sospetto era certezza. Ho visto a quale porta TCP si riferiva l’eccezione, ed era la 1138, una porta non privilegiata e non usata da nessun servizio noto. Usando il comando netstat -nao si ottiene la lista delle porta TCP e UDP aperte con i relativi PID (Process ID) dei demoni le usano. Un processo teneva effettivamente aperta questa porta, ed il PID corrispondeva ad una istanza di svchost.exe con utente SYSTEM, come dire tutto e niente. Su un’altra macchina, sempre compromessa, la porta TCP ed il nome della eccezione sul firewall erano differenti, ma anche qui vi era l’istanza di svchost.exe relativa alla porta TCP aperta.

Per farla breve, ho usato due differenti strategie per rimuovere l’ospite indesiderato: una con il tool di rimozione di Symantec, efficace e veloce, una manualmente, che però è molto laboriosa e a rischio di veder vanificato il lavoro se si salta un passo. L’insediamento è fatto sfruttando un bug nel servizio di esecuzione pianificata, attivato dalla rete usando una named pipe sulla porta 445: la macchina già infetta si connette alla vittima, ed attraverso la pipe denominata “atsvc” esegue qualcosa che provoca l’attivazione. Viene depositata una DLL dal nome casuale nella directory system32, con impostati permessi molto particolari, tanto da risultare apparentemente intoccabile anche dall’utente amministratore. In realtà basta riassegnare i diritti al gruppo Administrators e si riesce ad eliminare, ma se prima non si è chiuso il firewall, impedendo l’accesso anche alla porta 445 (basta spuntare la casella “Non consentire eccezioni”) e se l’infezione è diffusa a più macchine, in breve si è daccapo con una differente DLL e una differente porta TCP. La DLL viene infilata come servizio da lanciare in una chiave di registro riguardante un servizio nascosto, che si trova cercando il nome della DLL: il nome del servizio è casuale e viene inserito un una chiave di registro particolare, che lo fa lanciare ad ogni avvio. Tutte le chiavi di registro coinvolte hanno la ACL impostata in modo che apparentemente siano intoccabili anche da Administrator, ma usando la voce “Autorizzazioni” del menu “Modifica” di Regedit si riesce a riassegnare i permessi anche ad Administrator e rimettere a posto le cose, cancellando l’avvio del falso servizio.

Comunque, al di là della complessità di rimozione, e delle tecniche di hiding messe in atto, Conficker compie un passo in più verso l’operatività silenziosa: ho avviato uno sniffer su una macchina Linux, connessa allo stesso switch delle macchine compromesse, e la sorpresa è (poco) piacevole: naturalmente dallo switch ricevevo solo il traffico broadcast, ma è stato sufficiente per notare come la strategia di scansione di Conficker sia molto meno “rumorosa” di tanti altri malware: ogni due secondi tenta un nuovo indirizzo, andando progressivamente per tutti gli indirizzi della subnet in cui si trova. Dopo il primo giro di scansione, il processo si ferma e non si hanno altri segnali, almeno non nei minuti immediatamente successivi. Questo significa che, a meno di non usare uno sniffer, e di usarlo al momento giusto, difficilmente verrà notato il traffico anomalo, come invece succedeva con altri malware, che eseguivano scansioni senza fine alla ricerca di altri computer su cui propagarsi alla massima velocità permessa dalla interfaccia di rete, rallentando tutto e generando moltissimo traffico.

Altro passo è l’assenza di processi in esecuzione specifici: usa un demone di sistema, quindi non ci sono processi con nomi strani o che scimmiottano i nomi di altri demoni legittimi.

Ancora, Conficker impedisce l’accesso via Internet a tutto il dominio microsoft.com, oltre probabilmente a molti altri, senza modificare file di configurazione e senza installare strani servizi: agisce sul servizio di cache DNS, probabilmente inquinandone il contenuto con valori improbabili. Il risultato è che solo aprendo un browser e puntando ad uno dei siti Microsoft si ha il sentore che qualcosa non sia proprio al suo posto.

Queste caratteristiche lo rendono differente da tutti i malware di questa categoria visti in precedenza e soprattutto lo rendono pericoloso ad un nuovo livello, perché anche l’utente più smaliziato difficilmente si accorgerebbe di avere una macchina compromessa, venendo a mancare qualsiasi segnale, almeno fra i più comuni, della presenza di un malware annidato nelle profondità del sistema operativo. Da quella che è la mia esperienza, questa strategia mostra che chi ha creato e diffuso Conficker, e le sue varianti, ha l’interesse non solo a colpire più computer possibili, ma anche a prolungare il tempo di permanenza nelle macchine colpite, non solo rendendo difficoltosa la rimozione con l’uso di caratteristiche poco note ai più, ma anche e soprattutto rendendo meno evidenti i sintomi dell’infezione.

In conclusione, anche considerando la grande diffusione e la difficoltà di estirparlo, Conficker rappresenta forse il primo di una nuova categoria di malware, pensati per annidarsi nelle viscere dei computer infetti e fare il proprio lavoro in modo silenzioso e discreto. Tenendo poi presente la capacità di scaricare ed eseguire a comando altri programmi, è facile immaginare scenari dove si possa trasformare in keylogger per catturare coppie di login e password, trafugare file con le credenziali di accesso a servizi o server remoti, operare come testa di ponte per diffondere spam o altri malware, trasformare i computer infetti in proxy o installarvi un simpatico sito di phishing.

Manca solo la chiusura ad effetto. Concedetemela: che sia un altro passo verso un malware veramente cattivo?

In realtà, no, siamo ancora lontani, ma Conficker si situa a metà strada fra i malware di tipo 0 e quelli di tipo I (usando la tassonomia proposta da Joanna Rutkowska), usando un demone di sistema per essere avviato e non apparire direttamente fra i processi in esecuzione. Rimane comunque il fatto che è difficile accorgersi della sua presenza, e la sua discrezione e silenziosità lo rende molto più pericoloso di tanti altri della sua razza.

Riferimenti

Tags: , ,