O Remetente que Ninguém Possui: Percorrendo uma Árvore de Includes SPF até o NXDOMAIN
O desafio
Três clientes da Meridian pagaram uma fatura que a Meridian nunca enviou, e o e-mail falso passou no SPF. Ninguém mexeu nos servidores de e-mail, então a resposta está no DNS. O registro SPF da Meridian delega a outros remetentes com include:, e cada um desses registros pode delegar de novo. Percorra a árvore até que uma consulta responda NXDOMAIN. Esse nome não está registrado, ou seja, qualquer um pode registrá-lo, publicar um SPF nele e enviar mensagens que se autenticam como Meridian.
O que você vai aprender
- Resolver um registro SPF e seguir cada include: até o próprio registro
- Reconhecer um NXDOMAIN em um include como uma delegação pronta para takeover
- Explicar por que o registro SPF de um fornecedor faz parte da sua própria superfície de ataque
- Usar o dig para percorrer uma árvore de delegação um nome de cada vez
- Conectar o offboarding de um fornecedor a falhas de autenticação meses depois
Habilidades testadas
Pré-requisitos
- O que é um registro TXT de DNS
- Familiaridade básica com o dig
Como funciona
Um registro SPF responde a uma pergunta: quais hosts podem enviar e-mail por este domínio. A resposta raramente está escrita em um só lugar. include: diz ao avaliador para ir ler o registro SPF de outra pessoa e tratar o resultado dele como parte do seu, e esse registro é livre para conter includes próprios. O que parece uma única linha na sua zona é uma árvore que pode ter quatro ou cinco consultas de profundidade, a maior parte publicada por empresas que você não controla.
Um ramo dessa árvore deixa de ser seguro no momento em que um nome nele para de resolver. NXDOMAIN não é uma falha que fecha a porta: significa que ninguém é dono do nome. Qualquer um pode registrá-lo, publicar v=spf1 +all, e todo avaliador de SPF do mundo vai percorrer o caminho do seu domínio até o registro dele e retornar um pass. O DNS do domínio vítima permanece intocado e perfeito, por isso o time responsável costuma olhar para tudo, menos para a árvore.
É no offboarding de fornecedores que isso aparece. O contrato termina, a conta é encerrada, o domínio expira na renovação, e o include que apontava para ele permanece em um registro mantido por terceiros. Nada quebra de forma visível, então nada é limpo.
Erros comuns
- Parar no primeiro registro. Os três includes em
meridian.examplesão a pergunta, não a resposta. Dois são folhas; um delega de novo. - Responder
spf.mailhive.example. A MailHive resolve normalmente e é um fornecedor ativo. É o registro que carrega o include quebrado, não o nome quebrado. - Ler apenas a ANSWER SECTION. Uma consulta morta não tem seção de resposta nenhuma. O achado está na linha
status:do cabeçalho. - Supor que os servidores de e-mail foram comprometidos. Nada foi. O SPF passou honestamente, para um remetente que o registro autoriza de fato.
Como se proteger
Trate a árvore de includes como inventário, não como configuração.
- Resolva cada include recursivamente em um cronograma e alerte para qualquer nome que retorne NXDOMAIN ou SERVFAIL. São poucas linhas de script e isso pega o problema no dia em que o domínio expira.
- Coloque a remoção da delegação de DNS no checklist de offboarding de fornecedores, ao lado da revogação de chaves de API, e inclua os próprios registros do fornecedor onde eles citam você.
- Publique DMARC com uma política e colete os relatórios agregados. Uma tentativa de spoofing que passa no SPF a partir de uma rede desconhecida ainda aparece ali, com uma origem que você não reconhece.
- Mantenha a contagem de consultas baixa. O SPF permite dez consultas de DNS; um registro raso é mais rápido e muito mais fácil de auditar.