Mailsploit : une technique facilite le phishing sur de nombreux clients e-mail

Des bugs dans des clients et interfaces e-mail très utilisés permettent d'afficher une fausse adresse d'expédition, sans éveiller les soupçons du serveur. Une vingtaine d'entre eux seraient encore touchés, dont les clients d'iOS et macOS.

Afficher un e-mail venant de Donald Trump ([email protected]), sans que l'internaute ne puisse voir la vraie adresse d'expédition, voire insérer un contenu dans une page en exploitant une faiblesse de sécurité. C'est l'objet de Mailsploit, une « collection de bugs d'affichage » repérée dans 33 logiciels et webmails, découverte par Sabri Haddouche, chercheur en sécurité chez Wire, une alternative européenne à Signal.

« Le problème se situe au niveau du rendu de l'e-mail, qui t'autorise à afficher n'importe quelle adresse e-mail, même si le message est valide côté serveur. La technique permet d'avoir, dans les entêtes, l'adresse e-mail valide du côté du serveur et d'en afficher un autre du côté du client » nous déclare-t-il.

Une divulgation après trois mois d'attente

Aujourd'hui, le chercheur révèle Mailsploit, sur lequel il travaille depuis le mois d'août. Plusieurs approches existent sur la divulgation de failles de sécurité. D'un côté, il existe les partisans du « full disclosure », soit la publication d'une vulnérabilité, pour forcer les éditeurs touchés à les corriger rapidement. De l'autre, la « divulgation responsable » (responsible disclosure), qui consiste à obtenir la correction avant de divulguer quoi que ce soit.

Nous l'avons constaté sur certains clients mail, dont celui d'iOS : les fausses informations peuvent être reprises sans que la vraie adresse d'expédition ne soit révélée. Selon Sabri Haddouche, des clients comme Courrier de Windows 10, Outlook 2016 ou encore Thunderbird sont affectés par ces erreurs d'interprétation. Les clients et interface web de Gmail, eux, affichent bien l'adresse originelle.

Sur les 33 clients repérés, 32 ont été prévenus il y a au moins trois mois et huit ont apporté un correctif. Du point de vue d'Haddouche, le souci est désormais trop connu pour encore attendre, malgré le nombre d'outils affectés. Il fournit un outil de test de clients e-mail, via les 14 variantes d'exploitation, auxquelles sont sensibles différents clients.

• Tester vos clients e-mail
• Consulter le tableau des clients affectés

L'interprétation de texte non-ASCII en cause

La découverte de la faiblesse a été fortuite. « J'effectuais un test d'intrusion chez Wire. Je me suis rendu compte d'un bug sur iOS, qui faisait en sorte que tu ne pouvais pas cliquer sur un e-mail quand tu le recevais. Il est possible de hasher le nom du mail avec un guillemet au bout. J'ai essayé de travailler un peu dessus pour l'enlever mais je n'ai pas réussi, donc j'ai laissé tomber. C'est resté dans les cartons quelques semaines. J'ai ensuite commencé à vérifier les autres clients e-mail » nous détaille Haddouche.

Il a ensuite adapté la recette à Thunderbird et au client de macOS, chacun avec sa payload (charge utile) propre. Cette partie a été la plus longue. « La plupart des clients réagissent différemment. Certains sont sensibles à certaines payloads. Une payload peut fonctionner pour trois clients, une autre pour cinq clients » détaille-t-il.

Pour ses essais, il a d'abord conçu une charge générique, à même de montrer si un client affiche correctement une chaine de caractères spécifiques. « Si elle était coupée ou si elle était différente, c'est que le client était touché par ce bug. »

Quel est concrètement le souci ? La RFC 1342, une proposition de standard datée de 1992, depuis remplacée par la RFC 2047. Elle fournit une manière d'interpréter du texte non-ASCII dans un champ expéditeur. La plupart des clients e-mail interprètent donc le texte, sans assainir correctement le champ en question, ce qui ouvre la voie à des interactions indésirables.

Haddouche a trouvé deux manières de l'exploiter : du base64 (en débutant l'adresse par =?utf-8?b?[BASE-64]?=) ou du quoted printable (=?utf-8?Q?[QUOTED-PRINTABLE]?=). Via certains caractères, comme NUL, il est ensuite possible de masquer l'adresse réelle d'envoi. Des bugs spécifiques, par exemple sur iOS, peuvent interdire de cliquer sur l'adresse de l'expéditeur pour en apprendre plus.

Sur iOS, une variante permet de totalement masquer l'adresse réelle d'envoi (ici [email protected])

Une exploitation considérée comme aisée

Selon des spécialistes en sécurité, la technique facilite le spam ou le phishing. Pour Guillaume Vassault-Houlière de YesWeHack, « cela évite de compromettre un serveur pour de l'injection mail [...] pour un coût faible ». Une automatisation adéquate permettrait de l'exploiter quelques semaines.

« C'est très simple, bien plus simple que toute autre technique permettant d'obtenir quelque chose de similaire. Il n'y a pas beaucoup de prérequis » appuie Sabri Haddouche. L'envoi passe par un script dédié, non un client e-mail classique. Si chaque client e-mail répond à une payload différente, l'automatisation reste possible, en se fondant par exemple sur le nom de domaine, pour les webmails.

Surtout, les vérifications côté serveur (comme DMARC) n'ont que peu d'intérêt dans ce cas. Il suffit d'envoyer les messages depuis un nom de domaine avec des entrées DKIM et SPF valides pour berner le serveur. Pour lui, l'e-mail provient d'une adresse valide, même si le client en affiche une autre. Le message peut donc passer entre les filets d'un anti-spam qui s'appuierait trop fortement sur ces éléments côté serveur.

Les services contactés n'ont pas encore constaté d'exploitation du problème. Pour Haddouche, pourtant, « ça risque d'être découvert bientôt. Beaucoup d'entreprises sont au courant du bug ».

Des corrections et quelques récompenses

En trois mois, les réactions des services aux contacts du chercheur ont été variées : de la fermeture de ticket sans préavis à la récompense via un programme de bug bounty. « Les meilleurs étaient Opera Mail, qui m'ont répondu que c'est la faute du serveur ! Ils ont tort. Le message s'affiche sur le client, pas le serveur » relève Haddouche.

De grandes entreprises ont d'abord refusé de traiter le souci, avant de consentir à une correction. De plus petits acteurs ont apporté un correctif en quelques minutes. Car si l'exploitation est perçue comme facile, sa correction peut aussi être assez simple. Il reste que des clients, comme ceux de Yahoo, ont des cycles de mise à jour lents, repoussant d'autant une correction. Certaines équipes, comme celle de Thunderbird, refuseraient simplement de s'en occuper.

Le géant russe Mail.ru a été l'un des premiers à s'occuper du sujet, attribuant une récompense au chercheur. D'autres sociétés, comme les Suisses de ProtonMail, ont aussi récompensé la découverte, même si le chercheur se refuse à fournir les montants.

Pour ProtonMail, il ne s'agit pas d'une faille de sécurité, mais bien un problème d'affichage exacerbé sur mobile. L'habitude y est d'afficher le nom de l'expéditeur, sans l'adresse. Les spammeurs mettent fréquemment quelque chose de faux en nom d'utilisateur, comme PayPal, pour tromper l'utilisateur. Heureusement, nous avons beaucoup de moyens de détecter les spammeurs, et généralement les messages sont placés en Indésirables » rappelle Andy Yen, fondateur du service.

Openmailbox était, lui, affecté par une faille de sécurité, type XSS, qui permettait d'introduire du code indésirable. « Le problème a été résolu quelques instants après réception de son message, puis le patch a été déployé quelques dizaines de minutes après correction » nous répond Pierre Barre, administrateur système. Son exploitation aurait tout de même demandé « d'effectuer une attaque particulièrement ciblée », estime-t-il.

Avec cette publication, Sabri Haddouche espère amener les outils encore vulnérables à apporter un correctif, comme l'envisagerait Apple dans l'une des prochaines itérations d'iOS.