Kobold Letters: Die Gefährlichkeit von HTML-E-Mails
(lutrasecurity.com)- Kobold Letters sind eine Angriffstechnik, bei der HTML-E-Mails zunächst harmlos wirken, sich nach dem Weiterleiten für andere Empfänger jedoch in Phishing-Inhalte verwandeln
- Der Kern besteht darin, das von E-Mail-Clients erlaubte CSS und die sich beim Weiterleiten ändernde DOM-Position zu nutzen, um bestimmte Formulierungen zu verbergen oder wieder einzublenden
- Thunderbird und Outlook on the web können aufgrund ihrer DOM-Struktur und der Art der CSS-Umschreibung nach dem Weiterleiten zuvor verborgene Formulierungen anzeigen; bei Gmail ist durch das Entfernen von Styles beim Weiterleiten eine einfachere Form der Offenlegung möglich
- Mozilla, Microsoft und Google wurde das Problem am 5. März 2024 gemeldet; Microsoft schloss den Fall am 26. März ohne Sofortmaßnahme, Google bestätigte am 9. April, an einer Behebung zu arbeiten
- Nutzer können HTML-E-Mails deaktivieren oder in einem eingeschränkten Modus anzeigen, aber das Blockieren von `` könnte viele bestehende Anwendungsfälle im E-Mail-Ökosystem zerstören, weshalb eine Abmilderung auf Client-Seite nicht einfach ist
Angriffsszenario und Kernidee
- Eine von einem Administrator weitergeleitete E-Mail kann zunächst wie eine harmlose Anfrage aussehen und sich nach dem Weiterleiten für den neuen Empfänger in eine Phishing-Aufforderung verwandeln
- Der Empfänger kennt den Absender, in manchen Fällen ist sogar eine kryptografische Signatur vorhanden, und selbst eine telefonische Bestätigung der Weiterleitung kann zur Täuschung nicht ausreichen
- Da der ursprüngliche Empfänger, also der Administrator, die Phishing-Formulierung in der von ihm weitergeleiteten E-Mail nicht gesehen hat, ist der Angriff selbst bei bestätigter Weiterleitung schwer zu erkennen
Funktionsweise von Kobold Letters
- Die meisten E-Mail-Clients erlauben in HTML-E-Mails CSS-Styling
- Wird eine E-Mail weitergeleitet, ändert sich gewöhnlich die DOM-Position der ursprünglichen E-Mail, und der Angreifer wendet CSS-Selektoren gezielt anhand dieser Veränderung an
- Der Angreifer kann Elemente in die E-Mail einfügen, die je nach Kontext erscheinen oder verschwinden
- Normalerweise mit
display: none;verborgen - Nach dem Weiterleiten durch Regeln wie
display: block !important;sichtbar
- Normalerweise mit
- Solche Elemente sind normalerweise unsichtbar und erscheinen nur in bestimmten Situationen; weil sie sich für Phishing und Ähnliches missbrauchen lassen, werden sie Kobold Letters genannt
- Betroffen sein können allgemein E-Mail-Clients und Webmail-Dienste, die HTML-E-Mails unterstützen
Verhalten in Thunderbird
- Das Thunderbird-bezogene Problem wurde Mozilla am 5. März 2024 gemeldet; am 20. März 2024 wurden der geplante Offenlegungstermin und ein Entwurf übermittelt
- Mögliche Gegenmaßnahmen wurden diskutiert, die Umsetzung soll aber auf später verschoben werden
- Thunderbird umschließt E-Mails mit `
` und verändert sie ansonsten kaum
- Beim Weiterleiten wird die zitierte ursprüngliche E-Mail erneut in `
` eingefügt und im DOM eine Ebene nach unten verschoben
- Das Beispiel-CSS blendet
.kobold-letterstandardmäßig aus und zeigt es nur unter der Bedingung.moz-text-html>div>.kobold-letteran - Wer die ursprüngliche E-Mail ansieht, sieht nur den immer sichtbaren Absatz; beim Empfänger der weitergeleiteten E-Mail erscheint der zuvor verborgene Absatz plötzlich
- Da der Angreifer die relative Position im DOM kennt und das CSS steuern kann, kann er Teile der E-Mail verbergen oder anzeigen und so den gesamten Inhalt verändern
- Wenn ein Kobold Letter wie ein Overlay gestaltet wird, kann es sogar Kommentare ersetzen, die der Weiterleitende der ursprünglichen Mail hinzugefügt hat, was zusätzliche Phishing-Möglichkeiten schafft
Verhalten in Outlook on the web
- Das Problem in Outlook on the web wurde Microsoft am 5. März 2024 gemeldet; am 20. März 2024 wurden der geplante Offenlegungstermin und ein Entwurf übermittelt
- Microsoft entschied am 26. März 2024, keine sofortige Maßnahme zu ergreifen, und schloss den Bericht ab
- Da OWA ein Webmail-Dienst ist, ist die Lage komplexer; E-Mails werden in Container wie `
` eingefügt, aber die genauen Klassennamen ändern sich
- Outlook versieht id- und class-Namen mit dem Präfix
x_und passt auch das CSS entsprechend an, damit E-Mail-CSS die Webmail-UI-Styles nicht beeinflusst - Im Beispiel wird das CSS der ursprünglichen E-Mail bei der Darstellung in OWA wie folgt umgewandelt
.rps_78fa .x_kobold-letter {display:none}.rps_78fa > div > div > .x_kobold-letter {display:block!important}
- Nach dem Weiterleiten ändern sich die Klassen erneut zu etwas wie
x_x_kobold-letter, und auch das CSS wird wieder aktualisiert - In der zweiten Regel verschwindet das
>zwischen.rps_78faunddiv; das muss beim Erstellen komplexer Selektoren berücksichtigt werden - Diese Anpassungen in OWA verhindern den Angriff nicht grundsätzlich, stellen aber lästige Einschränkungen dar, wenn ein Kobold Letter gleichzeitig in mehreren Clients funktionieren soll
Verhalten in Gmail
- Das Gmail-Problem wurde Google am 5. März 2024 gemeldet; am 20. März 2024 wurden der geplante Offenlegungstermin und ein Entwurf übermittelt
- Google bestätigte am 9. April 2024, an einer Behebung zu arbeiten
- Gmail entfernt beim Weiterleiten alle Styles und ist deshalb für Kobold Letters im engeren technischen Sinn, bei denen CSS-Selektoren die Sichtbarkeit kontextabhängig ändern, nicht anfällig
- Ein einfacherer Angriff ist jedoch möglich
- In der ursprünglichen E-Mail wird das Kobold Letter per CSS verborgen
- Beim Weiterleiten werden die Styles entfernt, wodurch das verborgene Element automatisch sichtbar wird
- Diese Methode ist eingeschränkt; das umgekehrte Verhalten, also im Original sichtbar und nach dem Weiterleiten verschwunden, ist damit nicht möglich
- Da Gmail im Editor vor dem Versand das CSS noch nicht entfernt, bleibt der verborgene Absatz auch während des Verfassens eines Kommentars durch den Weiterleitenden unsichtbar
- In der resultierenden E-Mail werden die Styles entfernt, wodurch der zweite Absatz erscheint
- Würde Gmail das CSS bereits im Editor entfernen, könnte der Weiterleitende den Angriff vor dem Versand entdecken, was das Problem abmildern würde
Frühere ähnliche Fälle und Unterschiede
- Dass sich Antwort- oder Weiterleitungsinhalte in HTML-E-Mails per CSS verändern lassen, ist nicht neu
- Ähnliche Probleme wurden bereits früher gemeldet
- Der Unterschied bei Kobold Letters liegt darin, dass sie auf ein bestimmtes Angriffsszenario fokussieren und mehrere E-Mail-Clients gemeinsam betrachten
- Es braucht eine Diskussion über die Risiken von HTML-E-Mails und die Trade-offs bei ihrer Abmilderung
Gegenmaßnahmen und Grenzen
- Nutzer können HTML-E-Mails vollständig deaktivieren oder sie in einem eingeschränkten Modus wie „plain HTML“ in Thunderbird anzeigen
- Wenn E-Mail-Clients die Verwendung von `` unterbinden würden, ließe sich das Problem lösen, doch das könnte viele bestehende Anwendungsfälle im E-Mail-Ökosystem kaputtmachen
- Eine Umsetzung wie bei Gmail, die beim Weiterleiten Styles entfernt, könnte ein Kompromiss sein, der gestaltete Unternehmens-Newsletter erlaubt und zugleich die Risiken von HTML-E-Mails begrenzt
- Dass E-Mail-Clients in naher Zukunft starke Gegenmaßnahmen umsetzen, ist realistischerweise nicht zu erwarten
- Nutzer sollten sich der Risiken von HTML-E-Mails bewusst sein und selbst die nötigen Vorsichtsmaßnahmen treffen
1 Kommentare
Hacker-News-Kommentare
Der Teil „Ich bin mir trotzdem nicht sicher, rufe den Manager an und frage, ob die E-Mail echt ist. Der Manager bestätigt es, also überweise ich das Geld“ wirkt wie eine sehr große Annahme.
Normalerweise würde man nicht so vage fragen wie „Haben Sie diese E-Mail geschickt?“, sondern konkreter: „Soll ich wirklich auf diese Weise Geld überweisen?“ Dann wäre der Manager natürlich irritiert, und der Angriff würde in diesem Gespräch mit hoher Wahrscheinlichkeit gestoppt.
Es ist zwar ein interessanter Angriffsweg, aber die tatsächliche Erfolgswahrscheinlichkeit ist fraglich. Der Artikel stellt es so dar, als brauche es einen ziemlich spezifischen und engen Ablauf von Ereignissen, damit dieser Angriff funktioniert; persönlich überzeugt mich das nicht wirklich.
Ich weiß, dass Phishing in der Praxis funktioniert. Aber Menschen, die auf Phishing hereinfallen, brauchen dafür keinen derart ausgefeilten Angriff; im Gegenteil könnte der Angreifer die Erfolgschancen sogar einschränken, wenn er so viel konkrete Mühe investiert. Eine gewöhnliche Phishing-E-Mail dürfte schon ausreichen.
Die Informationen zu diesen Führungskräften waren leicht auf LinkedIn oder der Unternehmenswebsite zu finden, und erstaunlicherweise passierte das sogar, obwohl genau dieses Szenario als Beispiel in der Anti-Phishing-Schulung vorkam.
https://www.microsoft.com/en-us/research/publication/why-do-...
Der Angreifer könnte eine Formulierung einbauen wie „Ich bin gerade auf Geschäftsreise. Wenn Sie unsicher sind, rufen Sie mich auf meinem privaten Handy an ...“ und dann mit einer gefälschten Stimme antworten.
Ein guter Weg zum Ziel könnte eine „doppelte Weiterleitung“ sein: Der Absender gibt sich als Mitarbeiter aus, der die E-Mail des Managers an jemanden in der Nähe der administrativen Zuständigkeit weiterleitet; wenn diese Person dann aus einem scheinbar harmlosen Grund wie Geburtstagswünschen oder einer Krankmeldung erneut weiterleitet, wird es für das eigentliche Ziel schwer, die ursprüngliche Herkunft der E-Mail nachzuvollziehen.
Darüber hinaus fallen einem leicht kreativere Möglichkeiten ein, diese „Funktion“ zu missbrauchen. Zum Beispiel könnte man eine ahnungslose Person dazu bringen, problematische Inhalte weiterzuleiten, und sie anschließend erpressen.
Die zuständigen Personen werden nicht jedes Mal den Line Manager anrufen, wenn eine Zahlungsanforderung per E-Mail kommt, insbesondere nicht bei kleinen Beträgen und wenn keine vorherige Freigabe nötig ist.
Ich erinnere mich, dass auch Google einmal Opfer eines Betrugs wurde, bei dem jemand bezahlt wurde, obwohl keine echte Leistung erbracht worden war. In diesem Fall ging es um gefälschte Rechnungen, aber das Prinzip ist dasselbe.
Vor ein paar Tagen sah ich mir ein von einem Designer erstelltes „Update“-E-Mail-Design an, und wegen des absurd großen grafischen Headers ganz oben konnte man nicht einmal den Betrefftext der E-Mail sehen, ohne zu scrollen.
Dann leitete er eine andere Version weiter und bat um Feedback; plötzlich wirkte er verunsichert, weil die Schrift etwas kleiner zu sein schien, und sagte: „Ah, beim Weiterleiten wird sie von der mobilen Version in die Desktop-Version umgewandelt!“
Ich starrte ihn ungläubig an. Das ist eine E-Mail – was sollen da „Desktop-Version“ und „mobile Version“ heißen? Wie kann es so etwas geben? Was heißt „umgewandelt“? Es wird doch einfach kopiert. Allein die Tatsache, dass es beim Weiterleiten „kaputtgeht“, zeigt, wie unsinnig dieser Ansatz ist. Warum zum Teufel muss CSS in meiner E-Mail stecken?
Wenn man nur Kursivschrift ausdrücken will, hätte man eine viel einfachere Lösung wie Markdown übernehmen sollen; dass das immer noch nicht passiert ist, ist absurd. Es zeigt, wie wenig Interesse es daran gibt, diese Situation wirklich zu verbessern. Es geht nur darum, die seltsamen Unternehmenswünsche zu erfüllen, überall Logos und Banner einzubauen. HTML-E-Mails sind wirklich grotesk.
[1] https://www.rfc-editor.org/rfc/rfc1896.txt
Ich vertrete schon lange die Ansicht, dass für Rich Text in E-Mails statt HTML eine Form von Markdown ohne Inline-HTML oder eine ähnlich einfache Text-Markup-Sprache verwendet werden sollte.
Dann könnten E-Mail-Clients leicht entscheiden, ob sie den Inhalt als formatierten Text oder einfach als Plain Text anzeigen, und trotzdem die meisten Formatierungen unterstützen, die normale Nutzer brauchen: fett, kursiv, Zitate, Inline-Bilder, Codeblöcke, Überschriften usw.
Für Marketing-E-Mails mit sehr fortgeschrittenem HTML wäre das nicht gut, aber ich finde nicht, dass man sich um diesen Anwendungsfall kümmern muss.
https://en.wikipedia.org/wiki/Enriched_text
https://www.rfc-editor.org/rfc/rfc1896.html
Noch immer gibt es in E-Mails nicht einmal Unterstützung dafür, Hyperlinks zu setzen, und kürzlich wurde versucht, das zu beheben.
https://pastebin.com/kHQs50xm
Das eigentliche Risiko für eine Organisation besteht darin, dass der Entwickler, der damit beauftragt wurde, HTML-E-Mails zu erstellen, durchdreht, sich im Serverraum einschließt und mit dem Ruf „Warum rendert Outlook das anders?“ die gesamte Hardware zertrümmert.
Aber im Ernst: Das ist eine sehr interessante Schwachstelle.
Ließe sich das nicht beheben, indem man keine Stylesheets erlaubt, sondern nur das Inline-
style-Attribut von Tags?Aus Gründen der Usability könnten E-Mail-Clients auch einen automatischen Schritt einbauen, der alle Stylesheets zu Inline-Styles „kompiliert“.
Dann würden nur fortgeschrittene CSS-Selektoren kaputtgehen, etwa
hover, und ich bin mir nicht sicher, ob man die wirklich braucht.Pseudoklassen und Media Queries würden zwar nicht funktionieren, aber die können ein Sicherheitsrisiko sein und werden auch von großen Mail-Clients nicht unterstützt: https://www.caniemail.com/features/css-at-media/
Außerdem killt man, wenn man alle
style-Attribute deaktiviert, gleich auch die Mobile-Optimierung und den Dark Mode. Denn Media Queries lassen sich nicht inline setzen.Normalerweise werden Basis-/Desktop-Styles bereits kompiliert und inline gesetzt, während Media-Query-Selektoren im
style-Tag imheadstehen, damit es auf Mobilgeräten gut lesbar ist.Wirklich clever.
Die Prämisse ist, dass aufgrund von CSS in HTML-E-Mails bestimmter Text erst sichtbar werden kann, nachdem die Nachricht weitergeleitet wurde. Das ist eine große Bedrohung für die Vertrauenswürdigkeit verifizierter E-Mails.
Es werden Beispiele für Thunderbird, Outlook und Gmail gezeigt, gute Arbeit.
Ich lese alle Mails in mutt, daher ist das offiziell „das Problem anderer Leute“.
Wenn ich also an anderer Stelle meckern soll: Das Datum der Meldung an Mozilla ist als 05.03.2024 angegeben. Ich stimme zu, dass Little-Endian-Daten mehr Sinn ergeben als amerikanische Middle-Endian-Daten.
Aber als Techniker ist es falsch, nicht das ISO-8601-Datumsformat 2024-03-05 zu verwenden, mit oder ohne Bindestriche. :)
Little Endian hat immerhin den Vorteil, dass es umgekehrt zu der Art ist, wie man alle anderen Zahlen schreibt; Middle Endian ist einfach nur verrückt. Was natürlich auch der Grund ist, warum Amerikaner es verwenden.
Man sieht, dass einige der erwähnten E-Mail-Clients den Mailinhalt in zusätzliche HTML-Tags einhüllen und CSS sowie Klassennamen ändern.
Ich frage mich, warum E-Mail-Clients beim Rendern von HTML-E-Mails kein Sandbox-iframe verwenden. Gibt es da weiterhin ein Sicherheitsrisiko?
Die weiterleitende Person möchte der E-Mail möglicherweise weiteren Text hinzufügen, also ist das ein erwartbares Verhalten.
Wenn die E-Mail jedoch einen Link zu einer Website enthielt und das Sandbox-iframe kein JavaScript erlaubte, wurde dieser Sicherheitskontext bis zu der Seite weitergereicht, die durch Anklicken des Links im iframe geöffnet wurde, sodass die Website kein JS verwenden konnte.
Die Lösung war
allow-popups-to-escape-sandbox, daher sehe ich keinen Grund, warum es heute nicht funktionieren sollte.Das ist die klassische Lösung, bei der man Gliedmaßen amputiert, um eine Wunde zu behandeln. Das Problem ist die mangelhafte Standardisierung von E-Mail, die zugelassen hat, dass solche Hacks dominieren.
HTML im Allgemeinen ist für solche Bedenken anfällig. Trotzdem gibt es viele E-Mails, die HTML problemlos verwenden. Dieser Artikel liest sich so, als würde persönliche Frustration über etwas, dem man in freier Wildbahn begegnet ist, als Sicherheitsproblem verpackt.
Mögliche Gegenmaßnahmen, die mir in den Sinn kommen, sind diese, auch wenn sie möglicherweise nicht wirksam sind: auffällig vor versteckten Elementen warnen, die Anzahl der umschließenden
divs auf Empfänger- und Absenderseite randomisieren, beim Weiterleiten berechnen, wie es tatsächlich aussehen wird, und bei großen Unterschieden eine Bestätigung verlangen.Oder umgekehrt vorzugehen könnte effektiver sein, weil es keine Hilfe anderer Clients erfordert.
Man kann es einfach in „Warum E-Mail für Organisationen riskant ist“ ändern.
Dieser Artikel zeigt zwar einen für HTML-E-Mails spezifischen Angriffsweg, aber die meisten Angriffe per E-Mail lassen sich leicht auf WhatsApp, Slack, Jira, Zoom oder jedes andere Tool übertragen, mit dem Menschen mit der Außenwelt kommunizieren.