Skip to main content
Les faiblesses du récepteur DMARC

Les faiblesses du récepteur DMARC

-
Technologie du courrier électronique

Le directeur des services de dmarcian, Tomki Camp, travaille avec les technologies d'authentification des e-mails depuis plus de deux décennies et soutient les efforts de mise en œuvre de DMARC depuis 2012. Dans cet article, il parle des incohérences dans la façon dont certains fournisseurs donnent un retour d'information sur DMARC, et dans certains cas, n'en donnent pas du tout.


Les données DMARC fournies par les récepteurs sont extrêmement utiles pour aider les propriétaires de domaines à comprendre et à résoudre les problèmes d'authentification des domaines. Cependant, il faut beaucoup de travail et de connaissances spécialisées pour comprendre les variations des données "standardisées" envoyées par les fournisseurs.

Il n'existe pas deux fournisseurs de services similaires, et chaque environnement d'hébergement de courrier ou de site web a ses propres particularités, avec des avantages et des inconvénients connus de ses abonnés. Cependant, les outils fournis par ces entreprises ne sont généralement pas régis par des protocoles définissant leur comportement et leur présentation, et il existe donc d'énormes différences d'une entreprise à l'autre.

En revanche, l'utilisation prévue de DMARC est assez bien définie, du point de vue de "comment vérifier si un message donné passe le protocole d'authentification", à "que faire avec un message qui échoue à l'authentification DMARC", en passant par "comment présenter la communication sur les statistiques d'authentification DMARC à l'adresse spécifiée par le propriétaire du domaine". 

Malheureusement, il existe encore un certain nombre de détails de mise en œuvre que certains fournisseurs négligent ou négligent. Cet article ne constitue pas une revue exhaustive de tous les problèmes connus, et la plupart des utilisateurs finaux (propriétaires de domaines) reconnaissent rarement la plupart de ces problèmes. Cependant, ils deviennent apparents lorsqu'une entreprise telle que dmarcian reçoit chaque jour des centaines de milliers de fichiers de données XML individuels.représentant des milliards de messages électroniques pour des dizaines de milliers de clients. À cette échelle, les tendances des problèmes deviennent évidentes et même les plaintes de clients à faible volume ont mis en évidence des préoccupations. Cet article a pour but d'illustrer certains des problèmes rencontrés par dmarcian dans le but d'aider les gens à mieux protéger leurs domaines.

Google

Le seul problème que posent les données fournies par cet ESP ne réside en fait pas dans le format ou la qualité des données qu'il envoie ; le problème est qu'il ne respecte pas la restriction de la spécification DMARC concernant les destinataires auxquels il ne faut pas envoyer de données. Par exemple, si je publie un enregistrement DMARC pour tomki.com spécifiant que les rapports doivent être envoyés à support@gmail.com, nous pouvons convenir que c'est une mauvaise chose, et inappropriée.

Les auteurs de la spécification ont tenu compte de ce problème et ont imposé aux fournisseurs de données DMARC (toute entité qui envoie des données RUA et/ou RUF) de vérifier que ces rapports sont autorisés. Un enregistrement DMARC spécifiant que les rapports doivent être envoyés à une adresse située dans son propre domaine est une évidence - aucune autre vérification n'est nécessaire. Si un enregistrement DMARC spécifie un destinataire dans un domaine *extérieur* à ce domaine, le générateur de rapports DMARC doit vérifier l'existence d'un enregistrement spécial au niveau du domaine de destination - cet enregistrement doit exister pour fournir une autorisation positive.

Le fait que Google n'effectue pas cette vérification peut servir d'outil pour une attaque par déni de service, puisqu'il est possible d'inonder une adresse électronique de rapports.

Cisco IronPort ESA

Il s'agit d'un système bien connu qui présente quelques problèmes graves avec ses rapports DMARC, tant dans l'environnement de la solution hébergée (IPHMX) que du côté des installations matérielles dans les environnements clients.

L'un des problèmes est que les domaines et sous-domaines ne sont pas correctement regroupés pour l'établissement des rapports. L'enregistrement DMARC d'un domaine est hérité par tout sous-domaine qui ne possède pas son propre enregistrement DMARC explicite à son niveau. Cela signifie que les données XML détaillant les transactions de courrier électronique sur tous les sous-domaines (qui n'ont pas leur propre enregistrement DMARC) devraient être dans le même rapport que pour le domaine de premier niveau. Malheureusement, le Cisco ESA ne fait pas cela, ce qui entraîne la génération de nombreux (potentiellement des milliers) de fichiers XML supplémentaires chaque jour.

Un autre problème, plus complexe, se situe au niveau de la synchronisation de la génération des données DMARC par Cisco Email Security Appliance et de l'heure des données dans les rapports. La spécification DMARC stipule que les données quotidiennes générées et envoyées aux adresses d'enregistrement doivent respecter une fenêtre de 24 heures basée sur une période UTC de minuit à minuit. En d'autres termes, de 00:00 à 23:59:59 de ce même jour en heure UTC. Cela permet de bien coordonner les rapports sur le trafic de courrier électronique dans le monde entier par le propriétaire du domaine. Le problème avec Cisco ESA est qu'il n'est pas possible d'aligner les rapports DMARC sur l'heure UTC ; toutes les données des rapports sont dans des délais correspondant à l'heure définie sur cette instance ESA particulière uniquement.

Pour expliquer un peu plus loin, prenons un exemple : Une campagne frauduleuse abuse d'un domaine de messagerie d'une entreprise internationale en envoyant 500 messages à des environnements aux États-Unis, 200 à des environnements dans l'UE et 300 autres en Inde. Supposons un scénario dans lequel ces messages ont tous été reçus dans des environnements hébergés par Cisco ESA en utilisant des paramètres d'heure locale, ce qui est normal.

  • Les 200 messages reçus dans l'UE seront les plus proches de l'heure UTC.
  • Les 500 messages reçus aux États-Unis porteront sur des heures comprises entre -5 et -8 UTC.
  • Les 300 messages reçus en Inde indiqueront l'heure de +5:30 UTC.

Il en résulte que, même si la campagne d'e-mails frauduleux a duré moins de 10 minutes, selon les rapports reçus des rapporteurs DMARC qui ne respectent pas l'exigence de l'heure UTC, il semble que la campagne se soit étendue sur environ 24 heures, sur deux jours distincts. L'administrateur du domaine abusé serait bien en peine de dire si la campagne frauduleuse a eu lieu un jour ou l'autre, ou si elle s'est étendue sur toute la période, selon les rapports reçus pour le domaine.

Les récepteurs envoient des données incorrectes

Plus souvent que vous ne le pensez, nous voyons des rapports DMARC provenant d'environnements où la représentation des données est erronée sur le plan factuel ou logique. Par exemple, lorsqu'un résultat SPF est "fail" mais que le résultat de la politique DMARC-SPF est "pass". Par définition, le seul moyen pour qu'un résultat de politique DMARC puisse être "pass" est que le résultat SPF soit "pass".

Les problèmes de ce type sont variés, allant de l'erreur logique présentée ci-dessus aux sections vides ou manquantes des données requises. Dans le but de pouvoir guider les utilisateurs dans leurs efforts pour renforcer l'authentification, dmarcian travaille avec ces rapporteurs pour remédier à leur mise en œuvre. Dans certains cas, lorsque nous n'arrivons pas à nous entendre ou qu'un problème de déclaration ne peut être résolu, les importations de données d'une source sont entièrement interrompues.

Récepteurs qui ne génèrent pas de données

Une dernière catégorie de faiblesses du récepteur n'est pas liée à des problèmes de données ou de génération de données, mais plutôt à leur absence.

DMARC est une norme publique (RFC 7489) dont des millions de propriétaires de domaines ont tiré parti pour améliorer l'authentification du trafic de courrier électronique de leurs domaines. Dans de nombreux cas, ces mêmes propriétaires de domaines ont pris des mesures dans DMARC pour publier des restrictions politiques contre l'utilisation frauduleuse de leurs domaines. Ces efforts offrent des avantages considérables à tout environnement recevant des courriels censés provenir de ce domaine ; un historique viable de l'authentification des courriels et, mieux encore, une politique d'application publiée permettent à un récepteur de séparer de manière beaucoup plus fiable le trafic de courriels légitimes du trafic frauduleux.

Le travail que les propriétaires de domaines consacrent à la mise en place et à la correction des normes d'authentification des e-mails (SPF, DKIM, DMARC) appliquées à leur trafic d'e-mails dépend énormément du retour d'information DMARC des environnements récepteurs. Mis à part les aléas connus, le retour d'informations de la part de Google, Yahoo, tous les environnements Cisco ESA, Rackspace, Comcast, Mail.ru, etc. d'autres est inestimable dans ces efforts. Plus les destinataires participent, plus le courrier électronique s'améliore pour tout le monde. Cependant, certains profitent de ces normes d'authentification et fournissent des services d'authentification pour leurs propres environnements sans contribuer à l'écosystème.

Les principaux exemples de ce comportement non coopératif sont Proofpoint, MIMECast et Symantec.cloud. Chacun de ces environnements fournit des services d'authentification DMARC pour les messages envoyés à leurs environnements, mais n'envoie pas de rapports DMARC aux propriétaires de domaines. Sans rapports DMARC relatifs à l'authentification DMARC censée être appliquée dans ces environnements, le propriétaire d'un domaine ne peut même pas être certain qu'il effectue correctement les actions de vérification ou d'application.

Si vous êtes client de l'un de ces services, veuillez les contacter pour leur demander de fournir des rapports DMARC aux domaines qui en font la demande.

dmarcian s'efforce de rendre le courrier électronique plus sûr en développant la connaissance et la sensibilisation à DMARC. Si vous avez besoin d'aide pour votre projet DMARC, vous pouvez vous inscrire pour un essai gratuit et sans engagement ici.

Vous voulez poursuivre la conversation ? Rendez-vous sur le forum dmarcien.