Mois de la cybersécurité - Tordons le cou au phishing | RENATER Skip to main content

Mois de la cybersécurité - Tordons le cou au phishing

phishing

 

L’objectif d’un phishing est de vous voler des secrets. À vrai dire, c’est encore plus vicieux : l’objectif est que vous livriez vous-mêmes et volontairement vos secrets. Un peu comme un cambrioleur qui vous demanderait de venir livrer vos meubles à une adresse précise.

Présenté comme ça, on se dit que la démarche a fort peu de chances d’aboutir et pourtant le phishing a toujours le vent en poupe.

Pourquoi diable ce succès ? Les raisons sont nombreuses mais reposent toutes sur un postulat : à un moment, l’utilisateur a fait confiance à un message piégé, cliqué sur un lien ou ouvert une pièce jointe qui donné accès à des informations sensibles au pirate. Que cela soit dû à un message particulièrement bien fait, à une naïveté ou un manque d’attention passager, les conséquences sont les mêmes : les informations sont volées et le pirate a tout loisir de s’en servir.

 

SMTP : l’abus de confiance par construction

Parmi les nombreux éléments pouvant inspirer confiance, l’identité de l’émetteur est déterminante. On ne fournit pas ses identifiants de connexion à un inconnu. En revanche, on les fournit, via un formulaire que l’on a l’habitude de voir, à la demande d’une personne de confiance telle qu’un collègue ou un responsable hiérarchique. C’est là que la faiblesse majeure de SMTP se manifeste : Rien n’y empêche de se faire passer pour un autre.

Voir c’est croire, pas vrai ? Eh bien la seule chose que voit un utilisateur pour croire qu’un message vient bien d’un certain expéditeur, c’est son champ « From ». Plus précisément : ce qui est affiché en lieu et place du champ « From » par son client de messagerie, le plus souvent son gecos. Or, rien n’est plus simple que de trafiquer un champ « From ». Les client de messagerie vous permettent même aujourd’hui de « Personnaliser l’adresse d’expédition. » En clair, si aucune contre-mesure n’est en place, vous pouvez parfaitement mettre dans ce champ « From » l’adresse que vous voulez et c’est celle que verra le destinataire du message quand il voudra savoir de qui vient le mail.

 

La sécurité par les standards

Comme chacun peut, un jour ou l’autre, tomber dans le panneau, on doit protéger l’utilisateur contre lui-même. Il ne faut pas que les utilisateurs soient exposés à des phishings ou, si un doute subsiste, qu’ils disposent d’informations claires sur la nature de ce doute.

Les objectifs d’une protection contre le phishing sont donc :

  1. De ne pas présenter de phishing à l’utilisateur, tout comme les navigateurs ne présentent pas un site web dont le certificat serveur est invalide ;
  2. de fournir des informations de confiance sur les message affichés dans le client de l’utilisateur.

On a beaucoup fait pour accomplir le premier objectif, fort peu pour le second.

Il existe quatre RFC qui, combinées, peuvent permettre d’accomplir l’objectif 1 tout en offrant des pistes pour l’objectif 2.

Le but commun de ces RFC est de permettre l’authentification des serveurs de messagerie. L’idée est de ne recevoir que des messages venant effectivement d’une infrastructure de messagerie légitime et pas, par exemple, d’une ferme de machines piratées.

 

SPF

La première – et la plus anciennes – est SPF (« Sender Policy Framework »). À quoi ça sert ? À déclarer quelles sont les IP autorisées à envoyer du mail au nom d’un domaine. Ainsi, si vous recevez un message d’une autre IP que celles déclarées dans le SPF, il y a fort à parier qu’elles viennent d’une source malveillante.

Le défaut de cette RFC est que l’authentification s’appuie sur le « From de l’enveloppe » (le « MAIL FROM » d’une transaction SMTP) et non sur le contenu du champ « From » du message.

On s’en fout ? Pas vraiment : ce que voit l’utilisateur, c’est le champ « From » du message, pas le « From de l’enveloppe » qui disparaît dès la session SMTP achevée. On peut donc envoyer un message avec l’addresse « toto@domaine1.tld » dans le champ « From » depuis un serveur du domaine « domaine2.tl2 ». Dès lors que l’adresse employée dans le « From de l’enveloppe » sera de ce domaine, la RFC SPF sera respectée.

Autre défaut cette RFC : si un relai de messagerie intervient entre l’expéditeur et le destinataire, la vérification SPF devient impossible.

 

DKIM

DKIM (« Domainkeys Identified Mail ») va plus loin. Le principe et simple : le serveur émetteur du message signe le corps et les entêtes du message.

Avec DKIM, si le message est trafiqué, la signature sera invalide. Par ailleurs, tant que le message n’est pas modifié, la signature DKIM sera valide quelque soit le nombre de relais. On conservera la garantie que le champ From est bien celui employé lors de la signature du message.

 

On y est ?

Mais alors c’est bon, non ? SPF nous garantit que le serveur d’expédition est bien celui du domaine expéditeur, et DKIM nous garantit l’intégrité des entêtes du message et en particulier du fameux champ « From ».

Et ben non.

Rappelons l’objectif 2 : que l’on puisse donner des informations fiables à l’utilisateur. On revient donc à cette donnée unique : le champ « From », alpha et oméga de l’identité pour l’utilisateur final. C’est cette information qu’il voit, c’est celle qu’il croit.

Ce qui compte, ce n’est donc pas la présence d’une signature DKIM valide ou d’un enregistrement SPF respecté mais le respect des ces RFC pour le domaine employé dans le champ « From » !

En effet, un pirate peut parfaitement apposer un signature DKIM valide sur un message et l’envoyer depuis un serveur disposant d’un enregistrement SPF. Certains le font, d’ailleurs. On peut mettre « president@organisation.com » dans l’adresse d’expédition d’un message envoyé depuis un serveur autorisé par le SPF de « francis123.com » et disposant d’une signature DKIM valide de « fouchtra456.net ».

Autant du point de vue du destinataire que d’un filtre antispam, le respect de SPF ou DKIM n’est en  aucun cas un blanc seing. Seul la violation de ces RFC est un indice potentiel de malveillance. Et encore celle-ci n’a-t-elle qu’un effet marginal sur le classement en spam.

On ne peut donc pas vraiment faire confiance à ces deux RFC en l’état. Pour qu’elles soient efficaces, on doit introduire la notion d’alignement. Disons pour l’exprimer simplement que l’alignement est respecté si les RFC DKIM et SPF sont valides du point de vue du domaine présent dans le champ « From ». Vous voyez la nuance ? En tenant compte de l’alignement, on peut ajouter toutes les signatures DKIM que l’on veut pour le domaine « fouchtra456.net », elles seront totalement ignorées si le message a, dans son champ « From », l’adresse « president@organization.com ».

 

DMARC

Là, on tient quelque chose et c’est DMARC (« Domain-based Message Authentication, Reporting and Conformance ») qui l’a introduit. Le principe de DMARC est de valider l’authentification du domaine émetteur d’un message sur la base de SPF et DKIM, en respectant l’alignement.

Alors, comment ça marche ? Si un tiers reçoit un message dont le champ « From » est une adresse d’un domaine ayant une politique DMARC, il doit vérifier si les authentifications SPF et DKIM de ce domaine sont valides. Si aucune n’est valide, il applique la politique DMARC. Une politique DMARC indique ce que les domaines destinataires devraient faire des messages qui ne respectent pas SPF ou DKIM. Il y a trois politiques possibles : « reject », « quarantine » ou « none ».

DMARC oblige donc le destinataire à vérifier l’authentification de l’émetteur, d’où la présence du mot « authentication » dans le nom de la RFC.

Un lecteur attentif aura remarqué que ce nom contient aussi deux autres mots : « Conformance » et « Reporting ».

  • « Conformance : se réfère au respect de la politique DMARC exposée ci-dessus.
  • « Reporting » : le serveur destinataire envoie régulièrement des rapports à l’émetteur, sur les messages reçus et leur état d’authentification.

Avec DMARC, on a l’arme nucléaire : si on est sûr de son infrastructure de messagerie, on peut imposer une politique stricte (demander de rejeter les messages non conformes). Dès lors, tout message qui n’en soit pas issu sera rejeté. Et si l’on n’est pas sûr de soi, on peut utiliser un politique permissive (demander de laisser passer le messages dans tous les cas) et utiliser les rapports reçus pour savoir d’où partent nos mails.

 

Et là, ça y est ? C’est bon ?

Presque. On a la garantie de ne pas avoir d’usage abusif de son domaine si :

  • on positionne des enregistrements SPF et DKIM,
  • on respecte ces deux RFC via une infrastructure maîtrisée,
  • on positionne une politique DMARC agressive, demandant un rejet des messages non conformes.

Avec ceci, seul un compte compromis peut encore envoyer des phishings depuis le domaine protégé.

Le problème, c’est que DMARC va aussi bloquer des usages légitimes.

Par exemple, une liste de diffusion ne pourra respecter ni SPF, ni DKIM et tombera donc sous le coup de la politique DMARC.

Pour sauvegarder ces usages légitimes, une solution d’atténuation est proposée par la quatrième RFC : ARC.

 

ARC ou le retour de la confiance

ARC, pour « Authenticated Received Chain » propose que les intermédiaires au cours du transfert d’un message le signent s’ils l’ont reçu correctement authentifié.

Cela fonctionne sur le même principe qu’une succession d’enveloppes scellées :

  • un intermédiaire reçoit un mail,
  • si l’authentification DMARC réussit, il  le place dans une enveloppe qu’il scelle,
  • l’intermédiaire suivant fait de même si l’authentification DMARC est toujours valide, et ainsi de suite, chaque enveloppe scellée protégeant le contenue envoyé à l’étape précédente et permettant donc de constituer une chaîne d’authentification – d’où le nom de la RFC.

C’est le moment où le lecteur attentif – le même que tout à l’heure, sans doute, le genre à poser ses questions en conférence assis au premier rang, un sourire faussement innocent aux lèvres – se demande à quoi tout ça peut bien servir.

Eh bien voilà : si un serveur reçoit un message dont l’authentification DMARC échoue mais :

  • que l’authentification ARC réussit,
  • que le serveur qui a posé le sceau ARC a reçu le message avec une authentification DMARC valide,
  • et que le serveur qui a posé le sceau ARC est un serveur de confiance

ALORS le serveur destinataire peut ignorer l’échec à DMARC.

Compliqué ? Oui, peut-être, mais toute la complexité est côté serveur, jamais l’utilisateur n’y est confronté.

Et ceci permet d’ajouter des exceptions. On peut ainsi maintenir une liste des serveurs de confiance, par exemple les serveurs de listes, réputés casser l’authentification DMARC mais sans malveillance. Si ces serveurs implémentent ARC, alors ils peuvent se porter garants de la qualité de l’authentification au moment où ils ont reçu le message. Si celle-ci était valide, alors on peut faire confiance au contenu du message et à son origine.

 

Ça nous mène où, tout ça ?

Parvenus à ce point, il semble pertinent de résumer où nous en sommes.

Nous disposons donc de :

  • SPF et DKIM pour authentifier les sources des messages ;
  • DMARC pour définir ce qu’il doit arriver aux messages ne respectant ni SPF, ni DKIM ;
  • ARC pour permettre de laisser passer les messages ne validant pas DMARC mais ayant été validés en chemin par une source de confiance.

Pour atteindre l’objectif de cet article, à savoir se débarrasser de l’hameçonnage, il est nécessaire que le plus grand nombre de serveurs possible implémente SPF, DKIM et DMARC.

Pour mettre en place une politique stricte, il faut :

  • implémenter DMARC avec un politique « reject » ;
  • terminer les enregistrements SPF par « -all » ;
  • Signer DKIM en sortie.

De cette manière, on s’assure la plus grande sévérité possible vis à vis des messages entrants. Évidemment, tout cela ne fonctionne que si les serveurs destinataires respectent cette politique. Ceci aura pour effet de réduire fortement le nombre d’hameçonnages arrivant à destination.

Cette proposition se heurte à deux difficultés :

  1. certains serveurs peuvent envoyer des messages sans passer par un MTA sortant identifié ;
  2. nombre de services légitimes cassent SPF et DKIM ;

 

Le passage à un tel niveau de rigueur impose donc d’une part une période de transition et d’analyse et, d’autre part, une organisation afin d’implémenter ARC.

Pendant la période de transition, on positionnera une politique DMARC à « none ». De cette manière, aucun message n’est rejeté et on peut analyser les rapports reçus. En particuliers, les rapports d’erreur permettront de repérer les serveurs hors norme de l’infrastructure.

D’un point de vue organisation, on peut agir sur deux leviers :

  1. organiser une liste de serveurs de relais ;
  2. collaborer pour améliorer l’implémentation.

 

Une liste de domaines intermédiaires de confiance pouvant modifier les messages (redirection ou listes) pourrait être centralisée et téléchargeable pour usage par les outils d’analyse ARC , à la manière des métadonnées d’une fédération d’identités.

Les contraintes envisageables à l’établissement d’une telle liste sont :

  • sa vérification : s’assurer que les informations qui s’y trouvent sont fiables et à jour ;
  • sa sécurisation : la rendre disponible de manière sécurisée.

Une fois les RFC implémentées, il faut rendre habituel l’affichage d’informations de légitimité (à l’instar du cadenas dans le navigateur). Notons qu’aucun client de messagerie générique ne propose d’affichage d’informations relatives à l’authentification de la source d’un message.

La difficulté sera également de réunir un nombre suffisant d’entités implémentant toutes ces RFC. La cible de cet article est la population des établissements d’enseignement supérieur et de recherche. Mais l’objectif est de faire tâche d’huile.

En résumé, l’intérêt de ces RFC est de forcer les serveurs de messagerie à montrer patte blanche, à l’instar de ce qui s’est passé pour le web quand la majorité des sites sont passés en HTTPS. À partir de là, on peut commencer à être volontairement sévère avec les domaines n’implémentant pas ces RFC. En clair, si on veut que les messages passent, il faut faire un effort. Ceci donnerait aux pirates l’obligation de les implémenter également. Et à partir de là, on a des garanties sur le domaine expéditeur, pour un message légitime comme pour un hameçonnage. Ayant des garanties sur le domaine, on peut légitimement recenser les domaines à problèmes, potentiellement contrôlés par des pirates, et ainsi enrichir des listes de serveurs de confiance ou de défiance.

 

Retrouvez l'article complet dans le pdf joins.

 

 

 

 

A propos des auteurs

BIO

 

Documents associés
Fichier attaché Taille
Article complet - Tordons le cou au phishing.pdf 3.72 Mo
The website encountered an unexpected error. Please try again later.