Descobrindo gateways de e-mail ocultos com as técnicas OSINT
Descobrindo gateways de e-mail ocultos com as técnicas OSINT
Neste artigo, elaboramos como conseguimos identificar gateways de e-mail internos ocultos, confiando em várias fontes de dados de inteligência de fonte aberta (OSINT) para nossa pesquisa direta de ataque de spool de e-mail.
Este é um artigo com várias partes. Na Parte 1, revelamos como os grandes escritórios de advocacia na Austrália são suscetíveis a ataques diretos por spool ae- mails e quais foram as implicações. Em suma, descobrimos que as soluções de segurança de e-mail em um terço dos escritórios de advocacia avaliados podem ser contornadas com um truque simples. A parte 3. elabora as definições de configuração do servidor de correio do Postfix que usamos para a pesquisa.
Pré-requisitos do ataque de spool de e-mail direto
Normalmente, os ataques de spool de email direto não devem funcionar, pois os principais fornecedores de soluções de segurança de email recomendam que os clientes bloqueiem seus serviços de email locais e publiquem intervalos de rede pertencentes a seus serviços para permitir que os administradores bloqueiem serviços de email locais. Servidores de e-mail locais devem aceitar apenas e-mails da solução de segurança de e-mail upstream.
Como mostra o diagrama, a lista de requisitos para realizar um ataque de spool de email direto bem-sucedido é relativamente curta. Nós só precisamos de três coisas:
- O nome do host do servidor de e-mail local em execução por trás da solução de segurança de e-mail;
- Um servidor de e-mail alimentando os e-mails diretamente para o servidor de e-mail local, ignorando os registros MX; e
- Um servidor de e-mail local configurado incorretamente aceitando e-mails de outros servidores que não a solução de segurança de e-mail upstream.
Para avaliar se uma organização é suscetível a ataques de spool de email diretos, temos que tentar contornar a solução de segurança de email (conforme especificado pelo registro MX) e entregar emails diretamente para o servidor de email local.
O fluxo de trabalho da avaliação também foi simples:
- Configurar e configurar um servidor de e-mail remoto para enviar e-mails para destinos arbitrários especificados pelas regras de transporte de e-mail (isto é, o servidor de e-mail remoto no diagrama);
- Identifique o nome do host do servidor de email local, confiando em várias técnicas OSINT (este artigo detalha algumas delas);
- Atualize as regras de transporte de email no servidor de email remoto de envio;
- Escreva e envie um email através do servidor de email remoto. Se o email for entregue ao destinatário, é provável que o servidor de email local esteja vulnerável ao ataque de spool de email direto.
Como gerenciamos a descoberta de gateways de e-mail vulneráveis
Em nossa pesquisa, contamos com uma combinação de fontes de dados abertas para identificar o nome do host do servidor de e-mail local relevante em execução por trás da solução de segurança de e-mail nas organizações no escopo. Os administradores de e-mail podem pensar que, ao alterar os registros MX do serviço de e-mail, os agentes mal-intencionados não poderão identificar os detalhes da conexão do servidor de e-mail local.
No entanto, isso está longe de ser verdade, pois várias pistas estão disponíveis em conjuntos de dados públicos que podem revelar o nome do host do servidor de e-mail local que está sendo executado por trás da solução de segurança de e-mail.
Dados Históricos do DNS
Uma das fontes de dados que descobrimos ser mais valiosa para identificar servidores de e-mail locais foi dados históricos de DNS passivo. Serviços como o Farsight DNSDB e o SecurityTrails nos permitem verificar quais eram os registros MX do DNS da organização avaliada antes que os administradores de e-mail trocassem os registros com os detalhes da solução de segurança de e-mail. Como esses serviços mantêm os detalhes do DNS por vários anos, poderíamos voltar no tempo até 2010 para procurar os registros.
Por exemplo, o banco britânico Barclays possui o nome de domínio
barclayssurveys.com, que foi usado para fins de marketing por e-mail em um determinado momento. Embora o host MX atual aponte para Mimecast (uma solução de segurança de email), o nome do host do serviço de email local foi mailhost1.chimegroup.comentre 2017 e 2018.
De fato, o serviço de e-mail ainda está aceitando conexões pela Internet:
Supondo que o servidor de e-mail que aceita e-mail do serviço Mimstream upstream não tenha mudado,
mailhost1.chimegroup.compoderia entregar e-mails para a equipe do Barclays.Serviços de pesquisa de subdomínio
O segundo serviço mais útil foi um serviço de busca DNS chamado DNSdumpster , que nos permite identificar com dificuldade a localização de servidores de e-mail locais com subdomínios mais obscuros que
mail.mycompany.com.au. O serviço é uma ferramenta de pesquisa de domínio que usa recursos de inteligência de código aberto para descobrir dados de domínio.
Por exemplo, o banco Westpac parece estar executando vários servidores de email:
O Virustotal também pode listar os subdomínios associados do Westpac:
Outros mecanismos de pesquisa de subdomínio OSINT também estão disponíveis, como FindSubdomains ou Hacker Target .
Fazendo uma palpite educada
O terceiro método em que nos baseamos fortemente foi adivinhar. De acordo com nossa experiência interna, a grande maioria das práticas legais hospeda seu serviço de e-mail na Microsoft. Curiosamente, as locações do Office 365 têm uma convenção de nomenclatura que nos ajudou a encontrar o host MX do servidor de back-end.
Cada locação do Office 365 tem um nome de organização que é anexado ao nome de domínio
.onmicrosoft.com. Se uma organização registrou uma conta do Office 365, a consulta DNS de ORG.onmicrosoft.comdeve recuperar o nome do host do servidor de email do locatário.
Por exemplo, o registro MX
apple.onmicrosoft.comindica que uma organização possui uma conta do Office 365 e o servidor de email está disponível apple.mail.protection.outlook.com.
A segunda maneira de adivinhar se uma organização é um usuário do Office 365 está tentando estabelecer uma conexão de rede com o host MX assumido na Microsoft. Por exemplo, se o nome de domínio da organização for
apple.com, o nome do host do host MX deve ser apple-com.mail.protection.outlook.com. Poderíamos testar facilmente netcatse existe uma locação no nome do host tentando conectar-se à porta TCP 25.
Embora não tenhamos identificado nenhum escritório de advocacia usando o G Suite para hospedagem de e-mail, a adivinhação também funcionaria com organizações com uma assinatura do Google. Como o principal host MX de todas as locações do G Suite é
ASPMX.L.GOOGLE.COMindependente do nome da organização, vale sempre uma tentativa de enviar e-mails por meio do G Suite se as outras técnicas do OSINT falharem.
Entradas de registro SPF
Conseguimos identificar potenciais candidatos inspecionando o registro SPF público. Embora raramente tenhamos conseguido determinar o servidor de e-mail local real com esse método, encontramos endereços IP e nomes de host de sistemas de CRM e plataformas de automação de marketing. Se algum dos hosts tiver um serviço SMTP em execução, os emails alimentados nesses hosts podem acabar na caixa de correio de alguém de maneiras inesperadas.
Por exemplo, o Santander Bank (Reino Unido) usa uma plataforma de aquisição de talentos de terceiros para contratação. Os emails enviados por esse servidor SMTP podem acabar na caixa de correio do pessoal de RH do banco.
Motores de busca especiais
Serviços como Censys e Crt.sh Certificate Search também nos ajudaram a encontrar possíveis servidores de e-mail.
O Censys é um mecanismo de busca que ajuda a encontrar e analisar cada servidor e dispositivo acessível na Internet. O Crt.sh é uma interface web para o banco de dados distribuído chamado logs de transparência de certificados .
Com apenas alguns operadores de pesquisa simples no Censys , pudemos identificar o nome do host de possíveis servidores de email locais com a porta tcp / 25 aberta nessa organização específica.
Poderíamos identificar potenciais subdomínios em crt.sh procurando por hosts com palavras-chave como
*mail*, *exch*(como no Microsoft Exchange), *mta*ou *smtp*neles. Esses subdomínios estão potencialmente apontando para servidores de email que aceitam emails para a organização.
Conclusão
Servidores de e-mail na internet são difíceis de esconder, mesmo quando os detalhes da conexão não estão aparecendo nos registros MX. Como as várias técnicas OSINT demonstram, traços são deixados em todos os lugares, permitindo que os agentes mal-intencionados identifiquem o servidor de e-mail que está sendo executado no back-end.
Primeiro de tudo, sugerimos que os administradores de e-mail bloqueiem os servidores de e-mail locais para impedir o abuso, em vez de ocultá-los à vista, com a esperança de que ninguém os descubra.
Em segundo lugar, a segurança de e-mail é uma questão complexa e, como resultado, as organizações freqüentemente deixam seus servidores de e-mail locais abertos para os cibercriminosos. Essa supervisão deixa as organizações suscetíveis a ataques de phishing, como demonstra nosso último relatório sobre ataques a spool de e-mail direto . Além disso, considerando o crescente número de fraudes de Business Email Compromise (BEC) , pedimos que você avalie a segurança de seus gateways de email para evitar abusos.
Este artigo foi co-escrito por Gabor Szathmari e Nicholas Kavadias .
Comentários
Postar um comentário