SpamChannel: enviando e-mails falsificados a partir de mais de 2 milhões de domínios e praticamente virando Satanás [PDF]

 (media.defcon.org)
1 pontos por GN⁺ 2023-09-24 | 1 comentários | Compartilhar no WhatsApp
  • A apresentação SpamChannel, da DEFCON 31 2023, aborda um problema de spoofing contra mais de 2 milhões de domínios, a partir de uma tentativa de enviar e-mails com Cloudflare Worker
  • O experimento central parte da ideia de tratar o envio de e-mails não manualmente, mas de forma programática, conectando isso ao fluxo de implantação de Workers
  • Cloudflare Workers é apresentado como um ambiente de computação serverless baseado em JavaScript, TypeScript e WASM
  • O procedimento básico segue o fluxo de criar um projeto com npm create cloudflare@latest e fazer o deploy com npx wrangler deploy
  • A pista para enviar e-mails a partir de Workers vem de um post do blog da Cloudflare sobre integração com MailChannels

Ponto de partida da apresentação SpamChannel

  • SpamChannel é um PDF apresentado por Marcello Salvati (@byt3bl33d3r) na DEFCON 31 2023, tratando do tema de envio de e-mails falsificados a partir de mais de 2 milhões de domínios
  • O objetivo da apresentação é implementar o envio de e-mails sob as seguintes condições
    • Enviar e-mails de forma programática
    • Enviar por meio de um Cloudflare Worker
  • Inclui um aviso de isenção de responsabilidade relacionado à responsabilidade legal, dizendo “não cometa crimes”

Cloudflare Workers e pistas para envio de e-mails

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-24
Opiniões no Hacker News

  • Vídeo da apresentação: https://www.youtube.com/watch?v=NwnT15q_PS8
    Ou também está aqui. No meu Firefox o formato do vídeo não funcionou, mas reproduziu no VLC: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • O SPF está quebrado de muito mais maneiras do que as abordadas nesta apresentação. Do ponto de vista de quem trabalha como engenheiro de reforço de segurança de e-mail/suporte a entregabilidade, o conselho é sempre focar em DKIM + DMARC em vez de SPF
    Por motivos legados, o SPF ainda é necessário, mas não se deve depender dele para entregabilidade ou prevenção de falsificação de identidade
    O slide 54 diz que DKIM + DMARC não ajudam contra esse ataque, mas isso não é totalmente correto
    Só é possível ativar com segurança uma política DMARC p=reject quando DKIM estiver configurado em todos os remetentes delegados; ao chegar a esse nível, dá para começar a remover o SPF para remetentes terceiros usando o modificador neutro ? no SPF
    Por exemplo, v=spf1 include:relay.mailchannels.net ~all vira v=spf1 ?include:relay.mailchannels.net ~all
    Com isso, e-mails vindos da MailChannels são tratados como SPF neutro por destinatários com suporte a DMARC, forçando o uso de DKIM, e serviços de e-mail legados antigos também devem aceitar um resultado neutro
    Não é uma solução perfeita, mas e-mail, de todo modo, nunca poderá ser 100% confiável ou seguro

    • Então fico curioso sobre qual é o problema do SPF. Como falsificar o IP de origem em TCP é bem difícil, sempre me perguntei que vantagem o DKIM tem sobre o SPF
      Eu tenho configurado o SPF para permitir apenas $myIP. Para enviar spam em nome do meu domínio, seria preciso primeiro invadir meu ISP ou registrador; nesse ponto, também seria possível obter um certificado TLS para meu domínio
      Mesmo em organizações grandes que precisam colocar vários sistemas de envio em allowlist, não sei como alguém se passaria por um dos remetentes SPF legítimos numa situação em que falsificar registros DKIM é impossível
      Casos como o da apresentação enviada, em que se coloca em allowlist uma faixa de IP que qualquer pessoa pode usar publicamente, são simplesmente uma configuração tola
      Para falsificar toda a troca de e-mails, seriam necessários tráfegos na casa de terabytes para um único e-mail de alguns bytes, e isso se torna impossível se STARTTLS for obrigatório

  • Usamos Cloudflare Workers + MailChannels em produção. Arrepiante
    Já estávamos trabalhando para sair do CF Workers e migrar para um servidor real; agora acho que também teremos que sair da MailChannels
    O risco de segurança não vale a conveniência

    • Desde junho de 2023, não é possível enviar e-mails pelo MailChannels a partir do Workers sem publicar no DNS um registro _mailchannels
    • Para deixar claro, o problema aqui é que a MailChannels não autentica o remetente para verificar se ele é o proprietário verificado do domínio de envio. O CF Workers não é o problema

  • “Exibir um banner em todos os e-mails vindos de domínios que implementam DKIM, mas que não têm assinatura DKIM” é, pelo que entendi, praticamente impossível. Isso porque não há uma forma confiável de saber quais domínios implementam DKIM
    Em teoria, é possível fazer uma consulta DNS para "_domainkey.example.com" e ver se o resultado é NXDOMAIN ou NOERROR. Este último normalmente significa que há subdomínios e, portanto, pode indicar que existem algumas chaves DKIM no DNS
    Mas não dá para saber o nome do seletor, nem se essa chave está ativa ou se pretendem ativá-la depois
    Um domínio pode ter vários remetentes autenticados, e alguns podem usar assinatura DKIM enquanto outros não
    Nem todos os servidores DNS seguem o padrão corretamente, então a distinção NXDOMAIN/NOERROR só funciona de modo geral

    • Um provedor que veja uma porcentagem estatisticamente significativa do tráfego de e-mail consegue observar todos ou quase todos os seletores DKIM
      A frase citada parece querer dizer rejeitar e-mails vindos da MailChannels que não tenham assinatura DKIM

  • “Os principais clientes da MailChannels são provedores de hospedagem web que não são donos dos domínios dos e-mails que enviam” é a pior desculpa que ouvi em um bom tempo
    Provedores de hospedagem web normalmente não “possuem” os domínios que hospedam, mas certamente sabem quais domínios estão hospedando. Roteá-los para a conta/diretório do cliente é a essência da hospedagem web
    O necessário é algo como uma integração com cPanel para reportar a lista de domínios e vincular cada domínio a uma chave gerada aleatoriamente
    Tudo isso pode e deve ser automatizado sem incomodar o usuário final

    • E quanto às listas de discussão? E ao encaminhamento de e-mails?

  • Seria bom se a especificação do DMARC evoluísse e houvesse uma forma de usar apenas DKIM, e não SPF, na verificação. Infelizmente, coisas como convites do Google Calendar ainda falham no DKIM

    • É bem provável que a próxima versão do DMARC inclua uma opção para excluir o SPF da verificação DMARC. A equipe do Google está defendendo isso na lista de discussão DMARC da IETF:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Acho uma ideia muito boa, porque o dono do domínio poderia usar DMARC e, ao mesmo tempo, especificar: “quero que o único mecanismo que autentique de verdade o tráfego do meu domínio seja DKIM”
      O setor tem muitas formas de contornar as fraquezas de SPF e DMARC, como macros SPF que ajustam dinamicamente a autenticação com base em critérios que só podem ser conhecidos no momento da interpretação do SPF
      Mas nenhuma solução de contorno é melhor do que dizer “para o meu domínio, usem apenas DKIM”

  • Recentemente passei eu mesmo pela preparação de e-mail do meu domínio e fiquei absurdamente frustrado, especialmente por causa de um ISP que decidiu que “para enviar e-mail a partir do seu próprio equipamento, você precisa ter uma conta empresarial”; esse tipo de coisa dá muita raiva
    Eu me esforço pra caramba para ser um membro responsável da rede, vou até o estado da arte atual e destrincho tudo para configurar meus sistemas direito
    Aí esses caras não só existem, como operam de forma leviana, praticamente como um open relay, e quase metade da internet paga a conta. É inacreditável

  • Em resumo, a questão é que encontraram open relays incluídos em muitos registros SPF

    • Dos 2 milhões de domínios que se deixaram abertos por meio de registros SPF, menos de mil configuraram registros DKIM/DMARC; e mesmo nos casos em que configuraram DKIM e o deixaram largado, o Gmail ainda aceita como autenticado
    • É ainda pior do que isso. A própria plataforma nem sequer tentava fazer verificação de propriedade do domínio, então era possível enviar em nome de qualquer pessoa
    • Tecnicamente, não é um open relay. A MailChannels não conseguiria existir na internet se não controlasse spam e phishing de forma agressiva
      A apresentação da DEFCON não provou a existência de um buraco gigantesco; ela mostrou um fato que existe desde os primórdios do e-mail na internet
      Sem assinaturas de mensagem como S/MIME ou DKIM, não dá para autenticar suficientemente o domínio do remetente
      Mesmo com DKIM, é possível abuso em larga escala por meio de ataques de retransmissão DKIM

  • É interessante o impacto dos cabeçalhos ARC na pontuação de spam. Como alguém que roda um servidor de e-mail pessoal, será que só adicionar ao meu e-mail um conjunto de cabeçalhos ARC sem sentido já aumentaria a taxa de entrega?

    • Eu gostaria de dizer que não. Porque, se isso fosse verdade, todas as minhas caixas de entrada espalhadas por vários provedores provavelmente estariam inundadas de spam
      Spammers organizados e bem informados certamente investigam esse tipo de coisa a fundo e devem estar usando isso para furar bloqueios
    • O setor de e-mail não vê o ARC como um método definitivo para contornar os filtros de spam dos grandes destinatários. O apresentador da DEFCON não estava bem preparado para fazer esse julgamento

  • Parece que isso já tinha sido identificado em maio de 2022: https://news.ycombinator.com/item?id=30533032

    • O CEO parece ter dito algo assim:
      “Temos ampla capacidade de detecção de spam e phishing e conseguimos lidar com abusos”
      Ah, tá bom :D