Mots-clés : Protéger

Empêcher les usurpations d’adresses email (spoofing)

Par défaut, il est souvent possible d'usurper votre nom de domaine pour envoyer des emails frauduleux se faisant passer pour vous.

Florent
Mise à jour le

En 2019, près de 79% des domaines comportaient des failles permettant d’usurper des emails (pratique dite du spoofing). En clair, des attaquants peuvent dans ces cas-là utiliser votre nom domaine pour envoyer des emails à votre nom comme si de rien n’était !

Pourtant, si ces vulnérabilités et les contre-mesures sont décrites depuis 2014, elles sont encore très présentes. Dans les tests d’intrusion menés par cendium, nous vérifions systématiquement ces points et, bien souvent, les clients apprennent qu’ils sont vulnérables à ces attaques.

Trop souvent sous-estimée malgré des impacts importants en termes d’image, de sécurité et de confiance, cette faille est pourtant facilement corrigée grâce à mise en place des champs SPF et DMARC.

Découvrez dans cet article ce qu’il est possible de faire pour un attaquant, et comment se prémunir contre l’usurpation de votre nom de domaine dans des emails (email spoofing).

Comment ça marche ?

Cela peut être surprenant, mais à l’origine, les emails n’ont pas été prévus pour vérifier l’authenticité de l’émetteur.
Concrètement, si vous avez acheté le nom de domaine www.monentreprise.fr, vous pourriez imaginer que, par défaut, seul vous en tant que propriétaire êtes à même d’envoyer des emails à partir d’adresses se finissant en @monentreprise.fr, non ? Eh bien, non.

Par défaut, et sans action de votre part, c’est-à-dire sans SPF / DMARC pour protéger un domaine particulier, n’importe qui peut envoyer des emails au nom de n’importe qui !

Exemple de mail usurpé reçu avec un nom de domaine sans aucun champ SPF ni DMARC

Sous le capot, l’email est transmis au serveur email du destinataire avec un nom de domaine usurpé, mais ce dernier n’ayant aucun élément pour vérifier l’authenticité du message va simplement le laisser passer :

Cas d'usurpation de domaine sans champ SPF ni DMARC

Face à cette menace, le premier rempart à implémenter se nomme le SPF (Sender Policy Framework). Un champ SPF permet d’établir une politique de sécurité contre le spoofing d’emails sur un nom de domaine ou un sous-domaine spécifique.

Concrètement, avec le SPF, vous pouvez protéger les adresses en @monentreprise.fr ou bien @mail.monentreprise.fr par exemple (nous verrons plus loin techniquement comment cela s’implémente).

Toute tentative d’envoyer des emails terminant par ces domaines, mais depuis un serveur de messagerie qui n’y a pas été autorisé, est alors vouée à l’échec. En effet, le serveur mail du destinataire va (normalement) rejeter cet email (quelques subtilités sont abordées par la suite).

Cas d'usurpation de sous-domaine avec SPF mais sans DMARC

Vous pourriez penser que c’est suffisant, mais il subsiste un problème. Si le hacker décide d’usurper @bonjour.monentreprise.fr ou @support.monentreprise.fr, l’email sera bien délivré normalement.
Eh oui, avec le SPF, vous devez spécifier individuellement chacun des domaines et sous-domaines à protéger, et il en existe potentiellement une infinité !

C’est là que le DMARC entre en scène. Un champ DMARC sur le domaine racine permet de créer une politique de sécurité qui sera suivie par chaque sous-domaine même s’ils n’ont pas de champ SPF explicite. Seront alors protégés @bonjour.monentreprise.fr, @123.monentreprise.fr ou tout sous-domaine que vous pourriez imaginer.

Tentative infructueuse d'usurpation avec SPF et DMARC

Observez alors que les emails usurpés arrivent désormais dans les SPAMS (s’ils sont délivrés), et non plus en boîte de réception :

Email usurpé envoyé dans les SPAMS car un champ SPF / DMARC est en place

Pour résumer :

Sans SPF ni DMARC

Tout est possible et n'importe qui peut usurper votre nom de domaine.

SPF sur le domaine principal sans DMARC

Votre domaine principal est protégé, mais pas les sous-domaines.

SPF et DMARC implémentés

Vous avez un bon niveau de protection contre l'usurpation de vos domaines et sous-domaines.

Vérifiez votre niveau de vulnérabilité !

En utilisant les mêmes méthodes et outils qu'un attaquant, nos hackers éthiques mettent à l'épreuve vos applications, systèmes et processus. Estimation immédiate.

En savoir plus

Implémentation du SPF et de DMARC

Convaincu ? Il est alors temps de se retrousser les manches ! Mais pour cela, commençons par quelques explications techniques.

Avant de passer à l'implémentation du SPF et de DMARC

Chaque nom de domaine souscrit chez un hébergeur possède une zone DNS, divers champs sont présents dans cette zone et permettent d’effectuer de la translation entre nom de domaine et adresse IP. Ainsi, un nom de domaine peut avoir plusieurs sous-domaines redirigeant chacun vers des adresses IP différentes.

Si vous n’avez pas du tout compris ce dernier paragraphe, ce n’est probablement pas une bonne idée d’implémenter SPF et DMARC vous-même ! Mais rassurez-vous, vous pouvez envoyer cet article à qui de droit dans votre entreprise, il s’agit d’une opération techniquement plutôt simple et banale.

La gestion des champs SPF et DMARC se fait dans les paramètres de zone DNS sur le site web de votre hébergeur, à travers des enregistrements de type TXT. La configuration de ces paramètres peut être effectuée par vous-même si vous êtes bricoleur, votre DSI dans une grande entreprise, le prestataire qui s’occupe de votre site web ou à défaut votre administrateur systèmes et réseaux.

Note

Les enregistrements permettant de rediriger vers une adresse IP sont des champs dits de type A, ou AAA pour les redirections vers les adresses IPv6, les champs SPF et DMARC sont eux des champs de type TXT, n’impactant pas les redirections, mais permettant de spécifier des politiques de sécurité.

Mise en place du champ SPF

Il est temps de passer aux choses sérieuses ! Configurons ensemble les entrées DNS pour protéger votre domaine. Ici, nous prendrons l’exemple du domaine « cendium.net » que nous allons chercher à protéger, il faudra bien entendu le remplacer par votre propre nom de domaine.

Vous allez devoir rajouter une entrée DNS de type « TXT » qui doit ressembler à cela :

cendium.net.  3600   IN     TXT    "v=spf1 include:spf.protection.outlook.com -all"

La directive include permet de spécifier les relais SMTP (serveurs emails) autorisés à envoyer des emails provenant du domaine spécifié, ici « cendium.net ». Dans cet exemple, seuls les relais de Microsoft Outlook (spf.protection.outlook.com) sont autorisés à envoyer des emails avec un émetteur ayant une adresse appartenant au domaine « xxx@cendium.net ».

Dans votre cas, il faudra indiquer l’adresse de votre serveur mail. Si vous ne la connaissez pas, contactez votre fournisseur de service mail pour l’obtenir.

La directive suivante permet de spécifier le comportement à adopter lorsque la politique de sécurité n’est pas respectée et que l’email provient d’un serveur non spécifié dans la directive include :

?all pour le mode neutre (non recommandé)

Si l'email ne respecte pas la politique SPF / DMARC, le serveur de messagerie devra alors livrer le message sans aucune action de sécurité, ce qui implique la réception du mail frauduleux en boîte de réception. Autant alors ne pas mettre de SPF !

~all pour le mode soft-fail

Si l'email ne respecte pas la politique SPF / DMARC, le serveur de messagerie va généralement livrer le message avec une indication "potentiellement spam". La décision de traiter l'email comme indésirable ou non est ensuite laissée à la boîte mail de l'utilisateur, ainsi, l'email peut être placé en courrier indésirable sur Outlook, et en même temps être classé dans la boîte de réception sur une boite mail gmail par exemple.

~all pour le mode hard-fail (le plus sécuritaire)

Si l'email ne respecte pas la politique SPF / DMARC il sera marqué comme spam et classé comme courrier indésirable.

Mise en place du champ DMARC

Votre champ SPF est implémenté ? Très bien, finissons de sécuriser votre nom de domaine à l’aide de DMARC !

Plus complet, et voué à limiter le nombre de champs SPF nécessaires, le champ DMARC permet de spécifier une politique SPF sur un domaine racine (ex : cendium.net) qui englobera tous les sous-domaines. C’est donc une mesure de sécurité très efficace pour ne pas devoir créer de champs SPF sur chaque sous-domaine.

Une fois n’est pas coutume, vous allez devoir rajouter une entrée DNS de type « TXT » qui doit ressembler à cela :

_dmarc.cendium.net.  3600   IN     TXT    "v=DMARC1;p=reject;sp=quarantine;
ruf=mailto:contact@cendium.net;rua=mailto:contact@cendium.net
"

Plusieurs directives sont à votre disposition dans un champ DMARC :

Directive Valeurs Description
v DMARC1 Indique l'utilisation de DMARC. Obligatoire
p Permet de spécifier la procédure à suivre en cas de politique de sécurité non respectée par un mail :
none Livrer quand même sans aucune action de sécurité.
quarantine Traiter l'email comme suspect, l'email sera classé comme spam ou un avertissement sera présent lors de la lecture du mail.
reject Rejeter l'email.
sp Permet de spécifier la procédure pour les sous-domaines. La valeur de p est utilisée si ce paramètre n’est pas spécifié.
ruf
rua
Permet de spécifier à quelle adresse mail envoyer un rapport d'échec détaillé (ruf) ou un rapport d'échec agrégé (rua).
Ainsi, en cas de tentatives d'usurpation, vous serez informé par email ! Attention toutefois à inscrire une adresse potentiellement en capacité de recevoir de nombreux rapports.

Récapitulatif

En résumé, voici ce que nous conseillons pour un maximum d’efficacité :

La solution la plus efficace pour pallier cette vulnérabilité est d’ajouter un champ SPF en hard-fail sur le domaine concerné, ainsi que d’ajouter un champ DMARC avec la policy sur reject ou quarantine qui fera autorité pour tous les autres sous-domaines.

Les entrées DNS SPF et DMARC à configurer sont alors les suivantes :

votredomaineprincipal.  3600   IN     TXT    "v=spf1 include:votreserveurdemessagerie -all"
_dmarc.votredomaineprincipal.  3600   IN     TXT    "v=DMARC1;p=reject"

Vérifications finales

Vous avez bien suivi toutes les étapes ? Nous allons vous montrer comment vérifier que votre politique SPF / DMARC est bien en place.

Pour cela, nous allons utiliser l’outil dig présent sur Linux ou son équivalent sous Windows : nslookup. Il est possible de requêter les champs TXT du domaine ciblé, et donc de vérifier que nos champs sont bien diffusés.

Pour vérifier les entrées TXT d’un nom de domaine, les commandes sont les suivantes :

Sous Windows : nslookup -type=txt votredomaine.com

Sous Linux : dig -t TXT votredomaine.com

Si vous avez bien configuré votre SPF, vous devriez alors voir apparaître la ligne que nous venons de définir un peu plus haut :

[root /]$ dig -t TXT cendium.net

; <<>> DiG 9.16.8 <<>> -t TXT cendium.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19199
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cendium.net.			IN	TXT

;; ANSWER SECTION:
cendium.net.	  3600  IN  TXT  "1|www.cendium.net"
cendium.net.	  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Pour vérifier que DMARC est correctement implémenté, il suffit de lancer la même commande pour le sous-domaine _dmarc :

Sous Windows : nslookup -type=txt _dmarc.votredomaine.com

Sous Linux : dig -t TXT _dmarc.votredomaine.com

De la même façon, vous devriez voir apparaître l’entrée TXT correspondante :

[root /]$ dig -t TXT _dmarc.cendium.net

; <<>> DiG 9.16.8 <<>> -t TXT _dmarc.cendium.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9714
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dmarc.cendium.net.		IN	TXT

;; ANSWER SECTION:
_dmarc.cendium.net.  3600  IN  TXT  "v=DMARC1;p=reject;sp=quarantine;"

Si vous ne voyez rien apparaître, attendez quelques heures, jusqu’à une journée. Parfois la propagation prend un peu de temps.

Et si vous ne vous en sortez pas, faites appel à des professionnels : contactez-nous pour obtenir un accompagnement personnalisé !

Conclusion

Ces vulnérabilités peuvent avoir un impact conséquent sur la réputation d’une entreprise, et potentiellement mener à la compromission du Système d’Information en cas d’attaques par phishing ciblé.

Afin de se prémunir des usurpations et attaques par phishing, il est primordial de mettre en place les recommandations présentées et de sensibiliser vos collaborateurs aux risques de l’espace numérique.

Recevez nos conseils et alertes, demandez les actualités cendium !

Maximum 1 email par mois, révocable à tout moment.

Florent
Mise à jour le
Indépendant depuis 2018, Florent travaille autant sur des tests d’intrusion que sur des missions d'audit de code, de forensic et de conseil en sécurité organisationnelle. Florent participe également à de nombreux programmes de bug bounty.
Cybermalveillance.gouv.fr Assistance et prévention du risque numérique