Lettres kobold : les dangers des e-mails HTML

(lutrasecurity.com)

2 points par GN⁺ 2024-04-05 | 1 commentaires | Partager sur WhatsApp

Lettres kobold

Les personnes qui doivent gérer techniquement les e-mails HTML ont probablement déjà connu des moments où elles ont envie de quitter leur emploi ou de mettre le feu à tous les clients mail, à cause de leurs implémentations incohérentes.
Les e-mails HTML ne sont pas seulement une source de frustration, ils peuvent aussi représenter un grave risque de sécurité.
Imaginons que votre responsable transfère un e-mail demandant d’effectuer un virement important. Comme vous avez déjà entendu parler des arnaques au président, vous vérifiez que l’e-mail provient bien de votre responsable.
L’e-mail vient bien de votre responsable et, si c’est la pratique dans votre entreprise, il peut même être signé de manière chiffrée.
Pourtant, vous n’êtes toujours pas totalement sûr et vous appelez votre responsable pour confirmer l’authenticité du message.
Si votre responsable confirme, vous effectuez le virement.
Mais si ce n’était pas une arnaque, cet article s’arrêterait ici.

Thunderbird

Ce problème a été signalé à Mozilla le 5 mars 2024, et la date de publication prévue ainsi qu’un brouillon de la section suivante ont été transmis à Mozilla le 20 mars 2024.
Des mesures d’atténuation possibles ont été discutées, mais leur mise en œuvre n’est prévue que plus tard.
Dans Thunderbird, l’exploitation est simple. Thunderbird entoure l’e-mail avec `

` et ne modifie rien d’autre.

Lorsqu’un e-mail est transféré, le message cité est enveloppé dans un autre `

`, ce qui le fait descendre d’un niveau dans le DOM.

En tenant compte de cela, on obtient la preuve de concept suivante :


      .kobold-letter {
        display: none;
      }
      .moz-text-html>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.

L’e-mail contient un texte toujours visible et un texte masqué avec display: none;.
Une fois l’e-mail transféré, le texte caché devient soudainement visible, mais uniquement pour le nouveau destinataire.

Outlook Web

Ce problème a été signalé à Microsoft le 5 mars 2024, et la date de publication prévue ainsi qu’un brouillon de la section suivante ont été transmis à Microsoft le 20 mars 2024.
Le 26 mars 2024, Microsoft a décidé de ne pas prendre de mesure immédiate et a clôturé le rapport.
Dans Outlook Web (OWA), la situation est un peu plus complexe. L’e-mail est entouré de `

`, mais le nom exact de la classe peut changer.

Pour éviter que le CSS de l’e-mail n’affecte les styles du webmail, Outlook préfixe tous les id et classes de l’e-mail par x_ et ajuste le CSS en conséquence.
En tenant compte de cela, on obtient la preuve de concept suivante :


      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.

Lorsque l’e-mail est affiché dans OWA, le CSS ressemble à ceci :

Après le transfert de l’e-mail, la lettre kobold est entourée d’un `` supplémentaire et le CSS est de nouveau mis à jour.

Gmail

Ce problème a été signalé à Google le 5 mars 2024, et la date de publication prévue ainsi qu’un brouillon de la section suivante ont été transmis à Google le 20 mars 2024.
Gmail n’est techniquement pas vulnérable aux lettres kobold, car il supprime tous les styles lors du transfert d’un e-mail.
Lors du transfert d’un e-mail, la lettre kobold masquée en CSS devient automatiquement visible jusqu’à la suppression du CSS.

Recherches antérieures

Le fait que cela soit possible n’a rien de surprenant ni de nouveau.
Des problèmes similaires ont déjà été signalés par le passé.

Perspectives

Les utilisateurs peuvent atténuer les lettres kobold en désactivant complètement les e-mails HTML ou en les affichant dans un mode restreint.
Côté clients mail, il est difficile de mettre en œuvre des mesures d’atténuation. Empêcher l’usage de `` pourrait résoudre le problème, mais cela risquerait de casser de nombreuses solutions déjà présentes dans l’écosystème e-mail.
Malheureusement, il est peu réaliste d’espérer que les clients mail mettent en place des protections robustes dans un avenir proche.

L’avis de GN⁺

Cet article montre la vulnérabilité des e-mails HTML et décrit en particulier l’attaque des « lettres kobold », dans laquelle le contenu peut changer lorsqu’un e-mail est transféré. C’est une information importante qui sensibilise les utilisateurs à la sécurité.
Il montre que des failles de sécurité peuvent apparaître selon la manière dont les clients mail traitent le CSS, et appelle à la vigilance aussi bien des utilisateurs que des développeurs.
Ces attaques sont particulièrement dangereuses parce qu’elles semblent provenir d’une source de confiance pour l’utilisateur. Cela souligne la nécessité de rester constamment vigilant dans les communications par e-mail.
D’un point de vue technique, les développeurs de clients mail doivent améliorer la manière dont le CSS est traité afin d’empêcher ce type d’attaque. Cependant, cela peut poser des problèmes de compatibilité avec les conceptions d’e-mails existantes, d’où l’importance de trouver un bon équilibre.
Cet article ne porte pas sur une nouvelle technologie ni sur l’open source, mais il présente des éléments à prendre en compte lors de l’adoption de technologies liées à la sécurité des e-mails. Les développeurs de clients mail doivent chercher des moyens de renforcer la sécurité des utilisateurs tout en préservant l’utilisabilité.

1 commentaires

GN⁺ 2024-04-05

Commentaires Hacker News

« However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money. »
- Ce commentaire souligne que, lorsqu’un doute apparaît à propos d’une demande de virement reçue par email, il ne faut pas simplement demander « est-ce vous qui avez envoyé cet email ? », mais poser une question plus précise comme « voulez-vous vraiment que cet argent soit viré ainsi ? ». Selon lui, ce type d’échange augmenterait fortement les chances de faire échouer l’attaque. Il fait aussi remarquer que le scénario d’attaque décrit dans l’article exige des circonstances très spécifiques et limitées, et exprime des doutes quant à la probabilité réelle de succès d’une attaque aussi complexe.
The other day I was discussing the design for an "update" email that our designer was putting together...
- Ce commentaire partage une expérience liée au design d’emails. Il critique le fait qu’à cause de l’en-tête graphique conçu par le designer, il fallait faire défiler l’écran pour voir l’objet, et se dit surpris de voir qu’un email transféré passe de la version mobile à la version desktop. Il critique l’usage même du CSS dans les emails comme étant inutile et se plaint qu’une solution simple de balisage texte, comme le Markdown, ne se soit toujours pas imposée.
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...
- Ce commentaire défend l’idée d’utiliser le Markdown, sans HTML inline, ou un balisage texte simple similaire à la place du HTML dans les emails. Cela permettrait aux clients mail de décider plus facilement s’ils doivent afficher le message en texte enrichi ou en texte brut, tout en couvrant l’essentiel des besoins de mise en forme des utilisateurs. Il estime que le HTML avancé employé dans les emails marketing n’a pas vraiment d’importance.
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...
- Ce commentaire plaisante en disant que le vrai risque pour une organisation est que le développeur chargé de générer des emails HTML finisse par devenir fou à cause des différents moteurs de rendu d’Outlook, tout en ajoutant que ce type d’attaque par email reste intéressant.
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?
- Ce commentaire propose de résoudre le problème en n’autorisant pas les stylesheets et en limitant la mise en forme aux seuls attributs de style inline sur les balises. Il avance qu’un mécanisme où le client mail convertirait automatiquement les stylesheets en styles inline pourrait améliorer l’utilisabilité.
HTML in email shouldn't be as big of a nightmare as it is.
- Ce commentaire estime que le HTML dans les emails ne devrait pas être un tel cauchemar. Selon lui, il suffirait que tous les clients mail vérifient s’il s’agit de texte ou de HTML, puis basculent vers un moteur de rendu WebKit dans le cas du HTML pour résoudre facilement le problème. Il se demande si un standard de ce type a déjà été proposé.
Some possible mitigations from the top of my head (maybe ineffective):
- Ce commentaire propose quelques pistes de mitigation contre les attaques par email. Parmi elles : avertir en présence d’éléments cachés, ou encore recalculer l’apparence du message lors d’un transfert et demander une confirmation si le rendu diffère fortement.
When efail came out, I wrote a blogpost about the security risks of HTML mail.
- Ce commentaire mentionne avoir écrit un billet de blog sur les risques de sécurité des emails HTML à la sortie d’efail. Il explique que la spécification du mail HTML est ancienne et comporte très peu de considérations de sécurité, et que des emails HTML sûrs devraient reposer sur un sous-ensemble de HTML. Or, comme personne ne semble avoir défini clairement ce sous-ensemble, les failles de sécurité continuent d’apparaître sans cesse.
This is really clever!
- Ce commentaire salue l’astuce consistant à utiliser le CSS dans un email HTML pour faire apparaître un texte précis uniquement après le transfert du message. Il note que cela pourrait représenter une menace importante pour la fiabilité des emails vérifiés. Il s’interroge aussi sur le fait que les clients mail enveloppent le contenu des emails dans des balises HTML supplémentaires et modifient le CSS ainsi que les noms de classes, et se demande pourquoi ils n’utilisent pas un iframe sandboxé pour le rendu des emails HTML.