À l’heure actuelle, Mailsploit a ébouriffé la plupart des membres de la communauté de la sécurité des courriels, et pourrait même s « être frayé un chemin jusqu’aux oreilles de nombreux administrateurs informatiques. Bien que la vulnérabilité affecte principalement les clients de messagerie, ces exploits peuvent contourner efficacement DMARC, servant de pouce dans l » œil à la plupart des responsables de la sécurité des courriels qui travaillent depuis quelques années à l’amélioration et au déploiement de ces méthodes d’authentification améliorées.
Essentiellement, cet ensemble d’exploits repose sur l’utilisation de texte encodé qui est décodé par la plupart des clients de messagerie et des applications de messagerie Web. Lorsque du texte encodé est envoyé dans un champ « de » de l’expéditeur dans un courriel, il peut passer DMARC et d’autres mesures d’authentification au niveau de la passerelle, puis être décodé au niveau du client pour apparaître comme pratiquement n’importe quelle adresse courriel choisie par l’expéditeur.
Cela permet une usurpation parfaite, car les courriels peuvent passer les normes d’authentification les plus avancées tout en apparaissant aux utilisateurs comme indiscernables des courriels légitimes, même lorsqu’ils surveillent les tactiques d’usurpation les plus avancées couramment utilisées.
Les caractères nuls peuvent également être utilisés pour tromper certains clients de messagerie, car la plupart des clients interprètent les caractères nuls comme la fin d’une chaîne d’affichage, rendant les caractères ajoutés à une adresse d’expéditeur invisibles pour les utilisateurs, créant encore plus d’opportunités d’usurpation.
[cta id= »18654″]
Bien que des règles puissent être établies pour bloquer ou mettre en quarantaine ce type d’adresse d’expéditeur, la plupart des MTA ne l’empêchent pas, et peu d’entre eux peuvent corriger cette vulnérabilité, car elle se produit principalement au niveau du client. Quoi qu’il en soit, le bogue a été signalé et finalement trié par la plupart des organisations de développeurs pendant des mois, y compris Apple, Microsoft, Opera et AOL Mail.
En fin de compte, les développeurs de clients de messagerie n’ont pas complètement respecté les normes définies pour la rédaction de courriels, et ces raccourcis ont créé des vulnérabilités que les attaquants malveillants peuvent exploiter. Ce n’est pas entièrement de leur faute, cependant, car ces normes ne sont pas clairement établies comme obligatoires, et la racine de l’exploit – RFC-1342 – a été développée en 1992 (!). Cette vulnérabilité d’entrée de gamme permet également d’exploiter d’autres vulnérabilités, comme l’exécution de scripts malveillants dans des applications de messagerie Web et plus encore, où le code peut être injecté après la livraison et faire des ravages sur l’appareil d’un utilisateur cible.
Mailsploit est-il un « mailgeddon »? Un moment de panique? Probablement pas. Cependant, cela est plus préoccupant : si une vulnérabilité majeure comme celle-ci est signalée et non traitée par les grandes organisations clientes de messagerie pendant des mois, quelles autres vulnérabilités ne sont pas corrigées et quels autres problèmes non signalés persistent pour entraîner des exploits et des attaques d’ingénierie sociale encore plus importants, comme la compromission des courriels d’entreprise?
