#efail

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

#efail

J. Fahrner
Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem
werden, oder?
https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4048873.html

LG Jochen
Reply | Threaded
Open this post in threaded view
|

Re: #efail

Robert Schetterer-2
Am 14.05.2018 um 17:46 schrieb J. Fahrner:
> Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem
> werden, oder?
> https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4048873.html
>
>
> LG Jochen

hm grad erst eingelesen..
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
middle", ich stell mir das erstmal so vor, der Boese will doch nicht
entdeckt werden d.h er wird zunaechst ein Kopie herstellen/ausleiten
damit du nicht mitbekommst dass er mitliest. Er arbeitet dann mit der
Kopie und wendet efail an. Insofern wirst du via DKIM keine Manipulation
feststellen koennen.

Der wesentliche Punkt ist also erstmal die Uebermittlung und Speicherung
der Mail muss moeglichst sicher sein. Das immer sicherzustellen ist per
se schon gar nicht so einfach. Beim Transport sollte dann dane state of
the art sein, aber bei den Mail clients wird dann schon haarig.
Thunderbird und die neueste Enigmailversion mit gpg "sollen" halbwegs
gepatched sein.

In jedem Fall keine guten Nachrichten, aber wenn man genau nachliest nun
auch nicht wirklich so ueberraschend. Zufrieden mit smime/gpg usw konnte
man schon frueher nicht sein aber auf den anderen Seite ich sehe keine
grundsaetzlich bessere Idee/Verfahren. Die Berichterstattung empfinde
ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach
nicht mehr zu retten"



Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
On 14.05.2018 18:32, Robert Schetterer wrote:

> Am 14.05.2018 um 17:46 schrieb J. Fahrner:
>> Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem
>> werden, oder?
>> https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4048873.html
>>
>>
>> LG Jochen
> hm grad erst eingelesen..
> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
> middle", ich stell mir das erstmal so vor, der Boese will doch nicht
> entdeckt werden d.h er wird zunaechst ein Kopie herstellen/ausleiten
> damit du nicht mitbekommst dass er mitliest. Er arbeitet dann mit der
> Kopie und wendet efail an. Insofern wirst du via DKIM keine Manipulation
> feststellen koennen.
das Einfügen der beiden Teile vor und nach dem BASE64 Datenstrom?
wobei ich hier mir die Frage stelle, wieso soll ein Mailer hier ein HTML
rendering
anwerfen, wo es doch darum geht den BASE64 Datenstom unverschlüsselt
darzustellen?
zumindest das sagt der MIME-Type im Header aus(!)

> Die Berichterstattung empfinde
> ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach
> nicht mehr zu retten"
das ist Heise mittlerweile auf Bild-Niveau  ...



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: #efail

J. Fahrner
In reply to this post by Robert Schetterer-2
Am 2018-05-14 18:32, schrieb Robert Schetterer:
> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
> middle",

Der "man in the middle" modifiziert die Mail und fügt einen Anhang vorne
und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der
Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
Reply | Threaded
Open this post in threaded view
|

Re: #efail

J. Fahrner
In reply to this post by Robert Schetterer-2
Am 2018-05-14 18:32, schrieb Robert Schetterer:
> Die Berichterstattung empfinde
> ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist
> einfach
> nicht mehr zu retten"

Heise scheint da tatsächlich etwas zu übertreiben.
https://blog.fefe.de/?ts=a4076a8a
Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
In reply to this post by J. Fahrner
On 14.05.2018 21:59, J. Fahrner wrote:
> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>> middle",
>
> Der "man in the middle" modifiziert die Mail und fügt einen Anhang
> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was der
> Empfänger ja leicht feststellen kann (so er denn die Signatur prüft).
soferne die DKIM-Signatur dies erfasst, weil anscheinend ja nur im
Mail-Body etwas hinzugefügt wird;

schlimmer finde ich ein ganz anderes Szenario, da er ja die
verschlüsselte Mail im Original hat, hat er auch den Public Key des
Empfängers, und damit kann er dann den kompletten verschlüsselten Inhalt
durch was anderes ersetzen - Malware z.B. - und das hebelt dann
sämtliche Mechanismen am Transport aus - da ja verschlüsselt; und der
Client kann - schlampig wie sie alle implementiert sind - macht weiß
Gott was damit ...

DKIM-Signatur hin oder her, ein Mail Client der hier irgendwas anderes
macht als einen Fehler auszugeben ist kompletter Pfusch;


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: #efail

J. Fahrner
Am 2018-05-15 05:23, schrieb Walter H.:
> schlimmer finde ich ein ganz anderes Szenario, da er ja die
> verschlüsselte Mail im Original hat, hat er auch den Public Key des
> Empfängers, und damit kann er dann den kompletten verschlüsselten
> Inhalt durch was anderes ersetzen

Nur, wenn der Empfänger seinen Key auf einen Keyserver hochgeladen hat.
In der Mail ist der nicht enthalten. Keys von Keyservern holen kann aber
jeder, dazu muss er nicht als man-in-the-middle eine Mail abfangen und
manipulieren. Und Mail signieren kann er überhaupt nicht, dazu bräuchte
er den private key des Senders.

Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
On Tue, May 15, 2018 08:06, J. Fahrner wrote:

> Am 2018-05-15 05:23, schrieb Walter H.:
>> schlimmer finde ich ein ganz anderes Szenario, da er ja die
>> verschlüsselte Mail im Original hat, hat er auch den Public Key des
>> Empfängers, und damit kann er dann den kompletten verschlüsselten
>> Inhalt durch was anderes ersetzen
>
> Nur, wenn der Empfänger seinen Key auf einen Keyserver hochgeladen hat.
> In der Mail ist der nicht enthalten. Keys von Keyservern holen kann aber
> jeder, dazu muss er nicht als man-in-the-middle eine Mail abfangen und
> manipulieren. Und Mail signieren kann er überhaupt nicht, dazu bräuchte
> er den private key des Senders.

das ist ja das schöne, wenn der Böse als Man-in-the-Middle das veranstaltet,
dann kommt die Mail eben bei Dir so an, wie wenn ich sie verschickt hätte ...
(er beschädigt in 90% der Fälle die DKIM Signatur eben nicht)
und signieren braucht er die Mail auch nicht ...


Reply | Threaded
Open this post in threaded view
|

Re: #efail

lst_hoe02
In reply to this post by J. Fahrner

Zitat von "J. Fahrner" <[hidden email]>:

> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>> middle",
>
> Der "man in the middle" modifiziert die Mail und fügt einen Anhang  
> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was  
> der Empfänger ja leicht feststellen kann (so er denn die Signatur  
> prüft).

Jede Form der Integritätssicherung die auch sinnvoll verwendet wird  
umgeht das Problem. Der eigentliche Fail liegt aber im verwenden von  
HTML und dem nachladen externer Inhalte. Wer sowas macht braucht sich  
auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.



Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
On Tue, May 15, 2018 09:03, [hidden email] wrote:

>
> Zitat von "J. Fahrner" <[hidden email]>:
>
>> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>>> middle",
>>
>> Der "man in the middle" modifiziert die Mail und fügt einen Anhang
>> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was
>> der Empfänger ja leicht feststellen kann (so er denn die Signatur
>> prüft).
>
> Jede Form der Integritätssicherung die auch sinnvoll verwendet wird
> umgeht das Problem.

leider nicht;

> Der eigentliche Fail liegt aber im verwenden von
> HTML und dem nachladen externer Inhalte.

Nein, sondern in der schlampigen Implementierung; wie kommt  ein Mail
client auch nur annähernd auf die Idee, obwohl im Header eindeutig im
MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit ein
BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an
statt einen Fehler auszugeben ...

> Wer sowas macht braucht sich
> auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.

nicht wirklich;


Reply | Threaded
Open this post in threaded view
|

Re: #efail

lst_hoe02

Zitat von "Walter H." <[hidden email]>:

> On Tue, May 15, 2018 09:03, [hidden email] wrote:
>>
>> Zitat von "J. Fahrner" <[hidden email]>:
>>
>>> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>>>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>>>> middle",
>>>
>>> Der "man in the middle" modifiziert die Mail und fügt einen Anhang
>>> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was
>>> der Empfänger ja leicht feststellen kann (so er denn die Signatur
>>> prüft).
>>
>> Jede Form der Integritätssicherung die auch sinnvoll verwendet wird
>> umgeht das Problem.
>
> leider nicht;
>
>> Der eigentliche Fail liegt aber im verwenden von
>> HTML und dem nachladen externer Inhalte.
>
> Nein, sondern in der schlampigen Implementierung; wie kommt  ein Mail
> client auch nur annähernd auf die Idee, obwohl im Header eindeutig im
> MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit ein
> BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an
> statt einen Fehler auszugeben ...
>
>> Wer sowas macht braucht sich
>> auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
>
> nicht wirklich;

Multipart MIME erlaubt alles mögliche. Der Angreifer kann auch ohne  
Problem die ganze E-Mail nochmal verschlüsseln, das kann JEDER der den  
öffentlichen Schlüssel hat.
Das Problem besteht darin das externe Inhalte nachgeladen werden  
obwohl eine verschlüsselte E-Mail nicht vertrauenswürdiger ist als  
eine beliebige Spam E-Mail. Erst eine gültige Signatur wäre ein Grund  
für zusätzliches Vertrauen.
Jeder der keine externen Inhalte zulässt ist von diesem Problem NICHT  
betroffen.


Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
On Tue, May 15, 2018 11:57, [hidden email] wrote:

>
> Zitat von "Walter H." <[hidden email]>:
>
>> On Tue, May 15, 2018 09:03, [hidden email] wrote:
>>>
>>> Zitat von "J. Fahrner" <[hidden email]>:
>>>
>>>> Am 2018-05-14 18:32, schrieb Robert Schetterer:
>>>>> ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
>>>>> middle",
>>>>
>>>> Der "man in the middle" modifiziert die Mail und fügt einen Anhang
>>>> vorne und hinten an. Damit passt die DKIM-Signatur nicht mehr, was
>>>> der Empfänger ja leicht feststellen kann (so er denn die Signatur
>>>> prüft).
>>>
>>> Jede Form der Integritätssicherung die auch sinnvoll verwendet wird
>>> umgeht das Problem.
>>
>> leider nicht;
>>
>>> Der eigentliche Fail liegt aber im verwenden von
>>> HTML und dem nachladen externer Inhalte.
>>
>> Nein, sondern in der schlampigen Implementierung; wie kommt  ein Mail
>> client auch nur annähernd auf die Idee, obwohl im Header eindeutig im
>> MIME-Type steht, daß es sich um was verschlüsseltes handelt, und damit
>> ein
>> BASE64-Datenstrom zu erwarten ist, etwas anderes hier mitzubeachten an
>> statt einen Fehler auszugeben ...
>>
>>> Wer sowas macht braucht sich
>>> auch um Verschlüsselung und Signaturen keine Gedanken mehr zu machen.
>>
>> nicht wirklich;
>
> Multipart MIME erlaubt alles mögliche.

stimmt, im Mail-Header steht aber das

MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64



Reply | Threaded
Open this post in threaded view
|

Re: #efail

lst_hoe02

Zitat von "Walter H." <[hidden email]>:
>
> stimmt, im Mail-Header steht aber das
>
> MIME-Version: 1.0
> Content-Disposition: attachment; filename="smime.p7m"
> Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
> name="smime.p7m"
> Content-Transfer-Encoding: base64

https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-mail-client.html

Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht  
solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.



Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
On Tue, May 15, 2018 12:34, [hidden email] wrote:

>
> Zitat von "Walter H." <[hidden email]>:
>>
>> stimmt, im Mail-Header steht aber das
>>
>> MIME-Version: 1.0
>> Content-Disposition: attachment; filename="smime.p7m"
>> Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
>> name="smime.p7m"
>> Content-Transfer-Encoding: base64
>
> https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-mail-client.html
>
> Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht
> solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.

ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte hat
mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum anderen
habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;

Reply | Threaded
Open this post in threaded view
|

Re: #efail

lst_hoe02

Zitat von "Walter H." <[hidden email]>:

> On Tue, May 15, 2018 12:34, [hidden email] wrote:
>>
>> Zitat von "Walter H." <[hidden email]>:
>>>
>>> stimmt, im Mail-Header steht aber das
>>>
>>> MIME-Version: 1.0
>>> Content-Disposition: attachment; filename="smime.p7m"
>>> Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
>>> name="smime.p7m"
>>> Content-Transfer-Encoding: base64
>>
>> https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-mail-client.html
>>
>> Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht
>> solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.
>
> ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte hat
> mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum anderen
> habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;

Es geht darum das man entweder die MIME Struktur ändert wenn der  
Mailclient das toleriert oder das man direkt den verschlüsselten Teil  
"ergänzt", was durch CBC wohl möglich ist *ohne* das die Struktur  
ungültig wird. D.h. das Argument das es *nur* ein Fehler im Mailclient  
ist der die kaputte MIME Struktur akzeptiert ist falsch. Es ist ein  
Fehler das man extern (HTML) Inhalte zulässt, aber das war schon immer  
ein Fehler.


Reply | Threaded
Open this post in threaded view
|

Re: #efail

Walter H.
On Tue, May 15, 2018 15:06, [hidden email] wrote:

>
> Zitat von "Walter H." <[hidden email]>:
>
>> On Tue, May 15, 2018 12:34, [hidden email] wrote:
>>>
>>> Zitat von "Walter H." <[hidden email]>:
>>>>
>>>> stimmt, im Mail-Header steht aber das
>>>>
>>>> MIME-Version: 1.0
>>>> Content-Disposition: attachment; filename="smime.p7m"
>>>> Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
>>>> name="smime.p7m"
>>>> Content-Transfer-Encoding: base64
>>>
>>> https://www.ciphermail.com/blog/efail-who-is-vulnerable-pgp-smime-or-your-mail-client.html
>>>
>>> Der zweite Teil. Dort steht auch warum ein Signatur das ganze umgeht
>>> solange die Gültigkeit bzw. die Abwesenheit der Signatur beachtet wird.
>>
>> ich weiß nicht was Du da liest, aber eine multiplart/mixed Geschichte
>> hat
>> mit Mailverschlüsselung reichlich wenig zu tun zum einem, und zum
>> anderen
>> habe ich ja bereits erwähnt, daß Mailprogramme mehr als verbugt sind;
>
> Es geht darum das man entweder die MIME Struktur ändert wenn der
> Mailclient das toleriert

sagte ja Bug ..., es darf auch ein Fehler geliefert werden ...

> D.h. das Argument das es *nur* ein Fehler im Mailclient
> ist der die kaputte MIME Struktur akzeptiert ist falsch.

Nein das ist der Bug schlechthin;

> Es ist ein Fehler das man extern (HTML) Inhalte zulässt,
> aber das war schon immer ein Fehler.

das kommt davon, wenn Mail clients aus Browsern herausgewachsen sind;
kritischer als das ist die Tatsache, daß ein Mail auch ausführbare Skripte
enthalten kann ...