Efail - Verständnisfragen

[lordg2009]

Hi,

Ich habe in den letzten Tagen vermehrt Berichte über die Angriffsmöglichkeiten auf S/MIME und OpenPGP gelesen und würde gern einige Fragen loswerden. Zuvor möchte ich aber anmerken, dass ich kein IT-Profi bin.

1. Warum gibt es keine Checksum des verschlüsselten Textes, die mit dem öffentlichen Schlüssel verschlüsselt wird. Selbst mir als nicht ITler ist bekannt, dass man neben einer starken Vreschlüsselung auch die Integrität schützen muss. Da habe die Programmierer bestimmt auch daran gedacht und sich evtl. bewusst dagegen entschieden. Warum?
2. Ist bei vielen Mailprogrammen nicht die HTML Darstellung Standartmäßig ausgeschalten?
3. Kommen HTML Mails von Privatpersonen überhaupt durch den SPAM-Filter? Ich habe vor Jahren mal versucht eine hübsche Registrierungsmail für ein simples Forum zu programmieren, da gab es ständig Probleme.
4. Ist die Schwachstelle tatsächlich erst jetzt aufgefallen? Sie klingt für mich so simpel, dass man sich kaum vorstellen kann, das bisher niemand auf die Idee gekommen ist.
5. Gibt es eine Möglichkeit, die Schwachstelle mit ausgeschalteter HTML-Darstellung auszunutzen?

Vielen Dank für eure Antworten

 

[Toms]

Selbst wenn man die HTML-DARSTELLUNG abschaltet, parst das Programm im Hintergrund den HTML-Code und führt diesen damit auch aus. Daher ist die Lücke noch da, wenn man HTML-Mails abschaltet. Auch wird bei den einfach angriffen die Mail beim Empfänger nicht mehr manipuliert. Es wird nur noch der dann entschlüsselte Text von einem fremden Server ausgelesen. Daher bringen Integritätstests auch nichts mehr.

 

[Piktogramm]

1.
Die Checksumme wäre vorhanden, wenn die Email signiert werden würde. Die Trennung zwischen Verschlüsselung und Unterschrift ist jedoch gewollte, da der Absender ohne Unterschrift bestreiten kann, die Email verschickt zu haben.
An sich wird die Signatur (wenn vorhanden) auch vor dem Entschlüsseln geprüft. Wer also brav seinen private Key mit einem Passwort sichert kann erst die Signatur prüfen und sich bewusst entscheiden ob die Email zu entschlüsseln ist oder nicht. Wenn die Signatur stimmt und dennoch ein Angriff enthalten ist, dann ist der Angreifer der Absender (der kennt den Klartext eh) oder aber der private Schlüssel vom Absender ist in der Hand von Dritten und entsprechend ist die Kommunikation eh unsicher.

2. Outllookinfrastruktur in Firmen, da wird HTML Email als Standard angesehen, SMIME drauf geschmissen und die 80% der Firma wo Outlook noch nicht ausgerollt können den Mist dann nicht öffnen weil der Webmailer dran verreckt oder aber der Spamfilter gleich bouncen lässt

3. Der Spamfilter hat keine Chance HTML-Emails als solche zu erkennen, wenn die Mail selbst verschlüsselt ist. Normalerweise sollte man einen Spamfilter als unberechtigten Dritten ansehen, der Emails eben nicht im Klartext lesen können soll.

4. Jain, im Prinzip ist das alles nicht neu. Die Kombination ist neu und ganz besonders die Vermarktung unter eigenem Namen mit Logo, eigener Seite etc.

5. Soweit ich verstanden habe nein

 

[Yuuri]

Die Verschlüsselung ist überhaupt nicht das Problem, das wurde und wird komplett falsch kommuniziert. Das Problem sind fehlerhafte Mailclients, die die Mails nicht ordentlich parsen können und somit evtl. Schlüssel offenbaren, was wiederum zur Entschlüsselung von alten Mails führen kann, insofern sie evtl. abgegriffen wurden oder Zugang zum Postfach besteht oder Malware installiert ist oder oder oder... Die Verschlüsselung greift trotzdem problemlos. Evtl. solltest du dir danach halt ein neues Schlüsselpaar generieren/besorgen, damit zukünftige Kommunikation weiterhin verschlüsselt erfolgen kann und (noch) nicht kompromitiert ist.

https://www.golem.de/news/pgp-smime...elte-e-mails-schicken-lassen-1805-134370.html

Selbst wenn man die HTML-DARSTELLUNG abschaltet, parst das Programm im Hintergrund den HTML-Code und führt diesen damit auch aus. Daher ist die Lücke noch da, wenn man HTML-Mails abschaltet.

Quark, es kommt drauf an wie der Mail-Client damit umgeht. Schön zu sehen im Heise-Artikel, wo eine Auflistung an verwundbaren Mail-Clients (und nicht nach SMIME/PGP unterschieden wird) stattfindet: https://www.heise.de/newsticker/mel...um-sicher-E-Mails-zu-verschicken-4048988.html Outlook 2013+ lädt bspw. nichts ohne Userinteraktion aus dem Internet nach. Heißt also du kannst dort lustig verschlüsselte HTML-Mails öffnen, solange du nicht auf die Leiste oben klickst (das gleiche Problem wie bei Excel Makros übrigens...). Immun sind aktuell hingegen nur (so das Bild) Claws Mail und Mutt (was S/MIME betrifft).

 

[SoDaTierchen]

Um auch mal auf deine Fragen zu antworten:

1) Das Problem ist nicht, dass es keine Checksummen gibt, sondern dass diese optional sind und einige Mail-Clients trotzdem munter entschlüsseln und ausführen, selbst wenn die Checksumme fehlt / entfernt worden ist / falsch ist. Hier liegt das Problem in der Implementierung und darin, dass die Standards nicht strikt genug sind.

2) Ja und nein. Hängt vom Mail-Client ab. Im Zweifel einfach nach deinem verwendeten gucken und dort prüfen.

3) Du glaubst nicht, was alles durch Spamfilter kommt. Es gibt ja nicht "den Spamfilter" und "den Spam". Ich habe spaßeshalber mal eine fast leere Mail mit den Inhalten "Viagra" und "Penispumpe" im Betreff in ein Unternehmensnetzwerk geschickt, indem meine dafür genutzte Mail nicht bekannt war. Die Mail kam durch 5 Filter durch, keiner hat geschimpft. Hat der genutzte Spamfilter eine Regel, dass HTML-Inhalte geblockt werden, dann kommen diese nicht durch. Anderenfalls gibt es alleine deswegen noch keinen Grund, die Mails abzuhalten. Viele Mails unserer Geschäftspartner sind HTML-Mails, davon wird keine geblockt. Mal abgesehen davon reden wir hier über verschlüsselte Mails, der Spam-Filter kann den Inhalt nicht kennen.

4) Die Sicherheitslücke wurde jetzt erst veröffentlicht. Wann diese bekannt war, wird dir niemand mehr sagen können. Irgendwann zwischen der Erstellung von verschlüsselnden Mail-Clients und dem 13.Mai 2018 wurde diese bekannt. Genauer weiß das nur eine Glaskugel. Es ist zwar eigentlich Usus eine Sicherheitslücke vor Veröffentlichung erst an die Softwarehersteller zu propagieren und diesen 90 Tage Zeit zum fixen zu geben, da es dafür aber keine niedergeschriebene Regelung und schon gar keine Gesetze gibt, kann man sich nicht sicher sein, dass es auch hier einen Vorlauf gab.

5) Nein. Das heißt nicht, dass deaktivierte HTML-Darstellung sicher ist, aber diese einfache Form der Exfiltration ist nicht mehr möglich, wenn HTML-Mails nicht ausgeführt werden.


Wie Yuuri schon gesagt hat: Das Problem ist nicht die Verschlüsselung, es ist die Art und weise, wie damit umgegangen wird. Es ist ohne weiteres Möglich, Mail-Clients so zu entwerfen, dass diese gegen solche Arten von Angriffen sicher sind. Das geht aber erst, wenn diese Lücken bekannt werden. Würde ein Mail-Client bei der HTML-Darstellung schlicht keine Inhalte aus dem Netz nachladen, dann verpufft dieser Angriff. Es wird ja nicht das System selbst angegriffen, es wird die Motivation, verlinkte Inhalte darzustellen, missbraucht.

 

[Piktogramm]

Die Verschlüsselung ist überhaupt nicht das Problem, das wurde und wird komplett falsch kommuniziert. Das Problem sind fehlerhafte Mailclients, die die Mails nicht ordentlich parsen können und somit evtl. Schlüssel offenbaren,

Die Schlüssel sind bei Efail an keiner Stelle gefährdet. Es kann nur der eigentlich verschlüsselte Inhalt der Email ausgeleitet werden.

 

[Yuuri]

Na dann ists ja halb so schlimm. Da hab ich wohl irgendwo was falsch gelesen. Also jetzt bei Bekanntwerden einfach die HTML-Ansicht notfalls deaktivieren und wenn es gefixt wurde, wieder normal weiterarbeiten.

 

[lordg2009]

@SoDaTierchen meinte aber, dass auch eine deaktivierte HTML-Ansicht nicht unbedingt sicher sein muss. Wie sähe denn ein Angriffsszenario ohne HTML-Elemente aus?

 

[SoDaTierchen]

Ich meinte damit lediglich, dass 1. Mail-Programme diese Einstellung unter Umständen für eine Vorschau ignorieren und man trotzdem angreifbar ist (hängt vom Programm ab) und es 2. vielleicht auch eine noch nicht bekannte Möglichkeit gibt, einen ähnlichen Angriff auf Text-Mails auszuführen. Diverse Mail-Programme erlauben ja zum Beispiel auch Links oder eingebetteten Text in der Text-Ansicht. Hier könnte ein sehr ähnlich gearteter Angriff (nur halt ohne <a href>-Element) trotzdem Erfolg haben. Die Angriffsfläche ist aber geringer, da dies wohl weit weniger Mail-Clients betrifft als efail.