Explication détaillée d’une attaque par rejeu DKIM

Le 1er décembre 2021, nous avons commencé à recevoir des rapports sporadiques d’échecs de livraison d’adresses proton.me vers Gmail. Cela correspondait à une baisse dramatique de la réputation du domaine proton.me, comme observée via les outils de postmaster de Gmail, et à une augmentation de l’envoi depuis des adresses IP connues pour être mauvaises.

Il était clair, à la fois à partir des mauvaises adresses IP d’envoi (principalement en Russie) et de nos propres métriques, que les e-mails spam nuisant à la réputation du domaine de Proton Mail ne provenaient pas de nos serveurs. Cependant, les outils de postmaster indiquaient que tous les e-mails reçus par Gmail de proton.me étaient « entièrement authentifiés », y compris les frauduleux.

Cela a, à son tour, conduit les e-mails frauduleux à influencer l’algorithme de Google pour déterminer la réputation du domaine et l’a suffisamment abaissée pour que la délivrabilité des e-mails légitimes de nos serveurs soit également affectée.

Nous avons suspecté une attaque par rejeu DKIM, où un seul e-mail spam initialement envoyé depuis Proton Mail était renvoyé à de nombreux utilisateurs de Gmail dans le but d’exploiter notre capacité de livraison et notre réputation pour contourner les mesures anti-spam de Google. À un moment donné, environ 98 % des e-mails que Gmail recevait prétendant provenir de Proton Mail étaient en réalité des spams, ce qui signifie que les spammeurs envoyaient un volume d’e-mails équivalent à 50 fois notre trafic sortant normal vers Google.

Nous avons immédiatement fait pivoter notre clé de signature DKIM pour (temporairement) empêcher les e-mails de passer le contrôle DKIM et avons contacté l’équipe de lutte contre les abus de Google, qui a rapidement mis en place une solution pour les filtres anti-spam de Gmail et a rétabli la livraison des e-mails légitimes.

Les e-mails envoyés depuis proton.me, proton.me/mail et les domaines personnalisés n’ont pas été affectés par ce problème.

Fonctionnement des attaques par rejeu DKIM

Avant de pouvoir expliquer comment cela s’est produit, nous devons d’abord décrire comment les e-mails sont structurés, livrés et authentifiés sur Internet.

Les e-mails sont des messages MIME (Multipurpose Internet Mail Extensions), composés de en-têtes et de sections contenant le corps du message et éventuellement des pièces jointes. Les en-têtes contiennent certains champs qui seront familiers à tout utilisateur d’e-mail (À, Cc, De, Objet) mais aussi des informations cachées qui sont utilisées pour authentifier l’e-mail.

Cependant, aucun des en-têtes n’est réellement utilisé pour acheminer l’e-mail à sa destination finale. Le destinataire et l’expéditeur de l’e-mail sont spécifiés séparément dans le cadre de l’enveloppe électronique, ce qui est une métaphore très appropriée. Si le message électronique, y compris ses en-têtes, est équivalent à une lettre papier, alors l’enveloppe électronique dans laquelle la « lettre » est placée contient les adresses du destinataire et de retour, comme une vraie enveloppe.

Le point clé est que le destinataire sur l’enveloppe ne doit pas correspondre à un destinataire dans les en-têtes À ou Cc — des exemples typiques de cela sont les e-mails envoyés via Cci ou adressés à des « destinataires non divulgués ».

Peut-être encore plus surprenant, l’expéditeur sur l’enveloppe n’a pas à correspondre à l’en-tête De de l’e-mail. Cela a également un but légitime — les envois de masse spécifient souvent une « adresse de retour » différente de l’en-tête De pour analyser les problèmes de délivrabilité ou utiliser des services tiers pour envoyer des e-mails. Cette flexibilité est également importante pour permettre aux utilisateurs de transférer des messages d’une boîte aux lettres à une autre.

Ces adresses de retour sont authentifiées via SPF (Sender Policy Framework), qui autorise l’envoi de messages par des serveurs ou des adresses IP spécifiques à l’aide d’enregistrements DNS spéciaux. Mais cela ne valide que le serveur envoyant l’e-mail ; cela ne garantit pas que le contenu de l’e-mail n’a pas été altéré. Pour cela, nous avons besoin de DKIM (Domain Keys Identified Mail).

DKIM utilise également des enregistrements DNS spéciaux, mais au lieu d’une liste d’adresses IP, ces enregistrements contiennent des clés utilisées pour signer le contenu de l’e-mail et certains en-têtes associés. La signature cryptographique résultante est ajoutée au message sous forme d’un en-tête spécial, et le serveur de messagerie ou le client destinataire peut vérifier cette signature par rapport au contenu de l’e-mail lors de la livraison. Mais le domaine DKIM dans la signature peut également être différent de celui de l’en-tête De dans le message lui-même. Si la signature DKIM est vérifiée, cela confirme seulement que le message est passé par les serveurs de messagerie du domaine de signature et n’a pas été modifié depuis, mais pas que le message provient de l’endroit où il prétend.

Pour vérifier que le domaine dans l’en-tête De a envoyé le message, nous avons besoin de DMARC (Domain-based Message Authentication, Reporting, and Conformance). Pour réussir le DMARC, un e-mail doit passer soit le SPF soit le DKIM, et le domaine dans l’en-tête De doit être « aligné » avec le domaine SPF ou DKIM correspondant. L’en-tête De est ce que l’utilisateur voit finalement, donc DMARC est une partie cruciale pour assurer qu’un e-mail provienne bien de l’endroit qu’il prétend, car c’est la seule politique qui relie l’en-tête De soit au domaine d’envoi soit au domaine de signature.

(nouvelle fenêtre)

Revenons maintenant à l’attaque. La raison pour laquelle les attaques par rejeu de DKIM fonctionnent et pourquoi Gmail considérait ces spams retransmis comme « authentifiés » repose sur le fait que DMARC exige l’alignement de DKIM ou SPF, mais pas des deux. Le message retransmis avait une signature DKIM valide de proton.me, ce qui signifie qu’il a passé le DMARC. Ce message a ensuite été envoyé suffisamment de fois pour influencer la réputation du domaine proton.me dans le système de Gmail, devenant finalement suffisamment basse pour affecter la délivrabilité des e-mails légitimes.

Comment nous prévenons les attaques par rejeu

Le fait que DMARC soit validé si le domaine DKIM ou le domaine SPF est aligné avec le domaine De est une caractéristique de la spécification, et non un défaut. En particulier, cela permet le transfert automatique des messages et autorise l’envoi d’e-mails par des tiers de confiance. Cependant, pour les fournisseurs de messagerie électronique tels que Proton, Gmail ou Yahoo, cela permet également ce type d’attaques par rejeu, car tout utilisateur peut envoyer un e-mail, le faire signer par le domaine correspondant, puis le renvoyer avec la signature intacte.

C’est une des raisons pour lesquelles Proton et d’autres fournisseurs de messagerie électronique investissent massivement dans leur propre technologie et systèmes anti-spam. Ces systèmes sont complexes et reposent souvent sur des heuristiques compliquées pour distinguer les spams des e-mails légitimes. Dans ce cas, les attaquants ont trouvé une vulnérabilité dans le système anti-spam de Gmail et ont pu l’exploiter.

Nous apprécions la réactivité de Google pour résoudre le problème.

Comment vous pouvez prévenir l’usurpation de domaine sur votre domaine

Les attaques par rejeu de DKIM sont principalement un problème pour les fournisseurs de services de messagerie ou d’autres organisations qui offrent des adresses e-mail sur un domaine partagé. Cependant, les attaques d’authentification d’e-mails en général sont un risque pour toute organisation. Voici quelques conseils pour vous aider à vous assurer que personne d’autre ne peut usurper votre domaine ou l’utiliser pour envoyer des messages frauduleux.

1. Configurez SPF, DKIM et DMARC – Bien qu’imparfaits, ces politiques sont essentielles pour garantir que vos e-mails soient délivrés et résistent à l’usurpation. Si vous utilisez Proton pour héberger votre domaine, notre assistant de configuration de domaine vous expliquera comment le configurer et le protéger contre l’usurpation.
2. Changez régulièrement vos clés DKIM – Changer nos clés DKIM nous a permis d’arrêter rapidement l’attaque et de gagner du temps pour la solution permanente. Bien que fastidieux et risqué à faire manuellement, le système de gestion des clés DKIM(nouvelle fenêtre) de Proton nous a permis de le faire facilement en quelques minutes, et ce système est le même pour tous les domaines hébergés chez Proton. Le système effectue également un changement automatique des clés régulièrement pour réduire le risque de compromission des clés.
3. Sur-signez les en-têtes De, À et Cc – La plupart des implémentations de DKIM signent toujours les en-têtes De, À et Cc si elles sont présentes dans un e-mail, les empêchant d’être modifiées si le message est renvoyé. Cependant, si ces en-têtes sont absents, ils sont souvent non signés, ouvrant la porte aux attaques par rejeu avec des en-têtes falsifiés qui rendent les e-mails frauduleux apparemment légitimes. La sur-signature atténue ces attaques en signant ces en-têtes sensibles dans tous les cas, même s’ils sont vides. Si vous utilisez Proton pour envoyer vos e-mails, cette sur-signature est effectuée automatiquement par nos serveurs de messagerie.
4. Soyez prudent avec les sous-domaines – Si vous utilisez des enregistrements CNAME pour déléguer des parties de votre site internet à des tiers, vous pouvez également leur permettre d’envoyer des e-mails au nom de votre domaine principal. C’est parce que, par défaut, DMARC considère les domaines alignés s’ils ont une relation parent-enfant — c’est-à-dire que sub.example.com est aligné avec example.com. Vous pouvez forcer l’alignement exact pour SPF, DKIM ou les deux avec les options aspf et adkim dans votre politique DMARC. Cependant, soyez conscient que cela peut affecter l’intégration des services de messagerie tiers.

Beaucoup de choses se passent après que vous cliquez sur Envoyer dans Proton Mail

Si nous faisons tout correctement de notre côté, l’envoi d’un e-mail semble aussi simple qu’un simple clic, mais la vérité est qu’il repose sur un réseau complexe de politiques interdépendantes et imbriquées. Des événements comme cette attaque par rejeu démontrent à quel point il peut être compliqué de vérifier quelque chose d’aussi simple que « Qui a envoyé cet e-mail ? »

Chez Proton Mail, nous étudions constamment de nouveaux protocoles et politiques pour garantir que les millions d’e-mails envoyés via notre plateforme chaque jour soient livrés de manière fiable et sécurisée. Nous surveillons également en continu le courrier entrant pour nous assurer que notre vérification d’authentification a été optimisée et nous disposons de systèmes et d’analystes 24/7 pour atténuer les attaques de spam et de phishing.

C’est une partie essentielle de la création d’un internet où la confidentialité est la norme, et nous ne pourrions pas le faire sans le soutien de la communauté Proton. Merci.