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

Solitamente 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 è 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 via anonima abilitando la null session di default. Una volta abilitata tale connessione è possibile inviare differenti comandi al server d’interrogazione. In poche 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 nostra 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 c’era anche un martello pneumatico che ci permetterà di aprirci un buco all’interno del nuovo spazio messoci a disposizioni 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 e questa situazione porta ad un’analisi errata dei dati dando 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 eccedendo 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 successi 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 infatti alcuni file importanti che erano stati inseriti nel DB durante la notte, alcuni nel momento dell’attacco stesso e 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 che a quell’ora era 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 il relativo 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 avevo chiesto espressamente durante il viaggio in macchina, che il server oggetto dell’attacco fosse 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 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 operation systems (OS) 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 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 “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 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 comunicazioni 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:

• 1 – https://it.wikipedia.org/wiki/Umberto_Rapetto
• 2 – https://it.wikipedia.org/wiki/EternalBlue
• 2.5 – https://www.metasploit.com/
• 3 – https://en.wikipedia.org/wiki/Network_segmentation
• 4 – https://it.wikipedia.org/wiki/Macchina_virtuale
• 5 – https://tg24.sky.it/mondo/2017/05/16/marcus-hutchins-wannacry-attacco-hacker-eroe.html
• 6 – https://en.wikipedia.org/wiki/VMware_Infrastructure
• 7 – https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-hyperv-image-download/

A cura di: Vincenzo Digilio

L’articolo A case history: come ho risolto un WanaCrypt0r 2.0 Attack proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/a-case-history-come-ho-risolto-un-wanacrypt0r-2-0-attack/