La faille Mailsploit

Le développeur et chercheur en sécurité Sabri Haddouche a récemment découvert une faille dans la visualisation des e-mails dont l’objectif est l’usurpation de l’adresse email de l’expéditeur ou l’exécution de code malveillant. Il a averti les principaux éditeurs de clients de messagerie, les premiers concernés, et après trois mois, l’a finalement publiée, il l’a nommée Mailsploit.

Pour des raisons historiques, les en-têtes des messages ne peuvent contenir que des caractères ASCII. Or l’ASCII n’intègre aucun caractère des langues étrangères à l’anglais (accent, cédille ou caractère asiatique par exemple). Pour outrepasser cette limite, une solution technique d’encodage a été trouvée, elle est documentée dans la RFC1342. Elle est surtout utilisée pour encoder le sujet des emails.

Elle consiste en une syntaxe qui précise :
– Le jeu de caractères ou charset (ex: utf-8),
– La méthode d’encodage (ex: base-64),
– La chaîne de caractères encodée.

Voici un exemple :

Les caractères « =? » et « ?= » indique le début et la fin de la chaine. Les jeux de caractères autorisés sont ceux indiqués dans la RFC1341 – 7.1. L’encodage peut être de 2 types : « b » pour Base-64, et « q » pour Quoted-printable. Enfin la chaîne encodée est, dans notre exemple, « éric et françois » que nous avons généré grâce à l’utilitaire ‘base64’ sous GNU/linux :

echo "éric et françois" |base64 -> w6lyaWMgZXQgZnJhbsOnb2lzCg==

Pour générer une chaîne en quoted-printable sous GNU/Linux, vous pouvez utiliser le petit script créé par Jeff Jarmoc :

qp "éric et françois" -> =C3=A9ric et fran=C3=A7ois

Cette méthode globale d’encodage est prise en compte par les clients de messagerie. Ceux-ci savent interpréter puis décoder ces chaînes et ainsi les intégrer dans les en-têtes des messages reçus.

La faille Mailsploit consiste à exploiter cet encodage pour faire passer des caractères spéciaux qui modifient la façon dont le champ indiquant l’émetteur (« From ») sera perçu par le client de messagerie, par exemple les caractères « null » (« =00 » en quoted-printable) ou saut de ligne (« =0A » en quoted-printable).

Certains clients de messagerie (que Sabri Haddouche avec l’aide de la communauté a listé ici) ne gèrent pas correctement ces caractères et ont donc des comportements inattendus. La plupart du temps, la faille permet de cacher l’expéditeur réel et d’en afficher un autre. Dans les pires des cas (indiqués dans la colonne « XSS/Code injection » dans le tableau précité), il est possible de faire exécuter du code inclus dans la chaîne par le client.

Voici un exemple de « From » modifié pour utiliser la faille :

=?utf-8?b?cHJlc2lkZW50QGVudHJlcHJpc2UuY29tCg==?==?utf-8?Q?=00=0A?= <demo@mailsploit.com>

que nous pouvons décoder en :

president@entreprise.comn <demo@mailsploit.com>

Les clients de messagerie impactés arrêteront l’affichage de l’adresse expéditrice au «  » (caractère null) ou « n » (saut de ligne) cachant ainsi le véritable émetteur « demo@mailsploit.com ». Le destinataire ne verra donc que « president@entreprise.com » en émetteur et risque de traiter le message avec moins de prudence qu’avec un expéditeur inconnu.

Du côté d’Altospam, nous ne pouvons bloquer le principe d’encodage des en-têtes, il est régulièrement utilisé dans les messages légitimes et fait partie de la RFC. Par contre, nous y appliquons plusieurs vérifications et notamment au « From », à la recherche de code malicieux. Nous avons profité de cette alerte pour améliorer encore nos contrôles. Toutefois cette faille est et reste un problème du client de messagerie, qui est censé vérifier le formatage correct des en-têtes des messages reçus.

La plupart des informations de cet article sont issus du site www.mailsploit.com qui présente et explicite la faille.