A case history: come ho risolto un WanaCrypt0r 2.0 Attack

Lo scorso 11 Maggio questo worm colpì più di 75.000 macchine in 99 Paesi di tutto il mondo fra ministeri, università, banche, servizi sanitari, case automobilistiche, ferrovie, compagnie telefoniche e logistiche. L’Italia grazie alla sua “ridotta interconnessione informatica tra le divere strutture” (come la definì un giornalista¹), per non dire di peggio, limitò la virulenza di questo ransomware in sporadici focolai isolati.

In linea generale, i non addetti ai lavori credono che il punto forte di questo worm sia la parte di criptazione dei file, con la relativa schermata: “Ooops, your important files are encrypted”. Ma, come molti di voi ormai sapranno, il pezzo forte è in realtà l’Exploitation del Bug conosciuto con il suo nome più famoso: EternalBlue (CVE-2017-0144, ID MS17-010)².
Funzionava (e funziona ancora, se non sono state prese le misure di sicurezza adeguate) su tutte le versioni di Windows, comprese quelle Server, con particolare successo su Windows 8 che permette la condivisione IPC$ attraverso una null-session. Vale a dire che è possibile effettuare la connessione in maniera anonima, abilitando la null session di default; ed una volta abilitata tale connessione possono essere inviati differenti comandi al server d’interrogazione. Detto in altre parole, è come se la multinazionale example.com avesse previsto una sala d’attesa per chi scarica e carica merci all’interno del proprio magazzino centrale, accessibile in maniera anonima.La National Security Agency (NSA) ai tempi aveva creato il suo apposito strumento di deploy conosciuto come FuzzBunch (somiglia molto al famoso Metasploit^2.5). Il framework permetteva di settare l’IP della vittima, i thread da dedicare al processo di exploitation, il servizio di aggancio e molto altro: prendeva la mira e boom sparava sul bersaglio. Ora, l’ EternalBlue sfrutta 3 bugs: Wrong Casting Bug (WCB), Wrong Parsing Function Bug (WPFB) e Non-paged Pool Allocation Bug (Non-paged PAB). Senza scendere eccessivamente nel dettaglio dell’analisi: WCB: permette lo sfruttamento del processo di conversione File Extended Attributes (FEA). Dalla struttura Os2 a quella NT è possibile eseguire un buffer overflow in una sessione non-paged del kernel sfruttando il protocollo Server Message Block (SMB) di Windows (driver srv.sys). Nel momento in cui la parte SMB_FEA del nostro pacchetto SMB eccede la memory size, invece di ricalcolare lo shrink della memoria sulle dimensioni del pacchetto, viene dato temporaneamente a disposizione uno spazio di memoria molto più grande. In quel momento avviene l’injection della nostro payload. In questa stanza comune dove scarichiamo e carichiamo merci per la nostra multinazionale example.com, arriva un bel giorno un carico che eccede il volume della stanza, la multinazionale mette a disposizione altro spazio per farci stare tutta quella merce. Peccato che nel nostro carico ci fosse anche un martello pneumatico che ci permetterà di aprire un buco all’interno del nuovo spazio messo a nostra disposizione, che risulta sprovvisto di telecamere e misure di controllo.

WPFB: sfrutta lo stesso bug appena descritto e lo fa inviando dati al protocollo SMB SMB_COM_TRANSACTION2 e SMB_COM_NT_TRANSACT, che eccedono la grandezza massima del buffer. A questo punto la connessione di scambio richiama dei comandi secondari che a loro volta chiamano altri sub comandi. Questa situazione porta ad un’analisi errata dei dati, fornendo all’attaccante l’opportunità di sfruttare il bug WCB.

Non-paged PAB: in breve, questo bug consente di allocare un codice avente dimensione preassegnata in una pagina del kernel diversa da quella assegnatagli. Questo significa che, come già avvenuto per i precedenti bug, viene causato un buffer overflow che eccede nel blocco di memoria successivo.

Così, se all’alba di una calda mattinata primaverile fui svegliato dal rumore del campanello della porta, lo devo a questi tre bug e di conseguenza al successo che l’EternalBlue ebbe su decine di migliaia di macchine. <<Vestiti. Abbiamo un ICR-T:R qui nel nord Italia>>, esordì il mio socio dopo avermi frettolosamente salutato. Incident Case categoria Red di Tipologia: Ransomware (Ovviamente era superfluo specificare di quale si trattasse).

<<Hanno dei backup? Altrimenti torno a dormire>> risposi ancora frastornato dal sonno.

<<Parziali…Vogliono che tu dia un’occhiata>>. Parziali equivale a “No”, solitamente.

Era stato colpito un server di produzione di un importante studio d’elaborazione dati che gestiva servizi di criticità elevata per molteplici clienti e conteneva altrettante informazioni sensibili. L’attacco era avvenuto durante la notte e la criptazione del database (DB) era durata svariate ore. Il server di backup (erroneamente configurato) aveva eseguito una copia completa e i successivi due incrementali salvando le varie versioni criptate dell’immagine del server.
La più recente immagine ripristinabile senza il worm, quindi, non era sufficientemente completa. Mancavano alcuni file importanti che erano stati inseriti nel DB durante la notte, altri nel momento dell’attacco stesso, che dovevano ancora essere rielaborati dal sistema e integrati sotto forma di record nel DB.

Fui accolto dal responsabile (uno dei Soci Amministratori) che mi fece strada sin nel cuore dell’azienda, a quell’ora ancora deserta. Le uniche voci provenivano dal reparto IT, svegliato d’urgenza per l’occasione.
Di solito, un semplice ransomware si diffonde sfruttando tecniche di social engineering (ad esempio convincendo la vittima designata a cliccare su di un link, oppure aprendo un allegato), ma questo worm era diverso. Diviso in più parti, il dropper del WannaCry era costituito da un software che cercava in altri computer interconnessi a quello infettato la vulnerabilità CVE-2017-0145 (SMB Remote Code execution, descritta prima). Per questo, durante il viaggio in macchina, avevo chiesto espressamente che il server oggetto dell’attacco venisse spento ed isolato. Ovviamente ogni minuto in cui la macchina rimaneva offline, si traduceva in soldi persi per l’azienda.

L’Amministratore tralasciò i convenevoli e disse al suo gruppo IT che avevo carta bianca.
Chiesi di segmentare³ un’area della rete nella struttura virtuale e di ripristinare il backup più recente. L’ IT Architect mi mise in contatto con una famosa società italiana di hosting dove il cliente aveva allocata la sua struttura e chiesi di cominciare a preparare una virtual machine (VM)⁴ con l’ultima versione di Windows Server scaricata dal loro repository Microsoft e di procedere all’aggiornamento e alla configurazione. Sarebbe stata la futura macchina che avrebbe hostato l’applicazione, qualora fossi riuscito ad estrarre il DB ed i file necessari.
Come c’era da aspettarsi i backup e gli snapshot erano completamente criptati. L’unica mia vera possibilità restava il famoso Backup “Parziale”, che sulla linea temporale dell’infezione si collocava fra la fase di exploitation e quella di dropping del worm. Cominciai a lavorare su questa immagine. Una volta che l’infezione è ad uno stato avanzato, il worm, nella fase di avvio crea un “servizio” Windows che ha lo scopo di attivare l’exploit della vulnerabilità in altri OS (operation systems) analoghi. Il cuore vero e proprio si trova in un file .zip criptato e a sua volta protetto da password.

Purtroppo intervenire in questa fase è solitamente troppo tardi. L’unica possibilità che avevo era quella di intervenire prima della fase di avvio del ransomware e cioè nella fase di “Kill Switch”. La fase di Kill Switch ha limitato e rallentato l’infezione di questo worm⁵: tale fase assolveva la duplice funzione di “interruttore” o semplicemente di controllo, al fine di testare se il worm si trovasse in una sandbox o in un sistema operativo vero e proprio. Il funzionamento è alquanto intuitivo: se il dato dominio preinserito nel malware è raggiungibile attraverso la funzione InternetOpenUrl(), allora l’infezione si blocca; altrimenti no. Vale a dire che se il sito è raggiungibile, la criptazione non avviene.

In pratica nel codice del worm esisteva la seguente condizione un “if”:

memcpy=(&sxUrl, “http://www.dominio-non-registrato.com , 0x21u);  //dominio-non-registrato da verificare
…..
…..
vX = InternetOpenA( 0, 1u , 0, 0,0);
vX+1 = InternetOpenUrlA(v4, &szUrl …. )  //esegui la richiesta http al precedente dominio-non-registrato
If (vX+1)                               //il dominio-non-registrato esiste? La richiesta ha avuto successo allora Esci
{
InternetCloseHandle(vX);
InternetCloseHandle(vX+1);
result = 0;
}
else   //il dominio-non-registrato non esiste? La richiesta non ha avuto successo: esecuzione del payload
{
InternetCloseHandle(vX);
InternetCloseHandle(0);
detonate();
result = 0;
}

Il mio piano era quindi tentare di bloccare la criptazione utilizzando la funzione di Kill Switch.
La prima cosa che avrei dovuto fare sarebbe stata quella di analizzare il traffico in uscita dal server infetto al fine di capire quale fosse il dominio di riferimento che permetteva di attivare la funzione e quindi di “spegnere” il worm (il dominio-non-registrato). Con le credenziali di accesso che mi ero fatto lasciare dal gruppo IT, installai sulla loro infrastruttura virtuale⁶ (precisamente nel segmento di rete che avevamo isolato) una distribuzione di Kali Linux scaricata dalla rete e già predisposta per l’ambiente VM. Modificai il file nella directory etc/network/interfaces in modo da configurare manualmente gli IP e da raggiungere il server infetto. A questo punto avviai il restore dal Backup “Parziale” del server e rimasi in ascolto sulla macchina Kali analizzando il traffico in uscita con il programma WireShark. Quando il backup ripristinato ed ancora infettato con il worm nello stato embrionale riprese il suo decorso, la prima cosa che eseguì fu il check sul dominio di Kill Switch.

Sul mio WireShark in ascolto apparve il record che stavo cercando:
Source: 192.168.150.serverinfetto Protocol: DNS Lunghezza: 109 Info: Standard query 0x4ec1 A www.kjasndkjansdkjasndkjsandsakmkcnjaiuewhdoeawpopwmfw.com

Nel frattempo non essendo la condizione di Kill Switch verificata, il worm eseguì ancora una volta il resto del suo codice. Chiamai ancora una volta l’IT Architect e chiesi di ricontattare la società di hosting al fine di ripristinare il backup “Parziale” del server e di freezzarlo nel momento del boot. Ora avevo una possibilità: tentare di utilizzare il dominio che avevo reperito tramite sniffing del traffico con WireShark, azionando il meccanismo di Kill Switch del WannaCry sul server infetto.

Il tempo fuori si era annuvolato ed era quasi ora di pranzo, la voce si era già sparsa nell’azienda e nell’ufficio del gruppo IT c’era stato un via vai di persone per tutta la mattinata, scandito da continue chiamate. Se fossi riuscito a verificare la condizione della Kill Switch come vera e cioè il dominio www.kjasndkjansdkjasndkjsandsakmkcnjaiuewhdoeawpopwmfw.com avesse risposto, sarei riuscito a fermare il worm e a rimettere la macchina in rete per salvare le ultime modifiche al DB ed eseguire un dump completo.

Quindi escogitai un piano. Riavviai la macchina infetta utilizzando una bootable key di una versione di Linux che avevo sotto mano e aprii il file hosts contenuto nella directory
C:\Windows\System32\Drivers\etc\hosts di Windows Server 2008 R2.
Prima di consultare un server DNS, la macchina cerca se il valore dominio.example è presente nel file hosts della macchina locale. Se il record è presente, il computer cercherà di collegarsi all’indirizzo IP specificato sulla stessa riga, in caso contrario tenterà di risolverlo tramite DNS. Ciò che feci fu mappare nel file hosts del server infetto il percorso del dominio facendolo puntare alla mia distro Linux che avevo messo in ascolto sulla porta 80 e 8080, avviando inoltre il servizio di apache2.
Aprii il file hosts e introdussi il seguente record:
192.168.150.miamacchinalinux www.kjasndkjansdkjasndkjsandsakmkcnjaiuewhdoeawpopwmfw.com
Riavviai il server ed incrociai le dita. Nel momento in cui il dropper fu rilanciato la condizione della Kill Switch fu verificata ed il processo di esecuzione del WannaCry arrestato.

Mi precipitai nell’ufficio dell’IT e dissi di rimettere il server in comunicazione con gli altri nodi, in modo da terminare il processo di scrittura dei diversi record nel DB e successivamente eseguire un dump di tutta la struttura esportandolo sulla nuova macchina.

<<Ma il Virus?>> esordì il responsabile…
<<Per ora non è più un problema.>>

Referenze:

A cura di: Vincenzo Digilio

Profilo Autore

Vincenzo Digilio

Ha lavorato come Network System Administrator, Security Auditor, System Integrator, Penetration Tester per importanti client, enti governativi ed agenzie spaziali. Seguendo progetti come calcolo distribuito, security resource implementation in aree nuclearizzate, adeguamenti di security policy e Security Engineering per la selezione d’importanti fornitori al fine d’implementare sistemi di sicurezza per diverse Multinazionali. Ha tenuto corsi di tecniche Hacking, studiando in contemporanea per il corso di Laurea in Sicurezza delle reti Informatiche. È attualmente impiegato in progetti classificitati in ambito spaziale di Cyber Sicurezza; nella ricerca di vulnerabilità, sviluppo di exploit e whitebox / black box Penetration Testing. Coordina, inoltre il RedTeam della società Cyber Division di cui e’ uno dei fondatori. È consulente in materia di Global Security Policy Statement, Risk management e Data Breach Investigation. È intervenuto in diversi casi di compromissione dati, analisi forensi, system breach e attacchi hacking al fine di mitigare la situazione. Crede nella libertà d’informazione e nel diritto alla privacy.