Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

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

« La faute à la RFC ! »
Internet 6 min
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 (potus@whitehouse.gov), 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.

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.

Mailsploit iOSMailsploit iOSMailsploit iOS
Sur iOS, une variante permet de totalement masquer l'adresse réelle d'envoi (ici demo@mailsploit.com)

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 ».

thunderbird mailsploit

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.

40 commentaires
Avatar de levhieu INpactien
Avatar de levhieulevhieu- 05/12/17 à 09:05:18

Combinez ça avec un corps de message qui contient un lien avec des caractères unicode pris parmi ceux qui ressemblent fortement à certains caractères ASCII, bingo

Avatar de CryoGen Abonné
Avatar de CryoGenCryoGen- 05/12/17 à 09:20:41

On va de nouveau avoir les mails Bill Gates :dd:

Avatar de Jarodd INpactien
Avatar de JaroddJarodd- 05/12/17 à 09:27:44

Tout ça pour nous montrer que Guénaël reçoit des e-mails de Trump, quelle immaturité :fumer:

Avatar de raphmar Abonné
Avatar de raphmarraphmar- 05/12/17 à 09:31:06

Sous Thunderbird, si je clique sur 'Afficher la source' du mail je vois bien :
 
From: "=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=0A=00?=" <=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=0A=00?=@mailsploit.com>

Donc ça doit pas être compliqué d'afficher la vraie source.
Quelqu'un sait si Thunderbird se bouge sur ce point ?

Edit: ah super dans le tableau fournit sur son site, c'est inscrit "won't fix"...

Édité par raphmar le 05/12/2017 à 09:34
Avatar de Ricard INpactien
Avatar de RicardRicard- 05/12/17 à 09:37:34

Ca me rappelle quand je faisais ça via Telnet, pour faire flipper les collègues en leur envoyant des mails d'insultes qui venaient du patron.... :francais:

Avatar de Vekin Abonné
Avatar de VekinVekin- 05/12/17 à 09:39:13

Oui, c'est regrettable... Peut-être y a-t-il moyen en modifiant un paramètre ou via une extension ?

Avatar de WereWindle INpactien
Avatar de WereWindleWereWindle- 05/12/17 à 09:41:05

Ricard a écrit :

Ca me rappelle quand je faisais ça via Telnet, pour faire flipper les collègues en leur envoyant des mails d'insultes qui venaient du patron.... :francais:

voila, j'allais dire que quand j'étais étudiant (début des années 2000), j'avais un petit soft pour envoyer des mails avec des adresses bidon et un pote savait également le faire par Telnet comme tu dis :mdr:

ça nous rajeunit pas :phiphi:

Cela dit, je suppose que le cas présent ne repose pas sur le même principe, si ?

Avatar de secouss Abonné
Avatar de secousssecouss- 05/12/17 à 09:42:27

Marrant ! Sur windows phone c'est corrigé il semble (outlook sur windows phone)

il met l'adresse entre " " et quand tu clique tu retrouve l'adresse de mailsploit en clair, demo@mailsploit.com

Avatar de raphmar Abonné
Avatar de raphmarraphmar- 05/12/17 à 09:42:54

Oui c'est ce que je me dis, doit bien y avoir quelqu'un capable de faire un petit plugin qui rajoute une ligne dans l'entête...

Après j'aimerais bien comprendre pourquoi ils ne veulent pas régler ce point, ils ont peut être une raison ? et la connaître permettrait d'en discuter, mais j'ai absolument rien trouvé sur le sujet (pas vue d'issue sur github non plus).

Avatar de Vekin Abonné
Avatar de VekinVekin- 05/12/17 à 09:48:23

Sur le site, il est noté :

Two vendors (Mozilla and Opera) said they won’t fix the bug (they consider it to be a server-side problem) (...)

Je ne vois pas en quoi c'est un problème du côté du serveur, alors que le problème se situe clairement dans l'affichage de l'adresse de l'expéditeur :fumer:

Il n'est plus possible de commenter cette actualité.
Page 1 / 4