Depuis ses humbles débuts en 2010, DMARC (Domain-based Message Authentication, Reporting & Conformance) est devenu un outil puissant pour de nombreuses organisations afin d’améliorer leur filtrage des courriels et d’évaluer correctement la force des courriels de leurs domaines
En particulier, la prévalence des attaques de compromission des courriels d’affaires (BEC), qui a été multipliée par 42 par rapport aux chevaux de Troie bancaires entre la fin de 2015 et la fin de 2016, a donné une importance accrue à DMARC. Les fonctionnalités d’authentification robustes de DMARC peuvent prévenir avec succès la majorité des attaques BEC. La plupart d’entre eux s’appuient sur divers types d’usurpation de domaine ou d’e-mail pour passer à travers des filtres sans être détectés et tromper les parties prenantes de l’entreprise. Un rapport du HMRC a montré que DMARC est capable d’arrêter 99% des escroqueries malveillantes impliquant un courriel d’hameçonnage.
Bien que la valeur de DMARC soit claire, il peut être difficile de le comprendre. Pour simplifier les choses, voici une explication du scientifique en chef de Vircom, Deeptiman Jugessur, sur le fonctionnement de l’enregistrement DMARC et pourquoi il est important.
Motivation – Qu’est-ce que DMARC et que fait-il pour le courrier électronique?
Pour comprendre DMARC et sa valeur, nous devons d’abord comprendre la structure d’un courriel et le défi fondamental qui existe dans cette structure. Pour commencer, un courriel se compose de 3 parties; L’enveloppe, les en-têtes et le corps.
L’enveloppe
Semblable à une enveloppe postale, l’enveloppe est principalement utilisée pour identifier l’expéditeur et le destinataire. L’expéditeur, c’est-à-dire l’adresse courriel spécifiée dans le « chemin de retour » dans le jargon des courriels, est utilisé dans les cas où le message n’a pas pu être livré. Dans SMTP (Simple Mail Transfer Protocol), c’est aussi connu sous le nom de champ « MAIL FROM ». On l’appelle souvent « adresse de rebond », « adresse de l’expéditeur de l’enveloppe » ou « enveloppe de ».
L’en-tête
La section En-tête contient des renseignements qui peuvent être analysés par les agents de transfert du courrier (ATM). Par exemple, les en-têtes « reçu » permettent aux MTA de connaître le chemin que votre courriel a emprunté sur Internet, ainsi que les informations qui sont affichées au destinataire. Le champ « Objet » est probablement le champ d’en-tête le plus connu. Parmi les différents champs d’en-tête, il y a un champ « de » (que nous appellerons « en-tête de » pour différencier de l’« enveloppe de ») qui intéresse particulièrement ceux qui cherchent à comprendre DMARC.
Le corps
Enfin, le corps du message contient la charge utile réelle du courriel.
[cta id= »18654″]
Le défi de l’authentification
Compte tenu de la structure générale d’un courriel, le problème fondamental qui demeure est qu’il n’y a pas de mécanisme intégré pour valider l’authenticité d’un expéditeur. Un expéditeur est identifié à l’aide des 2 champs mentionnés ci-dessus, l’adresse « enveloppe de » et l’adresse « en-tête de ». On peut envoyer un courriel en se faisant passer pour quelqu’un d’autre en usurpant l’un ou l’autre de ces 2 champs.
Par exemple, disons qu’un comptable nommé Njord travaille dans l’entreprise asgard.com et reçoit un courriel falsifié lui demandant de l’information. Le courriel ci-dessous est un exemple de message falsifié envoyé de Loki@midgard.com à Njord@asgard.com. Cependant, dans ce courriel, Loki prétend être le PDG de asgard.com, Odin.
Il s’agit d’un exemple de courriel d’hameçonnage, car le véritable expéditeur (l’attaquant, Loki) veut des informations confidentielles. Lorsque Njord ouvre ce courriel dans son client de messagerie, il ne verra pas le champ d’en-tête « répondre à » (qui identifie Loki) – il verra seulement que l’expéditeur est Odin. S’il tombe dans le piège et répond à ce message en pensant qu’il répond à Odin, le message sera en fait envoyé à l’attaquant : Loki@midgard.com.
Les lignes 1 à 3 font partie de l’enveloppe. L’« enveloppe de » ici est odin@asgard.com. Les lignes 5 à 8 sont des en-têtes et l’en-tête de » est le PDG <d’Odin Borson odin@asgard.com>. Le reste du message est le corps. Lors de la connexion à un MTA, ce qui précède est envoyé via SMTP. Le MTA ne connaît que l’adresse IP de connexion du véritable expéditeur, tandis que le reste des données qu’il peut utiliser pour valider le courriel se trouve dans le message ci-dessus.
L’enregistrement FPS : la première étape de l’authentification des courriels
Les spammeurs exploitent cette vulnérabilité dans les courriels depuis des décennies et, en réponse, plusieurs mesures ont été élaborées pour valider les champs de l’expéditeur. Entrez dans SPF (Sender Policy Framework). SPF s’attaque à l’authentification de l’expéditeur en exigeant que les MTA qui le prennent en charge effectuent des requêtes DNS TXT sur le domaine spécifié dans l’« enveloppe de ». Si un propriétaire de domaine souhaite que l’authenticité des messages provenant de son domaine soit vérifiée, il peut spécifier des listes d’expéditeurs autorisés en les ajoutant à un enregistrement TXT SPF dans son infrastructure DNS. Un MTA vérifierait ensuite simplement si l’adresse IP de connexion figure dans la liste des expéditeurs autorisés dans l’enregistrement TXT SPF de ce domaine.
Ainsi, en tirant parti du fait qu’un propriétaire de domaine devrait être le seul à pouvoir modifier ses propres enregistrements DNS, on devrait être en mesure de garantir l’authenticité de l’expéditeur. Dans l’exemple ci-dessus, si le propriétaire de asgard.com avait configuré un enregistrement SPF indiquant la liste des serveurs autorisés à envoyer des courriels pour asgard.com, avec une vérification rapide du FPS sur asgard.com, la MTA aurait pu bloquer le message avant qu’il n’atteigne Njord, notre comptable à asgard.com, car Loki ne possède pas d’adresse IP autorisée à envoyer au nom de asgard.com. Cela empêcherait cette forme particulière d’usurpation d’identité, mais le problème de asgard.com est-il résolu?
Eh bien, pas vraiment. Considérez le message usurpé suivant :
Notez la différence à la ligne 2. Le champ « MAIL FROM » (enveloppe de) contient maintenant loki@midgard.com. Loki possède midgard.com, donc s’il configurait son propre enregistrement TXT SPF, une vérification SPF par le serveur de messagerie d’asgard passerait maintenant. Comme le pauvre Njord ne voit pas l’« enveloppe de » dans son client de messagerie, il ne verrait encore une fois que l’en-tête de » et répondrait ainsi au message, envoyant des données confidentielles à Loki. Bien qu’il existe des moyens d’examiner les en-têtes de message complets d’un courriel sur la plupart des clients de messagerie, un utilisateur de courriel typique ne le fait pas, ce qui signifie que les utilisateurs de l’organisation qui utilisent SPF sont toujours vulnérables à la révélation de données confidentielles, ainsi qu’à d’autres menaces de type hameçonnage.
Le dossier DKIM : une autre tentative de validation par courriel
Une autre technique introduite pour garantir l’authenticité d’un expéditeur était DKIM (DomainKeys Identified Mail). Une fois de plus, il a tiré parti du DNS. Le propriétaire du domaine générerait des paires de clés et publierait sa clé publique dans un enregistrement DNS TXT. Tous les messages sortants seraient ensuite signés à l’aide de la clé privée et un en-tête DKIM contenant la signature serait ajouté au message (voir les lignes 5 à 9 ci-dessous pour un exemple). Les MTA compatibles DKIM pouvaient ensuite examiner cet en-tête DKIM et vérifier que le courriel n’avait pas été modifié en déchiffrant la valeur de hachage dans la signature et en recalculant le hachage en fonction des champs spécifiés dans la signature DKIM. S’il y avait une correspondance, le courriel n’avait pas été modifié.
Encore une fois, cependant, si un spammeur créait des signatures DKIM valides et signait ses courriels falsifiés avec la signature valide, le pauvre Njord recevrait toujours le message car son MTA l’accepterait. De plus, il répondait au message, car l’en-tête de » montrerait toujours le PDG <d’Odin Borson odin@asgard.com>. Dans l’exemple ci-dessous, Loki a envoyé un message signé DKIM à partir de son midgard.com de domaine compatible DKIM et SPF.
Le dossier DMARC : la meilleure authentification des courriels (à ce jour)
DMARC s’occupe de ce problème. Avec DMARC, la validité du courriel spécifié dans le champ « en-tête de » est testée. Au lieu de repartir de zéro pour s’attaquer au problème de l’authentification de l’expéditeur, DMARC tire parti des avantages du SPF et du DKIM. Comme pour les 2 autres techniques, DMARC exige également que le propriétaire du domaine configure un enregistrement DNS TXT.
Un enregistrement TXT DNS DMARC typique ressemblerait à : v=DMARC1; p = quarantaine; rua=mailto:vor@asgard.com. Cela indique effectivement que si la validation DMARC échoue, le message doit être mis en quarantaine. De plus, le dossier indique au serveur de messagerie d’envoyer périodiquement des rapports DMARC à vor@asgard.com.
S’il y avait eu un tel enregistrement DMARC publié pour asgard.com, un MTA compatible DMARC effectuerait des vérifications supplémentaires pour valider l’expéditeur dans le champ « en-tête de ». Une requête DMARC DNS TXT serait effectuée pour le domaine dans l’en-tête de, à savoir asgard.com. S’il existe, la MTA tente de le valider.
Pour qu’une validation DMARC réussisse, les validations SPF et/ou DKIM doivent réussir et le domaine de l’un ou l’autre des algorithmes de passage (enveloppe du domaine dans le cas de SPF, et le domaine spécifié dans le champ d= de la signature DKIM pour DKIM) doit s’aligner avec le domaine spécifié dans le champ « header from ». L’alignement signifie que les domaines correspondent ou que l’un est un sous-domaine de l’autre. Donc, dans l’exemple ci-dessus, nous voyons que midgard.com (le domaine de SPF et DKIM) ne s’aligne PAS avec le domaine dans l’en-tête de asgard.com. Il s’agit donc d’un échec DMARC et le dossier DMARC dit de mettre ces courriels en quarantaine. Njord a enfin une pause car le courriel ne se retrouve pas dans sa boîte de réception.
Rapports DMARC : Améliorer le FPS et le DKIM
DMARC est allé plus loin que SPF et DKIM avec sa fonction de rapport. Cela était nécessaire en raison du fait que les enregistrements DNS SPF et DKIM étaient souvent mal configurés, et que les propriétaires de domaine ne découvraient généralement les erreurs de configuration que lorsqu’ils étaient informés par leurs clients que leurs courriels n’étaient pas livrés à une partie. En spécifiant un rua dans l’enregistrement DMARC, les validateurs DMARC peuvent envoyer des rapports détaillés à l’adresse courriel du destinataire du rua sur les performances de DMARC sur leurs serveurs.
Un enregistrement DMARC détaille également les performances de SPF et DKIM sur le serveur de validation, de sorte qu’un administrateur de domaine peut garder un œil sur les performances de ses enregistrements SPF et DKIM lors de la modification. Il faut garder à l’esprit que les dossiers SPF et DKIM changent au cours de la vie d’une entreprise. Par exemple, si une entreprise utilise un service de marketing pour envoyer des courriels sur son dossier, son dossier FPS doit être mis à jour en conséquence. Une analyse constante d’un rapport DMARC informerait une entreprise d’une telle rupture, s’il n’était pas mis à jour, et assurerait ainsi que ses courriels de marketing sont livrés alors que les courriels de son organisation restent plus sécurisés.
DMARC, bien qu’il ne soit pas parfait, est de loin l’outil d’authentification des courriels le plus avancé qui soit. Alors que les messages d’hameçonnage et de compromission des e-mails professionnels continuent de constituer une menace croissante pour les organisations de toutes tailles, l’utilisation de DMARC devrait être au premier plan de la protection des e-mails de toute entreprise.
Que penses-tu? Votre organisation a-t-elle toujours des difficultés à authentifier les courriels avec DMARC? Commentez vos réponses ci-dessous.
La publication de disques DMARC fera bientôt partie de modusGate. Cliquez ici pour en savoir plus sur notre sécurité des courriels sur site.
