Da una vulnerabilità all'altra: l'analisi delle patch di Outlook rivela un difetto importante nell'API di Windows
Editoriale e contributi aggiuntivi di Tricia Howard
Analisi riassuntiva
Ben Barnea, ricercatore di Akamai, ha scoperto una nuova importante vulnerabilità in un componente di Internet Explorer, a cui è stata assegnato il codice CVE-2023-29324 con un punteggio CVSS base di 6,5.
La vulnerabilità fa sì che una funzione API di Windows, MapUrlToZone , consideri erroneamente locale un percorso remoto.
MapUrlToZone è comunemente usato come misura di sicurezza. In particolare, è stato utilizzato per mitigare la vulnerabilità critica di Outlook, nota come CVE-2023-23397 e corretta nella Patch Tuesday di marzo.
Un criminale non autenticato su Internet potrebbe sfruttare la vulnerabilità per costringere un client Outlook a connettersi a un server controllato da un hacker al fine di rubare le credenziali NTLM. Si tratta di una vulnerabilità facile da sfruttare perché può essere attivata senza alcuna interazione da parte dell'utente.
Tutte le versioni di Windows sono interessate da questa vulnerabilità. Di conseguenza, tutte le versioni del client Outlook su Windows sono sfruttabili. Tuttavia, secondo Microsoft, i server Exchange con l'aggiornamento di marzo non presentano questa funzionalità vulnerabile per impedire lo sfruttamento dei client vulnerabili.
Il problema è stato segnalato in modo responsabile a Microsoft e risolto nella Patch Tuesday di maggio 2023.
Introduzione
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-23397.
Questa vulnerabilità consente a un criminale di costringere un client Outlook a connettersi al server controllato dall'hacker. In questo modo, il client invia le credenziali NTLM al computer, il che consente al criminale di decifrare la password offline o di utilizzarla in un attacco di inoltro. Questa vulnerabilità può essere sfruttata in remoto su Internet senza alcuna interazione da parte dell'utente (zero clic).
Come osservato da Microsoft Threat Intelligence, un criminale russo ha utilizzato questa vulnerabilità per circa un anno in attacchi mirati contro diverse organizzazioni europee che operano nei settori dell'amministrazione pubblica, dei trasporti, dell'energia e della difesa.
Nell'ambito della nostra analisi della patch, abbiamo scoperto un modo per aggirare la correzione di questa vulnerabilità critica. In questo blog, esamineremo la vulnerabilità originale, la relativa patch e come aggirarla.
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 proprietà MAPI estesa 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.
Per risolvere il problema, il codice ora chiama MapUrlToZone per verificare che il percorso non faccia riferimento a un URL Internet. In tal caso, viene utilizzato il suono di promemoria predefinito anziché quello personalizzato.
Come aggirare la mitigazione
Diamo prima un'occhiata al flusso di codice pertinente in Outlook. Durante il caricamento del file audio personalizzato vengono richiamate le due importanti funzioni riportate di seguito.
MapUrlToZone : restituisce la zona dell'URL per determinare se il percorso è locale, intranet o attendibile (e non Internet)
CreateFile : apre un handle al file audio
Nota: anche SearchPath viene chiamato prima di CreateFile, ma gestisce il percorso in modo simile, quindi per facilità di comprensione, qui faremo riferimento solo a CreateFile.
Per aggirare la mitigazione, dobbiamo trovare un percorso che MapUrlToZone consideri come locale, intranet o zona attendibile e che CreateFile tratti anche come un dominio Internet.
Per chiamare MapUrlToZone, possiamo usare il seguente script PowerShell che richiama la funzione tramite il modello COM (Component Object Model).
Per verificare che MapUrlToZone sia una mitigazione adeguata, possiamo provare a chiamare la funzione sullo stesso percorso che ha attivato la vulnerabilità: un percorso UNC assoluto con un dominio Internet. MapUrlToZone restituisce 3 a indicare che il percorso si trova nell'area Internet, come previsto.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
Possiamo anche modificare il nostro percorso UNC usando un percorso del dispositivo locale:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
Come osservato sopra, MapUrlToZone identifica ancora il percorso come una zona Internet, quindi sarebbe ancora bloccato, come previsto dalla correzione.
Tuttavia, aggiungendo un altro "\" dopo "UNC\", MapUrlToZone ora restituisce 0, che indica un percorso locale:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
Quindi, MapUrlToZone conclude che questo URL è locale. Ora la domanda importante è: come verrà considerato questo URL da CreateFile? Accederà a un file locale o lo scaricherà tramite SMB?
Vediamo...
Figura 1. Simulazione di una chiamata CreateFile con il percorso UNC, che provoca una richiesta DNS
Bene! È stata inviata una richiesta DNS per recuperare l'IP di Akamai.com (Figura 1). Sembra che il percorso da noi trovato venga considerato come locale da MapUrlToZone, tuttavia CreateFile attiva una richiesta a Internet!
Ora attiviamo la vulnerabilità originale di Outlook, questa volta aggirando la mitigazione aggiunta.
Figura 2. Attivazione dell'evento del calendario, che provoca l'autenticazione NTLM su un server remoto
Come potete osservare nella Figura 2, una volta visualizzato il promemoria, Outlook si connette al server remoto che richiede l'autenticazione NTLM.
Secondo Microsoft, i server Exchange con l'aggiornamento software di marzo installato bloccheranno la proprietà PidLidReminderFileParameter, eliminando la funzione del file audio personalizzato. Pertanto, solo i computer che dispongono di client Outlook con un server Exchange senza patch sono vulnerabili a questo problema.
La causa principale
Questo problema sembra essere il risultato della complessa gestione dei percorsi in Windows.
MapUrlToZone chiama la funzione CreateUri che converte erroneamente il percorso '\\.\UNC\\Akamai.com\file.wav' in '/.//UNC//Akamai.com/file.wav'.
Per vedere quale accesso viene attivato da quest'ultimo percorso, possiamo utilizzare lo script ConvertDosPathToNtPath riportato nel blog di James Forshaw.
PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
Converting: '/.//UNC//Akamai.com/file.wav'
To: '\??\C:\UNC\Akamai.com\file.wav'
Type: RtlPathTypeRooted
FileName: file.wav
FullPathName: 'C:\UNC\Akamai.com\file.wav'
Ora possiamo vedere che questo percorso punta a una directory denominata "UNC" sull'unità C: locale. Si tratta ovviamente di una directory locale, quindi MapUrlToZone restituisce 0.
D'altra parte, CreateFile prima converte il percorso originale da un percorso DOS a un percorso NT chiamando la funzione RtlpDosPathNameToRelativeNtPathName. Ancora una volta, l'utilizzo dello script ci consente di osservare l'output di questa conversione.
PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
Converting: '\\.\UNC\\Akamai.com\file.wav'
To: '\??\UNC\Akamai.com\file.wav'
Type: RtlPathTypeLocalDevice
FileName: file.wav
FullPathName: '\\.\UNC\Akamai.com\file.wav'
Si noti che questa volta il risultato non punta a un'unità locale. Quindi, perché viene attivata una richiesta SMB? Come si può vedere nello snippet sopra, il percorso risultante è '\??\UNC\Akamai.com\file.wav'. L'accesso a questo percorso NT farà in modo che il gestore oggetti instradi la richiesta IO al driver MUP (Multiple UNC Provider) perché la voce della directory oggetti globale per "UNC" è un link simbolico a "\Device\Mup". Poiché RtlpDosPathNameToRelativeNtPathName ha rimosso o compresso il segno "\" aggiuntivo, il percorso ora contiene solo il nome del dominio Internet.
Riteniamo che questo tipo di confusione possa potenzialmente causare vulnerabilità in altri programmi che utilizzano MapUrlToZone su un percorso controllato dall'utente e quindi utilizzano un'operazione di file (come CreateFile o un'API simile) sullo stesso percorso. Inoltre, non possiamo escludere altri problemi derivanti dai programmi che chiamano la funzione CreateUri.
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 .
Riepilogo
Questa vulnerabilità è un altro esempio di controllo delle patch che causa nuove vulnerabilità e aggiramenti. In particolare per questa vulnerabilità, l'aggiunta di un carattere consente di aggirare le patch critiche.
Ci auguriamo che la funzione del suono di promemoria personalizzato venga completamente rimossa, in quanto sono maggiori i rischi per la sicurezza che pone rispetto al valore che offre agli utenti. Si tratta di un attacco alla superficie di analisi multimediale "zero-clic" che potrebbe potenzialmente contenere vulnerabilità critiche di danneggiamento della memoria. Considerando l'enorme diffusione di Windows, l'eliminazione di una tale superficie di attacco potrebbe avere effetti molto positivi.
Come parte del nostro costante impegno volto a proteggere i nostri clienti e la community, continueremo ad analizzare patch e altri sistemi per le vulnerabilità. Per restare aggiornati sulle ultime ricerche sulla sicurezza di Akamai, seguiteci su Twitter.
Desideriamo ringraziare Microsoft per la collaborazione e la rapida risposta nella gestione di questo problema.
