Como uma chave DKIM de 512 bits foi quebrada com menos de US$ 8 em custos de nuvem
(dmarcchecker.app)- Em uma pesquisa com os 1 milhão de sites mais acessados, foram encontradas mais de 1.700 chaves públicas DKIM com menos de 1.024 bits, e o experimento verificou se a chave DKIM RSA de 512 bits da redfin.com era realmente explorável
- Após decodificar a tag
pdo registro DKIM para obter o módulo RSAne o expoente públicoe=65537, o módulo foi fatorado com o CADO-NFS - Em um servidor da Hetzner com 8 vCPUs dedicadas e 32 GB de RAM,
nfoi dividido em dois primospeqem cerca de 86 horas, e a partir disso a chave privada RSA foi reconstruída - Ao assinar e-mails enviados de
security@redfin.comcom a chave privada reconstruída, Gmail e Outlook rejeitaram, mas Yahoo Mail, Mailfence e Tuta retornaramdkim=pass - Na política DMARC da redfin.com,
p=reject; pct=100, a aprovação em DKIM levou à aprovação em DMARC, mostrando que provedores de e-mail devem rejeitar assinaturas DKIM RSA com menos de 1.024 bits
O problema das chaves DKIM de 512 bits que ainda existem
- Em uma pesquisa sobre registros SPF, DKIM e DMARC dos 1 milhão de sites mais acessados, foram encontradas mais de 1.700 chaves públicas DKIM com comprimento inferior a 1.024 bits
- Chaves RSA com menos de 1.024 bits são consideradas inseguras e, no DKIM, seu uso é desencorajado desde a RFC 8301, de 2018
- O alvo do experimento foi a chave pública RSA de 512 bits encontrada em
key1._domainkey.redfin.com - O objetivo era verificar se seria possível restaurar a chave privada usando apenas a chave pública e assinar e-mails como se fossem enviados pelo domínio original
- Também foi verificado se grandes provedores de e-mail, como Gmail, Outlook.com e Yahoo Mail, aceitariam assinaturas DKIM feitas com chaves curtas
Extração dos componentes RSA da chave pública DKIM
- A tag
pdo registro DKIM contém a chave pública codificada em formato ASN.1 DER e depois recodificada em Base64 - A chave pública foi lida com
Crypto.PublicKey.RSA.import_keyno Python para extrair os componentes RSA- Módulo
n:10709580243955269690347257968368575486652256021267387585731784527165077094358215924099792804326677548390607229176966588251215467367272433485332943072098119 - Expoente público
e:65537
- Módulo
Fatorando o módulo com CADO-NFS
- Para criar a chave privada RSA, era necessário decompor o módulo
nno produto de dois primospeq - A fatoração foi feita com CADO-NFS
- O CADO-NFS é uma implementação do algoritmo Number Field Sieve (NFS), usado para fatoração de grandes inteiros
- Para não ocupar o computador local por vários dias, foi alugado um servidor em nuvem da Hetzner
- Especificações do servidor: 8 vCPUs dedicadas, série AMD EPYC 7003, 32 GB de RAM
- O sistema operacional era Ubuntu
- Para garantir memória suficiente para a tarefa, foi adicionado swap de 32 GB
- A fatoração foi executada passando o módulo
npara ocado-nfs.py - O trabalho completo levou cerca de 86 horas no servidor com 8 vCPUs, e
nfoi fatorado nos dois primos abaixop = 97850895333751392558280999318309697780438485965134147739065017624372104720767q = 109447953515671602102748820944693252789237215829169932130613751100276125683257
- O tempo pode ser reduzido com um servidor mais potente ou com execução distribuída em vários sistemas, e o CADO-NFS simplifica esse tipo de operação distribuída
Reconstrução da chave privada RSA
- Depois de obter
p,qee, a chave privada RSA foi montada com Python e PyCryptodome - Os cálculos usaram os seguintes valores e procedimento
n = p * qphi = (p-1) * (q-1)d = inverse(e, phi)RSA.construct((n, e, d, p, q))
- O resultado foi uma chave privada RSA em formato PEM, integrada à configuração do OpenDKIM para assinar e-mails de teste
Resultado da validação DKIM por provedor de e-mail
- A chave privada reconstruída foi carregada no OpenDKIM, e e-mails de teste com endereço FROM
security@redfin.comforam enviados para vários serviços de hospedagem de e-mail - A maioria dos provedores considerou a chave de 512 bits insegura e rejeitou a assinatura DKIM, mas três deles retornaram
dkim=pass - Os resultados por provedor foram os seguintes
- Gmail: FAIL
- Outlook: FAIL
- Yahoo Mail: PASS
- Zoho: FAIL
- Fastmail: FAIL
- Proton Mail: FAIL
- Mailfence: PASS
- Tuta: PASS
- GMX: FAIL
- OnMail: FAIL
- A redfin.com tem um registro DMARC válido no formato
v=DMARC1;p=reject;pct=100;... - A aprovação na validação DKIM para redfin.com levou à aprovação em DMARC e também atendeu aos requisitos do BIMI
Custos e medidas operacionais
- Há 30 anos, quebrar uma chave pública RSA de 512 bits exigia capacidade de supercomputador, mas hoje isso é possível em um servidor de nuvem por menos de US$ 8
- Se houver um computador doméstico potente com 16 núcleos ou mais, isso pode ser feito de forma ainda mais rápida e barata
- Não há motivo para manter chaves DKIM de 512 ou 768 bits, e provedores de e-mail devem rejeitar automaticamente assinaturas DKIM geradas com chaves RSA menores que 1.024 bits
- Yahoo, Mailfence e Tuta receberam os resultados do experimento e a recomendação
- Proprietários de domínios devem revisar registros DKIM antigos nas configurações de DNS
- A tag
pdo registro DKIM pode ser verificada de forma simples contando o número de caracteres Base64 - Uma chave pública RSA de 1.024 bits tem no mínimo 216 caracteres em Base64
- A tag
1 comentários
Opiniões no Hacker News
Mesmo 14 anos atrás, já era possível quebrar chaves RSA DKIM de 512 bits: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b...
A lógica era que, com chaves curtas, a assinatura DKIM não permaneceria por muito tempo como prova, preservando uma negabilidade que tornaria difícil provar depois se determinado e-mail era autêntico
Claro, isso não quer dizer que esse fosse o motivo pelo qual a maioria das empresas usava chaves curtas; apenas que havia um clima de que chaves curtas não eram totalmente ruins
A negabilidade no DKIM é um tema em que pessoalmente venho insistindo há muito tempo [1]; essas chaves curtas claramente não são a solução, mas as vejo como resultado do pensamento confuso em torno do DKIM e da relutância da comunidade em aceitar as implicações de qualquer sistema de assinatura de e-mails
[1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
https://www.wired.com/2012/10/dkim-vulnerability-widespread/
Ou seja, em cerca de 14 anos, caiu de algumas semanas para 8 horas
Se quiser brincar com isso, crie uma chave DKIM de 4096 bits
Os verificadores online de DKIM/SPF olham apenas o DNS e dizem que está tudo correto, mas o e-mail de teste falha
Eles mostram uma explicação excelente, algo como
STATUS: Fail,DKIM: Pass,SPF: PassUsar uma chave maior que 2048 bits em um registro DKIM é permitido e válido, mas os verificadores não eram obrigados a lidar com chaves maiores que 2048 bits
Perdi alguns fios de cabelo aprendendo isso na prática
Curiosamente, os sites dizem que os três itens estão corretos e válidos, mas ainda assim o e-mail é tratado como falha
Provavelmente porque a verificação dos registros DNS e a validação do e-mail são feitas por softwares diferentes
Ela diz que os verificadores devem ser capazes de validar assinaturas com chaves de 512 a 2048 bits, e que também podem validar chaves maiores
Escrevi uma dissertação de mestrado sobre esse tema um ano atrás, e hoje os principais provedores de e-mail suportavam todos 4096 bits; alguns chegavam a suportar 16384 bits
Fico me perguntando por que não aumentamos bastante o tamanho das chaves de forma geral em toda a criptografia
Mesmo que não seja uma solução, parece uma forma possível de ganhar tempo
O desempenho computacional aumenta rapidamente e a conversa sobre computadores quânticos continua, mas tenho a impressão de que todos estão parados
Claro que chaves maiores têm custo computacional maior, mas nossos recursos de computação também aumentaram, então não deveríamos usá-los só no ataque, e sim também na defesa
Até algo simples como forçar TLS 1.3 no lado do cliente em vez de TLS 1.2 quebra muita coisa, inclusive o site do HN
Esses números têm a ver não com o nível da tecnologia dos dispositivos, mas com os limites máximos permitidos pela termodinâmica
Em resumo, quebrar AES-256 ou RSA-4096 por força bruta é fisicamente impossível
Chaves de 1024 bits vêm sendo aposentadas há mais de 10 anos em vários sistemas criptográficos
Tirando uma exceção atrasada em algum lugar, o único risco para chaves de 2048 bits são computadores quânticos — e isso ameaça o próprio RSA
O progresso não é linear, então o fato de 1024 ter ficado fraco não significa que 2048 vá cair mecanicamente em breve; mesmo 1024 ainda não é fácil de atacar na prática hoje
DKIM é uma das exceções
No lado do DKIM, estamos esperando que Ed25519 seja amplamente adotado, o que deve resolver vários incômodos
Em geral, essa dor é repassada diretamente ao usuário, não ao operador do serviço, e a estrutura acaba sendo torcer para que o usuário reclame bastante a ponto de o operador se importar
Mas também há uma boa chance de o usuário migrar para um concorrente que não deixe uma coisa pequena como segurança atrapalhar a receita
Na prática, é como perguntar “por que não fazemos algo que já estamos fazendo?”
Com CADO-NFS, dá para fazer isso com uma facilidade surpreendente
Algumas semanas atrás, por causa do trabalho, fatorei uma chave RSA DKIM de 512 bits em um computador desktop, e levou só 28 horas
Mais especificamente, era um AMD Zen 5 9900X
Infelizmente, chaves de 1024 bits ainda são difíceis para um esforço de hobby, mas um projeto acadêmico na escala do que fatorou uma chave de 768 bits em 2010 talvez consiga: https://eprint.iacr.org/2010/006.pdf
Ontem recebi um e-mail do Bank of America sobre um problema na configuração da conta
É verdade que eu tinha criado uma conta nova, e o e-mail também sabia disso, além do nome da empresa etc.
Não havia links; só uma orientação para ligar para o número empresarial do BofA. Conferi o número no site do BofA e era o mesmo, então liguei
Mas ninguém conseguiu me dizer por que recebi o e-mail nem qual era o problema na conta, e o atendente também não encontrou registro do envio desse e-mail
Tenho 100% de certeza de que esse e-mail veio do Bank of America
Não havia elementos de phishing, nem links, nem número de telefone malicioso
SPF, DKIM e DMARC passaram nos ARC-Authentication-Results do Google, e a chave DKIM também era de 2048 bits
Pedi ao Bank of America que investigasse, e eles responderam que “provavelmente era uma mensagem de phishing”, enviando um link com dicas para evitar phishing
Provavelmente foi só um erro simples: algum sistema rodou uma verificação de consistência cedo demais durante a criação da conta e gerou o e-mail
Mas, como eles disseram que era “phishing”, enviei todo o material em anexo por FedEx ao CTO
É uma de duas coisas: ou a chave DKIM vazou e eles precisam emitir um alerta público imediatamente, ou funcionários e sistemas de TI incompetentes me fizeram ficar de um lado para o outro e desperdiçar uma hora
De qualquer forma, quero uma investigação completa e uma solução
Alguns provedores de DNS são péssimos e só permitem configurar chaves de até 1024 bits
Por exemplo, o wordpress.com é assim
Para referência, o último número RSA quebrado foi o RSA-250, ou seja, 829 bits, e em 2020 isso levou 2700 anos-núcleo [1]
Já o RSA-155, ou seja, 512 bits, foi fatorado em 1999
Não é uma situação perigosa
[1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
O motivo é que ele não oferece um nível de segurança suficiente
Não é algo capaz de barrar a NSA, mas, considerando que DKIM é uma entre várias camadas de proteção, parece suficiente para impedir spammers
Fico curioso se há uma limitação no tamanho de registros TXT, ou se eles tentam analisar especificamente um registro TXT que parece DKIM, falham e recusam a adição
Quebrar uma chave de 512 bits para uma boa demonstração é uma pesquisa de segurança muito valiosa, mesmo que isso já tenha sido feito antes
Também é legítimo publicar “aqui está a lista de lugares que ainda usam 512 bits, vocês precisam migrar”
Mas quebrar diretamente uma chave real em operação no mundo real me incomoda; pessoalmente, parece cruzar uma linha ética
Não sou advogado, mas também parece que poderia ser crime, e soa um pouco desnecessário
Basta procurar
now no longer availableno texto originalNormalmente, quando se mostra que um sistema online é vulnerável, reproduz-se a vulnerabilidade de boa-fé, documenta-se a pesquisa e pede-se revisão
O processo é o mesmo seja ao quebrar um sistema criptográfico, obter execução de código arbitrário em um console de jogos bloqueado, provar que é possível manipular dados de uma urna eletrônica ou mostrar que dá para editar comentários de Q&A do Google Meet
Se você apenas disser que algo é vulnerável, podem ignorar; se você disser e provar, fica difícil ignorar
Se além disso você definir um prazo de divulgação padrão da indústria e disser que vai publicar a vulnerabilidade depois de tentar contato por cerca de 60 dias, praticamente não sobra espaço para ignorarem
É simplesmente matemática
O que é ilegal é usar essa matemática para cometer fraude ou enviar e-mails que violem leis de uma jurisdição específica
O ponto central não é a matemática, mas a ação e a intenção
Apontar que alguém está fazendo algo idiota também não é ilegal, embora eles possam tentar infernizar a sua vida
Algo como “tudo bem mostrar que um bug é explorável, mas escrever código de prova de conceito passa do limite”
O problema é que, se você não mostrar que é realmente possível, a maioria das pessoas não dá ouvidos à pesquisa de segurança
Em vez disso, dos 10 grandes provedores de e-mail que não seguiam corretamente a RFC de DKIM, 3 — Yahoo, Tuta, Mailfence — foram divulgados após notificação
Foi por isso que tive de parar de gerenciar DNS pela Hover
Eles não oferecem suporte a registros TXT com mais de 255 caracteres, e também não encontrei nenhum caso em que registros divididos funcionassem na Hover
Acabei usando a Digital Ocean
Se esse problema ainda vai continuar por mais 10 anos, seria bom que criptografia de curva elíptica virasse o padrão
No trecho “a maioria dos provedores identificou corretamente chaves de 512 bits como inseguras e recusou a assinatura DKIM, mas três provedores importantes — Yahoo Mail, Mailfence, Tuta — reportaram dkim=pass”, fico curioso se, no caso do Google, a assinatura DKIM realmente falhou por ser insegura ou se falhou por causa de uma falha no SPF
dkim=policy (weak key)É exatamente o requisito de que “verificadores não devem considerar assinaturas que usam chaves RSA com menos de 1024 bits como assinaturas válidas”
Se 512 bits é um número grande ou pequeno depende de se tratar de criptografia simétrica ou criptografia assimétrica
Dá para considerar que a criptografia assimétrica é sempre 8 vezes mais fraca que a simétrica
Como DKIM usa um método assimétrico, DKIM de 512 bits corresponde a 64 bits em termos de hash simétrico, um nível que já foi quebrado há muito tempo
Até SHA-1 de 160 bits é considerado quebrado
Para um DKIM com força semelhante à do SHA-3 de 512 bits, seriam necessários pelo menos 4096 bits, e mesmo assim isso não incluiria os mecanismos de mitigação contra ataques de repetição do SHA-3
É um padrão que coloca uma assinatura no cabeçalho do e-mail e a verifica
Infelizmente, o DKIM só oferece suporte às assinaturas
rsa-sha1ersa-sha256: https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3Seria bom se o DKIM fosse revisado para permitir Ed25519 ou assinaturas semelhantes
Por exemplo, ECC de 224 bits é aproximadamente semelhante a RSA de 2048 bits
Ambas são abordagens assimétricas
Por outro lado, curvas elípticas assimétricas têm força semelhante à da criptografia simétrica AES
Claro, são vulneráveis a computadores quânticos