2 Punkte von GN⁺ 2024-04-05 | 1 Kommentare | Auf WhatsApp teilen

Kobold-Briefe

  • Wer sich technisch mit HTML-E-Mails befassen muss, war wegen der inkonsistenten Implementierungen der Clients vermutlich schon an dem Punkt, den Job hinschmeißen oder alle Mail-Clients anzünden zu wollen.
  • HTML-E-Mails sind nicht nur eine Quelle des Ärgers, sondern können auch ein ernstes Sicherheitsrisiko darstellen.
  • Man stelle sich vor, der Vorgesetzte leitet eine E-Mail weiter, in der dazu aufgefordert wird, eine große Geldsumme zu überweisen. Da man von CEO-Betrug gehört hat, prüft man, ob die E-Mail wirklich vom Vorgesetzten stammt.
  • Die E-Mail stammt tatsächlich vom Vorgesetzten, und wenn das im Unternehmen so gehandhabt wird, ist sie vielleicht sogar kryptografisch signiert.
  • Trotzdem bleibt ein Restzweifel, also ruft man den Vorgesetzten an und überprüft die Echtheit der E-Mail.
  • Wenn der Vorgesetzte sie bestätigt, wird das Geld überwiesen.
  • Wäre das kein Betrug, würde der Artikel hier enden.

Thunderbird

  • Dieses Problem wurde Mozilla am 5. März 2024 gemeldet, und das geplante Veröffentlichungsdatum sowie ein Entwurf des nächsten Abschnitts wurden Mozilla am 20. März 2024 übermittelt.
  • Mögliche Gegenmaßnahmen wurden diskutiert, sollen aber erst später implementiert werden.
  • Die Ausnutzung in Thunderbird ist einfach. Thunderbird umschließt E-Mails mit `

` und verändert sie ansonsten nicht.

  • Beim Weiterleiten einer E-Mail wird die zitierte E-Mail in ein weiteres `

` eingeschlossen und im DOM eine Ebene nach unten verschoben.

  • Berücksichtigt man das, ergibt sich der folgende Proof of Concept:

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

  • Die E-Mail enthält Text, der immer sichtbar ist, sowie Text, der mit display: none; verborgen wird.
  • Wird die E-Mail weitergeleitet, wird der versteckte Text plötzlich nur für den neuen Empfänger sichtbar.

Outlook Web

  • Dieses Problem wurde Microsoft am 5. März 2024 gemeldet, und das geplante Veröffentlichungsdatum sowie ein Entwurf des nächsten Abschnitts wurden Microsoft am 20. März 2024 übermittelt.
  • Microsoft entschied am 26. März 2024, keine sofortigen Maßnahmen zu ergreifen, und schloss den Bericht.
  • In Outlook Web (OWA) ist die Situation etwas komplexer. E-Mails werden mit `

` umschlossen, wobei sich der genaue Klassenname ändern kann.

  • Damit das CSS der E-Mail die Styles des Webmailers nicht beeinflusst, setzt Outlook vor alle IDs und Klassen der E-Mail ein x_ und passt das CSS entsprechend an.
  • Berücksichtigt man das, ergibt sich der folgende Proof of Concept:

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

    This text is always visible.

    This text will only appear after forwarding.

  • Wenn die E-Mail in OWA angezeigt wird, sieht das CSS wie folgt aus:

  • Nach dem Weiterleiten der E-Mail wird der Kobold-Brief in ein weiteres `` eingeschlossen und das CSS erneut aktualisiert.

Gmail

  • Dieses Problem wurde Google am 5. März 2024 gemeldet, und das geplante Veröffentlichungsdatum sowie ein Entwurf des nächsten Abschnitts wurden Google am 20. März 2024 übermittelt.
  • Gmail ist technisch nicht anfällig für Kobold-Briefe, weil beim Weiterleiten einer E-Mail alle Styles entfernt werden.
  • Beim Weiterleiten wird der per CSS versteckte Kobold-Brief automatisch sichtbar, noch bevor das CSS entfernt wird.

Frühere Forschung

  • Dass dies möglich ist, ist weder überraschend noch neu.
  • Ähnliche Probleme wurden in der Vergangenheit bereits gemeldet.

Ausblick

  • Nutzer können Kobold-Briefe abmildern, indem sie HTML-E-Mails vollständig deaktivieren oder in einem eingeschränkten Modus anzeigen.
  • Für E-Mail-Clients ist es schwierig, Gegenmaßnahmen zu implementieren. Die Verwendung von `` zu verhindern, könnte das Problem lösen, würde aber viele bereits bestehende Lösungen im E-Mail-Ökosystem zerstören.
  • Leider ist es unrealistisch zu erwarten, dass E-Mail-Clients in naher Zukunft robuste Gegenmaßnahmen implementieren werden.

Meinung von GN⁺

  • Dieser Artikel zeigt die Verwundbarkeit von HTML-E-Mails und beschreibt insbesondere den Angriff mit „Kobold-Briefen“, bei dem sich Inhalte verändern können, wenn eine E-Mail weitergeleitet wird. Das ist eine wichtige Information, die E-Mail-Nutzer für Sicherheitsrisiken sensibilisiert.
  • Er zeigt, dass je nach Art, wie E-Mail-Clients mit CSS umgehen, Sicherheitslücken entstehen können, und ruft sowohl Nutzer als auch Entwickler zu mehr Aufmerksamkeit in Sicherheitsfragen auf.
  • Solche Angriffe sind besonders gefährlich, weil sie so wirken, als kämen sie von einer vertrauenswürdigen Quelle. Das unterstreicht die Notwendigkeit, bei der Kommunikation per E-Mail stets wachsam zu bleiben.
  • Aus technischer Sicht müssen Entwickler von E-Mail-Clients die CSS-Verarbeitung verbessern, um solche Angriffe zu verhindern. Das kann jedoch Kompatibilitätsprobleme mit bestehenden E-Mail-Designs verursachen, sodass es wichtig ist, ein angemessenes Gleichgewicht zu finden.
  • Dieser Artikel handelt zwar nicht von neuer Technologie oder Open Source, zeigt aber auf, welche Punkte bei der Einführung von Technologien rund um E-Mail-Sicherheit berücksichtigt werden sollten. Entwickler von E-Mail-Clients müssen nach Wegen suchen, die Sicherheit der Nutzer zu stärken und zugleich die Nutzbarkeit zu erhalten.

1 Kommentare

 
GN⁺ 2024-04-05
Hacker-News-Kommentare
  • “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.”

    • Dieser Kommentar betont, dass man bei Zweifeln an einer per E-Mail angeforderten Geldüberweisung nicht einfach fragen sollte: „Hast du diese E-Mail geschickt?“, sondern konkret nachhaken sollte, etwa: „Willst du wirklich, dass ich das Geld auf diese Weise überweise?“ Die Meinung ist, dass ein solcher Dialog die Wahrscheinlichkeit eines erfolgreichen Angriffs deutlich senken würde. Außerdem wird darauf hingewiesen, dass das im Artikel beschriebene Angriffsszenario sehr spezifische und enge Rahmenbedingungen erfordert, und es wird bezweifelt, dass ein so komplexer Angriff in der Praxis tatsächlich oft erfolgreich wäre.
  • The other day I was discussing the design for an "update" email that our designer was putting together...

    • Dieser Kommentar schildert eine Erfahrung mit E-Mail-Design. Es wird kritisiert, dass man wegen des grafischen Headers der vom Designer erstellten E-Mail erst scrollen muss, um die Betreffzeile zu sehen, und Verwunderung darüber ausgedrückt, dass eine weitergeleitete E-Mail in der mobilen Ansicht in eine Desktop-Version umgewandelt wird. Zudem wird der Einsatz von CSS in E-Mails als unnötig kritisiert und Unzufriedenheit darüber geäußert, dass sich bis heute kein einfaches Text-Markup wie Markdown durchgesetzt hat.
  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • Dieser Kommentar argumentiert, dass man in E-Mails statt HTML besser Markdown oder ein ähnliches einfaches Text-Markup verwenden sollte. Dadurch könnten E-Mail-Clients leichter entscheiden, ob sie die Nachricht als Rich Text oder als Plain Text anzeigen, und gleichzeitig ließe sich der Großteil der von Nutzern benötigten Formatierung abdecken. Die komplexen HTML-Konstruktionen aus Marketing-E-Mails seien dagegen nicht wichtig.
  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

    • Dieser Kommentar macht scherzhaft die Bemerkung, dass der eigentliche Risikofaktor für eine Organisation darin besteht, dass der Entwickler, der HTML-E-Mails erzeugen soll, wegen der unterschiedlichen Rendering-Eigenheiten von Outlook verrückt wird. Zugleich wird erwähnt, dass die beschriebene Angriffsmethode per E-Mail interessant sei.
  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • Dieser Kommentar schlägt vor, das Problem vielleicht dadurch zu lösen, dass in E-Mails keine Stylesheets erlaubt werden, sondern nur Inline-Style-Attribute direkt an den Tags. Wenn E-Mail-Clients zusätzlich einen Schritt einbauen würden, der Stylesheets automatisch in Inline-Styles umwandelt, könnte das die Nutzbarkeit verbessern.
  • HTML in email shouldn't be as big of a nightmare as it is.

    • Dieser Kommentar meint, dass HTML in E-Mails kein so großer Albtraum sein sollte, wie es derzeit ist. Wenn alle E-Mail-Clients einfach zwischen Text und HTML unterscheiden und bei HTML auf eine WebKit-Rendering-Engine umschalten würden, ließe sich das Problem seiner Ansicht nach leicht lösen. Außerdem fragt er sich, ob dafür jemals ein Standard vorgeschlagen wurde.
  • Some possible mitigations from the top of my head (maybe ineffective):

    • Dieser Kommentar nennt einige mögliche Maßnahmen zur Abschwächung solcher E-Mail-Angriffe. Genannt werden etwa Warnungen bei versteckten Elementen oder die Idee, beim Weiterleiten das Erscheinungsbild der Nachricht zu berechnen und bei starken Abweichungen eine Bestätigung anzufordern.
  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

    • Dieser Kommentar erwähnt, dass der Verfasser einen Blogpost über die Sicherheitsrisiken von HTML-E-Mails geschrieben hat. Es wird kritisiert, dass die HTML-E-Mail-Spezifikation alt sei und kaum Sicherheitsaspekte berücksichtige. Sichere HTML-E-Mails müssten eigentlich auf einer Teilmenge von HTML basieren, aber da niemand diese Teilmenge klar definiert habe, träten ständig neue Sicherheitslücken auf.
  • This is really clever!

    • Dieser Kommentar lobt als sehr clever, dass sich mit CSS in HTML-E-Mails bestimmter Text so steuern lässt, dass er erst nach dem Weiterleiten sichtbar wird. Das könne eine erhebliche Gefahr für die Vertrauenswürdigkeit verifizierter E-Mails darstellen. Außerdem wird die Frage aufgeworfen, warum E-Mail-Clients den Inhalt von E-Mails mit zusätzlichen HTML-Tags umschließen und dabei CSS sowie Klassennamen verändern. Ebenso wird hinterfragt, warum E-Mail-Clients zum Rendern von HTML-E-Mails nicht einfach sandboxed iframes verwenden.