*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!