BreakSPF, publicado no NDSS 2024, examina como a infraestrutura compartilhada pode ampliar SPF autorização. A sua lição operacional central é perguntar quem pode originar tráfego a partir de um endereço autorizado, e não apenas se um recorde é sintaticamente válido. Uma descoberta histórica de pesquisa é uma razão para avaliar uma configuração atual, e não uma prova de que um provedor nomeado permanece vulnerável.
Separe o resultado da pesquisa do sistema atual
O artigo original estuda infraestrutura acessível a invasores, dependências permissivas SPF e comportamento do receptor, incluindo caminhos entre protocolos. Seus relatórios de discussão são corrigidos durante a pesquisa e consideram outros controles de filtragem. Leia essas seções de escopo e divulgação junto com as principais conclusões. Artigo original do BreakSPF, seções VII-IX.
Não transforme a contagem de domínios do artigo em uma estimativa atual de prevalência da Internet nem repita um exemplo histórico como uma acusação atual. Este artigo não reproduz os experimentos, não verifica a infraestrutura de terceiros nem avalia um provedor ativo. As recomendações abaixo constituem um plano de revisão defensiva fundamentado no protocolo e na questão de pesquisa.
Identifique o limite de autorização
SPF avalia se o host de conexão está autorizado para a identidade SMTP avaliada. Seu resultado não estabelece quem controlava o aplicativo que iniciou a mensagem. Um intervalo autorizado pode ser apropriado para um serviço de envio rigidamente controlado e inadequado quando inquilinos não relacionados podem originar tráfego equivalente sem impor a propriedade do domínio. RFC 7208 , seções 2, 4 e 11.
Faça um inventário dos domínios de envelope reais da organização, das dependências SPF e dos serviços de envio. Para cada dependência, registre seu proprietário, por que ela é necessária e como o serviço restringe o uso das identidades do remetente pelo cliente. Um alcance grande é um sinal de revisão, não sendo informação suficiente por si só para declarar a exploração possível. Os caminhos de rede e os controles de serviço atuais são importantes.
Mantenha o alinhamento DMARC na análise
DMARC precisa de um caminho de autenticação alinhado de passagem. Se uma autorização excessivamente ampla produzir uma passagem SPF para uma identidade alinhada com o domínio De visível, adicionar DKIM para mensagens legítimas não remove por si só esse caminho SPF . Por outro lado, uma passagem SPF para um domínio de envelope não relacionado não satisfaz por si só DMARC alinhamento. RFC 9989.
Uma política DMARC mais rigorosa exige tratamento de falhas; ele não converte um caminho alinhado que já está passando em uma falha. Corrija autorizações desnecessárias e avalie os controles de domínio do lado do serviço, em vez de tratar um rótulo de política como uma solução completa. Preserve remetentes legítimos por meio de alterações revisadas e preparadas.
Trabalhe por meio de uma matriz de revisão limitada
O livro de pré-requisitos escrito abaixo estipula quatro campos independentes: autorização de origem SPF , capacidade de origem não intencional, acessibilidade de caminho e alinhamento da identidade SPF com De. Nenhuma linha é uma descoberta de provedor observada.
- A: autorizado verdadeiro; capacidade de origem não intencional verdadeira; alcançável verdadeiro; alinhado verdadeiro. Escalar para validação autorizada atual deste possível caminho SPF alinhado; não rotule a exploração da produção estabelecida.
- B: autorizado verdadeiro; capacidade verdadeira; alcançável verdadeiro; alinhado falso. Este caminho SPF específico não estabelece a passagem DMARC . DKIM e outras evidências reais de mensagens ainda precisam ser inspecionadas antes de decidir o resultado completo DMARC .
- C: autorizado verdadeiro; capacidade verdadeira; alcançável falso; alinhado verdadeiro. Mantenha a preocupação com a configuração, mas nenhum caminho de envio acessível foi demonstrado por essas premissas.
- D: autorizado verdadeiro; capacidade desconhecida; alcançável verdadeiro; alinhado verdadeiro. Obtenha evidências de controle de serviço; capacidade desconhecida não é segura nem comprovadamente explorável.
Estas são deduções narrativas, não um avaliador, exploração ou teste de receptor em execução. Nenhum DNS ou infraestrutura em nuvem foi acessado. A seção 7.4 RFC9989 requer DKIM válido para p=reject domínios; esse dever de implantação não apaga um caminho SPF alinhado que já está passando.
Aplicar mitigações à camada responsável
Revise e remova autorizações obsoletas somente após confirmar as dependências do remetente. Pergunte aos proprietários de serviços sobre a aplicação e o isolamento de identidade. Os operadores de infraestrutura devem avaliar a saída de correio não intencional e os controles de limites de protocolo por meio de seu processo de segurança autorizado. Os destinatários devem reter evidências de autenticação confiáveis e testar o comportamento da política usando domínios e destinatários controlados.
Para uma avaliação real, preserve DNS datado, evidências de propriedade de serviço, escopo de teste aprovado e resultados de recebimento observados. A revisão independente da segurança deve distinguir um risco de configuração de um caminho demonstrado e de um resultado de mensagem entregue. A validação atual do fornecedor e a reprodução experimental permanecem pendentes; a leitura retida do artigo original apoia o resumo da pesquisa, enquanto a matriz escrita ilustra apenas os pré-requisitos estipulados.