Comment se prémunir contre l’usurpation d’e-mail avec le SPF, DKIM ou DMARC ?

Malgré tous les outils en notre possession, citons par exemple Slack, la communication par e-mail a su s’adapter aux grandes évolutions, et reste première dans sa catégorie, que ce soit pour les communications internes ou externes en entreprise.

Les e-mails sont acheminés d’un serveur à un autre en utilisant le protocole SMTP. Ce protocole n’est pas conçu à l’origine pour sécuriser l’échange d’e-mails entre les utilisateurs. Le spam est donc rapidement apparu dès lors que l’utilisation d ’e-mails a commencé à se démocratiser.

Suite à cela, au début des années 2000, le système du SPF est annoncé et sortira 6 ans plus tard, suivi de très près par le DKIM qui viendra le compléter.

Plus tard le DMARC viendra s’ajouter afin de résoudre les problématiques des deux premiers.

Qu’est-ce que le SPF ?

Le SPF (Sender Policy Framework) est un protocole créé en 2006, qui consiste en la vérification du nom de domaine expéditeur d’un e-mail.
Ce système permet de définir quels serveurs ont l’autorisation d’émettre un e-mail pour un nom de domaine.

Voici un exemple :

example.com. IN TXT  »v=spf1 ip4:201.57.100.224 -all »

Cela signifie que les serveurs ayant pour adresse IP 201.57.100.224 sont autorisés à envoyer des e-mails en tant que example.com.
Le  »-all » signifie que tous les e-mails ne provenant pas de 201.57.100.224 sont rejetés.

Qu’est-ce que DKIM ?

DKIM (Domain Keys Identified Mail) est une norme créée en 2007 pour compléter l’action du SPF, permettant l’authentification du nom de domaine expéditeur d’un e-mail.
Cette norme permet également de s’assurer de l’intégrité d’un e-mail, grâce à une signature apposée à ce dernier.

Prenons cet exemple :

1632477194.example._domainkey.example.com. IN TXT (
                 »v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5klm13EvCRP »
                »OJyH2076Hrdzzlh5opdsR86J46St50WyCcSPJGphl1SpRYCEqX1XmdLPdzOJCF6M »
                »mOYwXbGUPuk0UpB0NdhkDGB6W81UX8hFWK4wZIpGBM8quv1X4JsrK0q+MiAqUsYo »
                »X2Fk1K0BG9vmLv0jLwIDAQAB’)

Dans l’exemple ci-dessus, la clé publique est intégrée dans un enregistrement DNS.
Lorsqu’un mail est envoyé, il sera quant à lui signé grâce à la clé privée.
Lors de la réception, le serveur mail va interroger le serveur DNS qui va lui retourner la clé publique.
Si cette clé publique correspond à la signature de l’e-mail, il sera alors considéré comme légitime.

Quelles sont les limites de ces politiques ?

Les enregistrements SPF et DKIM, seuls, peuvent être contournés et ce de manière assez simple.
Lorsqu’un e-mail est envoyé, il contient deux champs indiquant l’expéditeur :
• MailFrom/ReturnPath : Ce champ est celui que vérifie le SPF et le DKIM, il n’est cependant pas visible directement sur le client mail de l’utilisateur.
• From : Ce champ est quant à lui celui qui sera visible par l’utilisateur, mais il n’est pas vérifié par le SPF et/ou le DKIM.

Une personne malveillante peut donc utiliser le ReturnPath avec un domaine qu’elle possède afin de ne pas être bloquée par le SPF ou le DKIM, puis mettre dans le From (qui n’est pas analysé) le domaine de la victime afin d’usurper son identité.

Voici un exemple d’en-tête e-mail :

Return-Path: <hello@hacker.org>
Received-SPF: pass (domain of hacker.org designates 47.154.85.67 as permitted sender)
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Type: text/html; charset=utf-8
X-Mailer: Microsoft Outlook 16.0
Date: Fri, 24 Sep 2021 15:06:49 +0200
From: <xxx@example.com>
Reply-To: <xxx@example.com>
To: yyy@example.com
Subject: Very important message!
Message-Id: <42726176-6f2c-2074-7520-6d276173-2074-726f-7576-e9210a@example.com>
Content-Length: 26024

Dans cet exemple, nous voyons que hello@hacker.org se fait passer pour xxx@example.com dans son e-mail envoyé à yyy@example.com, son message sera validé au niveau SPF ainsi qu’au niveau DKIM étant donné qu’il a la main sur son domaine ‘hacker.org‘.

Qu’est-ce que DMARC ?

Le DMARC a justement été créé pour corriger le problème d’usurpation d’identité contournant le SPF et le DKIM.

DMARC (Domain-based Message Authentication Reporting and Conformance) est une norme, créée en 2012, permettant une précision du SPF et du DKIM
Elle permet d’analyser les e-mails ayant passé le SPF et le DKIM de manière plus approfondie en vérifiant que l’identité de l’expéditeur visible (Champ From) est bel et bien la même que celle transmise au serveur (Champ MailFrom/ReturnPath).
Le point fort de DMARC est également d’offrir un visuel sur les tentatives d’usurpation d’identité, en fournissant un rapport, envoyé par e-mail à un administrateur du domaine.

Exemple :

_dmarc.example.com IN TXT  »v=DMARC1; p=reject; rua=mailto:postmaster@example.com; »

Dans cet exemple, la politique appliquée aux e-mails illégitimes est reject, ce qui veut dire que les e-mails ne remplissants pas les conditions de validité DMARC seront supprimés.
Il existe trois politiques applicables :

• none : Ne rien faire, laisser tout de même passer l’e-mail.
• quarantine : Notifier l’e-mail comme étant un SPAM.
• reject : Rejeter l’e-mail.

Le rapport DMARC est ensuite envoyé à l’adresse : postmaster@example.com.
Il existe deux types de rapport DMARC :

• rua : Permet de générer des rapports au format XML, ils contiennent les adresses IP étant à l’origine des e-mails, les résultats du SPF, du DKIM et du DMARC, ainsi que des informations sur les actions prises par le serveur du destinataire.
• ruf : Permet de générer des rapports d’e-mails ayant échoué la vérification DMARC, ces rapports contiennent des exemples d’e-mails envoyés (attention aux données personnelles).
Il est bien évidemment possible de demander les deux types de rapport en ajoutant le rua ainsi que le ruf.

Une fois toutes ces politiques correctement implémentées, l’usurpation d’identité devient plus complexe.

 Elles restent le strict minimum à appliquer afin de limiter les risques et même si elles ne sont pas présentes dès le départ, il semble nécessaire de les intégrer rapidement.

Ce n’est pas parce que vous n’utilisez pas un nom de domaine pour l’envoi d’e-mail qu’une personne malveillante ne peut pas usurper votre identité et envoyer des e-mails avec votre nom de domaine.