Descobrindo automaticamente o Grande Vazamento

Views: 567

Resumo Executivo

• A Autodiscover, um protocolo usado pelo Microsoft Exchange para configuração automática de clientes como o Microsoft Outlook, tem uma falha de design que faz com que o protocolo “vazamento” solicitações da web para domínios de descoberta automática fora do domínio do usuário, mas no mesmo TLD (i.e. Autodiscover.com).
• A Guardicore Labs adquiriu vários domínios de descoberta automática com um sufixo de TLD e os configurou para alcançar um servidor web que controlamos. Logo depois, detectamos um vazamento maciço de credenciais de domínio do Windows que chegaram ao nosso servidor.
• Entre 16 de abril de 2021 e 25 de agosto de 2021, capturamos:
  • 372.072 credenciais de domínio do Windows no total.
  • 96.671 credenciais ÚNICAS que vazaram de vários aplicativos, como Microsoft Outlook, clientes de e-mail móveis e outros aplicativos que fazem interface com o servidor Exchange da Microsoft.
• Este é um grave problema de segurança, já que se um invasor puder controlar esses domínios ou tiver a capacidade de “cheirar” o tráfego na mesma rede, ele poderá capturar credenciais de domínio em texto simples (autenticação básica HTTP) que estão sendo transferidas pelo fio. Além disso, se o invasor tiver recursos de envenenamento de DNS em larga escala (como um invasor do estado-nação), ele poderá desviar sistematicamente senhas com vazamento por meio de uma campanha de envenenamento por DNS em larga escala baseada nesses TLDs de descoberta automática.
• Além disso, desenvolvemos um ataque – “The ol’ switcheroo” – que rebaixa o esquema de autenticação de um cliente de um seguro (OAuth, NTLM) para a Autenticação Básica HTTP, onde as credenciais são enviadas em texto simples.

Introdução

Como parte dos esforços contínuos de pesquisa de segurança da equipe da Guardicore Labs, descobrimos um caso interessante de vazamento de credenciais afetando um grande número de pessoas e organizações em todo o mundo.

As credenciais que estão vazando são credenciais válidas de domínio do Windows usadas para autenticar nos servidores do Microsoft Exchange. A fonte dos vazamentos é composta por duas questões:

1. O design do protocolo Autodiscover da Microsoft (e o algoritmo “back-off”, especificamente).
2. Má implementação deste protocolo em alguns aplicativos.

Como mencionado, o protocolo de descoberta automática da Microsoft foi feito para facilitar a configuração de clientes Exchange, como o Microsoft Outlook. O objetivo do protocolo é fazer com que um usuário final possa configurar completamente seu cliente Outlook apenas fornecendo seu nome de usuário e senha e deixando o resto da configuração para o protocolo de descoberta automática do Microsoft Exchange. É importante entender que, como o Microsoft Exchange faz parte do “conjunto de domínios da Microsoft” de soluções, as credenciais necessárias para fazer login na caixa de entrada baseada no Exchange são, na maioria dos casos, suas credenciais de domínio. As implicações de um vazamento de credenciais de domínio em tal escala são enormes e podem colocar as organizações em perigo. Especialmente no mundo devastado de ataques ransomware de hoje – a maneira mais fácil de um invasor entrar em uma organização é usar credenciais legítimas e válidas.Em 2017, pesquisadores da Shape Security publicaram um artigo sobre como implementações de Autodiscover em clientes de e-mail em telefones celulares (como o cliente de e-mail da Samsung no Android e o Apple Mail no iOS) podem causar tais vazamentos (CVE-2016-9940, CVE-2017-2414). As vulnerabilidades divulgadas pela Shape Security foram corrigidas, mas aqui estamos em 2021 com um cenário de ameaças significativamente maior, lidando com exatamente com o mesmo problema apenas com mais aplicativos de terceiros fora dos clientes de e-mail. Esses aplicativos estão expondo seus usuários aos mesmos riscos. Iniciamos processos de divulgação responsável com alguns dos fornecedores afetados. Mais detalhes sobre esse aspecto serão divulgados como uma segunda parte deste artigo.

Este documento detalhará como os problemas de design do protocolo acima mencionado causam vazamento severo de credenciais que nos dá a capacidade de receber dezenas de milhares de credenciais de domínio válidas do Windows sem enviar um único pacote.

O que é Autodiscover?

O protocolo de Descoberta Automática do Exchange foi feito para fornecer uma maneira de os clientes configurarem facilmente seus aplicativos cliente do Exchange. Normalmente, para configurar um cliente de e-mail, o usuário precisa definir várias configurações:

• Nome de usuário e senha.
• Os nomes de host/endereços IP dos servidores de e-mail/troca.
• Em alguns casos, configurações adicionais são necessárias (configurações LDAP diversas, calendários WebDAV, etc.).

O protocolo tem várias iterações, versões e modos – sua documentação completa pode ser encontrada no site da Microsoft, no entanto, neste artigo, discutiremos uma implementação específica do Autodiscover com base no protocolo POX XML. Depois que o usuário adicionar uma nova conta do Microsoft Exchange ao Outlook, ele receberá um prompt solicitando seu nome de usuário e senha:

Assim que o usuário preencher todos os detalhes, o Outlook tentará usar a Descoberta Automática para configurar o cliente. Esta etapa do processo é assim:

No entanto, para realmente entender como a Autodiscover funciona, precisamos saber o que acontece “nos bastidores”:

1. O cliente analisa o endereço de e-mail fornecido pelo usuário – amit@example.com.
2. O cliente então tenta criar um URL de descoberta automática com base no endereço de e-mail com o seguinte formato:
   • https://Autodiscover.example.com/Autodiscover/Autodiscover.xml
   • http://Autodiscover.example.com/Autodiscover/Autodiscover.xml
   • https://example.com/Autodiscover/Autodiscover.xml
   • http://example.com/Autodiscover/Autodiscover.xml

Caso nenhuma dessas URLs esteja respondendo, a Autodiscover iniciará seu procedimento de “back-off”. Esse mecanismo de “back-off” é o culpado por esse vazamento porque está sempre tentando resolver a parte Autodiscover do domínio e sempre tentará “falha”, por assim dizer. Ou seja, o resultado da próxima tentativa de criar uma URL de descoberta automática seria:http://Autodiscover.com/Autodiscover/Autodiscover.xml. Isso significa que quem possui o Autodiscover.com receberá todas as solicitações que não podem chegar ao domínio original. Para mais informações sobre como a Autodiscover funciona, confira a documentação da Microsoft.

Abusando do Vazamento

Para ver se o cenário de vazamento de Descoberta Automática é viável, compramos os seguintes domínios:

• Autodiscover.com.br – Brasil
• Autodiscover.com.cn – China
• Autodiscover.com.co – Colômbia
• Autodiscover.es – Espanha
• Autodiscover.fr – França
• Autodiscover.in – Índia
• Autodiscover.it – Itália
• Autodiscover.sg – Cingapura
• Autodiscover.uk – Reino Unido
• Autodiscover.xyz
• Autodiscover.online
• Autodiscover.cc
• Autodiscover.studio
• autodiscover.capital
• autodiscover.club
• autodiscover.company
• autodiscover.jp
• autodiscover.me
• autodiscover.mx
• autodiscover.ventures

Mais tarde, esses domínios foram atribuídos a um servidor web sob nosso controle e estávamos simplesmente aguardando que as solicitações da web para que vários endpoints de Autodiscover chegassem. Para nossa surpresa, começamos a ver quantidades significativas de solicitações para endpoints de descoberta automática de vários domínios, endereços IP e clientes. A coisa mais notável sobre essas solicitações foi que elas solicitaram o caminho relativo de/Autodiscover/Autodiscover.xml com o cabeçalho Authorization já preenchido com credenciais na autenticação básica HTTP.

Geralmente, as solicitações da web não devem ser enviadas cegamente pré-autenticadas, mas sim seguindo o processo de autenticação HTTP:

1. Um cliente solicita acesso a um recurso protegido.
2. O servidor web retorna uma caixa de diálogo que solicita o nome de usuário e a senha (de acordo com os métodos de autenticação suportados, no nosso caso, autenticação básica).
3. O cliente envia o nome de usuário e a senha para o servidor.
4. O servidor autentica o usuário e retorna o recurso solicitado.

Como pode ser visto no trecho a seguir, os nomes de host que aparecem no log (esfregados por motivos de privacidade) são os domínios a partir dos quais os clientes de Autodiscover estavam tentando se autenticar, juntamente com seu respeitado nome de usuário e senhas:

2021–05–18 03:30:45 W3SVC1 instance-2 10.142.0.4 GET /Autodiscover/Autodiscover.xml – 80 – <arbuscado de endereço IP> HTTP/1.1 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro) – -<L 2021–05–18 03:30:52 W3SVC1 instance-2 10.142.0.4 GET /Autodiscover/Autodiscover.xml – 80 – <Endereço IP esfregado> HTTP/1.1 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro) – – <L 2021–05–18 03:30:55 W3SVC1 instance-2 10.142.0.4 GET /Autodiscover/Autodiscover.xml – 80 – <Endereço IP esfregado> HTTP/1.1 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro) – – <Esp 2021–05–18 03:31:19 W3SVC1 instance-2 10.142.0.4 GET /Autodiscover/Autodiscover.xml – 80 – <Endereço IP esfregado> HTTP/1.1 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro) – – <L

O problema interessante com uma grande quantidade de solicitações que recebemos foi que não houve tentativa do lado do cliente de verificar se o recurso está disponível, ou mesmo existe no servidor, antes de enviar uma solicitação autenticada. Normalmente, a maneira de implementar tal cenário seria primeiro verificar se o recurso que o cliente está solicitando é válido, já que pode ser inexistente (o que acionará um erro HTTP 404) ou pode ser protegido por senha (o que acionará um código de erro HTTP 401), conforme visto no diagrama acima.

Entre 16 de abril de 2021 e 25 de agosto de 2021, capturamos um grande número de credenciais dessa maneira, escusado será dizer, sem enviar um único pacote diferente do necessário para estabelecer uma sessão HTTP/HTTPS entre nosso servidor e os diversos clientes.

Os seguintes dados foram coletados entre 20 de abril de 2021 e 25 de agosto de 2021:

Ao examinar os domínios dessas credenciais vazadas, conseguimos encontrar credenciais de várias empresas em várias verticais:

O velho switcheroo

Ao observar os registros do servidor HTTP, podemos ver claramente que o cliente é rebaixado com sucesso depois de receber a resposta HTTP 401 do servidor, dizendo-lhe para usar a Autenticação Básica HTTP:

Observação: O token de portador vazio é enviado como parte do processo de descoberta automática do reino, que é discutido mais detalhadamente na documentação da Microsoft. Do lado da vítima, no entanto, é difícil perceber que o usuário está enfrentando qualquer tipo de ataque. Quando a vítima está sendo redirecionada para o nosso servidor de descoberta automática devido ao vazamento, um alerta de segurança aparece:

Este aviso indica que, embora o certificado seja válido, ele é autoassinado e não deve ser confiável. No entanto, isso poderia ser facilmente evitado implantando um certificado SSL real. No nosso caso, implantamos o certificado aLetsEncrypt em segundos, o que corrigiu o problema do aviso SSL exibido.

Uma vez que uma sessão segura tenha sido estabelecida, a vítima agora verá este prompt de autenticação legítimo exibido pelo Microsoft Outlook:

Esta é a última etapa deste ataque – a vítima inserirá suas credenciais nesta caixa de diálogo, que, por sua vez, enviará as credenciais para o nosso servidor web. As credenciais agora aparecem em nossos registros.

Mitigação

Atenuar a questão dos vazamentos de Autodescoberta é importante, como demonstramos anteriormente. Para mitigar esse problema, duas abordagens separadas são necessárias:

1. Uma abordagem precisa ser implementada pelo público em geral que usa tecnologias baseadas no Exchange, como Outlook ou ActiveSync (protocolo de sincronização do Exchange móvel da Microsoft) e a outra abordagem deve ser implementada por desenvolvedores/fornecedores de software que estão implementando o protocolo Autodiscover em seus produtos:
2. Para o público em geral: Certifique-se de estar bloqueando ativamente os domínios Autodiscover. (como Autodiscover.com/Autodiscover.com.cn, etc.) no seu firewall.

• Ao implantar/configurar configurações do Exchange, verifique se o suporte para autenticação básica está desativado – usar autenticação básica HTTP é o mesmo que enviar uma senha em texto claro pelo fio.
• Uma lista textual abrangente de todos os domínios de nível superior pode ser encontrada na seguinte URL:https://data.iana.org/TLD/tlds-alpha-by-domain.txt
  • Preparamos um arquivo txt com todos os domínios Autodiscover.TLD possíveis que podem ser adicionados ao seu arquivo de hosts locais ou configuração de firewall para mitigar o risco de resolução de tais domínios de Autodiscover. Verifique nosso repositório github para obter mais informações:
    https://github.com/guardicore/labs_campaigns/tree/master/Autodiscover

3. Para fornecedores e desenvolvedores de software:

• Certifique-se de que, ao implementar o protocolo Autodiscover em seu produto, não esteja deixando que ele “falhe para cima”, o que significa que domínios como “Autodiscover”. nunca devem ser construídos pelo algoritmo “back-off”.

Conclusão

Neste documento, discutimos as implicações da falha básica de design no protocolo de Autodiscover (o algoritmo “back-off”) e demonstramos que, se um invasor controlar domínios de Autodescoberta de nível superior (ou se o invasor tiver a capacidade de realizar um ataque de envenenamento DNS usando esses domínios), ele poderá facilmente consumir credenciais de domínio válidas dessas solicitações de Autodis

Muitas vezes, os atacantes tentam fazer com que os usuários enviem suas credenciais aplicando várias técnicas, sejam técnicas ou por meio de engenharia social. No entanto, esse incidente nos mostra que as senhas podem vazar fora do perímetro da organização por um protocolo que visava agilizar as operações do departamento de TI em relação à configuração do cliente de e-mail sem que ninguém do departamento de TI ou segurança esteja ciente disso, o que enfatiza a importância da segmentação adequada e da confiança Zero.

Nós, do Guardicore Labs, continuamos nossos esforços contínuos para proteger redes, aplicativos e protocolos, encontrando, alertando e divulgando tais problemas.

FONTE: GUARDICORE