A volte le vulnerabilità hanno risvolti inaspettati e quello che sembra molto pericoloso non lo è poi così tanto dal lato pratico, mentre quello che è passato in sordina nel tempo diventa molto più problematico di ciò che si pensava: altre volte, invece, capita che le falle vengano inavvertitamente annunciate e per poi essere “smentite” come è successo a marzo 2020 per SMBGhost, una particolare vulnerabilità presente nei moderni sistemi di ultima generazione come Windows 10 e Windows Server 2019.
Una vulnerabilità che ha tenuto con il fiato sospeso l’intera community di sicurezza e parecchi amministratori di sistema.
Una vulnerabilità dalla storia travagliata, la cui reale pericolosità si è manifestata solo nel maggio 2020 con la scoperta di altre falle che ne hanno abilitato il vero potenziale distruttivo, tant’è che qualcuno la referenzia anche con il nome CoronaBlue, ispirandosi un po’ alla recente pandemia di Covid-19 e un po’ alla famosa vulnerabilità EternalBlue, che nel 2017 letteralmente permesso al ransomware WannaCry di mettere ginocchio innumerevoli organizzazioni in tutto il mondo.
Indice degli argomenti
SMBGhost: come funziona
Inizialmente questa vulnerabilità fu annunciata per errore da Microsoft il 10 marzo 2020 sul suo stesso portale ufficiale. Un annuncio rimasto online per poco tempo e fatto sparire dopo poche ore.
L’annuncio non conteneva molti dettagli tecnici, ma diceva chiaramente che la falla poteva essere sfruttata da codici malevoli autopropaganti – cosiddetti worm – e puntava a due articoli nei blog di Cisco Talos e Fortinet.
Questi approfondimenti, invece, contenevano più dettagli su SMBGhost e anch’essi sono stati messi offline poco dopo. Un silenzio misterioso che ha fatto preoccupare non poco gli esperti del settore.
L’impasse è stata poi risolta da Microsoft stessa, che due giorni dopo ha pubblicato il bollettino sulla vulnerabilità CVE-2020-0796, SMBGhost appunto, contestualmente al rilascio della patch per risolverla.
Qui non si parlava di vulnerabilità “wormable”, come in gergo viene detto per le falle che possono essere sfruttate automaticamente da malware su larga scala, ma comunque veniva indicato che la vulnerabilità aveva alte probabilità di diventare bersaglio degli hacker.
Dopo li pasticciato annuncio ufficiale, i dettagli cominciarono ad affiorare: SMBGhost era originata da lacune nella gestione della memoria durante una particolare operazione di decompressione, una routine annidata nel cuore del codice che gestisce i servizi Server Message Block (SMB) più all’avanguardia, la versione 3.1.1 appunto, introdotta per la prima volta da Windows 10.
In particolare, la funzione incriminata era proprio la SmbCompressDecompress all’interno del modulo di sistema srv2.sys, driver che si occupa proprio della gestione dei messaggi SMB, funzione che fa da interfaccia, da strato di astrazione – cosiddetto wrapper – alla routine nativa RtlDecompressBufferEx2. Questa particolare funzione non veniva utilizzata correttamente.
Infatti, durante il processamento dei messaggi SMBv3 compressi pervenuti dalla rete, il codice del driver di sistema effettuava una serie di operazioni apparentemente innocue, ma che agli occhi di hacker esperti comportano gravi rischi.
In particolare, si verificava una condizione in cui le funzioni più esterne, ovvero la macro routine Srv2DecompressData, predisponeva aree di memoria per contenere la versione estesa, decompressa, del messaggio in base ad una lunghezza espressa nel messaggio stesso, marchiandosi però di un peccato apparentemente veniale: non considerando affatto se quel valore rappresentava un numero intero con o senza segno. Dettaglio che in alcune condizioni dà vita a comportamenti del tutto inattesi e al contempo estremamente graditi da chi si occupa di sfruttare vulnerabilità, da chi scrive i cosiddetti exploit.
Condizione che si verificava proprio nel come veniva interpretato il particolare valore dalla routine di decompressione Srv2DecompressData, che lo assumeva rappresentato come intero privo di segno.
Insomma, per una serie di divergenze nella rappresentazione dello stesso valore, parte del programma si aspettava di poter utilizzare un’area di memoria molto più vasta di quella che era stata in realtà riservata, creando una condizione in cui da un semplice messaggio ricevuto senza alcuna autenticazione pregressa, si poteva corrompere, alterare, modificare porzioni di memoria adibite ad altri scopi. Porzioni di memoria all’interno del cuore del sistema operativo.
Poco dopo la pubblicazione dei dettagli tecnici, sono comparsi online anche stralci di codice che andavano a testare queste condizioni inattese, dei proof-of-concept in grado di creare crash di sistema, di spegnere le macchine Windows bersaglio corrompendo la memoria del kernel generando la famosa Blue Screen of Death (BSoD), tipica schermata blu che indica all’amministratore di sistema che l’unica cosa da fare è riavviare completamente la macchina.
Benché i ricercatori avessero ben chiaro cosa separava SMBGhost dal diventare una nuova EternalBlue, per il momento la falla era “solamente” in grado di spegnere qualsiasi sistema collegato in rete con un servizio SMB v3.1.1 con supporto alla compressione abilitato, condizione di default, in pratica tutte le macchine:
- Windows 10 Version 1903 (32-bit, ARM64, x64)
- Windows 10 Version 1909 (32-bit, ARM64, x64)
- Windows Server, version 1903 (Server Core installation)
- Windows Server, version 1909 (Server Core installation)
Il ruolo di SMBleed e la combinazione fatale
Quello che mancava a SMBGhost per compiere il suo prossimo step evolutivo era un modo affidabile di permettere all’attaccante di imparare qualcosa sulla struttura della memoria del sistema bersaglio. Memoria core che nei sistemi moderni viene cambiata ad ogni avvio.
Questa tecnica di protezione della memoria è detta Address Space Layout Randomization (ASLR) e nel particolare caso si parla di KASLR, dove “K” sta per Kerner perché si tratta di una variante del meccanismo di protezione applicato alle aree di memoria privilegiate del sistema operativo.
La randomizzazione della memoria rende molto più ostico per gli hacker lo sfruttamento di falle come SMBGhost: benché sia possibile alterare arbitrariamente delle porzioni di memoria, non si sa bene dove siano le locazioni che vanno modificate per alterare a piacere il flusso di esecuzione del sistema.
In buona sostanza in questa condizione un hacker poteva riuscire solamente a rompere funzionalità a caso e forzare il riavvio della macchina, condizione che per macchine particolarmente importanti può comunque essere davvero problematica.
Esempio di ASLR su Windows.
Siccome le disgrazie non vengono mai sole, pochi mesi dopo la scoperta di SMBGhost venne scoperta e pubblicata una nuova falla battezzata SMBleed (CVE-2020-1206), il cui nome non troppo velatamente richiama il servizio SMB e la famosa vulnerabilità HeartBleed: un pezzo di storia della cyber security moderna, falla che nel 2014 ha messo a rischio un’enormità di sistemi che facevano uso di crittografia OpenSSL, permettendo ad attaccanti di rete di accedere e scaricare pezzi della memoria interna dei sistemi con un semplice messaggio, una banale richiesta che dava origine ad una lettura un po’ troppo sbarazzina.
In completa analogia con quello che avvenne nel 2014, SMBleed permette di fare sostanzialmente lo stesso però attraverso il protocollo SMBv3: ovvero dare un’occhiata alle porzioni di memoria più intime del sistema. Proprio quello di cui si aveva bisogno.
Infatti, a giugno 2020, si è manifestata una sorta di congiunzione astrale dove da un lato vi erano i codici per sfruttare SMBGhost, rilasciati pubblicamente dai ricercatori ed in seguito integrati in strumenti di attacco come Metasploit, e dall’altro la nuova vulnerabilità SMBleed che permetteva di ottenere quelle informazioni fondamentali per creare un attacco SMBGhost più evoluto, che passasse dal rompere la macchina bersaglio all’iniettarvi codice e malware arbitrario in una delicata danza di equilibri tra locazioni di memoria e scritture controllate.
Questa congiunzione è stata dimostrata con il whitepaper di SMBleedingGhost, dove è stata documentata la fattibilità pratica del combinare le due criticità per ottenere l’esecuzione di malware sfruttando le informazioni estratte dalla memoria di sistema con SMBleed e preparando un exploit SMBGhost mirato per la particolare macchina Windows.
Il tutto ovviamente corredato dal rilascio di codici eseguibili di test per provare inconfutabilmente che lo scenario è effettivamente reale, che il rischio è concreto e che bisogna agire subito.
Conclusioni
Al momento SMBGhost (nota anche come EternalDarkness) non ha raggiunto i livelli di diffusione del suo predecessore EternalBlue.
Da un lato, per i più ottimisti questo può significare che qualche lezione dal passato dopotutto è stato appressa, dall’altro, per i più cinici, è una sorta di effetto collaterale positivo del mancato aggiornamento dei sistemi operativi: ovvero che ancora ci siano relativamente pochi sistemi operativi Windows moderni.
Tuttavia, questa particolare vulnerabilità non è affatto da sottovalutare perché detiene ancora un fortissimo potenziale distruttivo. Inoltre, da essa possiamo ricevere importanti indicazioni anche su aspetti metodologici.
Infatti, innanzitutto la sua storia ci aiuta a capire come le vulnerabilità evolvano nel tempo e siano tutt’altro che statiche, come possano divenire molto più pericolose man mano che dettagli emergono e come la decisione di non applicare gli aggiornamenti o applicare solamente i workaround, in questo caso la disabilitazione della compressione SMBv3, siano completamente da rivalutare nel corso del tempo: un giorno siamo di fronte ad un problema contenuto, un problema calcolato solamente dalle comunità di ricerca, un altro giorno ci troviamo di fronte ad un nuovo WannaCry, un qualcosa che può mettere in ginocchio un’organizzazione in pochi minuti.
Il bello, però, è che con i giusti occhi e con costanza, queste condizioni e queste evoluzioni si possono cogliere per tempo, prima che abilitano forze ostili a penetrare le infrastrutture IT ed a mettere a repentaglio il business.
