A cura di: Manuel Roccon (Team Hackerhood)
Introduzione
Nel precedente articolo ci eravamo già occupati della CVE-2023-23397, che permetteva di ricevere hash NTLMv2 di un utente tramite un appuntamento Outlook inviato alla vittima
Abbiamo analizzato come sfruttare questa vulnerabilità, apparentemente risolta con la patch di marzo 2023. Di seguito il link all’articolo:
Dopo la patch il ricercatore di Akamai, Ben Barnea, ha scoperto un modo per aggirare la mitigazione utilizzando un altro difetto critico in un componente di Internet Explorer.
RHC si era occupato di questo nel seguente articolo:
Il nuovo difetto fa sì che una funzione API di Windows (MapUrlToZone), una misura di sicurezza utilizzata per mitigare CVE-2023-23397, pensi erroneamente che un percorso remoto sia locale.
L’API in questione viene usata nella prima fix di Office di marzo per determinare se il percorso fornito per audio del remainder sia interno o esterno alla rete.
Barnea ha sottolineato come l’aggiunta di un carattere nel percorso UNC abbia indotto MapUrlToZone a identificare che il percorso fosse un percorso locale, consentendo un bypass critico della patch.
Akamai ha segnalato la nuova vulnerabilità, CVE-2023-29324 a Microsoft alla fine di marzo, che è stata risolta negli aggiornamenti del Patch Tuesday di maggio (KB5026361).
Verifichiamo il bypass
Anche se ora speriamo che la vulnerabilità sia stata definitivamente risolta, andremo a testare questo escape individuato da Akamai (installando la patch che doveva risolvere il problema iniziale) e poi successivamente la patch tuesday di maggio per vedere che effettivamente sia stata risolta.
Riproviamo il test iniziale
Con Office alla versione vulnerabile del primo exploit, proviamo a verificare se la vecchia vulnerabilità effettivamente sia ancora sfruttabile.
Rispetto al nostro precedente articolo, abbiamo modificato solo leggermente il nostro exploit utilizzando un url per il puntamento alla nostra macchina attaccante.
A questo punto eseguiamo la procedura dell’ultima volta.
Importo di nuovo appuntamento e vediamo cosa succede quando viene visualizzato il reminder.
A questo punto vediamo che con URL analizzato in precedenza exploit è funzionante.
Installazione prima patch
A questo punto installiamo la prima patch del 14 marzo 2023 (patch per CVE-2023-23397) che avrebbe dovuto risolvere definitivamente questo problema.
Questa è la versione di Office attualmente installata nella macchina di test, non sono state installate patch successive.
Ora analizziamo la documentazione Microsoft riguardo la fix
Quindi andiamo a scaricare e installare la KB5002254 ai seguenti link:
x64: https://www.microsoft.com/it-IT/download/details.aspx?id=105058
x86: https://www.microsoft.com/en-us/download/details.aspx?id=105053
installiamo la patch
Rifaccio il solito test con lo stesso appuntamento ed effettivamente il nostro reponder sulla macchina attaccante non riceve più nessuna connessione smb e l’hash della password.
Quindi risolto? non proprio…
Bypass KB5002254
Ora con le informazioni fornite dall’analisi di Akamai, proviamo a usare un percorso UNC e forgiamo di nuovo il nostro appuntamento con il percorso modificato.
Facciamo notare che stiamo facendo il test in una versione obsoleta di Windows 20H1.
Nel precedente vulnerabilità avevamo usato url \\malicius.url\exploit, in questo nuovo test utilizzeremo \\.\UNC\\malicius.url\exploit.
Prima di fare ciò, verifichiamo da dove deriva questo il bug tramite uno script powershell, analizzando come Windows rilevi i vari link che li forniremo.
Utilizziamo questa funzione su github per testare dei percorsi.
Modifichiamo il batch così
Avviamo lo script e vediamo dal output che l’API di Windows ci informa che il terzo link è identificato come locale come il percorso C:\WINDOWS (è stato ritornato il valore 0 mentre il valore 3 è per i percorsi esterni), ecco il bug!
Se è come descritto, che la precedente fix rileva l’ultimo URL come locale, il bypass dovrebbe funzionare.
Non ci resta altro che riforgiare il messaggio e rifare il procedimento di prima
Salviamo appuntamento
Ed ecco qui, la nostra macchina attaccante ha di nuovo acquisito gli hash delle credenziali
Patch risolutiva
Microsoft ha incluso la fix nella May patch tuesday KB5026361.
Ora non ci resta altro che applicare la KB det path thursday per verificare che sia stato Api sia stato corretto.
Dopo aver installato la patch ed essere passati alla 22H2
Verifichiamo di nuovo il risultato dello script usato in precedenza.
Possiamo vedere che tutti gli url, a parte l’ultimo, sono identificati come url remoti.
Riproviaml l’exploit con il il percorso UNC modificato e notiamo che nulla più è inviato alla macchina attaccante.
Conclusione
In questo articolo abbiamo visto come la patch di maggio abbia definitivament risolto il problema legato al exploit di Outlook risolto parzialmente con quella di marzo.
Questo ci fa anche riflettere come alcune patch potrebbero non risolvere i problemi di sicurezza e qualcuno potrebbe sempre trovare dei modi di evasione alle Fix rilasciate.
Con questo ci si raccomanda sempre di mantenere i sistemi aggiornati e di eseguire un corretto patch management (magari con il supporto di software specifici).
Il Team hackerhood vi terrà aggiornati sull’evoluzione di questa vulnerabilita’ che affligge Outlook particolarmente importante.
Comments are closed