Google sofre spoofing por ataque de replay de DKIM: análise técnica

• Caso em que um invasor conseguiu enviar com sucesso um e-mail de phishing se passando pelo Google usando um ataque de replay de DKIM
• O endereço do remetente e os resultados de autenticação aparecem como se fossem de um e-mail oficial real do Google, o que facilita enganar o usuário
• O invasor usou o Google Sites para criar um site com aparência de página oficial de suporte, aumentando a credibilidade
• SPF, DMARC e DKIM passam na autenticação, mas o ponto central é o reenvio do e-mail sem modificar o corpo nem os cabeçalhos assinados
• Como medidas práticas, recomenda-se a rotação periódica das chaves DKIM e o aumento da conscientização dos usuários

---

Início: um e-mail de phishing que parece legítimo

• Pela manhã, um conhecido recebeu um e-mail dizendo ter recebido um pedido de documentos legais sobre a conta Google
• O remetente aparecia como o endereço oficial no-reply do Google, e a mensagem era elaborada com precisão, sem erros de digitação, links suspeitos ou domínio anormal
• Como era difícil determinar se era verdadeiro ou falso, o destinatário pediu ajuda a um especialista

Análise detalhada do e-mail

• Os cabeçalhos do e-mail e a prévia dos links foram investigados em um ambiente sandbox
• Endereço do remetente, branding, qualidade do texto e ausência de anexos pareciam normais
• No entanto, surgiram sinais anormais ao verificar os resultados de autenticação SPF, DKIM e DMARC

Cuidados com e-mails de phishing

• Reforça-se que não se deve clicar em links nem seguir instruções contidas em e-mails suspeitos
• Responder à mensagem ou abrir anexos fora de um ambiente sandbox pode causar vazamento de informações, comprometimento do e-mail corporativo, tomada de conta e invasão da rede
• Em caso de dúvida, é necessário solicitar análise especializada e reportar imediatamente à equipe de segurança

Fluxo do ataque: uso do Google Sites

• O link no e-mail malicioso direciona diretamente ao Google Sites se o usuário já estiver logado
• O Google Sites é um subdomínio oficial do google.com que qualquer pessoa pode usar gratuitamente, mas o conteúdo em si não é uma página oficial de suporte
• Ele é usado para diversos fins, como wiki interna, dashboard de projetos, documentação e sites de eventos, e pode ser abusado como neste ataque

Quando a confiança na infraestrutura vira ameaça

• O Google Sites, lançado em 2008, integra-se ao Google Workspace e oferece criação e publicação fáceis, SSL e confiança de marca
• Assim, o invasor pode montar com facilidade e baixo custo um site de phishing com aparência oficial, sem precisar de domínio ou hospedagem próprios

Processo detalhado do ataque de replay de DKIM

Etapa 1: obter um e-mail real do Google

• O invasor recebe um e-mail legítimo da conta [e-mail] e salva o corpo original e os cabeçalhos

Etapa 2: preparar o reenvio da mensagem assinada

• O DKIM aplica uma assinatura digital a parte do corpo do e-mail e a cabeçalhos específicos
• Se a mensagem original e os cabeçalhos assinados forem preservados, a autenticação continua válida mesmo após o reenvio

Etapa 3: reenvio via Outlook

• O invasor envia a mensagem de ataque a partir de uma conta Outlook
• Algumas informações de origem e rota mudam, mas a assinatura DKIM permanece válida

Etapa 4: uso do servidor de relay SMTP Jellyfish

• O e-mail é roteado pela Microsoft por meio do sistema Jellyfish (criando distância em relação ao servidor de origem)

Etapa 5: envio via Namecheap PrivateEmail

• O serviço PrivateEmail da Namecheap recebe o e-mail e atua como relay adicional
• Nesse processo, uma nova assinatura DKIM é adicionada, mas ela não atende ao critério do DMARC
• Como a assinatura DKIM original do Google continua correspondente e válida, a verificação DMARC é aprovada

Etapa 6: entrega final no Gmail

• No fim, o destinatário recebe um e-mail que parece ser um e-mail oficial do Google
• O resultado é que SPF, DKIM e DMARC passam na autenticação

Por que o e-mail falso de intimação é perigoso

• Uma mensagem de “intimação” provoca medo, urgência e confusão no destinatário
• Ela difere da forma como uma intimação real costuma ser emitida ou entregue; em situações normais, isso ocorreria por entrega física ou canais oficiais
• Esse tipo de phishing é muito convincente e pode enganar facilmente até usuários tecnicamente experientes

Conclusão e resposta

• Quanto mais inesperado e urgente for o e-mail, mais indispensável é verificar sua autenticidade e solicitar ação de especialistas
• Não clique em links, não responda e não execute nada
• Recomenda-se pedir análise à equipe de segurança ou a profissionais especializados em investigação

Adicional: processo de reprodução do ataque

• O invasor registra um domínio na Namecheap e obtém o serviço gratuito PrivateEmail
• Depois, faz cadastro no Google Workspace (avaliação gratuita), verifica o domínio e cria um aplicativo malicioso do Google OAuth
• No campo App Name, é possível definir o nome desejado (por exemplo, Google Support)
• Os alertas de conta enviados pelo Google são encaminhados ao PrivateEmail, permitindo manipular o endereço do remetente e o endereço de resposta
• Por fim, o e-mail malicioso é entregue ao alvo desejado

Perguntas frequentes

• Ataque de replay de DKIM: o invasor captura um e-mail legítimo com assinatura DKIM válida e o reenvia com o mesmo conteúdo e cabeçalhos
• Limites de bloqueio de SPF e DMARC: o SPF verifica apenas o servidor/IP de envio; em um ataque de replay, o DMARC também pode passar se houver alinhamento DKIM
• Por que é difícil detectar: sem alteração no corpo ou nos cabeçalhos, é difícil identificar o ataque apenas pela verificação da assinatura
• Bypass usando Google OAuth: o invasor cria um aplicativo OAuth malicioso e reenvia alertas oficiais enviados pelo Google para ganhar credibilidade
• Medidas de resposta: são importantes a rotação periódica das chaves DKIM (ciclo de 30 dias ou menos) e a educação dos usuários (cuidado com links suspeitos, checagem de URL e cultura de reporte)

[GN⁺]

Comentários no Hacker News

• Estou trabalhando em uma solução para esse problema (com coautores ex-Google e ex-Yahoo, e é um projeto confiável)
  Consulte o documento Draft: DKIM2 Motivation
  Essa abordagem não impede que um texto inserido pelo usuário seja realmente enviado pelo Google, mas impede ao menos que essa mensagem seja retransmitida sem a intenção real do Google
  Isso porque os campos SMTP FROM/TO ficam protegidos
  O rascunho de motivação não inclui detalhes técnicos; os rascunhos podem ser vistos nos documentos relacionados
  Consulte DKIM Working Group Documents

  • Como o site do Datatracker não mostra bem os documentos candidatos, estou colocando links diretos
    Draft: dkim2-dns
    Draft: dkim2-header
    Draft: dkim2-modification-algebra
    Draft: dkim2-bounce-processing
    Draft: dkim2-message-examples

  • Fico me perguntando como isso funcionaria com listas de e-mail ou grupos
    Por exemplo, muitas vezes um e-mail vindo de fora para [e-mail] é encaminhado automaticamente para membros da equipe
    No sistema do destinatário final, seria necessário configurar confiança no encaminhador da lista de e-mail, ou haver alguma lógica interna para rastrear em quais listas ele está incluído?
    Deveria ser possível verificar que accounts-payable, o destinatário original, é um destinatário válido

• Já passei pela experiência de o FBI apreender todos os dados da minha conta do Google depois de eu ser condenado por crime de invasão de computadores
  Levaram os dados uma vez em 2016 e outra vez em 2018
  Na prática, eles não fazem isso como neste artigo
  Pela minha experiência, eles enviam um e-mail a um departamento específico do Google e fazem a comunicação oficial por ali
  As autoridades agem com o máximo de cuidado para que o alvo da investigação não perceba nada

  • Para quem estiver curioso, explicando em mais detalhes
    Você recebe um e-mail de [e-mail] com algo assim:

Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

Em uma intimação de grande júri federal (Federal Grand Jury subpoena), normalmente se pede um atraso de notificação de 1 a 2 anos para impedir que o provedor de serviço (como o Google) avise você
A intimação fornece apenas registros genéricos (informações de cobrança, histórico de login etc.), não o conteúdo em si (como e-mails)
Para obter os dados reais, como e-mails, é preciso um mandado de busca separado, e o Google normalmente não notifica separadamente quando esse mandado é executado

• É sexta-feira, e este comentário me deixou 10% mais acordado
  Quero muito saber o resto da história

• Interessante
  Fico pensando se esses pedidos ficam registrados ou marcados no arquivo completo dos dados da minha conta ao fazer uma solicitação do tipo GDPR de “me mande todos os dados da minha conta”

• Meu palpite é que o mandado de busca deve ter sido por violação do CFAA, wire fraud ou conspiracy
  Espero que você tenha conseguido um bom advogado e que tudo tenha se resolvido bem

• Recebi recentemente um ataque parecido
  O invasor envia um e-mail de [e-mail] (não exatamente gmail.com), depois encaminha para [e-mail] a mensagem de erro de entrega (bounce) recebida dos servidores de e-mail do Google e, ao final, injeta uma mensagem de spam
  Isso faz com que passe por todas as verificações de segurança
  É realmente peculiar como mistura um erro de postmaster com uma campanha de phishing
  Alguém não técnico poderia cair nisso facilmente
  No meu caso, o conteúdo do phishing dizia que eu havia ganhado ferramentas de construção

  • Também estou recebendo esse tipo de e-mail há algumas semanas
    Estou começando a achar que o Google desistiu do e-mail

• Fiquei muito confuso lendo o texto
  Ele descreve em detalhes como se o invasor tivesse manipulado o corpo do e-mail para inserir links de phishing, mas na prática não havia evidência nem manipulação desse tipo
  A assinatura DKIM inclui um hash do corpo
  Tecnicamente é possível limitar o escopo do hash usando o campo I=, mas confirmei que o Google não usa essa opção em e-mails curtos (verificando diretamente e-mails de [e-mail])
  Ou seja, para passar nas verificações de DKIM e DMARC, o corpo não pode ter sido alterado, então o link de phishing também era conteúdo originalmente enviado pelo Google (só que talvez destinado a outro destinatário)
  Portanto, o ponto principal é mais um “caso de encaminhamento incorreto de um e-mail assustador” do que qualquer outra coisa, e o título “DKIM replay attack” pode soar bem mais grave para quem não está familiarizado com a área
  Edit: eu achei que o texto acabava em “The Takeaway?”, mas a atualização logo abaixo explica que o link foi na verdade inserido no nome de um app OAuth do Google e incluído no template de e-mail do Google
  Esse é o ponto mais importante do ataque, mas está enterrado por causa da péssima estrutura do texto, dando a impressão errada de que seria possível enviar conteúdo arbitrário
  Adendo: outro comentário também aponta que o screenshot do e-mail foi cortado no meio para esconder a parte fixa do template de e-mail do Google
  O ataque em si é muito mais tosco do que parece

  • Este texto parece ter sido escrito de forma deliberadamente enganosa
    Fez parecer que a parte mostrada na captura era o e-mail inteiro, quando na verdade deve ter havido mais texto que serviria de alerta

  • Pelo que entendi, o DKIM está validando porque o invasor está apenas encaminhando um e-mail que realmente recebeu do Google
    O vetor real do ataque é fazer o Google enviar um e-mail contendo um texto controlado pelo invasor

• Para mim, a vulnerabilidade real aqui é o fato de ser possível colocar uma URL no nome de um app OAuth do Google, e isso ser renderizado sem critério em e-mails no-reply vindos do domínio raiz do Google para endereços arbitrários
  Mesmo que o link não seja clicável, se o texto ao redor for ameaçador o suficiente, há uma boa chance de a vítima digitar o endereço manualmente
  O fato de poder haver várias camadas de serviços de encaminhamento que preservam a integridade do DKIM é mais um ponto educativo adicional
  Deveriam simplesmente bloquear URLs em nomes de apps OAuth, especialmente URLs contendo google.com

• Finalmente!
  Recebi um e-mail quase idêntico alguns meses atrás (destinado a administradores do Google Domains)
  Definitivamente me deu calafrios também
  Eu também não cliquei apressadamente no link; esperei e tentei encontrar outras referências sobre esse golpe
  O estranho é que todos os endereços de e-mail estavam ocultos, e o padrão dessa ocultação não correspondia aos e-mails que eu administro
  O e-mail em si era legítimo, e ao pesquisar no Google vi que o texto do corpo também batia
  No meu caso, era um e-mail sobre conta de pessoa falecida, o que não fazia sentido na realidade
  Mas eu suspeitei, quase com 100% de certeza, que alguém estivesse tentando convencer o Google de que eu havia morrido para tomar posse de toda a minha conta do Google
  Foi uma experiência realmente assustadora

• Etapa 3: o invasor envia o e-mail pelo Outlook
  Pelo que sei, não dá para falsificar o caminho do cabeçalho Received:
  Cada servidor vai adicionando suas próprias informações de rota
  Por isso eu sempre verifico essas informações ao validar a origem de um e-mail
  Uma mensagem vinda do Google não deveria passar por servidores da Microsoft

  • O cabeçalho do último servidor “confiável” é impossível de falsificar; o restante do caminho pode ser falsificado

  • Fico curioso se você verifica manualmente os cabeçalhos de todos os e-mails
    Ou se usa alguma ferramenta para destacar ou visualizar isso

• É uma situação realmente assustadora
  Imagine tentar explicar a lição deste texto para um parente
  Ter de dizer que, mesmo que venha de um domínio confiável e passe em tudo, na ordem, dkim/dmarc/spf, ainda assim é preciso desconfiar, é desanimador
  Mas este ataque é bastante limitado no que consegue fazer
  Por exemplo, ele não permite falsificar mensagens a partir da conta Gmail de outra pessoa
  “Quando uma mensagem é encaminhada, a assinatura DKIM é preservada desde que o corpo e os cabeçalhos assinados não sejam alterados”
  O surpreendente é que o cabeçalho To: não esteja incluído no que o DKIM assina
  Acho que ou a configuração da assinatura precisa mudar, ou os clientes de e-mail deveriam alertar quando o To tiver sido alterado, mesmo que a mensagem em si pareça normal

  • Imagine explicar a lição deste texto para um parente — dizer para sempre desconfiar
    Só de ter que explicar o que são dkim/dmarc/spf já complica tudo
    Na verdade, essas são tecnologias de backend que o usuário nem deveria precisar conhecer
    Este ataque não é tão assustador quanto parece
    O texto tem um tom exagerado de quem está tentando vender produto
    O fato de o cabeçalho To: não estar assinado, na verdade, não significa muita coisa
    Na prática, o To de um e-mail não precisa obrigatoriamente indicar o destinatário final

  • Essa postura de sempre desconfiar de e-mail já é o estado padrão há muito tempo
    A melhor prática é nunca confiar cegamente nem mesmo no campo From

  • Você disse que é surpreendente o To: não fazer parte da assinatura DKIM, mas na verdade faz
    Por isso o valor original de To: precisou ser mantido
    O endereço To: original aparece no screenshot da seção de reprodução
    Isso não significa que a entrega tenha sido feita para esse endereço
    Em essência, um e-mail pode ser entregue a qualquer endereço com qualquer valor de To:

  • Meu conselho padrão é: se algum e-mail pede que você tome uma ação, vá diretamente ao site em questão
    Não clique em link nenhum
    É mais inconveniente, mas no fim resolve o problema
    Especialmente para banco ou sistemas importantes, esse inconveniente vale muito a pena

  • Onde eu trabalho, esse tipo de ameaça já virou política estabelecida
    Na internet, desconfiar de tudo é uma boa prática
    Muitas pequenas empresas e freelancers ainda nem usam MFA e, quando usam, muitas vezes ainda caem facilmente em roubo de token
    Quando essas contas são comprometidas, começam a chegar e-mails maliciosos que realmente parecem vir de usuários internos
    Para o usuário, parecem totalmente legítimos
    Por isso, e-mail sempre deve ser tratado com desconfiança

• O autor escreveu
  “Here is the URL from that email [...] https://sites.google.com[...]”
  Esse link em si já era o primeiro sinal de alerta
  Acho que o autor deveria ter destacado esse ponto logo no começo, não três parágrafos depois

  • Nem todo mundo conhece todos os subdomínios de google.com
    O problema real, além da questão dos campos válidos no SSO, é que o Google serve conteúdo de usuário em subdomínios do domínio principal
    Outros serviços, como Drive, também podem fazer isso

  • Pode ser um sinal vermelho para você, mas talvez não seja para os nossos pais

• No geral, acho que isso mostra o quão frágil é todo o sistema de segurança de e-mail
  Há tantas pessoas inteligentes neste fórum que dá para imaginar alguma alternativa que resolva isso de uma vez
  Também acho que o Google deveria servir esse tipo de site em um domínio separado, como hostedbygoogle.com, em vez do domínio principal
  Fico me perguntando por que ainda não fizeram essa separação

  • Todas as alternativas realisticamente possíveis acabam, no fim, criando um sistema em que todo o controle fica nas mãos de uma única empresa
    Isso destrói um dos principais valores restantes do e-mail: ser um sistema que não é totalmente controlado por ninguém
    Os problemas técnicos até são solucionáveis, mas os problemas humanos e de interesses são muito mais difíceis
    As entidades com recursos para resolver isso geralmente não têm motivação para criar uma plataforma totalmente aberta
    A menos que levem todo o dinheiro e todo o controle, elas não vão se esforçar para isso
    Por outro lado, nem todo mundo quer entregar todo o controle a uma única empresa
    Esse é justamente o ponto: não é um problema técnico, e sim de negócios
    (É exatamente o mesmo motivo pelo qual é praticamente impossível, no metaverso, que todos os serviços compartilhem avatares e itens
    Não é tanto uma impossibilidade técnica, mas algo que os detentores de direitos jamais permitiriam)

  • Anúncio da nova startup Shadowfax, com investimento do Thiel!
    Nosso serviço monopolista seguro e centralizado vem com uma camada baseada em IA e blockchain e vai substituir o sistema ultrapassado de e-mail
    Já garantimos contratos com o Departamento de Defesa dos EUA e devemos nos tornar o padrão para todas as comunicações do governo federal, internas e externas, até 2027