Lettres kobold : les risques des e-mails HTML
(lutrasecurity.com)- Les kobold letters sont une technique d’attaque qui fait qu’un e-mail HTML semble d’abord inoffensif, puis se transforme en contenu de phishing pour d’autres destinataires après transfert
- Le point clé consiste à exploiter le CSS autorisé par les clients e-mail et les changements de position dans le DOM lors du transfert pour masquer ou réafficher certaines formulations
- Thunderbird et Outlook on the web peuvent faire apparaître des formulations cachées après transfert en raison de la structure du DOM et de la réécriture CSS, tandis que Gmail permet une exposition sous une forme plus simple en supprimant les styles lors du transfert
- Le problème a été signalé à Mozilla, Microsoft et Google le 5 mars 2024 ; Microsoft a clos le dossier sans action immédiate le 26 mars, et Google a confirmé le 9 avril qu’un correctif était en cours
- Les utilisateurs peuvent désactiver les e-mails HTML ou les consulter en mode restreint, mais bloquer `` pourrait casser de nombreux cas d’usage de l’écosystème e-mail existant, ce qui rend une atténuation côté client difficile
Scénario d’attaque et idée clé
- Un e-mail transféré par un administrateur peut d’abord ressembler à un message de demande inoffensif, puis se transformer en requête de phishing pour le nouveau destinataire après le transfert
- Le destinataire voit un expéditeur qu’il connaît, parfois avec une signature cryptographique, et peut être trompé même s’il confirme par téléphone que le message a bien été transféré
- Comme l’administrateur, destinataire initial, n’a pas vu le texte de phishing dans l’e-mail qu’il a transféré, il lui est difficile de soupçonner l’attaque même s’il confirme le transfert
Fonctionnement des kobold letters
- La plupart des clients e-mail autorisent le style CSS dans les e-mails HTML
- Lorsqu’un e-mail est transféré, la position DOM de l’e-mail d’origine change généralement, et l’attaquant applique des sélecteurs CSS en fonction de ce changement
- L’attaquant peut insérer dans l’e-mail des éléments qui apparaissent ou disparaissent selon le contexte
- normalement masqués avec
display: none; - puis affichés après transfert avec une règle comme
display: block !important;lorsque la structure du DOM change
- normalement masqués avec
- Ces éléments restent généralement invisibles puis n’apparaissent que dans certaines situations, ce qui permet notamment des usages malveillants comme le phishing ; c’est pourquoi on les appelle des kobold letters
- L’ensemble des clients e-mail et webmails prenant en charge les e-mails HTML peut être concerné
Fonctionnement dans Thunderbird
- Le problème lié à Thunderbird a été signalé à Mozilla le 5 mars 2024, puis une date de divulgation prévue au 20 mars 2024 et un brouillon ont été transmis
- Des mesures d’atténuation possibles ont été discutées, mais leur mise en œuvre a été repoussée à plus tard
- Thunderbird encapsule les e-mails dans `
` et ne modifie presque rien d’autre
- Lorsqu’un e-mail est transféré, le message d’origine cité se retrouve à nouveau à l’intérieur de `
`, ce qui le fait descendre d’un niveau dans le DOM
- L’exemple de CSS masque
.kobold-letterpar défaut et ne l’affiche que sous la condition.moz-text-html>div>.kobold-letter - Pour la personne qui consulte l’e-mail d’origine, seul le paragraphe toujours visible apparaît, mais pour le destinataire de l’e-mail transféré, le paragraphe jusque-là caché surgit soudainement
- Comme l’attaquant connaît la position relative dans le DOM et contrôle le CSS, il peut masquer ou afficher certaines parties de l’e-mail pour en modifier complètement le contenu
- Si la kobold letter est stylisée comme un overlay, elle peut même remplacer les commentaires ajoutés par la personne qui transfère le message, ce qui élargit encore les possibilités de phishing
Fonctionnement dans Outlook on the web
- Le problème d’Outlook on the web a été signalé à Microsoft le 5 mars 2024, puis une date de divulgation prévue au 20 mars 2024 et un brouillon ont été transmis
- Microsoft a décidé le 26 mars 2024 de ne pas prendre de mesure immédiate et a clos le signalement
- OWA étant un webmail, la situation est plus complexe ; les e-mails sont placés dans des conteneurs comme `
`, mais les noms de classes exacts changent
- Outlook préfixe les id et class par
x_et ajuste aussi le CSS afin que les styles d’un e-mail n’affectent pas l’interface du webmail - Dans l’exemple, le CSS de l’e-mail d’origine est transformé ainsi lors de l’affichage dans OWA
.rps_78fa .x_kobold-letter {display:none}.rps_78fa > div > div > .x_kobold-letter {display:block!important}
- Après transfert, les classes deviennent de nouveau quelque chose comme
x_x_kobold-letter, et le CSS est mis à jour lui aussi - Dans la deuxième règle, le
>entre.rps_78faetdivdisparaît ; il faut donc en tenir compte lorsqu’on construit des sélecteurs complexes - Les ajustements d’OWA n’empêchent pas l’attaque en elle-même, mais imposent des contraintes fastidieuses lorsqu’on veut créer une kobold letter fonctionnant simultanément sur plusieurs clients
Fonctionnement dans Gmail
- Le problème lié à Gmail a été signalé à Google le 5 mars 2024, puis une date de divulgation prévue au 20 mars 2024 et un brouillon ont été transmis
- Google a confirmé le 9 avril 2024 qu’un correctif était en cours
- Gmail supprime tous les styles lorsqu’un e-mail est transféré ; il n’est donc pas techniquement vulnérable aux kobold letters au sens strict, où des sélecteurs CSS changent l’affichage selon le contexte
- Mais une attaque plus simple reste possible
- dans l’e-mail d’origine, la kobold letter est masquée avec du CSS
- lors du transfert, la suppression des styles fait automatiquement apparaître l’élément caché
- Cette méthode est limitée, et l’effet inverse — visible à l’origine puis masqué après transfert — n’est pas possible
- Comme Gmail ne supprime pas encore le CSS dans l’éditeur avant l’envoi, la personne qui transfère le message ne voit toujours pas le paragraphe caché pendant qu’elle rédige son commentaire
- Dans l’e-mail final, les styles étant supprimés, le deuxième paragraphe apparaît
- Si Gmail supprimait le CSS dès l’étape de l’éditeur, la personne qui transfère pourrait repérer l’attaque avant l’envoi, ce qui atténuerait le problème
Cas similaires antérieurs et différences
- Le fait que le CSS dans les e-mails HTML puisse modifier le contenu d’une réponse ou d’un transfert n’est pas nouveau
- Des problèmes similaires avaient déjà été signalés par le passé
- La particularité des kobold letters est de se concentrer sur un scénario d’attaque précis et d’examiner plusieurs clients e-mail ensemble
- Il faut discuter des risques des e-mails HTML et des trade-offs liés à leur atténuation
Mesures d’atténuation et limites
- Les utilisateurs peuvent désactiver complètement les e-mails HTML ou les consulter dans un mode restreint comme le « plain HTML » de Thunderbird
- Les clients e-mail pourraient résoudre le problème en bloquant l’usage de ``, mais cela risquerait de casser de nombreux cas d’usage existants dans l’écosystème e-mail
- Une implémentation comme Gmail, qui supprime les styles lors du transfert, peut constituer un compromis permettant les newsletters d’entreprise stylisées tout en limitant les risques liés aux e-mails HTML
- Il n’est pas réaliste d’espérer que les clients e-mail déploient rapidement des mesures d’atténuation fortes dans un avenir proche
- Les utilisateurs doivent prendre conscience des risques des e-mails HTML et adopter eux-mêmes les précautions nécessaires
1 commentaires
Avis de Hacker News
Le passage « malgré tout, n’étant pas sûr, il appelle le responsable pour vérifier que l’e-mail est authentique. Le responsable confirme, alors il effectue le virement » me paraît être une très grosse hypothèse.
En général, on ne demanderait pas vaguement « avez-vous envoyé cet e-mail ? », mais plutôt quelque chose de plus précis comme « vous me demandez vraiment de virer de l’argent de cette manière ? ». Dans ce cas, le responsable serait évidemment surpris, et il y a de fortes chances que l’attaque soit bloquée pendant cet échange.
C’est un vecteur d’attaque intéressant, mais ses chances de succès réelles me laissent sceptique. L’article décrit une séquence d’événements assez précise et étroite pour que cette attaque fonctionne, et personnellement j’ai du mal à y adhérer.
Je sais que le phishing fonctionne réellement. Mais les personnes susceptibles de se faire piéger par du phishing n’ont pas besoin d’une attaque aussi sophistiquée ; au contraire, si l’attaquant fournit autant d’efforts spécifiques, il risque même de réduire ses chances de succès. Un e-mail de phishing ordinaire aurait déjà de bonnes chances de marcher.
Les informations sur ces dirigeants étaient faciles à trouver sur LinkedIn ou sur le site de l’entreprise, et c’était même l’exemple exact utilisé dans la formation anti-phishing ; malgré cela, ça arrivait quand même, ce qui est assez stupéfiant.
https://www.microsoft.com/en-us/research/publication/why-do-...
L’attaquant pourrait ajouter une phrase du type « Je suis en déplacement en ce moment. Si vous avez un doute, appelez mon téléphone personnel... », puis répondre avec une fausse voix.
Une bonne façon d’atteindre la cible pourrait être une « double transmission ». L’expéditeur joue le rôle d’un employé qui transfère l’e-mail du responsable à quelqu’un proche du personnel administratif ; puis cet employé transfère à nouveau un e-mail apparemment inoffensif, pour un anniversaire ou un avis d’arrêt maladie par exemple. La cible réelle aura alors du mal à identifier l’origine initiale de l’e-mail.
On peut facilement imaginer d’autres manières plus créatives d’abuser de cette « fonctionnalité ». Par exemple, faire transférer un contenu problématique par quelqu’un qui ne se doute de rien, puis s’en servir pour le faire chanter.
Les personnes chargées du traitement ne vont pas appeler leur manager à chaque demande de paiement reçue par e-mail, surtout si le montant est faible et ne nécessite pas d’approbation préalable.
Je me souviens que Google s’était déjà fait avoir par une arnaque où de l’argent avait été versé à quelqu’un alors qu’aucun travail réel n’avait été effectué. Ce cas impliquait de fausses factures, mais le principe est le même.
Il y a quelques jours, je regardais le design d’un e-mail de « mise à jour » créé par un designer, et à cause d’un énorme en-tête graphique absurde placé tout en haut, on ne voyait même pas le texte du sujet de l’e-mail sans faire défiler.
Puis j’ai transféré une autre version pour demander un retour, et il a soudain semblé paniqué en disant que la police paraissait un peu plus petite : « Ah, quand on le transfère, il est converti en version desktop au lieu de la version mobile ! »
Je l’ai regardé, incrédule. C’est un e-mail : qu’est-ce que ça veut dire, une « version desktop » et une « version mobile » ? Comment est-ce possible ? Que signifie « converti » ? C’est censé être simplement copié. Le simple fait que ça « casse » quand on le transfère montre à quel point cette approche est idiote. Pourquoi diable mon e-mail devrait-il contenir du CSS ?
Si l’on veut juste exprimer quelque chose comme l’italique, il aurait fallu adopter depuis longtemps une approche bien plus simple, comme Markdown. Le fait que ce ne soit toujours pas le cas montre à quel point il y a peu d’intérêt pour réellement améliorer la situation. Tout ça sert uniquement à satisfaire des exigences corporate bizarres qui veulent mettre des logos et des bannières partout. Les e-mails HTML sont vraiment absurdes.
[1] https://www.rfc-editor.org/rfc/rfc1896.txt
Cela fait longtemps que je soutiens que, pour le texte enrichi dans les e-mails, il faudrait utiliser à la place du HTML une forme de Markdown sans HTML inline, ou un balisage texte simple similaire.
Ainsi, un client e-mail pourrait facilement décider de l’afficher en texte enrichi ou simplement en texte brut, tout en prenant en charge la plupart des mises en forme dont les utilisateurs ordinaires ont besoin : gras, italique, citations, images inline, blocs de code, titres, etc.
Ce ne serait pas idéal pour les e-mails marketing qui utilisent du HTML très avancé, mais je ne pense pas qu’il faille se préoccuper de ce cas d’usage.
https://en.wikipedia.org/wiki/Enriched_text
https://www.rfc-editor.org/rfc/rfc1896.html
Il n’y a même pas encore de prise en charge des hyperliens dans les e-mails, et quelqu’un a récemment essayé de corriger cela.
https://pastebin.com/kHQs50xm
Le vrai risque pour une organisation, c’est que le développeur à qui on a confié la génération d’e-mails HTML devienne fou, s’enferme dans la salle serveurs et casse tout le matériel en hurlant « pourquoi le rendu d’Outlook est différent ».
Plus sérieusement, c’est une vulnérabilité très intéressante.
Est-ce qu’on ne pourrait pas corriger ça en interdisant les feuilles de style et en n’autorisant que les attributs style en ligne sur les balises ?
Pour l’ergonomie, les clients mail pourraient aussi ajouter une étape automatique qui « compile » toutes les feuilles de style en styles en ligne.
Comme ça, seuls les sélecteurs CSS avancés, par exemple
hover, casseraient, et je ne suis pas sûr qu’on en ait vraiment besoin.Les pseudo-classes et les media queries ne fonctionneraient pas, mais elles peuvent présenter un risque de sécurité et ne sont pas prises en charge non plus par les principaux clients mail : https://www.caniemail.com/features/css-at-media/.
En plus, si on supprime tous les attributs
style, on tue aussi l’optimisation mobile et le mode sombre, parce que les media queries ne peuvent pas être mises en ligne.En général, les styles par défaut/desktop sont déjà compilés et mis en ligne, et on met des sélecteurs de media queries dans une balise
styledans leheadpour rendre la lecture plus confortable sur mobile.Vraiment ingénieux.
Le principe, c’est qu’à cause du CSS des e-mails HTML, un texte peut n’apparaître qu’après le transfert du message. C’est une menace importante pour la fiabilité des e-mails vérifiés.
Les exemples avec Thunderbird, Outlook et Gmail sont présentés, et c’est un excellent travail.
Comme je lis tous mes mails dans mutt, officiellement, c’est « le problème des autres ».
Donc, pour râler sur autre chose : la date de signalement à Mozilla est indiquée comme 05.03.2024. Je suis d’accord pour dire que les dates en little-endian ont plus de sens que les dates américaines en middle-endian.
Mais, pour un technicien, ne pas utiliser le format de date ISO 8601, 2024-03-05, avec ou sans tirets, c’est une erreur :)
Le little-endian a au moins pour lui d’être l’inverse de la manière dont on écrit tous les autres nombres, mais le middle-endian est juste délirant. Ce qui explique évidemment pourquoi les Américains l’utilisent.
On voit que certains des clients mail mentionnés enveloppent le contenu du mail dans des balises HTML supplémentaires et modifient le CSS ainsi que les noms de classes.
Je me demande pourquoi les clients mail n’utilisent pas une iframe sandboxée pour rendre les e-mails HTML. Est-ce qu’il y aurait encore un risque de sécurité ?
La personne qui transfère peut vouloir ajouter du texte à l’e-mail, donc c’est un comportement prévisible.
En revanche, si l’e-mail contenait un lien vers un site web et que l’iframe sandboxée n’autorisait pas JavaScript, ce contexte de sécurité se propageait jusqu’à la page ouverte en cliquant sur le lien dans l’iframe, et le site web ne pouvait pas utiliser JS.
La solution était
allow-popups-to-escape-sandbox, donc je ne vois pas pourquoi ça ne fonctionnerait pas aujourd’hui.C’est la solution classique qui consiste à amputer un membre pour soigner une égratignure. Le problème, c’est la mauvaise standardisation de l’e-mail, qui a permis à ce genre de bidouilles de dominer.
HTML dans son ensemble est vulnérable à ce type de préoccupations. Malgré tout, beaucoup d’e-mails utilisent HTML sans problème. Cet article se lit comme une frustration personnelle face à quelque chose rencontré dans la nature, présentée comme un problème de sécurité.
Les atténuations possibles qui me viennent à l’esprit sont les suivantes, mais elles pourraient ne pas être efficaces : afficher un avertissement bien visible sur les éléments masqués, randomiser le nombre de div englobantes côté réception comme côté envoi, calculer à quoi ressemblera réellement le message une fois transféré et demander confirmation si le résultat diffère fortement.
Ou bien l’approche inverse pourrait être plus efficace, puisqu’elle ne nécessite pas l’aide d’autres clients.
Il suffit de corriger en « pourquoi l’e-mail est un risque pour les organisations ».
Cet article présente un vecteur d’attaque propre aux e-mails HTML, mais la plupart des attaques par e-mail peuvent facilement être transposées à WhatsApp, Slack, Jira, Zoom ou à n’importe quel outil que les gens utilisent pour communiquer avec l’extérieur.