Disattivazione dell'audio: concatenamento delle vulnerabilità per ottenere RCE su Outlook - Parte 1
Analisi riassuntiva
Il ricercatore di Akamai Ben Barnea ha individuato due vulnerabilità in Microsoft Windows a cui ha assegnato i codici CVE-2023-35384 e CVE-2023-36710.
Un utente malintenzionato su Internet può concatenare le vulnerabilità per creare un exploit completo di esecuzione di codice remoto (RCE) a zero clic contro i client Outlook.
La prima vulnerabilità risiede nell'analisi di un percorso da parte del metodo MapUrlToZone . Lo sfruttamento di questa vulnerabilità richiede l'invio di un'e-mail creata appositamente a un client di Outlook, che a sua volta scaricherà un file audio speciale da un server controllato dal criminale.
La seconda vulnerabilità risiede nell'Audio Compression Manager (ACM). Questa vulnerabilità viene sfruttata quando il file audio scaricato viene riprodotto automaticamente e può portare all'esecuzione di codice sul computer preso di mira. Questo metodo è descritto dettagliatamente nella parte 2 di questo post del blog.
Le vulnerabilità sono state segnalate in modo responsabile a Microsoft e descritte nella Patch Tuesday di Agosto 2023 e Ottobre 2023 .
I computer Windows con l'aggiornamento software di ottobre 2023 sono protetti da queste vulnerabilità. Inoltre, i client Outlook che utilizzano server Exchange a cui è stato applicato l'aggiornamento software di marzo 2023 sono protetti contro la funzionalità abusata.
Panoramica
Tra le vulnerabilità risolte dalla Patch Tuesday di marzo 2023, era presente una vulnerabilità critica di Outlook a cui è stato assegnato il codice CVE-2023-23397e che è stata sfruttata da Forest Blizzard, identificato da Microsoft come un criminale russo sponsorizzato dallo stato. Nel dicembre 2023, Microsoft, insieme al Polish Cyber Command (DKWOC), ha pubblicato di aver assistito a recenti tentativi di sfruttamento della vulnerabilità da parte dello stesso criminale. Questa vulnerabilità consentiva al malintenzionato di costringere un client Outlook a connettersi al server da lui controllato. Come parte di questa connessione, il client inviava le proprie credenziali NTLM al criminale, che poteva quindi decifrarle offline o utilizzarle in un attacco di inoltro. Questa vulnerabilità poteva essere sfruttata in remoto su Internet senza alcuna interazione da parte dell'utente (zero clic).
Dopo il rilascio della patch per questa vulnerabilità, abbiamo trovato una modalità di elusione che abbiamo descritto in un post del blog precedente. Questa elusione è stata risolta nel Patch Tuesday di maggio 2023. In quella pubblicazione, avevamo raccomandato a Microsoft di rimuovere la funzione abusata, in quanto introduceva una superficie di attacco vasta e complessa. Poiché la funzione è ancora presente in Outlook, abbiamo deciso di indagare ulteriormente.
Alla fine siamo riusciti a ottenere una catena di vulnerabilità RCE completa su Outlook. Abbiamo trovato un'altra elusione della vulnerabilità originale di Outlook, che ancora una volta ci ha permesso di costringere il client a connettersi a un server controllato da un criminale e a scaricare un file audio dannoso. Poi, siamo riusciti a trovare una vulnerabilità nella libreria di analisi multimediale di Windows utilizzata per elaborare e riprodurre qualsiasi file audio in generale e i suoni di notifica di Outlook in particolare. Un utente malintenzionato che concatena queste vulnerabilità può ottenere un RCE a zero clic sui client Outlook vulnerabili.
Questa serie di post in due parti presenterà la ricerca che abbiamo condotto per individuare le due vulnerabilità. Questa prima parte si concentrerà sull'elusione precedente e su una nuova. Nella parte 2, descriveremo la vulnerabilità di analisi dei media che abbiamo trovato.
La vulnerabilità originale
La vulnerabilità di Outlook che è stata corretta a marzo viene attivata quando un criminale invia un'e-mail contenente un promemoria con un suono di notifica personalizzato. Questo suono personalizzato viene specificato dal criminale come percorso, utilizzando la MAPI proprietà PidLidReminderFileParameter. Un criminale può specificare un percorso UNC per fa sì che il client recuperi il file audio da qualsiasi server SMB. Durante la connessione al server SMB remoto viene inviato l'hash Net-NTLMv2 in un messaggio di negoziazione (Figura1).
Figura 1: Coercizione delle credenziali NTLM
Per risolvere il problema, il codice ora chiama MapUrlToZone per classificare il percorso come Intranet, locale o Internet. Se l'URL punta a una risorsa su Internet, viene utilizzato il suono di promemoria predefinito anziché quello personalizzato.
Trovare un'elusione
Dopo aver messo in atto la mitigazione, ci siamo chiesti se fosse possibile aggirarla.
In questo contesto, per elusione si intende un percorso che superi il test di localizzazione e che venga utilizzato da Outlook per scaricare il file audio da una posizione remota. In altre parole, dobbiamo trovare un percorso che MapUrlToZone consideri come non-Internet, ma che CreateFile tratti come dominio Internet.
Per trovare un'elusione di questo tipo, dobbiamo comprendere appieno il funzionamento interno delle funzioni e le operazioni eseguite nell'ambito dell'analisi dei percorsi.
Percorsi e URL di Windows
Esistono molti tipi diversi di percorsi DOS in Windows e sono state condotte molte ricerche su di essi e sulla loro conversione in percorsi NT. Qui non tratteremo i diversi tipi di percorsi di Windows; il post sul blog di James Forshaw tratta in modo esauriente questo argomento.
Torniamo alle funzioni di nostro interesse. CreateFile riceve un percorso Windows; MapUrlToZone (come suggerisce il nome) può ricevere un URL o un percorso. Per trovare un'elusione, dobbiamo prima capire quali tipi di percorsi sono supportati da ciascuna funzione (o da entrambe).
Nota: CreateFile e MapUrlToZone non elaborano i percorsi di per sé, ma utilizzano a tale scopo altre funzioni WinAPI. Per brevità, utilizzeremo CreateFile e MapUrlToZone per riferirci alle funzioni di analisi dei percorsi sottostanti.
CreateFile |
MapUrlToZone |
|
|---|---|---|
RtlPathTypeUncAbsolute |
✔ |
✔ |
RtlPathTypeDriveAbsolute |
✔ |
✔ |
RtlPathTypeDriveRelative |
✔ |
✔ |
RtlPathTypeRooted |
✔ |
✘ |
RtlPathTypeRelative |
✔ |
✘ |
RtlPathTypeLocalDevice |
✔ |
✔ |
RtlPathTypeRootLocalDevice |
✔ |
✘ |
Schemi (file://, http://) |
✘ |
✔ |
Tabella 1. Tabella di confronto tra CreateFile e MapUrlToZone per funzionalità percorso
Come si vede nella Tabella 1, solo quattro tipi di percorsi sono supportati da entrambe le funzioni: RtlPathTypeUncAbsolute, RtlPathTypeDriveAbsolute, RtlPathTypeDriveRelative, e RtlPathTypeLocalDevice.
Primo tentativo
Il primo tentativo di trovare un'elusione è stato effettuato con un percorso UNC assoluto (RtlPathTypeUncAbsolute(Secure Access Service Edge). La Figura 2 illustra in dettaglio la struttura del percorso.
Figura 2: Un percorso UNC assoluto e i suoi componenti
Come fa Windows a sapere dove inizia il componente del percorso? La Tabella 2 mostra il codice pertinente (RtlGetFullPathName_Ustr(Secure Access Service Edge).
case RtlPathTypeUncAbsolute:
SeperatorsFound = 0;
for ( CurrentIndex = 2; CurrentIndex < InputPathLength; ++CurrentIndex )
{
CurrentChar = InputPathString->Buffer[CurrentIndex];
if ( CurrentChar == '\\' || CurrentChar == '/' )
{
SeperatorsFound++;
if ( SeperatorsFound == 2 )
break;
}
}
Tabella 2. Frammento di codice RtlGetFullPathName_Ustr che gestisce il percorso UNC
Possiamo notare che il codice salta il prefisso UNC assoluto ("\") e assume che il componente del percorso inizi un carattere dopo il secondo separatore di percorso ('\' o '/').
Ma cosa succede se forniamo un percorso come "\\\\localhost\..\Akamai.com\dir\file.txt"?
Il percorso verrà elaborato nel modo seguente:
"\\\\" verrà interpretato come il prefisso UNC e il componente del percorso radice
Il componente del percorso è "localhost..\Akamai.com\dir\file.txt"
Normalmente, nessuna quantità di ".." può andare oltre il percorso principale. Ad esempio, "\localhost\directory\..\file.txt" risulterebbe in "\localhost\directory\file.txt". Tuttavia, poiché nel nostro esempio il simbolo ".." non fa parte del percorso principale, il percorso viene convertito in "\\\Akamai.com\dir\file.txt".
Ciò significa che abbiamo trovato un modo per manomettere il percorso eliminando parti di esso.
Ed è così che CreateFile elabora questo percorso; come fa MapUrlToZone a gestirlo (Tabella 3)? Per prima cosa rimuove le barre rovesciate aggiuntive, quindi interpreta il percorso in modo diverso:
\\localhost è il nome del server
\..\ viene ignorato (poiché non si può andare oltre il nome del server)
Akamai.com\dir\file.txt comprende il componente di percorso
Percorso di input: \\\\localhost\..\Akamai.com\dir\file.txt |
|
|---|---|
CreateFile |
MapUrlToZone |
\\\Akamai.com\dir\file.txt |
\\localhost\Akamai.com\dir\file.txt |
Tabella 3. Percorsi di input per CreateFile e MapUrlToZone e il risultato della loro analisi
MapUrlToZone restituisce 0 (Locale) per il percorso di output visto sopra.
Anche se ci sembra di aver trovato un'elusione, sfortunatamente il percorso non può essere usato per attivare una richiesta UNC. Notate la barra in più all'inizio del percorso elaborato da CreateFile ; questa barra segna il nome del server come vuoto. Quando il provider UNC multiplo (MUP) chiede ai diversi provider di rete se possono gestire questo nome di server (vuoto), tutti restituiscono false, quindi non viene effettuata alcuna richiesta.
L'abuso della differenza tra il modo in cui MapUrlToZone e CreateFile gestiscono questo percorso potrebbe richiedere una soluzione più complicata, ad esempio trovare un modo per omettere la barra rovesciata aggiuntiva o trovare un errore di analisi nel codice MUP. Questo è un suggerimento per una ricerca futura.
Secondo tentativo: Elusione n. 1 (CVE-2023-29324)
Dal momento che giocare con i percorsi UNC assoluti non ha funzionato, abbiamo proseguito con il tipo di percorso successivo che supporta UNC, ovvero RtlPathTypeLocalDevice. "\\.\UNC\Akamai.com\test.wav" è un esempio di percorso per un dispositivo locale. In particolare, punta al nome del dispositivo UNC, che sarà reindirizzato al driver MUP.
Come abbiamo detto prima, per trovare un'elusione dobbiamo osservare le diverse operazioni eseguite come parte dell'analisi dei percorsi. La Tabella 4 mostra questa differenza.
CreateFile |
MapUrlToZone |
|---|---|
se RtlPathTypeLocalDevice → Avanzare di 4 caratteri |
se RtlPathTypeLocalDevice → Avanzare di 4 caratteri |
Saltare gli spazi intermedi |
|
Convertire '/' in '\' |
|
Chiudere le '\' ripetute |
|
Rimuovere i componenti "." e ".." |
Rimuovere i componenti "." e ".." |
Tabella 4. Diverse operazioni completate come parte dell'analisi del percorso
Possiamo vedere che CreateFile effettua ulteriori operazioni, come la conversione delle barre semplici in barre rovesciate e la chiusura delle barre rovesciate ripetute.
Diamo un'occhiata a un percorso che sfrutta una di queste differenze , usando un separatore di percorso aggiuntivo. La Tabella 5 mostra i percorsi risultanti dopo che il codice ha saltato il prefisso "UNC\".
Percorso di input: \\.\UNC\\Akamai.com\test.wav |
|
|---|---|
CreateFile |
MapUrlToZone |
Akamai.com\test.wav |
\Akamai.com\test.wav |
Tabella 5. Percorsi risultanti dopo aver saltato il prefisso UNC/
Notate il percorso nella colonna di destra. Un percorso che inizia con un separatore di percorso seguito da un carattere che non è un separatore di percorso è chiamato percorso radicato. MapUrlToZone utilizza le funzioni IsRootedPath o IsDrivePath per determinare se il componente del percorso radice è locale. Nel nostro caso, il percorso è radicato e quindi MapUrlToZone restituisce il valore locale.
CreateFile non ha il separatore di percorso aggiuntivo dopo il prefisso UNC, quindi sa estrarre correttamente il nome di dominio e ora accede al server SMB Akamai.com per recuperare il file test.wav. Abbiamo trovato un percorso che MapUrlToZone considera locale, ma CreateFile non lo considera tale. Questa elusione ci ha permesso di sfruttare nuovamente la vulnerabilità di Outlook CVE-2023-23397.
Per mitigare questo problema, Microsoft ha cercato di rendere più simili i due flussi; le operazioni di conversione delle barre e delle barre rovesciate e la chiusura dei separatori di percorso ripetuti sono state aggiunte al flusso di analisi dei percorsi di MapUrlToZone .
Un pensiero …
Nella sezione precedente, abbiamo notato che MapUrlToZone controlla se il componente del percorso dopo "\\.\UNC" è un'unità o un percorso radicato. Dopo la correzione, non possiamo rendere questo componente del percorso un percorso radicato, perché i separatori di percorso ripetuti sono stati eliminati. Tuttavia, possiamo comunque fornire un percorso di unità, ad esempio "\\.\UNC\C:Akamai.com/test.wav".
In questo modo, costringiamo MapUrlToZone a restituire 0. Purtroppo, nessun provider di rete è in grado di gestire un percorso che include i due punti, quindi questa confusione non è utile per noi. Come nel nostro primo tentativo (fallito), trovare una confusione nel codice di analisi MUP può portare a una nuova vulnerabilità.
Terzo tentativo: Elusione n. 2 (CVE-2023-35384)
Dopo la correzione, le operazioni eseguite dalle due funzioni sono quasi le stesse (Tabella 6).
CreateFile |
MapUrlToZone |
|---|---|
se RtlPathTypeLocalDevice → Avanzare di 4 caratteri |
se RtlPathTypeLocalDevice → Avanzare di 4 caratteri |
Saltare gli spazi intermedi |
|
Convertire '/' in '\' |
Convertire '/' in '\' |
Chiudere le '\' ripetute |
Chiudere le '\' ripetute |
Rimuovere i componenti "." e ".." |
Rimuovere i componenti "." e ".." |
Tabella 6. Operazioni eseguite da CreateFile e MapUrlToZone postfix
Tuttavia, se andiamo in profondità, possiamo chiederci: In che modo ciascuna funzione decide che il percorso è un percorso di un dispositivo locale? La Tabella 7 illustra i frammenti di codice di ciascuna funzione che aiutano a determinare il tipo di percorso.
CreateFile
if (IS_PATH_SEPARATOR(Path[0]) &&
IS_PATH_SEPARATOR(Path[1]) &&
(Path[2] == '.' || Path[2] == '?') &&
IS_PATH_SEPERATOR(Path[3])
return RtlPathTypeLocalDevice;
MapUrlToZone
!strncmp(path, "\\.\", 4) || !strncmp(path, "\\?\", 4)
Tabella 7. Frammenti di codice che determinano il tipo di percorso
Con CreateFileun separatore di percorso può essere una barra o una barra rovesciata; ad esempio, "\\./" è considerato un percorso di un dispositivo locale. Con MapUrlToZonesolo i percorsi esatti "\\.\" o "\?\" sono considerati percorsi di dispositivi locali. Si tratta di una confusione sul tipo di percorso: possiamo fare in modo che CreateFile riconosca il componente "\\./" come un percorso del dispositivo locale, mentre MapUrlToZone non riesca a riconoscerlo. Questa confusione comporta una diversa gestione del percorso da parte delle due funzioni.
Tenendo presente ciò, utilizziamo un percorso che contenga il componente "confuso": \\./UNC/Akamai.com/file.wav.
Analizzando il processo decisionale per il tipo di percorso, questo è il flusso di MapUrlToZone:
Il percorso è un'unità locale o un percorso radicato? No
IsLocalDeviceUNC? No
PathIsUNCW? Sì
PathIsUNCW restituisce true e quindi la funzione lo contrassegna come un percorso UNC assoluto e avanza di due caratteri per saltare il prefisso UNC "\\". L'output di ciascuna funzione è mostrato nella Tabella 8.
Percorso di input: \\./UNC/Akamai.com/file.wav |
|
|---|---|
CreateFile |
MapUrlToZone |
UNC\Akamai.com\file.wav |
./UNC/Akamai.com/file.wav |
Tabella 8. Output dei percorsi per le funzioni CreateFile e MapUrlToZone
A questo punto, CreateFile conclude che il suo output è un percorso UNC e che Akamai.com è il nome host.
Al contrario, MapUrlToZone conclude le seguenti informazioni:
Schema: file://
Host: . (punto)
Percorso: /UNC/Akamai.com/file.wav
URI assoluto: file://./UNC/Akamai.com/file.wav
Pertanto, quando l'URI assoluto inizia con "file://./" (con l'host "."), il codice interpreta lo sharename come parte dello spazio dei nomi dei dispositivi DOS (Figura 3). Pertanto, "file://./UNC/" si riferisce allo spazio dei nomi UNC.
Figura 3: URL con nome host contenente un punto (https://en.wikipedia.org/wiki/File_URI_scheme)
Per chiarire, entrambe le funzioni considerano il nostro percorso di input un percorso UNC, ma di tipo diverso: CreateFile lo tratta come un percorso di un dispositivo locale di Windows, mentre MapUrlToZone lo considera un URL.
A questo punto, possiamo generare confusione tra le due funzioni. Purtroppo, se non eseguiamo alcun trucco, MapUrlToZone continuerebbe a interpretare Akamai.com come nome host e, poiché questo nome host è un dominio Internet, la funzione restituirà 3, quindi non sarà un'elusione. Dobbiamo trovare un altro modo per abusare del processo di analisi.
In seguito, MapUrlToZone utilizza una funzione interna chiamata SetPath per operare sul componente percorso (Tabella 9).
CreateFile |
SetPath |
|---|---|
se RtlPathTypeLocalDevice → Avanzare di 4 caratteri |
|
Saltare gli spazi intermedi |
|
Convertire '/' in '\' |
|
Chiudere le '\' ripetute |
|
Rimuovere i componenti "." e ".." |
Rimuovere i componenti "." e ".." |
Tabella 9. Confronto tra le operazioni completate tra CreateFile e SetPath
Ancora una volta possiamo sfruttare la differenza tra le operazioni eseguite dalle due funzioni. Sappiamo dalla nostra precedente vulnerabilità che l'aggiunta di una barra può portare a un'elusione, quindi ha senso provare di nuovo. CreateFile rimuoverà semplicemente la barra aggiuntiva.
Con MapUrlToZone, CreateUri restituisce l'URI assoluto "file://./UNC//Akamai.com/file.wav". Questo URI viene passato a GetZoneFromUriInternal, che internamente porta a un'altra chiamata CreateUri .
E perché questo è un problema? Dal momento che CreateUri ha ricevuto un URL, lo riconverte in un percorso Windows usando PathCreateFromUrlW. Il percorso Windows restituito è "\\.\UNC\\Akamai.com\test.wav". La versione corretta ora sa rimuovere la barra extra e, quindi, capisce correttamente che Akamai.com è il nome host.
Ciò significa che abbiamo bisogno di un abuso più complicato della differenza tra CreateFile e SetPath. Questa volta, abuseremo di due differenze:
CreateFile chiude i separatori di percorso ripetuti.
CreateFile rimuove i componenti '.' e '..' dopo la chiusura dei separatori di percorso ripetuti.
Un percorso che abusa di entrambe le differenze è \\./UNC/C://../Akamai.com/file.wav. La sua elaborazione è illustrata in dettaglio nel diagramma di flusso della Figura 4.
Figura 4: Diagramma di flusso del percorso analizzato dalle due funzioni
Sappiamo già che il percorso finale di CreateFilesarà trattato come un percorso UNC. Quanto all'output di SetPath, MapUrlToZone richiama GetZoneFromUriInternal con l'URI assoluto file://./UNC/C:/Akamai.com/file.wav. Questa volta, PathCreateFromUrlW converte questo URL nel percorso Windows "\\.\UNC\C:\Akamai.com\file.wav". Si tratta di un percorso locale, quindi MapUrlToZone restituisce 0 (locale). Abbiamo trovato ancora una volta un'elusione precisa!
Per risolvere il problema, il codice ora chiama NormalizeDosDevicePrefix per convertire le barre in barre rovesciate, evitando di confondere il rilevamento del percorso di un dispositivo locale.
Rilevamento e mitigazione
Microsoft ha pubblicato una guida completa per il rilevamento e la mitigazione della vulnerabilità originale di Outlook. Dalla nostra osservazione, tutti i metodi specificati sono applicabili alla nuova vulnerabilità in quanto non dipendono dall'URL specificato nella proprietà PidLidReminderFileParameter .
Raccomandiamo alle organizzazioni di usare la microsegmentazione per bloccare le connessioni SMB in uscita verso indirizzi IP pubblici remoti. Inoltre, consigliamo di disabilitare NTLM nel proprio ambiente, oppure di aggiungere gli utenti al Gruppo di utenti protetti, cosa che impedisce l'uso di NTLM come meccanismo di autenticazione.
Il blocco delle connessioni SMB in uscita e la disabilitazione di NTLM possono aiutare a prevenire il furto di credenziali. Tuttavia, quando le richieste SMB falliscono, Windows passa a WebDAV, se questo è abilitato. Il furto di credenziali non può essere abusato tramite WebDAV, ma è comunque possibile scaricare il file audio, che rappresenta il secondo passo della nostra catena RCE.
Perché fermarci ora?
In questo post abbiamo descritto in dettaglio il processo di ricerca che ha portato alla scoperta dei due elusioni, compresa l'analisi delle cause di fondo. Come abbiamo mostrato, il codice di analisi dei percorsi di Windows è complesso e spesso può portare a vulnerabilità. I ricercatori di sicurezza che si imbattono nel codice di gestione dei percorsi sono invitati a riflettere sulla superficie di attacco che presenta.
Oltre all'elusione di MapUrlToZone nel contesto di Outlook, non possiamo escludere la possibilità che queste vulnerabilità possano portare anche all'elusione di Mark-of-the-Web (MotW).
Oltre alla possibilità di perdere le credenziali NTLM, abbiamo anche la possibilità di scaricare e riprodurre un file audio arbitrario. Ora potete leggere la parte 2 di questa serie di blog, che illustra in dettaglio la vulnerabilità relativa all'analisi del suono.
