Duqu: analisi del worm successore di Stuxnet

Introduzione

Si fa un gran parlare in Rete di Duqu, un malware di ultima generazione che presenta alcune caratteristiche peculiari e forse rappresenta un punto di svolta nella codifica di un malware.

Le prime notizie di Duqu si hanno intorno a settembre 2011 quando, secondo quanto riferisce Costin Raiu (attuale R&D Chief di Kaspersky Lab Romania) in un'interessante intervista, un collega di un'altra azienda gli invia un file binario chiedendogli di dargli un'occhiata. A prima vista sembrava che mandando in esecuzione il file non accadesse assolutamente nulla. Se però l'eseguibile veniva invocato aggiungendo un parametro (chiamato "XXX"), si scatenava un keylogger in grado di intercettare keystrokes, schermate, copiare configurazioni ed altro. I dati raccolti venivano poi scritti in un file temporaneo, creato nella directory temporanea (%TEMP%) il cui filename iniziava con il prefisso ~DQ, da cui il nome affibbiato al malware: "Duqu". Tale file veniva poi compresso e restava inspiegabilmente lì, senza inviare informazioni a nessuno; un comportamento molto strano per un keylogger che, generalmente, è fatto apposta per rubare informazioni e inviarle ad un attacker. Il team di Raiu concluse, quindi, che probabilmente si trattava solo di uno dei componenti del malware o, più precisamente, di un solo modulo.

Ad ottobre 2011 viene pubblicato, in coda ad un report di Symantec, il lavoro svolto dai ricercatori del CrySyS Lab, della Budapest University of Technology and Economics, che avvalora la tesi del gruppo di ricerca di Costin Raiu, secondo cui siamo di fronte ad un hacking toolkit modulare.

Un malware Stuxnet-like

Nel report, il CrySyS Lab individua in Duqu una serie di elementi in comune con Stuxnet, il worm che attacca i sistemi basati su SCADA e di cui c'è ormai ampia letteratura in rete, soprattutto dopo l'attacco alle centrali nucleari iraniane. Tali elementi fanno concludere ai ricercatori che Duqu abbia una serie di punti in comune con Stuxnet e che chi lo ha scritto abbia partecipato anche al team di sviluppo di Stuxnet o quanto meno abbia avuto accesso al codice sorgente di quest'ultimo. Tale ipotesi viene sostenuta peraltro anche dallo stesso Raiu.

Altri analisti, invece, come quelli di NSS Labs, ritengono che, per quanto Duqu abbia molti elementi in comune con Stuxnet, sia prematuro parlare di uno "Stuxnet 2". Una cosa è certa, però. Mentre l'obiettivo di Stuxnet è quello di compromettere i sistemi industriali, autoreplicandosi il più possibile (e quindi facendo molto "rumore"), quello di Duqu è di acquisire informazioni nel modo meno invasivo possibile, ottenendo progetti, documenti, configurazioni, credenziali e quant'altro possa essere utile per poter condurre successivamente un attacco mirato. Da questo punto di vista, quindi, appare chiaro che Stuxnet sia stato realizzato per fare danni, mettendo in crisi i sistemi di controllo delle installazioni industriali, mentre Duqu sia essenzialmente un Remote Access Trojan (RAT), finalizzato all'information gathering, che non si autoreplica, lascia meno tracce possibili e dopo aver esaurito il suo compito, come vedremo, si autodistrugge.

Vediamo quindi una breve comparazione tra le caratteristiche principali di Duqu e Stuxnet:

• Duqu contiene codice sorgente simile a quello usato per Stuxnet.
• Duqu usa tecniche simili a Stuxnet, nello specifico per ciò che concerne l'utilizzo dei driver, che vengono firmati attraverso certificati digitali apparentemente legittimi. Non è noto se tali certificati siano stati trafugati o generati direttamente dagli attackers a seguito diella compromissione di una Certification Authority (CA).
• Duqu non è self-replicating, quindi non è un worm come Stuxnet. Esso richiede l'utilizzo di un "dropper", cioè di un modulo che faccia da "base di lancio" per installarlo in un sistema. Tale dropper viene installato grazie ad un kernel exploit di tipo 0-day che utilizza come vettore di attacco un normale documento Microsoft Word; il meccanismo verrà descritto nel dettaglio nel paragrafo dedicato al metodo di infezione usato da Duqu.
• Duqu installa un keylogger per registrare i keystrokes e carpire altre informazioni dal sistema "ospite". Come già accennato sopra, le informazioni trafugate vengono salvate all'interno di file di immagini che, a loro volta, vengono criptati e compressi.

In figura è riportata una tabella che mostra una comparazione puntuale tra Stuxnet e Duqu.

Figura 1: Confronto tra Stuxnet e Duqu
(clic per ingrandire)





Il meccanismo di infezione di Duqu

Come abbiamo già accennato al paragrafo precedente, per infettare il sistema ospite viene sfruttata una vulnerabilità, di tipo 0-day ed attualmente under review, del parser dei font TrueType all'interno del kernel Win32k. La vulnerabilità in questione, classificata come CVE-2011-3402, consente ad un attacker di eseguire arbitrariamente codice sull'host infetto. I sistemi operativi colpiti sono quelli di casa Microsoft e nello specifico Windows XP SP2 e SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, e R2 SP1, ed infine Windows 7 Gold e SP1.

Semplificando, il processo di infezione può essere suddiviso in due fasi: Exploit shellcode e Installer.

Exploit shellcode

In questa fase, l'exploit contenuto nel documento Word viene eseguito quando il docuemnto viene aperto. L'exploit contiene una shellcode che, come prima cosa, controlla che il computer non sia già stato infettato cercando, all'interno del registro di Windows il seguente valore:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsZones4"CF1D"

. Se lo trova, la shellcode termina la sua esecuzione. Diversamente, la shellcode estrae e decripta due file eseguibili dal documento Word, un driver e un DLL installer, dopodichè passa il controllo al driver che inietta all'interno dell'eseguibile services.exe il codice che esegue il DLL installer. Al termine del suo lavoro, la shellcode si autodistrugge riempendo di zeri lo spazio di memoria centrale da essa stessa occupato.

Installer

Il compito del DLL installer è quello di estrarre (da se stesso) e decriptare tre file:

• la DLL principale di Duqu (Main DLL)
• un driver con estensione .sys che costituisce il load point di Duqu dopo il reboot
• il file di configurazione dell'installer

Nel file di configurazione dell'installer è specificato un timestamp che indica entro quanti giorni deve essere completata l'installazione (ad es. 8 giorni). Se l'installazione avviene entro questo intervallo di tempo, il controllo passa alla Main DLL, che installa Duqu e si autocopia, criptandosi, nella cartella %Windir%inf. La Main DLL si autorinomina anche (secondo quanto specificato nel file di configurazione) e viene decriptata ed eseguita dal driver ogni volta che il computer parte, dopodichè il processo di copia ed encrypting si ripete. Si noti che alla fine del processo di installazione restano su disco i tre file descritti, ma mentre la Main DLL e il file di configurazione vengono sempre criptati (e decriptati dinamicamente solo durante l'esecuzione in memoria centrale), l'unico file che viene salvato in forma non criptata è il driver. Già dal processo di installazione quindi appare chiara l'intenzione di ridurre al minimo le "tracce" di Duqu su disco. Nella Fig. 2 è schematizzato il processo di installazione di W32.Duqu

Figura 2: Processo di installazione di W32.Duqu (Fonte: rapporto Symantec ottobre 2011)
(clic per ingrandire)





C&C e Proxy Servers

È ben noto che Duqu, come tutti i bot, utilizzi dei Command & Control (C&C) server sparsi un po' in giro per il mondo, per inviare le informazioni raccolte agli attacker. Dalle analisi effettuate è emerso che certamente alcuni di questi server sono localizzati in India, Belgio, Olanda, Germania, Vietnam. Si stima inoltre che, a partire da novembre 2009, siano stati operativi almeno una dozzina di C&C server al servizio di Duqu. Come risulta da una analisi condotta dagli esperti dei Kaspersky Labs, con buona probabilità non tutti i server giocano lo stesso ruolo. Oltre infatti ai C&C Server individuati in India e Belgio, altri server sono stati compromessi per svolgere funzioni di traffic redirect sulle porte TCP 80 e 443, nello specifico, quelli localizzati in Germania e in Vietnam. Questi server, quindi, hanno agito da proxy, ridirezionando il traffico verso altri C&C server "reali", di cui ad oggi non si conosce ancora l'ubicazione. Tutti i server, inoltre, sono basati su CentOS, versioni 5.2, 5.4 e 5.5, 32 e 64 bit. In Fig. 3 si può osservare una mappa dei server:

Figura 3: Duqu C&C e proxy server
(clic per ingrandire)





Strumenti per individuare Duqu

Sia il Crysys Lab che NSS hanno sviluppato dei detection tools per Duqu liberamente scaricabili.

Il CrySyS Duqu Detector Toolkit è un toolkit che permette di trovare tracce di infezione di Duqu sia in un singolo host che in un intero network, anche se - a detta dei ricercatori del Crysys - i componenti del malware sono stati rimossi dal sistema. Il tool, scaricabile qui è free ed Open Source ed è accompagnato da un manuale di utilizzo.

Lo scanning tool scritto (in Python) dai ricercatori di NSS Labs, invece, è scaricabile qui. Lo strumento (anch'esso free ed Open Source) è stato sviluppato (sempre secondo quanto riferiscono da NSS Labs) per individuare nuovi moduli e driver ancora sconosciuti, in modo tale da accrescere la conoscenza, le capacità e gli scopi ultimi della piattaforma Duqu.

Conclusioni

Nonostante i progressi fatti in questi mesi, Duqu resta un vero e proprio enigma per gli analisti. La preoccupazione maggiore è legata al fatto che si tratta di codice molto ben scritto, che certamente ha richiesto il lavoro di un team di professionisti con skill ai massimi livelli. Inoltre, diversamente da Stuxnet, Duqu è molto più "low-profile". Parafrasando il motto di Backtrack, possiamo dire che la filosofia di Duqu è del tipo "the quiet you become, the more you able to hear...".

Restano quindi aperte una serie di questioni intorno a Duqu:

• Chi c'è dietro a Duqu? Governi nazionali? Organizzazioni criminali?
• Il team di sviluppo di Duqu è lo stesso che ha prodotto Stuxnet o no?
• Come sono stati compromessi alcuni server? Dall'analisi dei log sembrerebbe attraverso attraverso il bruteforcing della password di root password. Ma ci sarebbe un'altra "teoria" che riguarderebbe l'esistenza di uno 0-day exploit in OpenSSH 4.3, tanto che gli attackers si sono affannati ad effettuare l'update di OpenSSH 4.3 alla versione 5 appena hanno ottenuto il controllo dei server compromessi.
• Il 20 ottobre 2011 è stata effettuata dagli attacker un'operazione di pulizia "a tappeto" su tutti i server.
• Il server C&C "madre" resta tuttora un mistero.