SpamChannel : envoyer des e-mails usurpés depuis plus de 2 millions de domaines et devenir virtuellement Satan [PDF]

 (media.defcon.org)
1 points par GN⁺ 2023-09-24 | 1 commentaires | Partager sur WhatsApp
  • La présentation SpamChannel à la DEFCON 31 2023 traite d’un problème d’usurpation visant l’envoi d’e-mails depuis plus de 2 millions de domaines via Cloudflare Worker
  • L’expérience centrale part de l’idée de gérer l’envoi d’e-mails non pas manuellement mais de manière programmatique, puis de l’intégrer au flux de déploiement des Workers
  • Cloudflare Workers est présenté comme un environnement de serverless computing basé sur JavaScript, TypeScript et WASM
  • La procédure de base consiste à créer un projet avec npm create cloudflare@latest puis à le déployer avec npx wrangler deploy
  • L’indice permettant d’envoyer des e-mails depuis Workers vient d’un article du blog Cloudflare sur l’intégration avec MailChannels

Point de départ de la présentation SpamChannel

  • SpamChannel est un PDF présenté par Marcello Salvati (@byt3bl33d3r) à la DEFCON 31 2023, consacré à l’envoi d’e-mails usurpés depuis plus de 2 millions de domaines
  • L’objectif de la présentation est d’implémenter l’envoi d’e-mails dans les conditions suivantes
    • envoyer des e-mails de manière programmatique
    • les envoyer via un Cloudflare Worker
  • Une clause de non-responsabilité indiquant de « ne pas commettre de crime » est incluse au sujet de la responsabilité légale

Indices sur Cloudflare Workers et l’envoi d’e-mails

À lire aussi

1 commentaires

 
GN⁺ 2023-09-24
Avis sur Hacker News

  • Vidéo de la présentation : https://www.youtube.com/watch?v=NwnT15q_PS8
    Ou aussi disponible ici. Le format vidéo ne passait pas dans mon Firefox, mais VLC le lit : https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF est cassé de bien plus de façons que celles abordées dans cette présentation. En tant qu’ingénieur travaillant sur le renforcement de la sécurité des e-mails et l’aide à la délivrabilité, mon conseil est toujours de se concentrer sur DKIM + DMARC plutôt que sur SPF
    Pour des raisons de legacy, SPF reste nécessaire, mais il ne faut pas s’y fier pour la délivrabilité ni pour empêcher l’usurpation d’identité
    La diapo 54 affirme que DKIM + DMARC n’aident pas contre cette attaque, mais ce n’est pas tout à fait exact
    On ne peut activer en toute sécurité une politique DMARC p=reject que lorsque DKIM est configuré pour tous les expéditeurs délégués ; et une fois ce niveau atteint, on peut commencer à retirer SPF pour les expéditeurs tiers en utilisant le modificateur neutre ? dans SPF
    Par exemple, v=spf1 include:relay.mailchannels.net ~all devient v=spf1 ?include:relay.mailchannels.net ~all
    Ainsi, les e-mails provenant de MailChannels auront un résultat SPF neutre auprès des destinataires compatibles DMARC et utiliseront donc DKIM, tandis que les anciens services de messagerie legacy devraient aussi accepter un résultat neutre
    Ce n’est pas une solution parfaite, mais de toute façon l’e-mail ne pourra jamais être fiable ou sûr à 100 %

    • Je me demande donc quel est le problème de SPF. L’usurpation d’IP source en TCP est assez difficile, donc je me suis toujours demandé quel avantage DKIM avait sur SPF
      J’ai toujours configuré SPF pour n’autoriser que $myIP. Pour envoyer du spam avec mon nom de domaine, il faudrait d’abord compromettre mon FAI ou mon registrar, et à ce stade il serait aussi possible d’obtenir un certificat TLS pour mon domaine
      Même dans une grande organisation qui doit mettre plusieurs systèmes d’envoi en liste blanche, je ne vois pas comment on pourrait se faire passer pour l’un des expéditeurs SPF légitimes si les enregistrements DKIM ne peuvent pas être falsifiés
      Les cas où l’on met en liste blanche des plages d’IP utilisables publiquement par n’importe qui, comme dans la présentation soumise, relèvent simplement d’une configuration stupide
      Pour falsifier tout l’échange mail, il faudrait des téraoctets de trafic pour un e-mail de quelques octets, et cela devient impossible si STARTTLS est imposé

  • Nous utilisons Cloudflare Workers + MailChannels en production. Ça donne le vertige
    Nous étions déjà en train de migrer de CF Workers vers de vrais serveurs, et maintenant il va sans doute aussi falloir quitter MailChannels
    Le risque de sécurité ne vaut pas le gain de confort

    • Depuis juin 2023, il n’est plus possible d’envoyer des e-mails via MailChannels depuis Workers sans publier un enregistrement _mailchannels dans le DNS
    • Pour être clair, le problème ici est que MailChannels n’authentifie pas l’expéditeur comme propriétaire vérifié du domaine d’envoi. CF Workers n’est pas en cause

  • « Afficher une bannière pour tous les e-mails sans signature DKIM provenant d’un domaine qui implémente DKIM », d’après ce que j’en comprends, est en grande partie impossible. Il n’existe pas de moyen sûr de savoir si un domaine implémente DKIM
    En théorie, on peut interroger le DNS pour "_domainkey.example.com" et voir si l’on obtient NXDOMAIN ou NOERROR. Le second indique généralement qu’il existe des sous-domaines, et donc qu’il peut y avoir des clés DKIM quelque part dans le DNS
    Mais on ne connaît pas le nom du sélecteur, et on ne sait pas non plus si cette clé est active ou destinée à être activée plus tard
    Un domaine peut avoir plusieurs expéditeurs authentifiés, dont certains signent avec DKIM et d’autres non
    Tous les serveurs DNS ne respectent pas correctement les standards, donc la distinction NXDOMAIN/NOERROR ne fonctionne que de manière approximative

    • Un fournisseur qui observe une part statistiquement significative du trafic mail peut voir tous, ou presque tous, les sélecteurs DKIM
      La phrase citée semble vouloir dire qu’il faudrait rejeter les e-mails provenant de MailChannels qui n’ont pas de signature DKIM

  • « Les principaux clients de MailChannels sont des hébergeurs web qui ne possèdent pas les domaines des e-mails qu’ils envoient » est l’une des pires excuses que j’aie entendues depuis un moment
    Les hébergeurs web ne « possèdent » généralement pas les domaines qu’ils hébergent, mais ils savent évidemment quels domaines ils hébergent. Router un domaine vers un compte ou un répertoire client, c’est le cœur même de l’hébergement web
    Il suffirait d’une intégration de type cPanel pour déclarer la liste des domaines et associer chaque domaine à une clé générée aléatoirement
    Tout cela peut, et devrait, être automatisé sans embêter l’utilisateur final

    • Et les listes de diffusion, alors ? Et le transfert d’e-mails ?

  • Ce serait bien que la spécification DMARC évolue pour permettre de n’utiliser que DKIM, et non SPF, pour la vérification. Malheureusement, des choses comme les invitations Google Calendar échouent encore avec DKIM

    • Il est très probable que la prochaine version de DMARC inclue une option pour exclure SPF de la vérification DMARC. L’équipe Google pousse cette idée sur la liste de diffusion IETF DMARC :
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Je trouve que c’est une très bonne idée, car cela permettrait au propriétaire d’un domaine d’utiliser DMARC tout en indiquant : « pour authentifier réellement le trafic de mon domaine, je veux que seul DKIM soit utilisé »
      Dans le secteur, il existe de nombreuses façons de contourner les faiblesses de SPF et DMARC, comme les macros SPF, qui ajustent dynamiquement l’authentification selon des critères connus uniquement au moment de l’interprétation SPF
      Mais aucune solution de contournement ne vaut le fait de dire : « pour mon domaine, utilisez uniquement DKIM »

  • J’ai récemment vécu moi-même la mise en place de l’e-mail pour mon domaine, et j’ai été particulièrement exaspéré par les FAI qui décident qu’« il faut un compte professionnel pour envoyer des e-mails depuis son propre matériel » ; ce genre de situation me met vraiment en colère
    Je fais des efforts énormes pour être un membre responsable du réseau, et je suis allé jusqu’au bout des pratiques actuelles pour configurer correctement mon système
    Et pourtant, non seulement ces gens existent, mais ils opèrent quasiment comme des relais ouverts, avec une légèreté incroyable, et près de la moitié d’Internet en paie le prix — c’est aberrant

  • En résumé, il s’agit d’avoir découvert des relais ouverts inclus dans de nombreux enregistrements SPF

    • Parmi les 2 millions de domaines qui se sont ouverts via leurs enregistrements SPF, moins de 1 000 avaient configuré des enregistrements DKIM/DMARC, et même dans les cas où DKIM était configuré puis laissé tel quel, Gmail les laissait encore passer comme authentifiés
    • C’est encore pire que cela. La plateforme elle-même n’essayait même pas de procéder à une vérification de propriété du domaine, ce qui permettait d’envoyer au nom de n’importe qui
    • À strictement parler, ce n’est pas un relais ouvert. Si MailChannels ne contrôlait pas agressivement le spam et le phishing, il ne pourrait pas exister sur Internet
      La présentation DEFCON n’a pas démontré l’existence d’un énorme trou ; elle a montré un fait qui existe depuis les débuts de l’e-mail sur Internet
      Sans signature de message comme S/MIME ou DKIM, il est impossible d’authentifier suffisamment le domaine expéditeur
      Même avec DKIM, les attaques par réémission DKIM permettent des abus à grande échelle

  • L’impact des en-têtes ARC sur le score de spam est intéressant. En tant que personne qui exploite un serveur mail personnel, est-ce que le simple fait d’ajouter à mes e-mails un ensemble d’en-têtes ARC sans signification pourrait améliorer leur délivrabilité ?

    • J’aimerais dire que non. Parce que si c’était vrai, toutes mes boîtes de réception réparties chez plusieurs fournisseurs seraient probablement submergées de spam
      Les spammeurs organisés et compétents explorent sûrement tout ce genre de choses, et les utilisent forcément pour passer les filtres
    • Dans l’industrie de l’e-mail, ARC n’est pas considéré comme un moyen infaillible de contourner les filtres antispam des grands destinataires. L’intervenant de DEFCON n’était pas suffisamment préparé pour porter ce jugement

  • Il semble que cela avait déjà été confirmé en mai 2022 : https://news.ycombinator.com/item?id=30533032

    • Le CEO semble avoir dit ceci :
      « Nous disposons de capacités étendues de détection du spam et du phishing, et nous pouvons gérer les abus »
      Ah, très bien :D