Kein Ende-zu-Ende gut, alles gut bei E-Mail

Ende-zu-Ende-Verschlüsselung ist heute bei E-Mails faktisch nicht vorhanden. Es gibt dafür zwei große Konzepte bzw. Standards: PGP (inline/MIME) und S/MIME. Doch sowohl mangels intuitiver Verwendung in den gängigsten E-Mail-Anwendungen als auch aufgrund des schlechten Rufs – hauptsächlich in Bezug auf Benutzbarkeit, aber auch auf Sicherheit – finden sie keine große Akzeptanz.

Dann halt WhatsApp?

Die gängigen Messenger sind inzwischen deutlich sicherer als E-Mail. Viele Organisationen scheuen zudem den Aufwand, eine Ende-zu-Ende-Verschlüsselung einzuführen. Sie fürchten einerseits die schlechte Außenwirkung, wenn E-Mails erst nach organisatorischem Aufwand ausgetauscht werden können (Schlüsselaustausch), und andererseits den Verlust von E-Mail-Historie (Backups), wenn Schlüsselmaterial verlorengeht. Auch das Einbinden von Spam- und Viren-Scanner ist keine einfache Angelegenheit. Es herrscht noch immer das Mantra: „Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie.“

Stellt eine Organisation die Möglichkeit, E-Mails verschlüsselt zu senden, als Option zur Verfügung, greifen die Mitarbeiterinnen und Mitarbeiter nur sehr selten darauf zurück. Oft sind es vermeintlich nur „nicht-sensible“ Informationen, die ausgetauscht werden. Später, bei kritischeren Daten, heißt es häufig, einmal sei keinmal – bis dann hochsensible Informationen zeitkritisch ausgetauscht werden müssen und keine Zeit mehr für einen Schlüsselaustausch ist.

Pfeiler der Verschlüsselung

Eine gute E-Mail-Verschlüsselung basiert auf drei Pfeilern:

  1. Sichere Software,
  2. Schulung (zur richtigen Verwendung) und
  3. Sensibilisierung (zur Motivation)

Schwächelt nur ein Pfeiler, bricht die ganze Konstruktion zusammen. Gerade die dritte Säule hat einen großen Feind: den Frust. Zu häufig kommt es vor, dass die Gegenseite aus verschiedenen Gründen nicht in der Lage ist, verschlüsselte E-Mail-Kommunikation durchzuführen, während eine unverschlüsselte E-Mail einfach funktioniert.

„Wir haben ein E-Mail-Gateway, das kann das alles.“, ist ein Lösungsansatz, den man öfters mal hört. Es ist richtig, E-Mail-Gateways adressieren einige Schwächen gängiger E-Mail-Anwendungen. Aber intuitive Verwendung ist auch hier Fehlanzeige. Meistens gilt auch hier: Die E-Mail muss raus – und der Schlüsselaustausch verbleibt beim Endanwender. Im Zweifel wird die E-Mail dann doch unverschlüsselt versandt.

Ist eine Verschlüsselung nur optional, kann man aus Versehen unverschlüsselt versenden oder die Notwendigkeit verschlüsselt zu versenden solange hinauszögern, bis eine vertrauliche E-Mail aus zeitlichen Gründen unverschlüsselt versendet werden muss.

Zentrale Qual: S/MIME

S/MIME ist vergleichbar mit HTTPS in folgender Hinsicht: Es braucht eine Welt umspannendes Netz aus PKIs (Public-Key-Infrastrukturen), um gut zu funktionieren.

Was S/MIME im Gegensatz zu HTTPS fehlt, ist ein Schlüsselaustausch-Element. Beim Entwurf von S/MIME (1995) stellte man sich einen Verzeichnisdienst oder eine Verzeichnisdienst-Infrastruktur vor, hatte jedoch die Rechnung ohne den Datenschutz gemacht. Die Alternative zu einem Verzeichnis, sich gegenseitig signierte E-Mails zu senden, kann schnell zu einem größeren Delay führen, wenn nicht beide Parteien gleichzeitig am Rechner sitzen.

Was S/MIME mit HTTPS gemeinsam hat, es werden vertrauenswürdige Zertifizierungsstellen benötigt. Man kann eine eigene Zertifizierungsstelle aufbauen, doch dann hat man das Problem, diese als vertrauenswürdig an alle (auch potentielle) Kommunikationspartner zu verteilen. Hier gibt es keinen einheitlich definierten Weg. Oder man wendet sich an die wenigen öffentlich anerkannten Zertifizierungsstellen, die neben Server-Zertifikaten auch Personen-Zertifikate ausstellen. Diese lassen sich dies jedoch gut bezahlen, vor allem im Vergleich zu Server-Zertifikaten, wo der öffentliche Dienst Let’s Encrypt für einen drastischen Preisverfall gesorgt hat. Ob aber eine öffentlich anerkannte Zertifizierungsstelle wirklich gute Arbeit leistet, ist auch nicht immer sichergestellt. Hier gibt es im Bereich der Server-Zertifikate viele Negativ-Beispiele. Nicht umsonst drohen Größen wie Google, Mozilla und Apple mit dem Rauswurf von Zertifizierungsstellen, wenn diese einmal wieder „Blödsinn“ gemacht haben. Nur gibt es eine solche Marktmacht bei S/MIME nicht.

Pretty Bad: PGP

PGP hat von Anfang an auf eine PKI verzichten wollen, kommt aber ohne einen (dezentralen) Verzeichnisdienst auch nicht wirklich aus. Und die Idee eines Web-Of-Trust kann man weitestgehend als gescheitert betrachten, da braucht man noch nicht einmal die Datenschutz-Karte zu zücken:

„Ach ja, ich konnte Deine E-Mail nicht öffnen“ – und das Tage oder Wochen nach dem Versenden der E-Mail und erst auf Nachfrage. Trotz Schlüsselaustauschs. Was ist passiert? Der Empfänger hat seinen Schlüssel „verloren“, sieht aber keine Notwendigkeit zu handeln, weder proaktiv noch reaktiv. Solche E-Mail-Empfänger adressieren ganz klar den Feind „Frust“.

Transportverschlüsselung als Rettung?

„Aber was ist mit der Transportverschlüsselung, da kann doch dann auch keiner mitlesen?“ Das Hauptproblem auch hier: Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie. Schlägt beim Versenden die Zertifikatsprüfung fehlt, wird trotzdem übertragen. Bietet die Gegenstelle keine Verschlüsselung an, wird trotzdem übertragen. Interessanterweise ist es immer erstmal ein Fehler des Senders, wenn eine E-Mail nicht versendet werden kann, auch wenn die Gegenstelle sich nicht an geltende Normen hält. Auch das Thema Sender-Authentizität wird von der Transportverschlüsselung nicht geleistet.

Schematische Darstellung Decryption Oracle

Von Decryption und Signing Oracles: Covert-Content-Angriffe auf E-Mail

Dieser Blog-Beitrag ist eine Zusammenfassung der Untersuchungen, welche von der Autorin im Rahmen einer Abschlussarbeit für den Studiengang Informatik/IT-Sicherheit durchgeführt wurden.

Mit der Entwicklung der Netzwerktechnologie ist die E-Mail zu einem unverzichtbaren Mittel für die tägliche Kommunikation geworden. Laut Untersuchungen der Radicati Group nutzten 2019 bereits über die Hälfte der Weltbevölkerung E-Mails. Viele sensible Informationen werden so ausgetauscht. Im geschäftlichen Kontext können das beispielsweise Liefervereinbarungen, Verträge verschiedenster Art oder vertrauliche Korrespondenz mit Kunden oder Geschäftspartnern sein. Im privaten Umfeld sind zum Beispiel personenbezogene Informationen, vertrauliche Korrespondenzen etc. nicht minder interessant für Internetkriminelle.

E-Mail-Sicherheit

E-Mail-Verschlüsselung und digitale E-Mail-Signatur schaffen im Idealfall Sicherheit für die Nutzer. So ist eine digitale E-Mail-Signatur mit einer Unterschrift im realen Leben vergleichbar. Durch das digitale Signieren einer E-Mail kann der Absender eindeutig identifiziert werden. Außerdem kann die Integrität der Nachricht sichergestellt werden. Das bedeutet, dass der Empfänger erkennen kann, ob die E-Mail unterwegs verändert wurde. Das Versenden einer E-Mail ist mit dem Verschicken einer Postkarte in der anlogen Welt vergleichbar. Die Postkarte wird in den Briefkasten geworfen, der Briefträger holt sie dort ab, und über verschiedene Stationen wird sie schließlich dem Empfänger zugestellt. Jeder, der an der Zustellung beteiligt ist, kann die Postkarte lesen. Beim Versand einer E-Mail ist es ähnlich. Standardmäßig werden E-Mails unverschlüsselt übertragen. Bis sie allerdings beim Empfänger zugestellt werden können, passieren sie viele verschiedene Mailserver und andere Netzwerksysteme. Jeder kann die unverschlüsselte E-Mail abfangen, zwischenspeichern oder mitlesen.

What’s up Johnny?

In 2019 stellten Müller et al. [1] in ihrer Veröffentlichung „Re: What’s up Johnny?“ die sogenannten Covert-Content-Angriffe auf E-Mail Verschlüsselungen und E-Mail Signaturen vor. Die Autoren zeigen, dass die Schutzziele Vertraulichkeit, Authentizität und Integrität einer E-Mail bei der Nutzung bestimmter E-Mail-Clients verletzt werden können.

Die Anfälligkeit der E-Mail Kommunikation in Bezug auf die Gewährleistung der Schutzziele wird durch die Angriffe belegt. Es sind verschiedene Angriffszenarien denkbar:

  1. Übertragung falscher Daten
    1. Impersonation
    2. Manipulation von Informationen
    3. Phishing
    4. Social Engineering
  2. Unbefugter Zugriff auf Daten
    1. Wirtschaftsspionage
    2. Verletzung der Privatsphäre

Die Covert-Content-Angriffe nutzen einerseits die Eigenschaften des MIME-Standards und andererseits HTML/CSS, um den Nutzer zu täuschen. Als Backchannel wird die Antwort-Funktion des E-Mail-Clients genutzt.

Es wird dabei zwischen zwei Angriffskategorien unterschieden: Decryption Oracle und Signing Oracle.

Decryption Oracle

Das Ziel des Angriffs im Sinne des Decryption Oracle ist es, den entschlüsselten Klartext über den Backchannel unbemerkt zu extrahieren. Müller et al. beschreiben, wie es einem Angreifer gelingt, (abgefangenen) Ciphertext in einer harmlosen E-Mail an das Opfer zu verstecken. Nutzt das Opfer die Antwort-Funktion des E-Mail-Clients wird es zum „Decryption Oracle“ und sendet unbewusst den versteckten, jedoch nun entschlüsselten Klartext an den Angreifer zurück.

Das Prinzip des Angriffs wird in Abbildung 1 dargestellt. Die Voraussetzung ist, dass der Angreifer Zugang zu der verschlüsselten Kommunikation zweier Parteien. Hierfür gibt es verschiedene Szenarien. Beispielsweise hat der Angreifer aufgrund eines schwachen, leicht zu erratenen Passworts, Zugang zu dem E-Mail-Konto auf dem E-Mail-Server. Eine weitere Möglichkeit ist, dass der Angreifer die verschlüsselte E-Mail mitliest und speichert, wenn der Nutzer diese über eine unverschlüsselte Verbindung vom Mail-Server abruft.

Abbildung 1: Covert-Content-Angriff gegen E-Mail-Verschlüsselung (Decryption Oracle)

Der Angreifer kann die verschlüsselten E-Mails jedoch nicht selbst entschlüsseln, denn er ist nicht im Besitz des privaten Schlüssels. Daher sendet er eine manipulierte E-Mail an einen der beiden Original-Kommunikationspartner. Dabei ist es unerheblich, ob es sich dabei um den ursprünglichen Sender oder Empfänger der E-Mail handelt. Denn die Verschlüsselung der E-Mail erfolgt beim Sender sowohl mit seinem eigenen öffentlichen Schlüssel als auch mit dem öffentlichen Schlüssel des Empfängers. Wie Abbildung 1 zeigt, besteht die manipulierte E-Mail aus zwei Teilen. Der erste Teil ist eine unverfängliche Nachricht, die das das Opfer zu einer direkten Antwort animieren soll. Um den Angriff erfolgreich durchführen zu können, ist der zweite Teil der Nachricht encω(m) für das Opfer unsichtbar. Antwortet das Opfer auf diese manipulierte E-Mail, dann wird der entschlüsselte Klartext m, als unsichtbarer Bestandteil der E-Mail zurück an den Angreifer gesendet.

Signing Oracle

Die zweite Angriffs-Kategorie verfolgt das Ziel, eine gültig signierte E-Mail durch den vom Opfer genutzten E-Mail-Client, welcher als Signing Oracle fungiert, zu erhalten. Abbildung 2 stellt das Prinzip des Covert-Content-Angriffs für das Signing Oracle dar. Die manipulierte E-Mail besteht hierbei wieder aus zwei Textteilen. Der erste, sichtbare und unverfängliche Teil, der zum Antworten animieren soll, und der zweite, versteckte Teil der Nachricht, der für weiterführende Angriffe genutzt werden soll. Im Kontext einer harmlos erscheinenden E-Mail an das Opfer wird dieser zweite Textteil mittels CSS-Conditional-Rules versteckt. So kann der Angreifer beeinflussen, dass die E-Mail je nach E-Mail-Client unterschiedlichen Text anzeigt. Da die digitale Signatur für die vollständige originale E-Mail gültig ist, kann die E-Mail durch den Angreifer für weitere Angriffe missbraucht werden. Beispielsweise kann der Angreifer sich per E-Mail als vertrauenswürdiges Mitglied des Unternehmens ausgeben, um dringende Überweisungen von ahnungslosen Mitarbeitern zu veranlassen.

Abbildung 2: Covert-Content-Angriff gegen E-Mail-Signatur (Signing Oracle)

Re-Evaluation

Seit der Durchführung der Tests sind mittlerweile ca. zwei Jahre vergangen. Daher wurden nun im Rahmen einer Re-Evaluation folgende Fragen beantwortet:

  1. Sind die Covert-Content-Angriffe auf die untersuchten Email-Clients weiterhin möglich?
  2. Falls nein, können die Gegenmaßnahmen durch Erweiterung der Angriffe umgangen werden?

Es wurden 22 E-Mail-Clients in die Untersuchung einbezogen. Davon unterstützen 19 Clients PGP-Verschlüsselung und -Signatur, 19 Clients S/MIME-Signatur und 18 Clients S/MIME-Verschlüsselung. Die Angriffe funktionieren bei vielen der getesteten E-Mail-Clients weiterhin. Die Re-Evaluation für die Signing Oracle-Schwachstelle ergab keine nennenswerte Veränderung im Vergleich zur Evaluation von Müller et al. [1]. Sämtliche Testcases der Evaluation als auch der Re-Evaluation sind auf Github veröffentlicht und können dort heruntergeladen werden [2].

Ergebnisse

Es sind 37% der S/MIME- und 32% der PGP-fähigen E-Mail-Clients als Signing Oracle angreifbar. Bei Müller et al. waren es 41% bzw. 32% der entsprechenden E-Mail-Clients. In Bezug auf die Decryption Oracle-Schwachstelle ist von Herstellerseite am meisten nachgebessert worden. Es existieren zwar nach wie vor E-Mail-Clients, bei denen es möglich ist, Klartext zu extrahieren, wenngleich deren Zahl um die Hälfte zurückgegangen ist. Insbesondere der Angriff für den Testcase 01-reply-mix-css.eml, der zum Ziel hat, den entschlüsselten Klartext vollständig zu verstecken, schlug bei allen E-Mail-Clients fehl. Die Hersteller haben teilweise die von Müller et al. vorgeschlagenen Gegenmaßnahmen gegen die Covert-Content-Angriffe umgesetzt. Die vollständige Ergebnisübersicht ist in der Tabelle 1 dargestellt.

Abschließend wurden verschiedene Modifikationen der Angriffe vorgenommen. War es im Rahmen der Re-Evaluation nicht mehr möglich, den Klartext vollständig zu verstecken, konnte dies durch eine Modifikation des Testcase 01-reply-mix-css.eml wieder realisiert werden. So ist es möglich, bei drei der S/MIME-fähigen und bei einem der PGP-fähigen Clients den entschlüsselten Klartext für den Nutzer unsichtbar zu gestalten. Dafür werden CSS-Regeln verwendet. HTML und CSS unterliegen einer ständigen Weiterentwicklung durch das World Wide Web Consortium (W3C). Es gibt immer noch E-Mail-Clients, die auch in der Antwort-E-Mail HTML/CSS unterstützen. Dies ist auch eine der Eigenschaften, die durch die reevaluierten Angriffe ausgenutzt wird. Daher ist es eine Frage der Zeit, bis neue Modifikationen, Schwachstellen in Bezug auf die Covert-Content-Angriffe aufzeigen.

Der Nutzer hat viele verschiedene Möglichkeiten, den Client nach seinen Wünschen und Bedürfnissen zu konfigurieren. Die E-Mail-Clients wurden in den Standard-Einstellungen getestet, aber die Re-Evaluation hat gezeigt, dass das Prinzip der Covert-Content-Angriffe, die Antwort-Funktion des E-Mail-Clients als Backchannel zu nutzen, nach wie vor funktioniert. Es entsteht der Eindruck, dass die Hersteller die Verantwortung für eine sichere E-Mail-Kommunikation auf den Nutzer abschieben. Und das ist nicht im Sinne der Sicherheit. Cranor und Buchler [3] stellten bereits fest, dass Benutzer nicht gewillt sind, aktiv die Einzelheiten der Sicherheitsmerkmale zu verwalten. Die Systemdesigner sind in der Pflicht, sich im Vorfeld über die Entscheidungsanforderungen Gedanken zu machen, welche an die Benutzer gestellt werden. Fast jeder Dritte der getesteten PGP-fähigen und gut jeder Fünfte der S/MIME-fähigen Clients ist als Decryption Oracle angreifbar. Sicherheit und Benutzerfreundlichkeit werden traditionell als Kompromiss betrachtet. Nach Schneier [4] führt genau dieses „Entweder-Oder“-Denken oft zu Systemen, die weder benutzbar noch sicher sind. Die Betrachtung, ob ein sicherer E-Mail-Client weniger funktional und ein flexibler und leistungsfähiger E-Mail-Client weniger sicher ist, lassen Raum für weitere Forschung.

Tabelle 1: Re-Evaluation Covert-Content-Angriffe

Quellen

[1] Jens Müller, Marcus Brinkmann, Damian Poddebniak, Sebastian Schinzel, und Jörg Schwenk. Re:What’s Up Johnny?: Covert Content Attacks on Email End-to-End Encryption. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 11464 LNCS:24–42, 2019. ISSN 16113349.

[2] https://github.com/RUB-NDS/Covert-Content-Attacks

[3] Lorrie Faith Cranor und Norbou Buchler. Better Together: Usability and Security Go Hand in Hand. IEEE Security Privacy, 12(6):89–93, nov 2014. ISSN 1558-4046.

[4] Bruce Schneier. Stop Trying to Fix the User. IEEE Security & Privacy, 14(05):96, 2016. ISSN 1558-4046. URL https://doi.org/10.1109/MSP.2016.101.