36c3
Vous pouvez facilement savoir s’il s’agit d’un e-mail de phishing en vérifiant l’adresse qui apparaît dans le champ « De ». Malheureusement cela n’est pas toujours faisable. Pourtant, il est bel et bien possible de créer un faux e-mail identique a un message authentique. Si un cybercriminel sait comment faire, l’entreprise prise pour cible va rencontrer de vrais problèmes. La plupart des utilisateurs n’hésitent pas à cliquer sur un lien malveillant ou à télécharger un fichier que leur supérieur, ou un client, aurait envoyé par e-mail. Nous ne pouvons pas vraiment leur en vouloir, surtout s’il est impossible de savoir si l’adresse e-mail a été usurpée.
Comment se fait-il qu’un cybercriminel puisse imiter si parfaitement un e-mail ? Lors de son intervention à la 36º édition du Chaos Communication Congress, sur l’authentification par e-mail pour les tests d’intrusion, Andrew Konstantinov a répondu à cette question et a donné un aperçu de l’efficacité des systèmes de protection de l’usurpation d’adresse e-mail.
Problème 1 : les e-mails doivent circuler
De nos jours, les e-mails sont une des méthodes de communication de base et les opérations quotidiennes de toutes les entreprises en dépendent fortement. Même si nous ne pensons pas vraiment à la technologie lorsque tout se passe bien, vous pouvez être certain que tout le monde va s’en rendre compte si d’un seul coup les employés ne reçoivent plus aucun e-mail. Par conséquent, la fiabilité est généralement la priorité de n’importe quel administrateur du serveur e-mail. Les e-mails doivent tout simplement être envoyés et remis aux destinataires, peu importe le moyen.
Cela signifie que le serveur e-mail de l’entreprise doit être compatible avec autant de serveurs que possible. C’est là qu’est le problème : les normes qui s’appliquent aux e-mails sont grandement dépassées.
Problème 2 : protocole e-mail sans authentification
Le protocole principalement utilisé pour les communications par e-mail entre le client et le serveur, et le serveur et le serveur est le SMTP. Il a commencé à être utilisé en 1982 et sa dernière mise à jour remonte à 2008. Plus de dix ans se sont écoulés. Tout comme avec d’autres normes anciennes, le SMTP est un cauchemar en matière de sécurité.
Analysons d’abord le contenu typique de vos e-mails :
• L’enveloppe SMTP. Cette partie est utilisée pour les communications serveur-serveur et n’apparaît jamais dans les e-mails de clients. Elle contient les adresses de l’expéditeur et du destinataire.
• L’en-tête. Les e-mails de clients l’affichent. C’est là où vous trouvez les champs habituels « De », « À », « Date » et « Objet » que vous utilisez pour n’importe quel e-mail.
• Le corps du message. Le texte de l’e-mail et autres contenus.
Quel est le contenu du message d’un e-mail. Image source
Le principal problème est que ce protocole n’offre aucun moyen d’authentification. La responsabilité du champ de l’adresse de l’expéditeur, qu’il s’agisse de l’enveloppe SMTP ou de l’en-tête, relève entièrement du serveur de l’expéditeur. Pire encore, l’adresse de l’expéditeur dans l’enveloppe SMTP n’a pas besoin d’être la même que celle qui figure dans l’en-tête (et l’utilisateur ne voit que cette dernière).
Même si la norme dit qu’il ne faut qu’un en-tête par e-mail, le SMTP ne respecte pas vraiment cette limite. Si un message contient plus d’un en-tête, alors l’e-mail du client choisit tout simplement lequel il veut afficher à l’utilisateur.
Pas besoin d’être un cybercriminel professionnel pour se rendre compte que cela pourrait engendrer beaucoup de problèmes.
Le protocole e-mail ne dispose d’aucun moyen permettant de s’assurer qu’un e-mail a vraiment été envoyé par l’expéditeur qui apparaît
Problème 3 : Faux entrant, faux sortant — il faut tout contrôler
Les choses se compliquent davantage puisque chaque communication par e-mail implique deux parties. Ce problème de non-authentification se divise donc en deux sous-problèmes.
D’une part, vous voulez être certain que l’e-mail reçu a vraiment été envoyé par l’adresse indiquée. D’autre part, il est fort probable que vous souhaitiez éviter que n’importe qui puisse envoyer des e-mails depuis votre adresse. Malheureusement le protocole ne peut pas vous aider.
Il n’est pas surprenant de constater que le protocole SMTP a si souvent mal été utilisé que certaines personnes ont commencé à concevoir de nouvelles technologies pour corriger les défauts mentionnés auparavant.
Tentative de correction 1 : SPF (vérification du nom de domaine de l’expéditeur d’un e-mail)
L’idée à l’origine du SPF est assez simple. Le serveur destinataire devrait pouvoir vérifier si l’adresse du serveur qui a envoyé l’e-mail correspond à la véritable adresse du serveur de l’e-mail associée au domaine.
Plus facile à dire qu’à faire. Le protocole SMTP ne dispose de rien pour faire cette vérification. Il faudrait donc ajouter une méthode d’authentification au système existant. Il a fallu attendre dix ans pour que cette technologie devienne une « norme proposée ». De nos jours, seulement environ 55 % du million de serveurs utilise le SPF, et la plupart d’entre eux emploient des politiques assez laxistes.
Le SPF rencontre bien d’autres problèmes : une architecture chaotique qui facilite une mauvaise configuration, certaines techniques permettent de le contourner, notamment grâce à d’autres serveurs hébergés sur la même adresse, etc. Le plus gros défaut du SPF est qu’il ne vérifie que l’adresse de l’enveloppe SMTP et ignore complètement le champ « De » de l’en-tête, qui correspond à l’adresse que l’utilisateur voit.
Résultat :
• Le SPF vous aide à vérifier si l’e-mail a été envoyé depuis un serveur authentique.
• L’adresse que l’utilisateur voit peut être fausse.
Tentative de correction 2 : DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail aborde le problème différemment. Le DKIM signe par chiffrement l’en-tête du message et une partie du corps du message grâce à une clé privée, dont la signature peut être vérifiée grâce à une clé publique publié sur le Domain Name System (système de noms de domaine).
Il convient toutefois de souligner que le DKIM ne devrait pas chiffrer la totalité du message. En réalité, il lui ajoute un addenda à signature cryptographique. C’est un problème. La partie chiffrée peut difficilement être modifiée, mais vous pouvez facilement supprimer la totalité de la signature et élaborer un faux message. Les résultats sont indétectables.
La mise en place du DKIM est compliquée puisqu’il faut émettre et gérer des clés cryptographiques. De plus, une mauvaise configuration du DKIM peut permettre à un cybercriminel de conserver la véritable signature du DKIM dans un message tout en modifiant complètement l’en-tête et le corps du message.
Résultat :
• Le DKIM vous permet de signer numériquement les messages, ce qui assure au serveur destinataire que vous avez vraiment envoyé le message.
• Difficile à mettre en place puisqu’il faut gérer les clés cryptographiques.
• Les cybercriminels peuvent tout simplement supprimer la signature et se faire passer pour vous.
• Un mauvais réglage peut permettre l’envoi de faux messages avec de vraies signatures DKIM.
Tentative de correction 3 : Domain-based Message Authentication, Reporting and Conformance (DMARC)
Même si son nom est assez long, le protocole Domain-based Message Authentication, Reporting and Conformance est plus facile à comprendre que le SPF ou le DKIM. Il s’agit d’une extension de ces deux para-mètres qui corrige la plupart de leurs erreurs.
Tout d’abord, le DMARC aide l’administrateur du domaine à indiquer quel mécanisme de protection (SPF, DKIM, ou les deux) le serveur utilise, ce qui rectifie vraiment le mécanisme DKIM. Ensuite, il corrige aussi le SPF puisqu’il vérifie l’adresse de l’en-tête, qui correspond au champ « De » visible par l’utilisateur, et il analyse aussi l’adresse de l’expéditeur qui se trouve dans l’enveloppe SMTP.
L’inconvénient est que le protocole DMARC est relativement nouveau, n’est pas encore une norme à pro-prement parlé (RFC 7489 ne le définit pas comme standard ou norme proposée mais comme « instructif ») et n’est pas utilisé autant qu’il devrait l’être. Une étude a analysé 20 000 domaines et a constaté que seule-ment 20 % d’entre eux ont adopté le DMARC en 2019 et que seul 8,4 % ont des politiques strictes.
Malheureusement, l’adoption du DMARC n’est pas courante et il est souvent utilisé sans « aucune » politique. Image source
Résultat :
• Correction de la plupart des problèmes que présentent SPF et DKIM.
• Pas encore adopté à grande échelle et donc efficacité réduite.
Comment se protéger de l’usurpation d’e-mail
En conclusion, la falsification d’e-mails est encore possible parce que le protocole SMTP n’a pas été conçu en pensant à la sécurité, ce qui permet aux cybercriminels d’introduire l’adresse e-mail de l’expéditeur dans un faux e-mail. Certains mécanismes de protection sont apparus au cours de ces dernières décennies (SPF, DKIM et DMARC). Pourtant, pour que ces mécanismes soient efficaces, ils doivent être utilisés par le plus grand nombre de serveurs possible et être mis en place correctement. Dans l’idéal, ils devraient être installés sur chaque serveur e-mail du Web.
De plus, il ne faut pas oublier qu’à cause de certaines erreurs de configuration le serveur e-mail pourrait commencer à ajouter des lettres, ce qui ferait automatiquement échouer la vérification du DKIM. Ayez toujours à l’esprit que ces technologies vous aident à gérer les menaces de masse mais que pour protéger votre entreprise des attaques e-mail sophistiquées vous devez installer d’autres solutions de protection sur vos postes de travail et sur le serveur e-mail
Voici quelques conseils pour protéger vos e-mails :
• Utilisez au moins le SPF. Vérifiez qu’il soit bien configuré. N’oubliez pas que les cybercriminels expérimentés peuvent contourner le SPF (plus de détails dans cette vidéo).
• Mettez en place le DKIM pour une meilleure protection. Ce système peut s’avérer plus complexe mais il en vaut la peine. Encore une fois, vérifiez qu’il soit bien configuré (des idées sur ce que les cybercriminels recherchent).
• Dans l’idéal, adoptez le DMARC puisqu’il corrige la plupart des vulnérabilités exploitables de SPF et DKIM.
• Vérifiez la configuration de vos e-mails entrants.
• Installez des solutions de sécurité compatibles avec les mécanismes modernes d’authentification. Par exemple, vous pouvez installer Kaspersky Security for Mail Servers ou Kaspersky Security for Microsoft Office 365
Conseils