Il est parfois facile de détecter les courriels de contrefaçon en vérifiant l’expéditeur. Cependant, ce n’est pas toujours le cas. Il est possible de faire ressembler un faux courriel à un vrai. Si un agresseur sait comment faire, la cible est vraiment en difficulté. La plupart des gens n’auraient pas pris la peine d’ouvrir des liens ou des fichiers malveillants qu’ils semblent avoir reçus dans un courriel de leur patron ou de leur meilleur client. Après tout, il est difficile de les blâmer, surtout lorsqu’il n’y a aucun moyen de distinguer un contrefaçon d’un vrai courriel.

Problème 1 : L’e-mail doit arriver

L’e-mail est l’un des moyens de communication les plus importants du monde moderne et chaque entreprise dépend fortement de l’e-mail dans ses opérations quotidiennes. Bien qu’on ne pense pas beaucoup à la technologie lorsqu’il s’agit de la bonne marche des opérations, vous pouvez être sûr que tout le monde remarquera la disparition d’un courriel. Par conséquent, la fiabilité est généralement la priorité absolue pour tout administrateur de serveur de courrier électronique. Le courrier électronique doit simplement être envoyé et livré quoi qu’il arrive.

Cela implique que le serveur de courrier électronique de chaque organisation doit être aussi compatible que possible avec tous les autres éléments du monde. Et c’est là que réside le problème : les normes en matière de courrier électronique sont très dépassées.

Problème 2 : le protocole de courrier électronique sans authentification

Le principal protocole utilisé pour les communications par courrier électronique à la fois entre clients et serveurs et entre serveurs est le SMTP. Ce protocole a été introduit pour la première fois en 1982 et mis à jour pour la dernière fois en 2008, il y a bien plus d’une décennie. Et comme beaucoup d’autres anciennes normes, le SMTP est un cauchemar en matière de sécurité.

Voici de quoi est fait le message électronique typique:

Le principal problème de la norme est le manque de capacités d’email contrefaçon authentification. La responsabilité du champ d’adresse de l’expéditeur – tant dans l’enveloppe SMTP que dans l’en-tête – incombe entièrement au serveur de l’expéditeur. Pire encore, l’adresse de l’expéditeur dans l’enveloppe SMTP n’a pas à correspondre à celle de l’en-tête (et l’utilisateur ne voit que ce dernier).

Bien que la norme spécifie un en-tête par courrier électronique, le SMTP ne limite pas la limite de l’en-tête. Si un message contient plus d’un en-tête, le client de messagerie en sélectionne simplement un pour l’afficher à l’utilisateur.

Problème 3 : Faux courriers entrants et sortants

Pour compliquer encore les choses, deux parties sont impliquées dans chaque communication par courrier électronique, de sorte que ce problème de non-authentification se divise en deux sous-problèmes.

D’une part, vous voulez être sûr que tous les courriers électroniques que vous recevez ont bien été envoyés à partir de l’adresse que vous indiquez. D’autre part, vous voulez probablement empêcher d’autres personnes d’envoyer des courriels qui semblent provenir de votre adresse. Malheureusement, la norme ne peut pas aider dans tout cela.

Il n’est pas surprenant que le protocole SMTP ait été si souvent utilisé de manière abusive et que de nouvelles technologies aient été développées pour remédier aux lacunes susmentionnées.

Tentative de solution n° 1 : Sender Policy Framework (SPF)

L’idée derrière le Sender Policy Framework est assez simple : le serveur de courrier électronique de réception vérifie l’authenticité de l’adresse du serveur d’envoi qui doit correspondre à l’adresse du vrai serveur de courrier électronique attribué au domaine.

C’est plus facile à dire qu’à faire. La norme SMTP ne permet pas d’effectuer un tel contrôle, de sorte que toute méthode de traçabilité d’email contrefaçon authentification devrait être ajoutée aux informations existantes. Il a fallu une décennie pour que cette marche devienne la “norme proposée” sur Internet. Aujourd’hui, seuls environ 55 des 1 million de serveurs les plus importants utilisent le produit SPF, et la plupart d’entre eux utilisent une politique confidentialite assez souples. Le SPF est également confronté à de nombreux autres problèmes, tels qu’une architecture confuse qui conduit facilement à une mauvaise configuration, ou crée certaines solutions de contournement pour d’autres serveurs résidant à la même adresse, etc. Le grave défaut du SPF est que seule l’adresse spécifiée dans l’enveloppe SMTP est vérifiée et que le champ “From” de l’en-tête – le champ qu’un utilisateur voit réellement – est complètement ignoré.

Résultat :

Essai n°2 : DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail est un produit qui aborde le problème différemment : DKIM signe de façon cryptographique l’en-tête du message et une partie du texte du message avec une clé privée. L’authenticité de la signature peut ensuite être vérifiée à l’aide d’une clé publique publiée dans le système de noms de domaine.

Il convient toutefois de mentionner que DKIM n’est pas destiné à crypter l’intégralité du message. Au lieu de cela, une pièce jointe signée cryptographiquement est jointe. C’est un problème. La partie cryptographique est difficile à modifier, mais il est facile de supprimer complètement la signature et de créer un faux message – et les résultats sont indétectables.

DKIM est difficile à mettre en œuvre car les clés cryptographiques doivent être émises et gérées. De plus, un DKIM mal configuré permet à un attaquant de conserver la véritable signature DKIM dans un message tout en modifiant complètement l’en-tête et le texte.

Resultat :

Essai n°3 : Authentification, rapport et conformité des messages basés sur le domaine (DMARC)

Malgré son nom long, le protocole DMARC est plus facile à comprendre que SPF ou DKIM. C’est une extension des deux qui corrige leurs vulnérabilités les plus importantes.

Tout d’abord, la DMARC aide l’administrateur de domaine à déterminer le mécanisme de protection utilisé par le serveur (SPF, DKIM, ou les deux), ce qui corrige réellement les failles du mécanisme DKIM. Deuxièmement, il corrige également le SPF en vérifiant l’adresse spécifiée dans le champ “From” de l’en-tête (l’adresse réellement visible par un utilisateur) en plus de l’adresse de l’expéditeur dans l’enveloppe SMTP.

L’inconvénient est que le protocole DMARC est relativement nouveau, n’est pas encore une véritable norme (la RFC 7489 ne le définit pas comme une norme ou une proposition de norme, mais seulement comme “informatif”) et n’est pas aussi largement utilisé qu’il devrait l’être. Selon cette étude portant sur 20 000 domaines, seuls 20 d’entre eux avaient introduit le protocole MARC en 2019, et seuls 8,4 % avaient des directives strictes.

Comment se protéger de l’usurpation d’adresse e-mail

En résumé, la falsification d’e-mail est toujours possible car le protocole SMTP n’a pas été développé dans un souci de sécurité, permettant à un attaquant d’insérer l’adresse de n’importe quel expéditeur dans un e-mail falsifié. Au cours des dernières décennies, certains mécanismes et produits de protection ont été développés – SPF, DKIM et DMARC. Toutefois, pour que ces mécanismes soient plus efficaces, ils doivent être utilisés et correctement mis en œuvre par le plus grand nombre possible de serveurs de courrier, ce qui n’est malheureusement pas encore le cas.

En outre, il est important de noter que certains serveurs de relais de courrier peuvent ajouter quelque chose aux lettres en raison d’erreurs de marche. Cela échouera automatiquement au contrôle DKIM. Il est également important de rappeler que ces technologies sont utiles pour faire face aux menaces de masse. Toutefois, pour protéger votre organisation contre des attaques sophistiquées par courrier électronique, vous devez déployer des solutions de protection supplémentaires sur les postes de travail et sur le serveur de messagerie.