Como um e-mail falsificado passou na verificação SPF e foi parar na minha caixa de entrada

Vinte anos atrás, Paulo Vixie publicou um Pedido de Comentários sobre Repudiando CORREIO DE que ajudou a estimular a comunidade da Internet a desenvolver uma nova maneira de combater o spam com o Estrutura de Política do Remetente (FPS). A questão então, como agora, era que o Protocolo de transferência de correio simples (SMTP), que é usado para enviar e-mail na Internet, não fornece nenhuma maneira de detectar domínios de remetente falsificados.  

No entanto, ao usar o SPF, os proprietários de domínio podem publicar registros do sistema de nomes de domínio (DNS) que definem os endereços IP autorizados a usar seu nome de domínio para enviar e-mail. Na extremidade receptora, um servidor de e-mail pode consultar os registros SPF do aparente domínio do remetente para verificar se o endereço IP do remetente está autorizado a enviar e-mails em nome desse domínio. 

Visão geral de e-mail SMTP e SPF 

Os leitores familiarizados com os mecanismos de envio de mensagens SMTP e como o SPF interage com eles podem preferir pular esta seção, embora ela seja felizmente curta. 

Imagine que Alice em example.com deseja enviar uma mensagem de e-mail para Bob em exemplo.org. Sem o SPF, os servidores de e-mail de Alice e Bob se envolveriam em uma conversa SMTP semelhante à seguinte, que é simplificada usando HELO em vez de EHLO, mas não de maneira que altere significativamente as construções básicas: 

Foi assim que ocorreu o envio e recebimento de e-mail da Internet (SMTP) desde os primeiros 1980s, mas tem – pelo menos pelos padrões da internet de hoje – um grande problema. No diagrama acima, Chad em exemplo.net poderia facilmente se conectar ao exemplo.org servidor SMTP, envolva-se exatamente na mesma conversa SMTP e tenha uma mensagem de e-mail aparentemente de Alice em example.com entregue a Bob em exemplo.org. Pior ainda, não haveria nada indicando o engano para Bob, exceto talvez endereços IP registrados ao lado de nomes de host em cabeçalhos de mensagens de diagnóstico (não mostrados aqui), mas isso não é fácil para não especialistas verificarem e, dependendo do seu aplicativo cliente de e-mail , muitas vezes são de difícil acesso. 

Embora não tenham sido abusadas nos primeiros dias do spam de e-mail, à medida que o spam em massa se tornou um modelo de negócios estabelecido, embora merecidamente desprezado, essas técnicas de falsificação de e-mail foram amplamente adotadas para melhorar as chances de mensagens de spam serem lidas e até mesmo aplicadas. 

De volta ao Chade hipotético em exemplo.net enviando essa mensagem “de” Alice… Isso envolveria dois níveis de falsificação de identidade (ou falsificação), onde muitas pessoas agora sentem que verificações técnicas automatizadas podem ou devem ser feitas para detectar e bloquear essas mensagens de e-mail falsas. O primeiro está no nível do envelope SMTP e o segundo no nível do cabeçalho da mensagem. SPF fornece verificações no nível do envelope SMTP e, posteriormente, protocolos de autenticação de mensagens e antifalsificação DKIM e DMARC fornecer verificações no nível do cabeçalho da mensagem. 

O FPS funciona? 

De acordo com um estudo publicados em 2022, cerca de 32% dos 1.5 bilhão de domínios investigados possuíam registros SPF. Destes, 7.7% tinham sintaxe inválida e 1% estava usando o registro PTR obsoleto, que aponta endereços IP para nomes de domínio. A aceitação do SPF tem sido lenta e falha, o que pode levar a outra pergunta: quantos domínios têm registros SPF excessivamente permissivos?  

Pesquisa recente encontrada que 264 organizações só na Austrália tinham endereços IP exploráveis ​​em seus registros SPF e, portanto, podem inadvertidamente preparar o terreno para campanhas de spam e phishing em grande escala. Embora não esteja relacionado ao que essa pesquisa descobriu, recentemente tive meu próprio contato com e-mails potencialmente perigosos que se aproveitavam de registros SPF mal configurados. 

E-mail falsificado na minha caixa de entrada 

Recentemente, recebi um e-mail que dizia ser da seguradora francesa Prudence Crévelho, mas tinha todos os marcas de spam e falsificação: 

 

Embora eu saiba que forjar o cabeçalho da mensagem From: address de um email é trivial, minha curiosidade foi despertada quando inspecionei os cabeçalhos completos do email e descobri que o domínio no envelope SMTP MAIL FROM: address responda@prudencecreole.com passou na verificação SPF: 

Então eu procurei o registro SPF do domínio prudencecreole. com: 

Isso é um enorme bloco de endereços IPv4! 178.33.104.0/2 contém 25% do espaço de endereços IPv4, variando de 128.0.0.0 para 191.255.255.255. Mais de um bilhão de endereços IP são remetentes aprovados para o nome de domínio da Prudence Creole – o paraíso de um spammer. 

Só para ter certeza de que não estava me enganando, configurei um servidor de e-mail em casa, recebi um endereço IP aleatório, mas elegível, do meu provedor de serviços de Internet e me enviei um e-mail spoofing prudencecreole. com:  

Sucesso! 

Para completar, verifiquei o registro SPF de um domínio de outro e-mail de spam na minha caixa de entrada que estava falsificando wildvoyager. com: 

E eis que o 0.0.0.0/0 block permite que todo o espaço de endereços IPv4, consistindo em mais de quatro bilhões de endereços, passe na verificação SPF enquanto se apresenta como Wild Voyager. 

Após este experimento, notifiquei a Prudence Créole e Wild Voyager sobre seus registros SPF mal configurados. Prudência Créole atualizaram seus registros SPF antes da publicação deste artigo. 

Reflexões e lições aprendidas 

Criar um registro SPF para seu domínio não é um golpe fatal contra os esforços de falsificação de spammers. No entanto, se configurado com segurança, o uso do SPF pode frustrar muitas tentativas como as que chegam na minha caixa de entrada. Talvez o obstáculo mais significativo no caminho do uso imediato e mais amplo e da aplicação mais rigorosa do SPF seja a capacidade de entrega de e-mail. São necessários dois para jogar o jogo do SPF porque tanto os remetentes quanto os destinatários precisam harmonizar suas políticas de segurança de e-mail caso os e-mails não sejam entregues devido a regras excessivamente rigorosas empregadas por ambos os lados. 

No entanto, considerando os possíveis riscos e danos causados ​​por spammers que falsificam seu domínio, o conselho a seguir pode ser aplicado conforme apropriado: 

• Crie um registro SPF para todas as suas identidades HELO/EHLO caso algum verificador SPF esteja seguindo o recomendação na RFC 7208 para verificar estes 
• É melhor usar o todos os mecanismo com o "-" or "~" qualificadores em vez de "?" qualificador, pois este último efetivamente permite que qualquer pessoa falsifique seu domínio 
• Configure uma regra de “soltar tudo” (v=spf1 -todos) para cada domínio e subdomínio que você possui que nunca deve gerar e-mail (roteado pela Internet) ou aparecer na parte do nome de domínio dos comandos HELO/EHLO ou MAIL FROM: 

• Como diretriz, certifique-se de que seus registros SPF sejam pequenos, de preferência até 512 bytes, para evitar que sejam ignorados silenciosamente por alguns verificadores SPF 
• Certifique-se de autorizar apenas um conjunto limitado e confiável de endereços IP em seus registros SPF 

O uso generalizado do SMTP para enviar e-mails criou uma cultura de TI focada na transferência de e-mails de forma confiável e eficiente, em vez de com segurança e privacidade. Reajustar-se a uma cultura focada em segurança pode ser um processo lento, mas que deve ser empreendido para obter dividendos claros contra um dos males da internet – o spam.