Comment cracker une clé DKIM 512 bits pour moins de 8 $ de coûts cloud

 (dmarcchecker.app)
3 points par GN⁺ 2025-01-09 | 1 commentaires | Partager sur WhatsApp
  • Une analyse du top 1 million de sites web a trouvé plus de 1 700 clés publiques DKIM de moins de 1 024 bits, et l’expérience vérifiait si la clé RSA DKIM 512 bits de redfin.com pouvait réellement être exploitée
  • En décodant le tag p d’un enregistrement DKIM pour obtenir le module RSA n et l’exposant public e=65537, le module a ensuite été factorisé avec CADO-NFS
  • Sur un serveur Hetzner avec 8 vCPU dédiés et 32 Go de RAM, il a fallu environ 86 heures pour décomposer n en deux nombres premiers p et q, puis reconstruire la clé privée RSA à partir de là
  • Une fois la clé privée reconstruite, des e-mails signés comme venant de security@redfin.com ont été rejetés par Gmail et Outlook, mais Yahoo Mail, Mailfence et Tuta ont renvoyé dkim=pass
  • Avec la politique DMARC p=reject; pct=100 de redfin.com, la réussite de DKIM entraînait celle de DMARC, ce qui implique que les fournisseurs de messagerie devraient refuser les signatures DKIM RSA de moins de 1 024 bits

Le problème des clés DKIM 512 bits encore en circulation

  • Une étude des enregistrements SPF, DKIM et DMARC du top 1 million de sites web a trouvé plus de 1 700 clés publiques DKIM de longueur inférieure à 1 024 bits
  • Les clés RSA de moins de 1 024 bits sont considérées comme non sûres, et dans DKIM leur usage est déconseillé depuis la RFC 8301 en 2018
  • Le sujet de l’expérience était une clé publique RSA 512 bits trouvée sur key1._domainkey.redfin.com
  • L’objectif était de vérifier s’il était possible de reconstituer la clé privée à partir de la seule clé publique afin de signer des e-mails comme s’ils provenaient réellement du domaine d’origine
  • L’expérience vérifiait aussi si de grands fournisseurs de messagerie comme Gmail, Outlook.com et Yahoo Mail accepteraient des signatures DKIM produites avec une clé trop courte

Extraction des composants RSA depuis une clé publique DKIM

  • Dans le tag p d’un enregistrement DKIM, la clé publique est encodée en ASN.1 DER, puis réencodée en Base64
  • La clé publique a été lue avec Crypto.PublicKey.RSA.import_key en Python afin d’en extraire les composants RSA
    • module n : 10709580243955269690347257968368575486652256021267387585731784527165077094358215924099792804326677548390607229176966588251215467367272433485332943072098119
    • exposant public e : 65537

Factorisation du module avec CADO-NFS

  • Pour produire la clé privée RSA, il faut décomposer le module n en produit de deux nombres premiers p et q
  • La factorisation a été réalisée avec CADO-NFS
    • CADO-NFS est une implémentation de l’algorithme Number Field Sieve (NFS) utilisé pour factoriser de grands entiers
  • Afin de ne pas monopoliser un ordinateur local pendant plusieurs jours, un serveur cloud Hetzner a été loué
    • configuration : 8 vCPU dédiés, AMD EPYC série 7003, 32 Go de RAM
    • OS : Ubuntu
    • 32 Go de swap ont été ajoutés pour garantir suffisamment de mémoire pendant l’opération
  • La factorisation a été lancée en passant le module n à cado-nfs.py
  • L’ensemble du travail a pris environ 86 heures sur le serveur 8 vCPU, et n a été décomposé en les deux nombres premiers suivants
    • p = 97850895333751392558280999318309697780438485965134147739065017624372104720767
    • q = 109447953515671602102748820944693252789237215829169932130613751100276125683257
  • Le temps peut être réduit avec un serveur plus puissant ou une exécution distribuée sur plusieurs systèmes, et CADO-NFS simplifie ce type d’exécution distribuée

Reconstruction de la clé privée RSA

  • Après avoir obtenu p, q et e, la clé privée RSA a été reconstruite avec Python et PyCryptodome
  • Les calculs ont utilisé les valeurs et la procédure suivantes
    • n = p * q
    • phi = (p-1) * (q-1)
    • d = inverse(e, phi)
    • RSA.construct((n, e, d, p, q))
  • Le résultat était une clé privée RSA au format PEM, intégrée à la configuration OpenDKIM pour signer les e-mails de test

Résultats de vérification DKIM selon les fournisseurs de messagerie

  • La clé privée reconstruite a été ajoutée à OpenDKIM, puis des e-mails de test avec l’adresse FROM security@redfin.com ont été envoyés à plusieurs services d’hébergement e-mail
  • La plupart des fournisseurs ont jugé la clé 512 bits non sûre et ont rejeté la signature DKIM, mais trois ont renvoyé dkim=pass
  • Résultats par fournisseur
    • Gmail : FAIL
    • Outlook : FAIL
    • Yahoo Mail : PASS
    • Zoho : FAIL
    • Fastmail : FAIL
    • Proton Mail : FAIL
    • Mailfence : PASS
    • Tuta : PASS
    • GMX : FAIL
    • OnMail : FAIL
  • redfin.com dispose d’un enregistrement DMARC valide de la forme v=DMARC1;p=reject;pct=100;...
  • Pour redfin.com, un succès de la vérification DKIM entraînait aussi un succès de la vérification DMARC, et satisfaisait également aux exigences de BIMI

Coût et mesures opérationnelles

  • Il y a 30 ans, casser une clé publique RSA 512 bits relevait de la classe des supercalculateurs, mais aujourd’hui cela peut être fait sur un serveur cloud pour moins de 8 $ US
  • Avec un ordinateur personnel puissant de 16 cœurs ou plus, cela pourrait être encore plus rapide et moins coûteux
  • Il n’y a aucune raison de conserver des clés DKIM 512 ou 768 bits, et les fournisseurs de messagerie devraient rejeter automatiquement les signatures DKIM générées avec des clés RSA de moins de 1 024 bits
  • Yahoo, Mailfence et Tuta ont reçu les résultats de l’expérience ainsi que la recommandation
  • Les propriétaires de domaines devraient vérifier la présence d’anciens enregistrements DKIM dans leur configuration DNS
    • le tag p d’un enregistrement DKIM peut être contrôlé simplement en comptant le nombre de caractères Base64
    • une clé publique RSA 1 024 bits comporte au minimum 216 caractères en Base64

À lire aussi

1 commentaires

 
GN⁺ 2025-01-09
Avis sur Hacker News

  • Il y a 14 ans déjà, il était possible de casser des clés RSA DKIM de 512 bits : https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b...

    • Pendant un temps, utiliser des clés DKIM faibles a même été considéré officieusement comme une fonctionnalité
      L’idée était qu’avec une clé courte, une signature DKIM ne reste pas longtemps une preuve, ce qui préserve une forme de déni plausible en rendant difficile de prouver plus tard qu’un e-mail donné était authentique
      Bien sûr, cela ne veut pas dire que la plupart des entreprises utilisaient des clés courtes pour cette raison, mais plutôt qu’il existait une certaine perception selon laquelle les clés courtes n’étaient pas entièrement mauvaises
      La possibilité de déni dans DKIM est un sujet auquel je reviens depuis longtemps [1] ; ces clés courtes ne sont clairement pas une solution, mais j’y vois le résultat d’une pensée confuse autour de DKIM et d’une communauté qui ne voulait pas accepter les implications de tout système de signature des e-mails
      [1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
    • Ça me rappelle l’histoire de la personne qui avait cassé une clé DKIM en pensant qu’il s’agissait d’un défi de recrutement de Google
      https://www.wired.com/2012/10/dkim-vulnerability-widespread/
    • En 1999, la factorisation de RSA-155 avec des centaines d’ordinateurs a montré que les clés de 512 bits pouvaient être cassées en pratique, et on disait qu’aujourd’hui c’était possible en quelques semaines avec du matériel courant
      En gros, en 14 ans, on est passé de quelques semaines à 8 heures
    • Pour référence, l’auteur du commentaire parent est le CTO de CloudFlare
    • Ce blog était aussi mentionné dans les commentaires de http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-...

  • Si vous voulez essayer pour le fun, créez une clé DKIM de 4096 bits
    Les vérificateurs DKIM/SPF en ligne regardent seulement le DNS et disent tous que tout est correct, mais les e-mails de test échouent
    Ils affichent une explication remarquable du genre STATUS: Fail, DKIM: Pass, SPF: Pass
    Utiliser une clé de plus de 2048 bits dans une entrée DKIM est autorisé et valide, mais les validateurs n’étaient pas obligés de gérer les clés de plus de 2048 bits
    J’ai perdu quelques cheveux en l’apprenant à mes dépens

    • À ajouter : pour voir l’échec de vérification, il faut définir une politique DMARC stricte
      Fait intéressant, les sites disent que les trois éléments sont corrects et valides, tout en traitant l’e-mail comme un échec
      C’est probablement parce que la vérification des enregistrements DNS et la validation des e-mails sont gérées par des logiciels différents
    • La RFC la plus récente, RFC8301, contient une exigence
      Les validateurs doivent pouvoir vérifier les signatures avec des clés de 512 à 2048 bits, et peuvent aussi vérifier des clés plus grandes
      J’ai écrit un mémoire de master sur ce sujet il y a un an ; aujourd’hui, les principaux fournisseurs de messagerie prennent tous en charge le 4096 bits, et certains vont même jusqu’à 16384 bits

  • Je me demande pourquoi on n’augmente pas massivement la taille des clés dans toute la cryptographie
    Même si ce n’est pas une solution, ça semble au moins pouvoir faire gagner du temps
    Les performances de calcul augmentent vite et on parle sans cesse d’ordinateurs quantiques, mais j’ai l’impression que tout le monde reste immobile
    Certes, les grandes clés coûtent plus cher en calcul, mais nous avons aussi davantage de ressources de calcul ; ne devrait-on pas les utiliser pour la défense, pas seulement pour l’attaque ?
    Même une chose simple comme forcer TLS 1.3 côté client au lieu de TLS 1.2 casse beaucoup de choses, y compris le site HN

    • Un article ancien, mais toujours pertinent : https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
      Ces chiffres ne concernent pas le niveau de technologie des appareils, mais les limites maximales permises par la thermodynamique
      En conclusion, casser AES-256 ou RSA-4096 par force brute est physiquement impossible
    • C’est déjà ce qui se fait
      Les clés de 1024 bits sont en cours d’abandon depuis plus de dix ans dans de nombreux systèmes cryptographiques
      À l’exception de quelques cas en retard, les clés de 2048 bits ne sont menacées que par les ordinateurs quantiques, et ceux-ci menacent RSA lui-même
      Le progrès n’est pas linéaire : ce n’est pas parce que 1024 est devenu faible que 2048 va mécaniquement tomber bientôt, et même 1024 n’est pas facile à attaquer en pratique aujourd’hui
    • RSA-2048 n’a pas encore été cassé ; ensuite, on peut s’appuyer sur RSA-4096, déjà courant dans la plupart des usages de RSA
      DKIM est l’une des exceptions
      Côté DKIM, on attend l’adoption large de Ed25519, ce qui résoudra plusieurs désagréments
    • Parce que pour en imposer l’usage, il faut finir par casser quelque chose
      En général, la douleur est transférée directement aux utilisateurs, plutôt qu’aux opérateurs du service, avec l’espoir que les utilisateurs se plaindront assez fort pour que les opérateurs s’en préoccupent
      Mais les utilisateurs risquent aussi de passer chez un concurrent qui évite qu’une petite chose comme la sécurité bloque le chiffre d’affaires
    • Il y a huit ans, quand je travaillais dans le secteur de l’e-mail, les DKIM 512 bits étaient déjà extrêmement rares
      En fait, cela revient à demander : « pourquoi ne faisons-nous pas ce que nous faisons déjà ? »

  • Avec CADO-NFS, c’est étonnamment facile
    Il y a quelques semaines, pour le travail, j’ai factorisé une clé RSA DKIM de 512 bits sur un ordinateur de bureau, et cela n’a pris que 28 heures
    Plus précisément, c’était sur un AMD Zen 5 9900X
    Malheureusement, les clés de 1024 bits restent hors de portée d’un effort de niveau hobbyiste, mais un projet académique de l’ampleur de celui qui a factorisé une clé de 768 bits en 2010 pourrait peut-être y parvenir : https://eprint.iacr.org/2010/006.pdf

  • Hier, j’ai reçu un e-mail de Bank of America au sujet d’un problème de configuration de compte
    Il est vrai que j’avais créé un nouveau compte, et l’e-mail connaissait ce fait ainsi que le nom de l’entreprise, etc.
    Il ne contenait aucun lien, seulement une consigne d’appeler le numéro professionnel de BofA ; j’ai vérifié le numéro sur le site de BofA, c’était le même, donc j’ai appelé
    Mais personne n’a pu me dire pourquoi j’avais reçu cet e-mail ni quel était le problème avec le compte, et le conseiller n’a pas non plus trouvé de trace de l’envoi de cet e-mail
    Je suis sûr à 100 % que cet e-mail venait de Bank of America
    Il n’y avait aucun élément de phishing, ni lien, ni numéro de téléphone malveillant
    SPF, DKIM et DMARC passaient tous dans les ARC-Authentication-Results de Google, et la clé DKIM faisait aussi 2048 bits
    Quand j’ai demandé à Bank of America d’enquêter, ils m’ont répondu que “c’était probablement un message de phishing” et m’ont envoyé un lien expliquant comment se prémunir du phishing
    Il est très probable qu’il s’agissait simplement d’une erreur : un système a généré un e-mail après avoir lancé trop tôt un contrôle de cohérence pendant la création du compte
    Mais comme ils ont dit que c’était du “phishing”, j’ai envoyé un FedEx au CTO avec l’ensemble des éléments en pièce jointe
    C’est l’un ou l’autre : soit leur clé DKIM a fuité et ils doivent immédiatement publier une alerte publique, soit des employés et des systèmes IT incompétents m’ont fait tourner en rond et perdre une heure
    Dans les deux cas, je veux une enquête complète et une résolution

  • Certains fournisseurs DNS sont tellement mauvais qu’ils ne permettent de configurer que des clés d’une longueur de 1024 bits
    Par exemple, c’est le cas de wordpress.com

    • 1024 bits est plusieurs ordres de grandeur plus difficile à casser que 512 bits
      Pour référence, le dernier nombre RSA cassé était RSA-250, c’est-à-dire 829 bits, et cela a pris 2700 années-cœur en 2020 [1]
      En revanche, RSA-155, c’est-à-dire 512 bits, a déjà été factorisé en 1999
      Ce n’est pas une situation dangereuse
      [1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
    • Le NIST veut interdire même RSA 2048 bits d’ici 2035
      Au motif que cela n’offre pas un niveau de sécurité suffisant
    • On peut considérer que RSA-1024 est environ 8 millions de fois meilleur que RSA-512, donc le casser coûterait environ 64 millions de dollars rien qu’en calcul
      Ce n’est pas au niveau de bloquer la NSA, mais vu que DKIM n’est qu’une couche de protection parmi d’autres, cela semble suffisant pour arrêter les spammeurs
    • Un enregistrement DKIM n’est qu’un enregistrement DNS TXT
      Je me demande s’il y a une limite à la taille des enregistrements TXT, ou si certains essaient à tout prix de parser les enregistrements TXT qui ressemblent à du DKIM, échouent, puis refusent de les ajouter

  • Casser une clé de 512 bits pour une bonne démonstration reste une recherche en sécurité très utile, même si cela a déjà été fait
    Publier “voici la liste des endroits qui utilisent encore du 512 bits, il faut migrer” est également légitime
    Mais casser directement une clé réelle utilisée en production me met mal à l’aise : personnellement, j’ai l’impression que cela franchit une limite éthique
    Je ne suis pas avocat, mais cela pourrait aussi être un délit, et ça semble un peu inutile

    • L’entreprise concernée a été informée de la vulnérabilité, l’a corrigée, puis l’article a été publié
      Il suffit de chercher now no longer available dans le texte original
      En général, quand on veut montrer qu’un système en ligne est vulnérable, on reproduit la vulnérabilité de bonne foi, on documente la recherche, puis on demande un examen
      Le processus est le même qu’il s’agisse de casser un système cryptographique, d’obtenir l’exécution de code arbitraire sur une console de jeu verrouillée, de prouver qu’on peut manipuler les données d’une machine de vote, ou de montrer qu’on peut modifier des commentaires de Q&A dans Google Meet
      Si vous vous contentez de dire que c’est vulnérable, on peut vous ignorer ; si vous dites que c’est vulnérable et que vous le prouvez, il devient difficile de vous ignorer
      Et si, en plus, vous fixez un délai de divulgation conforme aux standards du secteur et expliquez que vous publierez la vulnérabilité après environ 60 jours de tentatives de contact, il ne reste pratiquement plus de marge pour vous ignorer
    • Casser une clé n’est pas un crime
      Ce n’est que des mathématiques
      Ce qui est illégal, c’est d’utiliser ces mathématiques pour envoyer des e-mails frauduleux ou qui enfreignent la loi dans une juridiction donnée
      Le point central, ce ne sont pas les mathématiques, mais les actions et l’intention
      Signaler que quelqu’un fait quelque chose de stupide n’est pas non plus illégal, mais ces personnes peuvent essayer de vous rendre la vie difficile
    • On peut dire la même chose d’une grande partie de la recherche en sécurité
      Du genre : “montrer qu’un bug est exploitable, c’est acceptable, mais écrire un code de preuve de concept, c’est franchir la ligne”
      Le problème, c’est que la plupart des gens n’écoutent pas la recherche en sécurité si on ne leur montre pas que c’est réellement possible
    • Parmi les quelque 1700 domaines utilisant des clés de moins de 1024 bits, un seul a effectivement été nommé publiquement
      En revanche, parmi les 10 grands fournisseurs de messagerie qui ne respectaient pas correctement la RFC DKIM, 3 — Yahoo, Tuta, Mailfence — ont été publiquement nommés après notification
    • Si seules des informations publiques ont été utilisées et que rien n’a été fait avec le résultat, casser une clé utilisée dans le monde réel n’est probablement pas un crime en soi

  • C’est pour ça que j’ai dû arrêter de gérer mon DNS avec Hover
    Ils ne prennent pas en charge les enregistrements TXT de plus de 255 caractères, et je n’ai pas non plus trouvé d’exemple où des enregistrements segmentés fonctionnaient chez Hover
    J’ai fini par utiliser Digital Ocean
    Si ce genre de problème doit durer encore 10 ans, j’aimerais que la cryptographie à courbes elliptiques devienne la norme

  • Dans le passage “la plupart des fournisseurs ont correctement identifié les clés de 512 bits comme non sûres et ont rejeté les signatures DKIM, mais trois grands fournisseurs — Yahoo Mail, Mailfence, Tuta — ont signalé dkim=pass”, je me demande si, chez Google, la signature DKIM a vraiment échoué parce qu’elle n’était pas sûre, ou si c’était à cause d’un échec SPF

    • La vérification DKIM a échoué conformément à la RFC 8301 avec le résultat dkim=policy (weak key)
      C’est exactement l’exigence selon laquelle “les vérificateurs ne doivent pas considérer comme valide une signature utilisant une clé RSA de moins de 1024 bits”

  • Le fait que 512 bits soit un nombre grand ou petit dépend de s’il s’agit de cryptographie symétrique ou de cryptographie asymétrique
    On peut considérer que la cryptographie asymétrique est toujours 8 fois plus faible que la cryptographie symétrique
    DKIM étant un mécanisme asymétrique, un DKIM 512 bits correspond à 64 bits en termes de hachage symétrique, un niveau cassé depuis longtemps
    Même SHA-1 en 160 bits est considéré comme cassé
    Pour un DKIM d’une robustesse comparable à SHA-3 en 512 bits, il faudrait au moins 4096 bits, et cela n’inclurait toujours pas les techniques d’atténuation des attaques par rejeu de SHA-3

    • DKIM n’est pas un algorithme de chiffrement
      C’est une norme qui ajoute une signature aux en-têtes d’e-mail et permet de la vérifier
      Malheureusement, DKIM ne prend en charge que les signatures rsa-sha1 et rsa-sha256 : https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3
      Ce serait bien que DKIM soit révisé pour autoriser Ed25519 ou des signatures similaires
    • Le chiffrement RSA est 10 fois plus faible que la cryptographie sur courbes elliptiques
      Par exemple, l’ECC 224 bits est à peu près comparable au RSA 2048 bits
      Les deux sont des approches asymétriques
      À l’inverse, les courbes elliptiques asymétriques offrent une robustesse similaire à celle d’un chiffrement symétrique comme AES
      Bien sûr, elles restent vulnérables aux ordinateurs quantiques