Le principe le plus élémentaire en matière de programmation sécurisée est le suivant : n’ayez aucune confiance dans ce que vous prévoyez d’utiliser !
Pourquoi ? Parce que les programmes informatiques utilisent des ressources provenant du monde extérieur, comme des fichiers, des cookies, des commandes vocales, des mots de passe ou une multitude d’autres types de données, et les choses peuvent mal tourner s’ils étaient amenés à ingérer des données qu’ils n’auraient pas dû.
Les programmes peuvent être “empoisonnés” accidentellement, par des incidents au niveau des données qu’ils utilisent, ou bien délibérément par des hackers essayant de les alimenter avec des éléments conçus pour les détruire ou transformer ces derniers, tels des zombies, devenant ainsi des complices malgré eux !
Dans les deux cas, la vie de votre programme informatique revient à se promener dans les bois, en essayant de trouver le champignon comestible à déguster pour le petit déjeuner. Les plus dangereux ont la fâcheuse tendance à paraître totalement inoffensif.
Si votre programme informatique est censé durer dans le temps, il doit impérativement être méfiant par nature, signifiant ainsi que tout doit être considéré comme étant un champignon vénéneux et mortelle, jusqu’à preuve du contraire !
Mailsploit
Les ordinateurs se trouvent maintenant “dans la forêt” et reçoivent des emails depuis environ 45 ans à présent, ainsi votre logiciel de messagerie doit être assez efficace pour considérer chaque email reçu comme un danger mortel.
Les emails se composent de trois parties : le message lui-même, les pièces jointes et toute une série d’en-têtes qui définissent (entre autres choses) à qui l’email doit être envoyé, son objet et son destinataire.
Contrairement aux pièces jointes, dans lesquels on peut trouver toute sorte de format, les en-têtes sont régis par des règles assez strictes, lesquelles doivent faciliter l’identification d’un email avec un en-tête dangereux. L’en-tête De, par exemple, est censé contenir le nom et l’adresse email de l’auteur (ou des auteurs) du message en question.
Cependant, ce fut une surprise d’apprendre qu’une personne avait découvert un moyen d’utiliser des adresses électroniques malveillantes, introduites en douce via l’en-tête De, pour contourner les protections anti-spam et, dans certains cas, déclencher l’exécution de code hostile et arbitraire.
La découverte a été faite par le chasseur de bugs Sabri Haddouche, qui a récemment publié des détails concernant un BWAIN (Bug With An Impressive Name), une erreur de codage qui semble avoir été répétée, encore et encore, par des douzaines de clients de messagerie.
Il a appelé sa découverte Mailsploit:
Les bugs ont été trouvés dans plus de 30 clients de messagerie, y compris les plus connues comme Apple Mail (macOS, iOS et watchOS), Mozilla Thunderbird, divers clients Microsoft email, Yahoo! Mail, ProtonMail et bien d’autres.
Comment protéger ces adresses email ?
Les emails, étant vieux comme le monde, permettent uniquement aux caractères de l’ancien code ASCII d’apparaître dans les en-têtes. Tout va bien si vous voulez envoyer un email et que votre nom est Andrew, mais cela ne va plus si votre nom est André, car le code ASCII ne compte que 128 caractères et “é” n’en fait pas partie !
Avec seulement 128 caractères utilisables et un monde comprenant des noms non-anglais, le standard RFC-1342 a été rédigé en 1992 pour permettre à des caractères exotiques tels que é, ε, э, ainsi qu’à des dizaines de milliers d’autres caractères (y compris l’incontournable “Pile of Poo Emoji”) d’apparaître dans l’en-tête De.
Le standard RFC-1342 décrit une façon d’utiliser les 128 caractères ASCII pour représenter les centaines de milliers de caractères non-ASCII, en utilisant les codages Quoted Printable ou Base64 (André devient Andr=C3=A9 dans Quoted Printable et QW5kcsOp dans Base64).
Un en-tête qui arrive codé de cette manière, doit être décodé avant d’être affiché auprès du destinataire de l’email, afin qu’il puisse voir qu’il a reçu un email en provenance d’André, et non de Andr=C3=A9.
Haddouche semble avoir découvert des clients de messagerie qui faisaient trop confiance :
Malheureusement, la plupart des clients de messagerie et des interfaces web ne nettoient pas correctement la chaîne de caractères après le décodage, entraînant une attaque par usurpation d’adresse email.
Sans ce nettoyage, un cybercriminel peut tenter sa chance, en envoyant toute sorte de payloads malveillantes, au sein de votre logiciel de messagerie via l’en-tête De, à condition que ce dernier ait un wrapper RFC-1342.
Et c’est exactement ce que Haddouche a fait !
Les Attaques
Le bug Mailsploit a eu des conséquences variées sur différentes plateformes.
Douze clients de messagerie ont été jugés vulnérables vis-à-vis d’attaques par injection de code, intégrées en douce dans les wrappers RFC-1342. Hushmail, par exemple, a permis l’usurpation d’adresses email et l’injection de HTML et de JavaScript arbitraires dans son client web, laissant les utilisateurs à la merci d’attaques XSS (Cross-site scripting), lancées à partir de faux emails qui contournaient les protections du DMARC.
Hushmail, de manière remarquablement réactive, a corrigé ce bug le jour même de son signalement !
D’autres n’ont pas été si réactifs et Haddouche a publié un document Google détaillant les fournisseurs concernés, et les réponses suite aux signalements des bugs.
Le problème le plus fréquent découvert, et certainement le plus discuté, a été la capacité de cette attaque à contourner DMARC, une protection anti-usurpation. Si l’en-tête De contient une adresse que l’expéditeur n’est pas autorisé à utiliser, les protections telles que le DMARC sont censées stopper l’acheminement.
Mailsploit peut être utilisé pour transformer une adresse email, qu’un cybercriminel n’est pas autorisé à utiliser, en la plaçant à l’intérieur d’une adresse qu’il est autorisé à utiliser.
Par exemple, partons du principe que vous contrôlez example.org, et que vous voulez faire croire qu’un email provient de example.com.
Votre en-tête malveillant De ressemble à ceci, avant qu’il ne soit codé :
De: fake@example.com\0(fake@example.com)@example.org
Après l’avoir encodé, vous envoyez l’email et le Mail Transfer Agent (MTA) qui le reçoit l’interprète ainsi :
De: <some RFC-1342 encoded data>@example.org
Les vérifications du DMARC montrent que vous êtes autorisé à utiliser example.org, donc l’email n’est pas traité comme un spam (ce comportement est normal et correct). Il envoie l’email dans la boîte de réception de votre victime, et plus tard il l’affichera en utilisant son client de messagerie favori.
Les données codées par RFC-1342 sont ensuite décodées et, si vous avez correctement formaté votre payload malveillante (le formatage correct varie légèrement d’une application à une autre), le client de messagerie destinataire est dupé par l’utilisation de l’adresse fake@example.com dans le champs De de la victime.
Les attaques exploitent généralement les clients de messagerie en incluant des caractères nuls (à savoir, le \0 dans l’exemple ci-dessus), des caractères de retour à la ligne ou une combinaison des deux, ce qui incite les clients de messagerie à rejeter l’intégralité de ce qui suit au niveau de l’en-tête.
La faille dans laquelle s’est engouffrée cette attaque permet au MTA de procéder à l’identification en utilisant un domaine particulier, par contre le logiciel client de messagerie sera dupé et en affichera un autre.
Quoi faire ?
Le contournement du DMARC est intéressant, réel, et utilisé à grande échelle mais doit être repéré facilement par des moteurs anti-spam.
Il est bon de garder à l’esprit que même si le DMARC améliore les choses, il n’a jamais été un espace impénétrable. Il dépend à la fois du SPF et du DKIM, et beaucoup de messages inconnus ne peuvent pas être correctement évalués en raison de paramètres temporaires comme les enregistrements SPF avec une valeur ~all par défaut, alors que beaucoup de faux mails passent également les tests du DMARC sans être inquiétés, car ils proviennent de comptes frauduleux ou piratés sur de véritables serveurs comme Gmail.
Les utilisateurs de clients de messagerie doivent mettre à jour leur logiciel dès que cette dernière sera disponible.
Avis aux programmeurs : ne comptez pas sur d’autres parties du système pour gérer votre code correctement, et si vos entrées peuvent être transformées, zippées ou codées, alors assurez-vous de les nettoyer correctement en fin de processus.
Billet inspiré de Mailsploit: using emails to attack mail software, sur Sophos nakedsecurity.
Mister bricolage
Je ne savais pas que ce genre d’outil pouvait avoir des conséquences néfastes pour les emails.