35C3 - Attacking end-to-end email encryption

35C3 preroll music

Herald: The following talk is about email
encryption. Who worries that their email

encryption might be capable of being
hacked or cracked? Worry not as far as I'm

told it still is rather secure. But. And
the but will be answered by Sebastian

Schinzel who is one of the eight security
researchers who uncovered the drama and

the details behind e-fail. A recently
occurred issue with OpenPGP and S/MIME

in a lot of email clients. All the
technical details he will dig into so

please give a warm hand of applause for
Sebastian Schinzel.

applause

Sebastian: So it's good to be back. Thank
you everyone for coming. My name is

Sebastian. It's my fourth talk here at the
CCC. And the other talks that I did were

also on encryption so I somehow like
encryption and I like analyzing encryption

and I like to break encryption. So I did a
talk on TLS where we found an attack

against TLS and against XML encryption for
example. And I usually start my talk by

asking Who's using this this specific
technology, right? Because when you when

you usually when you're analyzing or doing
a talk about a communication protocol you

ask the people who's using that and you
know for e-mail it would be silly, right?

Because, who's using e-mail.
Every one of you is using e-mail.

OK. Because I don't know. I mean when you
started using the Internet like

in the last 20 years or so usually
the first thing that you do you dial in

onto the Internet and you make
yourself an e-mail address, right?

So everyone has everyone uses e-mail. But
let's take a look at how things work when

when you send an email. So when you click
in your email client when you when you

compose an email and you click into your
email client "Send". So the first thing is

on one of your devices you're using the
local network and there's a green arrow

because it's under your control. So you
can define by yourself how secure this

link is gonna be. Then you use the next
connection and the next connection will be

to your SMTP server. And this is also a
green arrow because it's under your control.

Okay. You can control this
and usually it's TLS.

The same as valid for your IMAP
folder because always when you send an

email via SMTP you will upload a copy to
your "sent" folder on IMAP and it uses TLS

in most of the cases so therefore the
arrow is green. The arrow is not that

green anymore when it comes to the backup
strategy for example an archiving strategy

of your email provider which may be gmail
or gmx for example or your company. OK.

But you may have a chance to know the
administrators and ask him whether they

are doing a good job and stuff like
that. You're also - it's not under your

control where else your email is uploaded
to. So for example in order to check it

for antivirus or anti spam and stuff like
that, right? So it gets uploaded to some

cloud, right? Because you want to do a
spam filtering and then it goes out to the

Internet and you know we learned what's
happening on the Internet. People are

listening in on the Internet and we heard
from Edward Snowden for example that many

nation state actors and agencies are
doing this as well they are listening into

your e-mails or they at least try to. And
then the arrows get red as soon as it hits

the SMTP server of the receiver. Right.
Because you don't really know whether they

are using TLS, encryption in any case. You
don't know whether they upload it to

another antivirus vendor or so and then it
gets uploaded to the IMAP folder to the

inbox of the receiver where it gets
archived again, right? There is a backup

is being done and stuff like that, it's
archived. And then finally the receiver of

the e-mail has the ability to check his
own email and retrieve the e-mail

from his inbox. OK. So even if you know
that the other person that you've just

sent the e-mail to does a good job in
securing it and uses encryption everywhere

and so on and so on.
You never know whether there's some

attacker or so who has compromised the
infrastructure and so on and so on. OK.

And this problem multiplies.
When you send an e-mail to multiple people

because then all of a sudden the e-mail
that you just sent, your e-mail, hits

infrastructures of many other people. OK?
So many people have access to this

e-mail and this is the first thing that I
want to - this is the first point that I

want to make in this talk. People usually
talk about their e-mail. It's my e-mail,

you know? And when I run my own mail server
it's going to be secure but this is not

the case. I mean the the point of
using e-mail is distributing it to your

friends to your colleagues and so on and
so on because we want to exchange.

It's a communication method but the
communication is archived so people

archive this and so on and so on. So it's
it's a mess basically. OK. So for the rest

of this talk we need to have some
assumption that someone has access to the

e-mails. OK. Because right. We just
learned that it's distributed. You're

archiving your own e-mails in your IMAP
folder and so on and so on I have the

e-mails of the last 15 years or so in my
in my IMAP folder and if someone gets

access to it - right - boom. I have a
problem. Okay. And in order to cope with

this people came up with end-to-end
encryption. And there's two competing

standards out there. The first one is
OpenPGP. It was first defined in 1991 from

Phil Zimmermann invited it. And this was
like this happened in the first crypto

wars. So this is a very interesting story.
And it's the most widely used e-mail

clients they they support OpenPGP but
only when you when you download the

plug-in, OK? For S/MIME you usually
have native support in most of the

applications so you just get an S/MIME
certificate and off you go.

You can just use it and it just works out
of the box but it's mostly used by

corporate organizations and military for
example right. Not so much by privacy

advocates like OpenPGP.
Now we can't measure very well how many

people use S/MIME. We tried but there
doesn't seem to be a public source where

we can measure this but we can do it on
PGP because PGP has key servers and you

can upload your key there so that people
can communicate with you in a secure

manner. And this statistic here is the
amount of new published public keys per

month. And it started off very low in
1997. Then in 2003 we saw a constant rise

until 2013 where we see a a spike here
where it more than doubled. Does anyone

know why we saw this spike in 2013?
Someone in the audience: Snowden!

Sebastian: Snowden right. Edward Snowden
we had the Snowden revelations and Edward

Snowden uses PGP to communicate with the
journalists who did the actual, like,

disclosure of the documents. And so we see
this in the uploader keys so people use

PGP much more. We also see this in
the amount of daily users of Enigmail

which is the plugin for Thunderbird.
And you can extract this

information and there we also see around
2013 we see a jump and it increased by 50

percent or so something like this. So
people use PGP, right? It's not that many

when you compare it to how many people use
e-mail a few hundred thousand is not that

much but still it's a substantial number.
The problem here is we know for a fact

that in the last 20 years or so especially
non-technical users are not able to use

PGP in a secure manner. Okay. So we have
the first paper from '99: "Why Johnny

Can't encrypt" and then we have a follow
up paper from 2006: "Why Johnny still

can't encrypt", OK? So OK. Must've
been better I hope and then in 2015 we

have "why Johnny Still, Still can't
encrypt". OK? so we have a long story

where people try to use PGP but failed,
OK? And this is not something that is

inherent in an OpenPGP. We have the same
papers for S/MIME where they said

novice users - and where they confronted
novice users with with S/MIME and they

failed, basically. They weren't able to
use it in a secure manner. Okay.

So therefore in order to enable people to
use PGP, especially PGP and S/MIME in a

secure manner you have many tutorials out
there. And this is a very interesting

tutorial because it's the original video
that Edward Snowden recorded in order to

teach Glenn Greenwald how to use openPGP.
It's still on Vimeo. The original video is

still there. And what is interesting there
is he doesn't recommend a plugin for an

email client. He basically says just use
web mail and use this PGP standalone

application type your message there click
encrypt and copy and paste the ciphertext

into your web mail, OK? So there's no
integration and others recommend for

example Enigmail or GPGtools. Enigmail is
the plugin for Thunderbird and GPGtools is

the plug in for Apple mail, which
means that most of them had HTML

switched on which is an interesting fact.
OK. For something that we are going to

talk about later. So I thought about how
can I do this talk. And this is how I came

up with the agenda. So we start off with
some attacks that are very I find pretty

interesting. At least for an academic they
are pretty interesting, and we slowly

degrade to pretty silly attacks and you
decide for yourself whether you would fall

for it or not. I came to the conclusion
that I would probably fall for them. OK,

I lied. So we start off with something
that is even worse than silly. So what is

it what's the worst thing that can happen
when you're sending an encrypted mail.

Audience: You send your private key.

Sebastian: if you send your private key
there would be bad. What's even worse?

Audience: You forget to encrypt.

Sebastian: you send a plain text. Okay
okay. So in 2014 there was a bug in

Enigmail which is documented in their bug
tracker. So basically you compose an e-mail

you tell Enigmail to sign and encrypt
it, and then you send it and it will be

sent in plain text. Okay. Oh okay. This is
not good. In 2017 Outlook did it much better

because they did encrypt it but they
packed the plain text along with the

ciphertext. (Audience: laughing) Okay. Bad.
And then in 2018 you may remember this is

just a few months back or so Enigmail or
pretty easy privacy. It's a plugin to

Enigmail, so a plugin to a plugin that's
actually used for novice users. It gave

the feedback that the email that you're
composing will be encrypted but it wasn't.

Okay. And the good news here is: the
e-mail attacks don't apply here because,

OK, I mean, it's about I don't want to make
fun of any developers. The point that I'm

trying to make here is that email is a
plaintext protocol and it's always very

difficult to make a protocol that was made
for plain text delivery - to make this

encrypted. When you have a plaintext
fallback you're into trouble. Okay. And we

we saw the same basically with HTTP and
HTTPS. OK. So HTTPS is like now secure but

they hit the same issues right and
browsers and so they were falling back to

HTTP and so on and so on. So it's really
really difficult. Now that we have this

out of the way. Okay. We tried to look at
the interesting interesting box and before

we start I want to make a short
introduction into how the cryptography in

S/MIME and PGP work. And I just make one
introduction because both are the same

from the viewpoint of the attacks that I'm
going to present. Okay. Both are very

similar actually. So we start off by
writing a message, m, this is here we

generate a session key, s, that that's
basically a random session key and we use

this session key to encrypt the message
and make a cipher text, c, and we use AES

or triple DES for example any symmetric
cipher will do here.

Then we use this session key that we just
generated and encrypt this with a public

key of the recipient and we get a K and we
pack this K into the message so everything

will be packed into a message and sent off
to the receiver. The receiver then

obtains the encrypted email he starts
extracting the ciphertext K and the

ciphertext C. From K he decrypts s which is
the session key, right? And with s he can

decrypt the ciphertext C and retrieves m.
And so both have the same message. Okay.

So it's basically a hybrid encryption you
use symmetric encryption for the actual

encryption off the message and then
asymmetric encryption to just encrypt this

session key. Now, if you attended my
previous talks I talk a lot about

ciphertext malleability. So you make tiny
changes to a cipher text and it will lead

to predictable changes in the plaintext
which is strange, right? So we would

assume when we just flip a bit here
somewhere, okay? Here's a bit that just

flipped and where we decrypted we get
something like this. Usually you would

think OK. It's total garbage. Nothing
sensible should come out of

this but we see something like this. Most
of the message is still intact. We just

have a few randomly looking junk binary
stuff in there and we see one changed

character here. That used to be "email"
and now it's "efail". Okay so there was

just some bit flipping happening here. In
order to understand this we need to

introduce something that we called a mode
of operation. AES or any other block

cipher has the property that it uses
blocks. In most cases it's 16 bytes.

And when you want to encrypt more than 16
bytes you need to call AES multiple times

and you split it into blocks and CBC is
one way of connecting these ciphertext

blocks so the decryption works like this.
You have the first ciphertext block the

second ciphertext block and the third
ciphertext block. Only the second one is

decrypted so C1 is decrypted using AES and
your key for example. And the result here

is not directly the plaintext but it will
be XORed with C0 which will we would also

call an initialization vector. Okay so
whatever is written in here will be XORed

on whatever comes out of this description
and we get this plaintext here. Now when

we flip a bit or when we change a certain
byte in C0 we change whatever comes out

here of the decryption and we will
flip the same bit at the same position in

the plaintext which is interesting because
now when we say we use the original c0 and

XOR it with p0. So when we XOR it when we
XOR two times the same value we get

basically a block of all zeros which is
like a blank sheet of paper that we can

write on and we call this thing - these two
blocks here in combination - we call this a

CBC gadget because we can reuse it as as
much as we want. And when we now take a

chosen ciphertext the nice thing is here
we just XOR it - the chosen ciphertext on

this initialization vector and it means
that it will here result in a chosen

ciphertext.
So this requires that we know the value of

p0. We need to guess this value of p0. And
this is always true at least for S/MIME

because all S/MIME emails start with a
content type so we always know the first

bytes. So this is valid. We can do this
now. This was like the perfect

scenario. It does have some drawbacks
because when we tried to do the same for

C1 we switch, we flip, a bit here then we
flip a bit also here. But the decryption

of C1 results in this random junk and we
can't do anything about it. We don't know

whatever will come out here and we can't
control it. Okay we just have to deal with

it. It's gonna be there when we use the
CBC gadgets and we have to deal with it.

We have to find a way to deal with it and
now we can explain this behavior, you know?

You remember this e-mail where we just
flipped a single bit and we saw one block

was destroyed basically. And then the
other block we had like we can flip

arbitrary bits. That's the explanation
for it. Now how do you how do

you deal with it. How should a proper
crypto protocol deal with it. Usually you

do something that is called a message
authentication code. It's not a digital

signature and message authentication code
is something like a checksum a

cryptographic checksum that is
put right next to the

encrypted message and that can be
checked after decryption or for

decryption. OK? The message
authentication code is solely there to

detect changes of a ciphertext. Digital
signatures are different especially in the

mail context because they're pretty
much totally separate from

the decryption part. So digital signatures
are merely only used to display an icon

for example for valid signature or invalid
signature. And the problem here is a smart

attacker can use a signed email and strip
off the signature. Okay. We just strip off

this part that we know there's a signature
we can remove the signature and then this

doesn't mean there will be an invalid
signature but will get something like

this. This is the icon in thunderbird for
encrypted and not signed so we can simply

strip off a signature and there's valid
reasons to send an encrypted email without

doing a digital signature on it, right? So
we want to do both. So digital

signatures won't prevent this
attack. So how does S/MIME look like?

Basically, I mean, most of you will have
heard of MIME. MIME is like a standard

that we use in emails anyway. Here
we have an e-mail header. It looks very

similar to HTTP. We have content type,
colon, empty space, and then it's

whatever is coming now for data. And then
we have an e-mail body with envelope data

and there we have the list of the of the
encrypted session keys that this

ciphertext was encrypted with. And after
that we have the encrypted content info

here. This part is the encrypted part
where the actual message where the actual

message lies. And now when you look
closely and you squint you see there's no

message authentication code and it's not
because I left them out but because S/MIME

doesn't define one. So S/MIME doesn't have
a message authentication code which

means it cannot detect bye the standard
whether a message was changed - whether

it was changed or not.
So how can we attack this?

How can we use it? I think you all have a
feeling that this shouldn't work, OK? This

is nothing that is supposed to work.
This is the plain text that we want to

exfiltrate and we only know the first
block. We can pretty much always guess the

first block because it's always content
type: text/html or text/plain something

like this. Now we can use this as a gadget
here and write our arbitrary plain text.

We have a random block and then chosen
plain text. Then we copy it again. We

again have a random block and some chosen
plain text. Then we have a random block

and a chosen plain text. Then we have a
random block and a chosen plain text. Then

we copy here the original ciphertext and
we close this thing. And when you look

closely again you'll see that we're
building HTML here right. That's the base

tag. That's an image tag. It uses a URL.
That is not closed here. It will be closed

down here. And this is effectively the
URL. OK. A URL-path and will thus be

exfiltrated. So when this XML is
interpreted the actual plain text is sent

to the server. And here we have an old
Thunderbird. So that is a version of

before May and before we did the
disclosure. We first compose a message

just to have some PGP ciphertext. This is
a very secret message. And here we have

the attack e-mail that is already
prepared. And now it asks us

"This remote content in here. What do you
want to do?" And we just for the

laughs just - like this - we just click it
and we see always now when we select the

message an HTTP request is done to this
to this URL. And when we decode this - it

looks pretty - it's encoded. But basically
what we have here now you see here is the

secret message and here is random junk.
And here again is random junk, right? So

it was successfully exfiltrated. This was
the first proof of concept that we had.

Right? And. Okay right? And so this works.
This is like - this

dialog here that you get in Thunderbird
that ask if should I should a load remote

images. Yes or no. This is basically
everything that is keeping you from losing

your your PGP or S/MIME ciphertext - S/MIME
we're talking about S/MIME here. Now what we

did next was we were asking ourselves, OK:
It works with remote images. We understand

this ,but what other back channels do we
have? Back channel is something where

your email client is communicating
over the network. That's. So it's not

necessarily exfiltrating but it's just
like how can we convince a client to make

a connection to somewhere else. Now I
colored in red all the e-mail clients that

require user interaction - that always
require user interaction before it

opens up a network connection somewhere.
In orange we say that there's no user

interaction. So these are the clients that
allow for example loading remote images by

default. OK. There's mail app for example
there's gmail for example. They will not

ask you they will just load it, OK? And
but what we think is worse and therefore

we colored it red are the clients that say
we won't load remote images or any other

way of communicating over the network. But
then they will because we want bypasses.

So because preventing loading remote
images is basically a firewall and we

bypass this local firewall and found
several ways of extracting it. And there's

even four or five of them that even allow
JavaScript execution in a mail

client. I mean come on this is really
weird. So basically 40 of 47 clients have

back channels that require no user
interaction at all. And now we went out

and tried to think about how can we
exfiltrate plain text over it. And this

is the final table the final result
table for S/MIME and it looks pretty

grim, right? So the red ones means it's
vulnerable. That means we could exfiltrate

plain text successfully. The ones with a
dash they don't support S/MIME and Claws

and Mutt we just didn't find any
remote connection there.

Okay. Which is good. Which is good. Yeah.
That's a round of applause. Right.

applause

So I didn't say what S in S/MIME means.
It actually means super. So it's super

MIME. I don't know. Is it Super MIME? And
basically his kryptonite. You know the the

super villan of Super MIME is HTML. Right.
You could say this. So S/MIME is broken

by HTML and it's a very annoying
kryptonite because it jumps you

know like it's ugly colors. Now this is my
Thunderbird that I have on my Mac at home.

So this is like something that I recorded
two days ago or so. And here I want to try

to show you a way of exfiltrading the data
without using HTML. So HTML here is

disabled. This is the message that we want
to break. And here we see the same message

where we just changed, using
gadgeting, we just changed the URL.

So in Thunderbird when you disable HTML
it will still highlight the links and when

you click on it you're gonna exfiltrate
plain text, right. So we require a little

bit of user interaction but we can
basically change a S/MIME ciphertext in a

way that it will contain links and when
you click a single link you will lose your

your plain text. It's just a single click
on it and the thing here is - I mean this

is not a zero day in e-mail client, right?
You just can't do anything about it.

That's the problem. Okay. So people said
okay so efail - just disable HTML and then

you'll be fine. But the problem here is
basically efail should work with any

format that supports external connections.
So as soon as you have a file format for

example that supports external connections
like PDF here, right? This is a PDF. When

you click on it it will warn you and will
say "Do you really want to make a

connection to this domain?" And if you
click "yes" you will do a connection there,

right? And when you look at the how
the URL is encoded in the PDF when you

open the PDF in an hex editor you see it's
just a string just like HTML,

basically, right? So we could in theory
use this as well. So you could change and

S/MIME e-mail that it contains a PDF
attachment and when you click the PDF

attachment it will exfiltrate. With no
user interaction, it works with with

Microsoft Word for example. So that's a
doc file and doc files allow external

images that will load. It has no user
interaction at all, so you just open it and

the request will happen and the only
problem that we're having here is it's not

an ASCII URL, it's a Unicode URL. So I'm
not sure whether this works with

exfiltration but hey no user interaction,
right? And. Now you could say "Okay PDF,

Microsoft Word. That's very bad." - The same
works in in LibreOffice and it's not a

bug in the viewers, right? It's a basic
feature that has been in these standards

forever, right? So it's a thing that will
be supported. It's not a zero day

vulnerability in these viewers. It's just
the file format support it, so you can

abuse it. If you have some time: here's a
challenge for you. If someone is able to

make a successful demo for exfiltrating an
S/MIME e-mail using a PDF or a doc file for

example you will get a crate of Club Mate
and some efail swag, if you want to?

OK. So what happened after we disclosed
it. Obviously we disclosed it to all the

manufacturers and so on. And there's an
S/MIME draft of a new RFC. So there's a

working group and they already
massaged the countermeasures into the

current RFC draft. So for example to
counter the CBC gadget attack they say: use

a GCM which is not right now in the in the
current RFC but in a draft it's already in.

And so they're referencing
the paper and they're saying:

"OK you need to do this and do this as
quickly as possible." And the second Efail

attack which I'll talk about very soon is
also mitigated in this in this RFC draft.

OK. So S/MIME was pretty much broken. And
you can just try to convince your e-mail

client not to do any external connections.
OK. That's all you have. Which at least,

I mean, for cryptographer this means
broken, OK? When you have to rely

on the viewer not making any connections,
the cryptography is broken. So what are

the changes to OpenPGP because there are
substantial differences to to OpenPGP.

So first of all PGP uses a variation of the
CFB-mode. It's not CBC-mode but CFB-mode.

And they have pretty similar, they are
very similar. So I won't show it here,

if you are looking for the details, please
look at the paper, but it's very similar.

We can also flip bits and we also have
these chunk bits in the middle and so on.

What really caused a lot of headaches is
the plain text compression. So that means

in OpenPGP you don't encrypt directly the
plain text but you deflate it

before you encrypt it and that makes it
very hard to guess plain text bytes, because

for our attack to work we need to guess plain
text bytes and when we know plain text

certain parts of the plain text but it's
deflated we have a problem. Okay? And what

is also the most important thing is that
OpenPGP defines a modification

detection code, which is basically this is
the message here. And the modification

detection code is a hash of the message
appended at the plain text and

then encrypted. Okay? Which should detect
plain text modifications. Now

how does the OpenPGP standard say how to
deal with broken MDCs when an MDC is not

valid. Well, they say an implementation
must treat an MDC failure as a security

problem, but they don't say what is a
security problem. What do you need to do

then. And the implementation may allow the
user access to the erroneous data. So the

modified data may be passed on to the
e-mail clients.

And basically we tried to do this, right?
But before we go there we looked at how

many keys on the public key servers
support MDCs at all.

So MDC is a feature that came to OpenPGP
in the early 2000s and before that it

wasn't possible to use it. And so
therefore to make this to make the change

from software that doesn't use MDC versus
software that that does use MDC they

encoded in the key whether you support MDC
or not. And here you see those keys that

were generated in 2000 they don't support
MDCs and the green ones - they support

it. But, the problem is, when you accumulate
all the valid keys in PGP that don't

support MDCs we still see that at the key
servers right now in 2017 we have

something like one point seven million of
the keys that don't support MDC. So when I

sent an email to one of these people my
implementation will not use an MDC, or

right? They - yeah I'll come to this later.
So we thought about okay how

can we make a structured analysis how the
MDC is treated with. The OpenPGP standard

is not clear what to do with it. And so
we have three test cases. First of all, we

try to strip the MDC. So we just use this
encrypted packet here and strip off at the

end. We just say OK it's incorrect, right?
So we make our modification in the

plain text and see whether they will detect
this error or we could also do this

downgrade from the packet type that
supports MDC to the old packet type that

does not support MDC, right? And when we
check this, especially with the most widely

used clients we saw that Thunderbird and
Enigmail and Apple Mail and GPG tools they

basically ignored the MDC and that was the
reason why we didn't see the MDC as very

important because in our test systems it
wasn't just treated, OK?

Now what are the Efail related changes
to OpenPGP. And we're talking about the

changes that were done after we
disclosed this to them.

First of all they made something that is
very important.

They say that the packet type and PGP that
does not support MDC is now obsolete. So

you must not use this packet type anymore.
You must ignore it. Which also means that

when you have used non MDC messages in
your mailbox you will not be able to open

them anymore, OK? Yeah. That's a
problem. Then they also said: "OK, what

is supposed to happen when the MDC
was wrong?" And this is the text that we

have already seen where we said "the
implementation may allow the user access

to the erroneous data" and they changed
this in the current draft to "the

implementation should not allow the user
to process the erroneous data." Right? They

must still warn the user. And so on and so
on. But it should not allow the user, which

is good. That's a good change. So this was
the - this MDC check is a bit troublesome

because it's right at the end of the
plain text, so you can only check the MDC

when you have fully decrypted the message
which means when you have a large e-mail

or a large back-up or so you have to fully
decrypt it and afterwards only you can tell

whether it was valid or not. And the
solution of GnuPG is that it will just

stream - while it decrypts it will stream
the data to to the e-mail client and

afterwards tell it whether it's supposed
to use it or not, OK? So here's your

email, here's your e-mail, here's your - Oh no!
You must not use it, please forget it, right?

Which is not fine. This is not a safe way of
doing it. So the current OpenPGP draft,

before Efail, before we did the
disclosure already supported something

that they called chunking. So they not
only have an MDC some kind of a MAC at the

end of the plain text, but they chunk it
into more chunks and each of these

has a MAC - a real MAC - which is much better
because, right? You can authenticate chunks

and cache it before you give it to the
app. The problem is that the standard says

that 120MB is like a good chunk size
which is far too big, right? Far too big.

And when we look at the Efail related
changes to GnuPG. So for example MDCs

where they used to be warnings. So when
GnuPG was detecting that an MDC is not

there or it's wrong, they would just warn
it but it would still print it out. GnuPG

now, like, fails it makes a hard failure now
and GnuPG now always uses the MDC

independently if the key denotes that
the receiver can use it or not. Which

is also very good but it is a breaking
change, rightß So when you have people that

send you PGP e-mails and you can't decrypt
them anymore you have to tell them that

they need to update GnuPG.
They also say that the default chunk size

is 120 megabyte which means they still
stream unauthenticated plaintext so they

missed this opportunity to make
this go away, which is a pity.

Okay. What is not answered neither by
S/MIME nor by PGP: How to deal with past

e-mails? So, basically all the emails that
you're sending in S/MIME encrypted right

now are insecure and the old ones that
don't use MDC in PGP they are also not

secure and nobody talks about what's
supposed to happen with them, right?

Okay, that was the interesting attack. That

was the one that was really
cryptographically involving,

that required changes to the standards and
so on. Now let's look at something that's

a bit more silly. Okay, so we have Alice
writes an e-mail to Bob, we encrypt it and

send it off to Bob. Now here we have the
original e-mail and now Eve composes an

attack e-mail. And it somehow gained access
to the PGP ciphertext, it also works for

S/MIME, right, it's independent. It's a
vulnerability in the in the mail clients.

And now we don't change the ciphertext we
just surround it with other MIME parts

that are of type HTML and that exfiltrated
the same as we did before only that we

don't need to change the
ciphertext at all, right?

So basically when this is decrypted it
will be replaced with a plain text in

place and then it will be merged into one
document. And now I have to tell you

something that many people don't seem to
know. All mail clients, except mutt, they

use HTML to view emails. So even when you
disable HTML it basically means that they

will use incoming HTML e-mails, parse
them, transform them into something that

looks like ASCII and display this in HTML.
Okay. So, right? There is no such thing as

ASCII e-mails with most of the clients. So
but here now you have one HTML document

which basically means the same, it will
exfiltrate and very easy. Okay? So let's

look here and on this video here we have
we create one ciphertext we encrypt it. We

use Apple Mail because this was one of the
two vulnerable clients and we just open this

email in order to view the PGP ciphertext,
right? We look at the raw code of the

ciphertext, raw source and we scroll down
and there we see there's the PGP message,

OK? Now in the next minute Eve somehow
gained access to this ciphertext and it

will compose a attacker email which is
hidden in a python program that we just

use to generate an e-mail, so this
happened now in the background, you will

see an e-mail is incoming. Here we
just open the access log for this and when

we click on it, right at this time, it will
be exfiltrated. Okay. So very easy attack,

anyone can do this, you don't need to know
anything about cryptography you only need

to understand a little bit of HTML and a
little bit of MIME and you can execute

this. You know what's worse than this? How
about we just exfiltrate many e-mails with

a single attack e-mail because we could
basically use - here we open an image,

here's the ciphertext. Here would close
it. Then we open another image. Here's the

second ciphertext. Then we close it. Then
we open a third one and so on and so on.

And what you see here, on the left hand
side you see there's 100 ciphertext packed

into one e-mail that is sent to this
client. I blurred this because I used 100

GPG e-mails that I sent, right? I didn't
want to show them to you. Now this takes

some time. Now it's like decrypting,
decrypting, decrypting, decrypting. And when

you look at the terminal on the left side
you see 100 e-mails getting exfiltated,

right? Automatically simply by opening a
single email. Okay this is horrifying.

Applause

And when I say horrifying I'm really
literally mean: this is horrifying. So we

were like afraid OK when we disclose this
then people will start attacking this

within the hour or so, OK? And so we
disclosed this in early 2018. End of 2017,

early 2018. And in May 2018 we had already
shifted the disclosure date twice and in

May we said OK we won't shift this
anymore. And so therefore we said OK we go

online but we want to make a
preannouncement. We want to

warn the people that if you use
PGP or S/MIME for very sensitive

communication you should disable it in
your e-mail client for now. These are the

original tweets that we sent and we said:
OK, In a day, OK, when you have done this

then we will disclose everything, OK? We
will go online with the paper and

everything. And now I mean people started
talking about it and then the GnuPG people

started tweeting and they basically broke
the embargo. So they told OK the attack is

working like this. First you do this and
then you do that and then you do that and

they were blabbing and so on and then they
sent it, which is annoying, but then they

sent this. So they said know that new
GnuPG team was not contacted by them in

advance. And this, this really, OK? Then
it got really hot. Okay.

This is not true. I will show you later,
but I mean this tipped off almost anyone

in the INFOSEC community. And we got hate
e-mails and yeah people were really mad

with them, I posted "We did contact them."
and this is like the, these are the

original dates when I talked with Werner
Koch which is the main developer of of

GnuPG. But it was too late. I mean they
they recognized that they said: "Oh yeah, oh

I forgot!" Right? That they sent this paper
here. That writes EFAIL with our names and

a date and an embargo and so on and so on.
And they said they forgot it, OK? But I

mean we lost at this point, OK? People
were hating us. I was called a murderer.

And and so on and so on and so it was
really, really weird. If you're interested

of how things worked, right, this is an
independent summary of the disclosure

timeline from Thomas Ptacek which is not
involved with us at all we have never met

him, but who was so kind to just compile
this just from public information that are

really reliable.
So and then something happened that

we what we could foresee. People were
finding - like there were some patches -

and I told you already that we saw
that these patches are not sufficient.

And two days later people came up with new
style of attacks, new EFAIL attacks and

this was Hanno who found something. So he
said I found a trivial bypass EFAIL is

still exploitable with the latest Enigmail
and Thunderbird - that is three days after

we did the disclosure and he responsibly
disclosed this and so on and so on. So

everything is fine. Micah Lee, from The
Intercept, also developed a proof of

concept exploit that works against Apple
Mail and GPG tools also 2 or 3 days later.

So we were right, right? So people were
finding ways to circumvent the fixes that

were in there. But still I mean, OK, media
was blowing up, OK? And we didn't actually

understand what was really going on there.
But you have to know I mean PGP is like,

one of the main users of PHP, eh of PGP is
journalists, right.

So and they basically, I mean you show
it to them look that's the attack and they

will like what? That's how easy it is? And
that's what you see in the press I guess.

So what are the lessons learned from the
disclosure. So first of all: people kept

complaining, I mean people kept
complaining to us that we didn't stick to

the 90 day disclosure deadline. So
we had more than 200 days disclosure and

we postponed it and so on and so on. And
in the aftermath it didn't make sense

because we were postponing and postponing
it and there were still no reliable fixes.

So we should have stuck to the 90 day
disclosure deadline because after we

disclosed it they were in a rush. They
released patches and stuff like, you know?

So it was, yeah. Be careful with
disclosure preannouncements. The problem

here is people will speculate about the
details. You know, because when you say: "OK

we'll disclose something tomorrow but
we're not going to speak today" - then

journalists will speak to some random
people, right? That they just get their

hands on and they will just try to guess
what it could be. And this means they will

underrate the risk or they will overrate
the risk. Underrate the risk is just

disable external images, loading external
images, then you're fine. That is

underrating and overrating is like: "OK, PGP
is broken, forever", right? Which is not

the case. And they will spread this false
information and you still see this out

there, right? It's documented. People have
issued like papers and so on and so on

with wrong information, provably wrong
information. Which is bad and so these

disclosure preannouncements are bad
because you're not in control of the

communication anymore. That's very bad.
And controlling information flow really is

key after you do the disclosure because
otherwise you get the wrong story out and

this this doesn't help at all. Okay. Let's
look at the last attack, and we call this

reply to attacker.
And I have to give credit to the people of

Cure53, which also found this bug or a
similar very similar version of this bug

as well and disclosed it. But they were
first to disclose it so credit goes to

them, OK? Here, the attacker scenario is
I get an e-mail from some person which

makes sense. It's a benign e-mail. Okay.
It doesn't look bad at all. And a person

wants to trick me to answer this e-mail.
So this is the e-mail that I get. There's

some footer here and stuff like that. And
now we look in the video, it's an old

version of Mail that we use here. Right.
This is the e-mail. We just - and I answer

it, right? Because people were asking
me for an appointment they want to

meet me and I was like yeah sure after my
talk let's just meet. And this is the

attacker e-mail that the attackers opened
and when you look closely down here you'll

see secret stuff here that shouldn't be in
there and that I didn't send actually.

Let's look at the plain text of this
e-mail and the source code of this e-mail.

And when you scroll down you see it's a
mix of just a normal, just a normal

e-mail, benign e-mail. And down here you
find a ciphertext it can be S/MIME it can

be PGP. It doesn't really matter. And
what's happening now is:

I get this e-mail, this here will be
decrypted from my mail client and I don't

see it because I won't scroll down. I'm a
lazy person I'm a top poster. Right, now

you can go boo and so on, OK. But still I
mean top posting is considered evil here.

Because I basically - the attacker was
sending me an e-mail where ciphertext was

hidden in there that my e-mail client was
decrypting and I was replying to this

e-mail sending the attacker the actual
plain text that I just decrypted, without

knowing it. Okay that's silly. Okay. Come
on. That's really silly. Okay. What are

you supposed to do now. What are the
things that you should do. And the

important question here is you should ask
yourself are you targeted by motivated

attackers?
And a motivated attacker is not

necessarily the NSA or so, right? It can
be just, I don't know, Cybercrime people or

so. I mean we we basically came up with
these attacks with 8 people abd the better

part of a year. Which is not you know,
which is a lot of research actually but

it's not like comparable to a nation
state. Right. So if you're targeted by a

motivated attacker and if you say yeah you
are probably targeted by motivated

attackers then avoid e-mail in total.
E-mail is not made for secure

communication. Okay. If you can't avoid it
and there's people who can't avoid using

e-mail they can't just use signal or any
other chat client, then definitely use

OpenPGP and encrypt and decrypt outside of
the mail client. If you are probably not

targeted by motivated attackers, which is
most of you and I presume I would count to

the same people here, definitely prefer
OpenPGP over S/mime because S/mime remains

broken. Right, there is a standard coming
up which fixes most of the stuff. Disable

HTML for encrypted emails and this is like
not that easy. Note that most email

clients use HTML by default and it might
be okay if you fix it, the people that I

hear in the audience. But think of all the
people who are not here in this audience,

who are not technically versed and so on
and so on and they will not disable HTML,

right. So be careful with attachments
which is also very difficult, how can you

be careful with attachments. Right. This
is not very good. And don't top post,

don't cite text in a reply. Okay. That was
my talk. If you want to meet us afterwards

we're gonna go to the Chaos West. There's
a huge and lighted palm and we'll be there

if you have questions you can ask us
there. Thank you very much.

applause

Herald: Thanks a lot Sebastian, for this
interesting talk. We still have some time

for questions, so if you would like to ask
some questions to Sebastian then please

queue up behind the microphones, and
please try to be concise with your

question, and please get close to the
microphone, because the mixing Angel in

the back is able to make it quieter, but
hardly much louder, if your distance is

not right. So let's start with microphone
number 2.

Microphone 2: Test, test. Hello. I'm
actually tested the HTML exfiltrate you

described. But I found out, in
Thunderbird, the HTML parsing of

Thunderbird was actually helping against
the attack, because the word tags was just

disabled any possibility to exfiltrate the
message, because there were some div tag,

which is closing your image tag at every
point in time

Sebastian: Yeah, so, this is one of the
fixes, that they did. I mean it doesn't

help with the cryptography, but it makes
the exeltration a bit more difficult. If

you want to do the testing, try the
versions from before May this year.

Microphone 2: I did, I did with the old
versions.

Sebastian: We can talk afterwards if you
want, and I will show it to you.

Herald: We are streaming all the talks on
the Internet and we have people on the

internet that would like to ask a
question, so please a question from the

internet.
Signal Angel: Yeah, so there were actually

many questions in the direction of
problems with MIME standards. So, like,

what they were asking was basically
"Woudn't the exploitation be prevented, if

the email clients would handle the
standart correctly?"

Sebastian: Mhm, okay. So, I am not sure
whether they meant the MIME standards or

the S/MIME standards. So basically, the
MIME standards are that one to blame for

the direct exoltration attacks, were you
have multiple MIME-parts that are mixed

together, and the MIME standards don't
state explicitly how to do this. So they

don't have any rules of how to handle it,
and basically I think, as a rule of thumb,

when you try to be concise and complete
with implementing the MIME standard you

were vulnerable, and if you were just lazy
and just for example decrypted the first

MIME-part or so you were not vulnerable.
So, leaving out much of the stuff made you

more secure, which is weird.
Herald: Thank you for the answer. We have

another question in this hall, on
microphone number 6, and please remember

to be concise and get close to the
microphone.

Microphone 6: What do you see
Audio feedback loop

Microphone 6: Sorry.
Herald: Very good! We can always make it

quieter.
Applause

Herald: Laughing

Microphone 6: What do you see as a future

replacement to PGP for email encryption?
Sebastian: So actually, we brainstormed a

little, because PGP lacks many of the
modern properties, like forward secrecy

and stuff like this, but it turns out that
it's not very easy to do this. Especially

not with - when you don't want to do
changes to SMTP and IMAP. So, it's gonna

be difficult. It's gonna be difficult to
make it more secure than PGP, besides the

critisism that I already brought in. So,
E-Mail is not a very good protocol, or the

protocols that are built in E-Mail are not
a very good to build proper crypto on top

of it.
Herald: Thank you for this answer, so

maybe we need build something entirely new
from scratch. There is another question on

Microphone number 2, if I see this
correctly.

Microphone 2: So, do I understand it
correctly, it looks like there won't be a

fix for that multi part attacks, like
there is the normal plain text the

attacker writes, and then there is a
ciphertext, which my mail client decrypts;

there won't be a fix for that?
Sebastian: There is a fix, so the mail

clients are fixed, so that's because
that's a non-breaking fix, that's a good

thing here. So you can't fix S/MIME, for
example, because it would be a breaking

fix, but you could fix the email clients,
which was a lot of work, because MIME

parsers are very complex, but they fixed
it, so it's not supposed to work in

current mail clients anymore. The direct
exfiltration part.

Herald: So we still have quite some time
left and so I would like to have another

question form the internet.
Signal Angel: Yes, so one user asked

"would you recommend a better
path to integrate PGP into the E-Mail

clients instead of using extensions?"
Sebastian: Yea. I'm not a - I mean

I already talked about this that not many
people use PGP. And also not many people

use S/MIME.
I'm not sure, whether this will be

increased, when OpenPGP spilled into most
of the mail clients, because you could use

S/MIME, you know. As soon as S/MIME is
fixed it will be fine to use S/MIME, and

it's already in all the clients in there,
but not many people use it.

So it would be nice, if we could have it,
but I'm not sure whether it would have

much of an effect on the amount of people
who use it. Herald Angel: Thank you. And

we have another question from Microphone
number 7.

Microphone 7: Yes, hello. So I work with
journalists - here! here! here!

Herald Angel: There, in the very back.
Microphone 7: There, Hello. Hello.

Sebastian: Hi. Oh, yeah hi. How's it
going?

Microphone 7: So I work with journalists,
and May was very annoying, and I cannot

stress enough how important it is to - the
point you've made about communicating

around disclosure.
Sebastion: Yeah

Microphone 7: We were scrambling. I work
with about 200 journalists, who use PGP

daily, and we were scrambling for any bit
of information.

Sebastian: Yeah.
Microphone 7: What, what should we do? It

was, it was madness.
Sebastian: Yes.

Microphone 7: But I actually have a
question. The question is: Have you played

with Mailpile? I've read the, I've read
the paper. In the paper Mailpile, I think

I remember, was mentioned, and I vaguely
remember it was mentioned in a positive

light, but I just want to make sure, if
that's the right thing that I should get

from this paper.
Sebastian: I don't know it on the top of

my head, but if you come afterwards to
Chaos West we'll get out the paper and

look at the tests, and then we can answer
this question. Cool.

Microphone 7: Thank you.
Herald: Okay. We have another question on

the microphone number 6.
Microphone 6: So, I'd like to know if

there's any difference in the attack
surface, regarding OpenPGP, if plain,

like, plain PGP is used or PGP/MIME. For
example if you set your E-Mail client to

disallow decryption of inline PGP.
Sebastian: Yeah, that's a very good

question.
I mean the reply to attacker attack that I

just showed at the last. The Q53 people
came up with a version that worked with

inline PGP, and we showed that it's also
possible with PGP/MIME. So, I wouldn't say

- I mean, most of the people use PGP/MIME.
Inline PGP is not used anymore. The

problem is, when you don't decrypt PGP,
inline PGP, then you have a problem when

people use PGP at an external application.
They can't copy and paste the ciphertext

in there anymore, which is also very
annoying. And I also told you that it's, I

think it's a very good idea to do this
outside of the mail client, if you're in

a, if you face motivated attackers. So,
it's not that easy. it would be a breaking

change that wouldn't, maybe not be too
good.

Microphone 6: Okay. Thanks.
Sebastian: Okay.

Herald: Thanks a lot for this answer. I
think we are done with all the questions

from the hall. If you like to continue the
discussion with Sebastian Schinzel, you

may move yourself to the assembly of Chaos
West in the next hall in this direction.

And now please give a big round of
applause for Sebastian Schinzel and the

awesome team behind.
Applause

Outro plays

subtitles created by c3subtitles.de
in the year 2020. Join, and help us!