 So, yes, welcome, and thank you for being here. When it comes to email, what's at stake? Maybe, this is from the keynote address at YouthNICS last week by Alex Damos, and he pointed out that a most harm that comes to users of computer systems actually does not come in the form of zero days or security vulnerabilities, but in updates and configuration management and passwords and actually most of it in form of abuse, so using the systems that we have in the right and proper way, but with malicious intent. So, for the purpose of this talk, let me, with apologies to Alex, change the top part of the pyramid to crypto, and then email is actually located mostly at the bottom of the pyramid. So, by default, email is not secure. It's not encrypted, it's not authenticated. So, we have two standards that are often used to add security to email systems, and this is OpenPGP and SMIME, and we tried last week, last year, my colleagues attacked the encryption part with e-fail, and this year, we are presenting attacks on the signatures, the authentication. So, this is a typical signed email in an email client called OneCube. This is a small example to motivate you, and I can see that it is, the digit is signed because of the green box here, which says, verified signature from the manager, and he congratulates me to my promotion. This picture is very nice, but even if you are not an expert, you can probably already see a problem here. Like, what are the attacker-controlled UI elements? I will give you some help here. I'm marking them in red, and we see that the information about the signature is actually contained in the body of the email. So, the attacker can simply spoof it by inserting a picture or some HTML that looks the same. And of course, this is a trivial example, but we will now show increasingly complicated ways to achieve similar things. I have to apologize, this is my slide of shame. We are not attacking the underlying cryptography at all, so we are mostly focusing on the presentation of the emails and the interpretation of the data formats. So, the presentation and the data formats can be attacked. We don't have any attacks on the underlying cryptographic parameters, but I still hope to bring these higher level implementation issues to your attention. And actually, I believe that cryptographers need to be more involved in all aspects of the application design, because these issues are very difficult, and the implementers, as we will see, cannot solve them by themselves. Can you start the timer? Okay. So, we have found several attack classes. It's a loose categorization based on the attack. One you have already seen, the UI redressing attack, where we spoofed the presentation. We also have attacks on the binding of signatures to keys and the digital identities. We have attacks on wrapping existing signatures with my data structures, and we have two attacks on the underlying cryptographic message formats for OpenPGP and SMIME. So, our methodology was to select basically all major PGP and SMIME implementations across our platforms. So, we have 25 clients for Windows, Linux, Mac OS, iOS, Android, and the web. And then, of course, we have our huge table with the attack classes for OpenPGP and SMIME. Three of them are the same, and one is specific to the protocol. And some clients don't implement one of those standards and then there's an NNA. And the goal of the attacker is basically to achieve a perfect forgery, which is for the user indistinguishable from a proper signature because it's pixel perfect or a perfect forgery. And this includes all levels of interaction. So, if there is a button with details and you click on it, then those details also must be spoofed and forged. For a partial forgery, we have seen that some attacks only achieve this forgery on the first level before any interaction. And because we assume that most users won't click on things unless they are suspicious, we believe it's useful to have a second category, partial forgery, where you can spoof everything on the first level and some details on the second level or deeper may not be forged. So, here for example, I have a forgery for Thunderbird and if I click on the details button, then I see that the signature is actually by somebody else and claimed at the first level. So, it says, good signature from the manager to the left and good signature from Eve to the right. And then we have a second, a third class where we do not even achieve a complete forgery at the first level. And then we say it's a weak forgery and we do not actually count these as vulnerabilities at all, but we include them in the report because there are many of them and they can be quite confusing. So, for example, here is a weak forgery in Thunderbird and I don't know if you've seen this, there is a box that says it's a good signature which looks perfectly like a normal signature but there are some who I indicate are missing which are these icons to the right, okay? And the attacker model, we don't assume too much. We say that Eve can send email to the target with a fake sender address. This is usually possible even in the presence of SPF and DKIM which try to prevences and for thumb attacks and the details on the paper we require that Eve has a valid signature from the spoofed signer and there can be any signature from an old email in a mailing list or for some source code download or something. And Eve may be trusted in thumb attacks but we also need to have established a trusted communication channel using the same protocol. So, for example, if Eve communicates with the victim and they have exchanged keys and then we can use this for an attack. This can be under a pseudonym so we don't think this is too much to ask for. Okay, so some background on email messages in case you haven't have studied this like 10 years ago or so, you already know this, there hasn't been any changes in the recent years. Emails are composed of an email header and a body and to make them more versatile, we have the MIME extensions which can, which allows you to compose an email message from several parts. For example, here's the multipart mix message with two parts and these parts, they can be interpreted differently by the email client depending on what content type is chosen. For example, the content type multipart alternative says that the email client should only show one of the two parts. One could be a text part and one could be a HTML part. And then there are these other options and one of them is signed. So a signed email would be a multipart signed and it also says which protocol and then we have the two parts, the plain text and the signature. And for PGP, it's mostly the same. So if you don't blink, you can see that there is only a different content type and the encoding is different and the protocol. So let's look at the attacks. The first attack class, why we just think we have already seen and I won't go into any more details except to say that these are usually perfect or partial forgeries. And if you think about the reasons why these happen, we have a quite rich content format support with HTML and CSS and email clients which is demanded by the user. So we can't really disable it. And we also don't see a reason why you should recommend to disable it except to acknowledge the actual state of things right now. The content of the email should not really have an impact on the security of the email signatures. And then the security indicators, why are they even in the email body? There are often two reasons for this, or at least one of the two. These security features are often implemented by third party plugins and that's the original application developer. And in this case, the plugin doesn't have access to the full UI. So they have to inject the status into the email body. And it's also intuitive because it brings the signature close to the text that is actually signed. So here we see a counter measure by Thunderbird which has been done in response to our report. The good signature box can be spoofed because it's part of the email body. So they moved it up above the header in a part where the attacker cannot control anything. But I don't know, this seems problematic because now it almost looks like the header is signed and it is not, never signed with this. And also it puts more distance between the signature and the text that is signed. So it can be more confusing. We have found these vulnerabilities in several clients. You see the list here. Often it's only a weak forgery because we cannot forge all the UI elements at the first level. So the second attack class, identity binding, raises the question how I'm actually binding the signer to the signed content. So here for example, Thunderbird says that the signature is by the manager and this is redundant information because it already says that the email is from the manager. And if I get an email from somebody and it is signed, then I expect it to be the same person as the form address. So some email clients, especially for S-Marm, they do not include this extra information. They just say like here, the GPGL plugin for Outlook says it is a trusted center address. So you have to look at the form address, manager at work and then it says that the signature is by that person. But how does this work? So the S-Marm standard demands this check. It says that receiving agents, that means the email clients, must check that the address in the form or sender of an email message matches an internet mail address in the signer certificate. If mail addresses are present in the certificate, okay. That's the first question. What can go wrong? So here we have an email header that says that the email is from Eve. And the verification logic we expect will check that the certificate of the signer is Eve. But we also have a display name and an email address and this display name may be the only thing that's displayed to the user. So we can change it to something else. And to make it more convincing, we can also change it to an email address. So we already see some complication here. Then we set the reply to a header so the answer doesn't go to the attacker. We can also have multiple form addresses. That's perfectly fine with the standard. It doesn't say anything about it. And then we hope that the security plugin will check a different field than is displayed by the user interface. And this also can work with a form and a sender address. So here's an example. I already showed you the screenshot before from Outlook but I didn't tell you that it is actually spoofed. There is an extra email address in there and that has just moved out of the window with spaces. So very simple attack, very powerful. So how does this happen? Sender and form have been there from the very start of email and they've been purely functional features. So if you displayed one or the other, they didn't, was never a security concern but now they've become security relevant and their presentation and consideration has to be included in your evaluation of the security of the system and that is never done. And the other thing is if you do, if as a countermeasure you include all the details for the signature, like it was done with Sunderberg, then you're basically just shifting the problem to the user who has to read all this information and process it. So this is also not easy. We have a lot of partial forgeries because often email clients include some detailed button where you can get additional information from the certificate and then you can look deeper inside it and see the problem. And the third attack class is a classical signature wrapping attack where we take an existing signature, for example an email on a mailing list and then we put it as a normal mind part in a multipart mixed message with a second text. So this would be displayed like this in Sunderberg which finds the signature in the second part and uses that as a summary for the whole email. This is of course a simple misattribution and now we have two plain text there and we need to hide the second. There are a couple of tricks. For example, you can simply move it down with white space. Then you get an extra scroll bar which is not so pleasant. So why not hide it in an attachment? But then you get the attachment bar at the bottom. So let's try some more tricks. How about using an image? And the second, you can actually take attachments or parts in the email and reference them as data for an image. But because there is no image in that attachment or in that part, it will actually not show anything. But it will still say good signature and the reason is that the second part could be encrypted. So the whole email and all parts have to be processed by the cryptographic layer. And the cryptographic layer will check for decryption and for the signatures and then evaluates the whole thing and returns the status and then Sunderberg will include this in the summary of the email. And the easiest way to do it actually is the best way. You can just comment it out and then it will be gone. So the deeper reason for this problem is that email clients often try to implement support for partially signed content. And this is because of the concept of forwarded email messages where you include a signed email in an email and then you sign the whole thing or you don't sign the whole thing and only the attachment is signed. And you sometimes have mailing lists which include extra text at the bottom for instructions how to subscribe and unsubscribe. And for this reason, these email clients try to support partially signed content. And this is very dangerous as we have seen. OpenPGP is more vulnerable than SMIME because SMIME clients usually don't try to add support for these complex cases. They just reject it which is one of the possible counter methods. Or you show for each part if it's signed and by whom but then you have the problem of how to display all this information. So this is the table. We see that for SMIME only mailmate is vulnerable but for OpenPGP we found a bunch of them including Apple Mail. And now we come to two more involved attacks on the underlying data structures. So PGP is here an example of a base 64 encoded string which has a sequence of packets. The first packet is a little data packet which contains the plain text of the signed message and also some information like if it's text or binary the timestamp of the signature and the embedded file name. And then there is a signature packet which includes the actual signature and which is a fingerprint of the key that signed it and so on. This is a simplified version PGP has some packets more but it's not so important here. Because this is complex to implement it's usually not done by the email client themselves but they use in this case not a library but an application called GroupGPG. Many of you know this and it's a command line executable not a software library. It has many options and commands and provides a structured line oriented text interface for automatic processing. It also provides a debug output on the log interface and the applications actually called GroupGPG gets this output and parse it and then aggregates the results themselves. So here's an example. GPG called the option status FD will output the status line in interface and the verb is it will output the log interface and here we see the status line information for a signature and here we see the log output. And we can see pretty much the same information in both of them. It's a good signature by the manager and it was created at a certain time and it has a certain embedded file name in it. So one problem here is so first applications need all this information. Some information is only available in the log interface so they have to include this and but it's complex to process two output streams in parallel and on some platforms it's very difficult. So usually they request GroupGPG to merge this into a single output stream and then it gets interspersed like this which is still fine but you have to be a bit careful because there is attacker controlled content here, right? So the idea was to they looked at the whole GroupGPG source code in all places where we can possibly inject things and we didn't find anything in the status interface but if verb is enabled then we found something in the log interface. So here's the attack. We do this again. We don't need the signature anymore because we are injecting all the data and we are using the file name. So we are changing the plain text because there is no signature anymore and this looks like this. All the things that we need from GroupGPG or from the status line interface we are moving into the file name and now we look how GroupGPG outputs this. All the red stuff is injected so we see that if an application would merge these streams it would see the status line API as expected and this completely breaks GroupGPG so we can inject arbitrary data. There is no signature anymore. We also verified before publication that this would not affect other applications because this is the pattern that's very common not only for email clients but also for package managers and source code verification programs, passport managers and so on and we found a bunch of them. You can find them in the additional finding section of the paper. So yeah, this was a little bit scary and this is how it looks in the email client. It thinks it's a good signature because it sees exactly the data it expects. So why is this happening? There is a complex API, it's text-based. It contains attacker-controlled data in the output. It wasn't sanitized completely in this case and the client parsers have to be very accepting and relaxed about parsing this because it can change from version to version of GroupGPG and they need to be backwards compatible with a long list of GroupGPG versions. So there's actually something that applications can do like do not use the debug output and then it's a little bit better but in general, this is just not a good interface and we have seen that we can attack Thunderbird but also Apple Mail. For S-MIME, we have also some interesting things. So S-MIME is basically the same thing but the base 64 encoded content here is a different data format. It's called CMS, Cryptographic Message Syntax and it's specified here. You all know this grammar from the RSTs. To make it a little bit easier, I'm simplifying here the signed data which contains the plaintext and the signature, has some additional fields that are not important here. Let's remove this stuff and then we can see there is the encapsulated content info which is the plaintext that is signed but it is a swing that is optional so it can be absent. And then we have a list of certificates which is basically signing keys and this also can be absent and it can be empty and then we have the signer info which is actually the signatures and a back reference to the certificate in the list. So what can go wrong here? Well, what happens if the certificate list is absent or a present.empty? What happens if we point to a non-existing certificate? What happens if we have no signatures but an empty list of signatures? So some email clients will then say there is a signature just because there is a CMS structure but they can't find an actual signature so that is very confusing and the encapsulated content can be absent. So to focus on one of these cases here let's look at this encapsulated content. So this looks like this. We have a plaintext and usually the encapsulated content in a detached signature is not set, it's absent. And in this case the email client will use the signature and verify it against the provided plaintext in the first part of the email. But what if we move this part of an existing signature into the encapsulated content field? Now the verification logic should use the encapsulated content field for the verification and we can change the first part of the email to basically say anything we want. So this is verified and the other text is displayed. It's also a kind of signature wrapping attack. And we have actually, so this works in several email clients and it's indistinguishable from a proper signature. So the flexibility and the specification is maybe not directly the problem but it should at least be checked carefully and the standard is actually not very expressive in what you should do in these cases. Because this is a technical crowd I can add a little bit of detail here which is interesting that you can replace this plaintext with a structure that contains the hash of the plaintext. It's a special case and in this case it would verify against this hash and then you can't even see the original plaintext anymore so it's forensically more difficult to find out what is signed. Of course if you look into the data structure you can see what's going on but the original plaintext is not included in the message anymore, which is very useful. So this works in a surprising number of clients including Thunderbird and the iOS mail app actually and this completes one more row of the table. So signatures can be spoofed in 70% of the tested clients. This only includes the perfect forgeries and partial forgeries. It does not include the weak forgeries. The mitigations are not really well understood. We had a lot of problems getting these issues fixed because the fix would introduce new problems and all of them could easily be circumvented or bypassed. So actually it's a bit of a tough situation if the implement has come to you as an expert and you can't really tell them what to do, right? You can say, well, you can do it this way but then you have these problems or you can do it another way and then you get a whole bunch of other problems. It's a tough situation. The weak forgeries actually would require a careful user study because we believe that there are many weak forgeries that would actually fool users but we can't prove this without a study. So that would be interesting. If we would include the weak forgeries then we would have 100% coverage, right? So in conclusion, I wonder what we can do about email. So some people have already given up and say it can't be fixed and some have been very outspoken about it and I appreciate it but if that's the consensus of this community then we should probably be even more vocal about it and tell more people that this is broken or we should work on fixing these things but currently that trajectory is not very promising. So we are now in the stage one year after e-fail where some of the e-fail bugs have been mitigated in the sunglass but it's still an open situation actually. So there's been a new S1 version which includes a fix and PGPA was not updated because the working group has spanned it before it could finish its work. And so I don't know. So I see something says something, right? If you see somebody, you will see something right? If you see somebody using email and needs it to be secure then maybe you need to have a discussion. Otherwise, you should probably proactively tell people where to go else but yeah, this is very difficult. Thanks for your time. Thank you very much, Markus. Are there any questions? Please come to the microphone. Maybe I have a question. So how about, I ask you about, I'm also a co-author of the papers so I will ask you about the usability studies. So I'm curious what do you think about what should be done in the usability studies because we have seen many usability studies in the era of TLS. There are many papers which are investigating how the, what's the color of the lock and so on and where should they be positioned and can you summarize so what has been done in the era of email and what should be done? Right, so we have seen with TLS that you have to be very careful with security indicators and warnings. So usually we know that the best thing is if security is transparent and just enabled by default and there is no option to turn it off. We are not there yet and if there is not an industry-wide effort to update all the systems at the same time it will be very difficult to introduce this. So what you can actually measure is what the impact of the mitigations would be. Like if you change something you can see if you make an improvement or not and that would be helpful. And of course we wanna know how many of the attacks would be working if you actually try to fool people. So there are these things like studying the security indicators and the possibilities to upgrade the system to be transparently secure then finding out which attacks work even if they are not perfect and then are the mitigations actually helpful because this is something that's very concerning to me. We are now, we are at now a window where we could make changes because we found bugs and vulnerabilities and completely parted them to the vendors but we didn't have a really good advice on what to do instead. So one chance to improve things has like, it didn't pass, we did improvements but they were random. They were not based on factual data what is an improvement and whatnot. So yeah, that's the problem. Okay, thank you. Any other questions? Okay, if this is not the case then let's thank the speaker again. Thank you. Thank you. Okay.