 Hello, hello everyone. So, um, welcome to this year's email security talk at, um, DevCon. So, uh, my name is Hans Müller, I'm a PGD student at the Jeffery Networking Data Security at the University of, uh, Wohlhum in Germany. And, uh, this is joint work with the University of Applied Sciences in Münster, uh, on covert continent techs targeting PGD and asthma based encryption and digital signatures. Okay, so, um, what happened in the world of email security last year? EFIL happened. Some of you may remember it. It was one of the most important attacks of last year. Uh, why was EFIL so important? Because it was one of those attacks that come with a logo. Okay? And, besides some clickbaiting headlines we've seen in the press, actually EFIL was a real world crypto issue targeting the cyber modes of evaporation in both PGD and asthma with a lot of things not fixed until today. So, when we did EFIL last year, we also stumbled across some minor bugs in, in email clients. So we thought it would be minor bugs but then we looked deeper and, uh, then we found out, whoa, that's actually totally RFC standard, uh, behavior of email. And that's what I'm going to talk about today. So we are not going to do any mass, not no crypto, but super practical, uh, and super simple attacks against encryption and digital signatures in the context of email. Okay, so here's an outline of the talk. First I'm going to give you a short introduction on, uh, email and PGD and asthma. Um, then I'm going to come to the attacks on encryption and digital signatures and an evaluation of those attacks on 24 widely used email clients. Uh, and finally I'm going to show some countermeasures so developers of email clients can protect, um, their customers from those attacks. Okay, let's start with technologies promise. So, in the 90s we've heard, um, representatives of the cyber movement, cyberpunk movement claiming like strong crypto is mathematically unbreakable, use it encryption for the masses. And they were right, of course, yes, we should use it. Um, and then we've heard other actors like government people, they didn't believe in mass encryption at that time, but they like to think about, well, in the year 2000 everybody will use like digital signatures to sign the business contracts and things like that, which also didn't really happen. But, um, well it's based on the same idea that they're mathematically hard to solve, uh, problems. Okay? Um, so, now let me ask the what if question. What if both claims could be bypassed with a single reply to a benign looking email? And that's what today's talk is going to be about. Okay, to fully understand, let me give you a pre-history lesson on email. So, in the beginning there was ASCII text messages. Okay? And it was good. Okay? We had a great signal to noise ratio, no spam basically. And until today emails consist of like a header which contains, uh, information about maybe send a recipient's up check and so on. And a body containing the actual message. And because email back in the time was transferred usually over unencrypted insecure channels, um, people began to think about privacy, okay? So Phil Zimmerman came up with this great idea of traditional PGP, PGP inline back then. So, which basically leaves the header as it is, but encrypts the text message body using public key crypto. And it was good back at that time, okay? And then people came around and thought, well, we want to do more. We want not only to send text messages over email, we also want to send like binary data, binary files and so on. Therefore, multipurpose internet mail extensions was born. So with my email, you can for example, send an email that contains of multiple parts of multiple data formats. Okay? Like for example, you could have a mixed multipart message with multiple parts that are separated by some boundary. And in this example we have two plain text, uh, two ASCII text messages. Okay, resulting in a structure like this. But you could also of course, for example, use, uh, and create an HTML email with a PDF attachment, okay? So MIME, MIME is how modern email is used today. Okay, and then, um, based on the MIME standard, people came around with yet another, um, standard for email end to end encryption, which is ASMIME. You probably have heard about it, um, similar to PGP, but more used in like corporate environments. So, um, ASMIME defines a content type of application, PQSA7, MIME, and then encrypts and base 64 encodes the body of the email which could by itself be a complete MIME structure. Okay, so how do you, um, encrypt your emails in, uh, 2019? So we still have those two competing standards like PGP which is more used by journalists, activists, hackers, by us. And ASMIME which is more used in business environments or like by universities who can afford running a central certificate authority. And besides the, the trust model, actually both standards use more or less the same crypto which is, which has a lot of flaws in this old crypto, but it's not, I'm not going to talk about crypto today because the attacks I'm going to present now are basically independent of the actual encryption scheme. Okay, let it be PGP or ASMIME or whatever. At least, um, um, unless, um, so they must be used in the context of email, then we can probably, uh, apply them. Okay, so let me come to the attacks on encryption. So our attacker model is super simple. The EFTRAP or EFTRAP has somehow captured cyber attacks between two communication parties. It's quite a strong attacker model, obviously, but the only reason why you use end-to-end email encryption is that an insecure communication channel of course is presumed, right? So, um, what EFTRAP can do is the, a captured ciphertext email is she can modify the outer structure of the email. We do not do any ciphertext modifications, any bit flipping today, but we modify the, the outer MIME structure, okay? And then she can resend that modified email to the victim which can either be the original sender or the original recipient of the message because emails are usually encrypted with the, uh, public key of both of them. So both of them should be able to decrypt the email later. Okay, both of them can be misused as a decryption oracle. Um, so here's an outline of the attack. The attacker EFT, um, sends a benign looking, uh, email message that is visible to Johnny. And then she, um, appends, um, um, something we call, um, um, covert content like the hidden ciphertext part, okay, which Johnny cannot really see. But Johnny's email client can parse it. So for reasons we will see later, if Johnny replies to that, uh, message, um, to that harmlessly looking message, he will leak the plain text to the attacker. Okay, how do we do that in practice? So, assume this is, um, uh, a captured asmime email from Alice to Johnny. Now what could Eve possibly do with that email? So of course she can simply change the from address to her own address. So replies go to her, okay. And then what she can do is she can use this ciphertext part and wrap it into her own specially crafted mime structure. Okay, for example she can prepend some ASCII text resulting in a mime tree like this. So, um, an email client would then of course parse that message and see there's encrypted part and decrypted, okay, that's what email clients do. So this, uh, this message would be shown in Thunderbird like this. You have the attackers part and the original ciphertext which got translated to the plain text which got decrypted by the email client, okay. You see what I'm pointing you to. What happens if we reply to that message, okay? If Johnny replies to that message, he will also leak the secret message, he will leak the plain text. Well, Johnny is not the brightest guy on Planet Earth, but Johnny is not super dumb either. He sees that something fishy is going on. But all we need now is some way to hide the existence of the second part. So what we can simply do is some obfuscation like add a lot of new lines. Um, and if Johnny is in a hurry, he may already reply to that message, okay. Uh, and thereby leak the decypher text if it doesn't scroll down. We could also hide it with some longer communication on history or things like that. We could also use html and simply comment out the second part. So if Johnny replies to that email, he sees nothing but a benign looking message and thereby leaks the plain text. So if email clients do try to account to those attacks and enforce a strong isolation between multiple mind parts, or we can simply break that isolation using content ideas which allow you to refer from one mind part to another part, which is even an RSE standard. So supported by most email clients. Okay. You may say, well, that's html issues. But, um, there are lots of other possibilities. Like for example, we could also define the second part as an attachment, use unicode tricks and coding tricks and so on. So the take away here is that it's not an html issue, okay. The issue is mime wrapping. Why is it possible to use the encrypted part in a completely different context? Um, and then it's only engineering, um, to hide it basically. Okay. So, um, I hope I can give you a demo for that one. I need some help here. Can you sync the screens? Thank you. Okay. So, um, in this example we have, um, I captured, um, as my message, um, from the manager to Johnny. Um, but it could also be PGP MIME or, or PGP inline or whatever. Now, Eve can of course modify the subject of that email and also change the from address. And what she does now is she wraps, simply wraps that encrypted part into her own MIME structure. In this example we have some html message, um, before the actual cyber text part. And in this example we use some iframe to basically hide the second part. Okay, um, so, uh, let's send that email to put Johnny. And what Johnny's email client in this example, uh, Apple mail does is it will only, of course, display the first part because of the iframe. So it will only display something like, hello Johnny, I'm interested in your research, could be, could you tell me blah blah blah. And because Johnny's a nice guy, he replies to that email. Okay, he uses email as a communication medium. And in the reply to Eve, you will not see anything visible, but if you look at the, if you look at the source code she will see that in the quoted, uh, reply message not only the visible part, but also the invisible part containing the, uh, cyber text was, uh, quoted. Okay, so, um, the takeaway here is that, um, you cannot only, um, leak one single cyber text, okay? So the NSA could, for example, have captured hundreds of emails, um, over years. And then she wraps all of them into one specially crafted email, resents that email to the victim, and this one single reply, hundreds of plain text would be leaked. Okay, so, um, we thought can we adapt those attacks maybe to digital signatures. So the, um, the outline is pretty much the same. Again we, um, have some benign looking message. And in this case, what we want to do is we want to misuse the email client of Johnny, not as a decryption oracle, but as a signing oracle, okay? We want to obtain a relatively signed, uh, message that displays I hereby declare war. Okay, Johnny is the commander in chief in this example, and we want to start false flag warfare. Okay, if Johnny replies to that message, he will sign, he will quote and sign there for both parts. And for, for, with some tricks we will see, uh, in a second we can resend that sign message to a third party like to some army general who will then only see a displayed string which is signed by Johnny and says I hereby declare war. So hopefully the army commander general will give some phone call to Johnny before actually starting that war, right? Okay, um, how can we do that in practice? Um, well we can use HTML email and, um, have two strings, uh, a malicious one and, um, a benign one, and we can wrap the malicious message into some diff class. And all we need now is some CSS conditional rules to, based on some conditions, hide the first text or the second text, okay? So for example we can do this using the media CSS conditional rule. So based on the screen size, for example, so the certain text is hidden maybe on mobile devices but shown on desktop devices. Okay, so, um, if this email is, um, opened by Johnny, in most email clients so what will be shown is a benign looking message. Here's the reply. Johnny actually, uh, uses this technology, believes in PGP and S-MAP definitely signs all his outgoing messages, okay? Because he does not want to be impersonated. But the signed message, um, on a desktop device with another screen size would of course, um, have a completely different string being displayed, okay? Okay, so now we can target like the device type, okay? Like, like, you know, mobile desktop, maybe that's not too interesting. But we can also target, um, each and every email client. So using the supports conditional rule in CSS we could be, um, fingerprinted, um, all major email clients, um, and show, can show a certain string only on certain email clients. Um, and also we can go down further and target certain user accounts only, which is what I'm hopefully going to show you, um, now. Okay, so, um, in this example we have, um, only two parties like, um, if directly impersonates the manager, so it's an email from the manager to Johnny, if directly spooves the, the, um, from address, um, to make things a bit easier in this example. And what you can see here is some CSS code based on the mods document URL prefix. If it starts with IMAP call and double slash manager at something, a certain text is shown, okay? So let's send that message from the manager to poor Johnny. So as you can see there's, uh, just some harmlessly looking message, um, and, well, what's up Johnny from the manager? Well, whatever Johnny replies, yeah, I'm fine, blah, blah. And as said, Johnny believes in PGP and Asmime, he, he uses actually this technology, he always signs his outgoing messages, okay? And now if this message is received by the manager, a completely different string is shown like, like, I hereby quit my job, but it's validly signed by Johnny. Okay. That's HTML tricks. For signatures that's HTML tricks. But anyway, um, if we define digital signatures as mathematically unbreakable and unfortunately such simple stupid tricks shouldn't be working, right? Okay. So now let me come to an evaluation of those attacks. So, um, we tested, uh, 24 widely used email clients, basically every client that supports either PGP or Asmime or both. And regarding being misused as a decryption oracle, um, uh, a lot of email clients including, uh, Sunderbrood and Apple Mail, for example, uh, Wilner Rebel and all Linux based email clients. And, uh, my guess here is actually that email clients where the, um, the developers actually read the RFCs and tried to implement a standard compatible email client, they are more vulnerable than those who maybe just had a quick hack for a PGP plugin. And, uh, regarding signatures, it's kind of even worse. I mean, basically every email client that supports HTML, uh, can be at least tricked to, uh, display a certain, uh, message only in this client and things like that. It's hard to counter against. Also, the signature issues are not fixed until today. Okay, so let me come to some, uh, some counter measures. Well, you may say, let's accept ASCII text only. Let's finally get rid of HTML email. I'm totally on your side. Let's start get another ASCII ribbon campaign. But it will not solve the decryption issues, okay? Because it's, um, the problem is mime wrapping, okay? We could also use some unicode tricks and other tricks to hide the second part. It will not unfortunately solve the decryption oracle tricks. Um, we could say, what about, do not decrypt unless the email is well at least signed. Doesn't work either in the context of email, um, because attackers can simply strip the signatures and re-sign on their own, on their own identity. So, what a lot of email clients now did as a counter measure is they warned the user if the email is partly encrypted. Um, I think that's a bad idea. Because it delegates security decisions back to the user which, which I don't want. So what I would prefer is like having an all or nothing decryption. Email clients should not decrypt my email unless the whole, um, message was encrypted within one single mime plot, one single element, okay? Yeah. Uh, also we could of course think about other cryptographic counter measures. Um, one thing maybe regarding all or nothing encryption, it will break some, it will, may break some PGP inline emails. It will break definitely emails, some emails, uh, composed by K-mail which allows you to encrypt only the attachment and things like that. But it's a trade off between, you know, compatibility and security. Okay, also we could think about cryptographic counter measures like, why is it even possible to use decipher text from one email? And years later, use it in a completely different context and a completely different email. Modern online protocols, they would, you have a binding of the cipher text to the current communication session, right? Um, in email this, this still seems hard, how to do. Okay, regarding signatures, uh, you may say let's drop simply support for CSS. I'm, on your side, yeah? Um, I, I think, uh, unfortunately a lot of like, a lot of people want to have fancy formatting and, and they, they which is done by CSS, so, so it may not be realistic for, for many email clients, so. Um, but email client vendors, um, and, and, and implementers, what they can at least do is only reply with ASCII text or remove CSS styles from replies so they cannot be misused as, uh, signing oracles anymore. Okay, so, um, let me come to a conclusion. Um, so crypto is great, okay? But sometimes, sometimes super simple bypasses exist. Sometimes we do not have to break the mask, um, and in, in this example, these bypasses existed for, for decades, okay? And the vast majority of the tested clients are vulnerable to either being misused as decryption oracles or, or signing oracles or both. Um, and, and PGP and SMAM they are more or less equally affected, okay? Because we do not target the underlying cryptography. We target standard email features. So, um, this brings me to the final question, is it even possible to build security on top of email? I think this is very, very challenging, okay? And this talk is just one of many examples, um, where things fail. Okay, so, um, we reported, um, all those issues to affected vendors in, uh, until February, and, uh, most of the decryption oracle issues are fixed now, uh, the signing issues are not fixed. Um, anyway, we are going full disclosure now. So, if you want to test if your client is still vulnerable, um, you can use the test cases on, on Github. Okay, thank you guys and enjoy this great conference.