Re: What's up, Johnny?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 335 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/48384 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
CryptographyElectronic signatureMathematicsEmailMessage passingASCIIContent (media)Standard deviationMultiplicationRootHierarchyInformation privacyEncryptionCentralizer and normalizerPublic key certificatePerformance appraisalIntegrated development environmentData structureProbability density functionDigitizingClient (computing)CryptographyElectronic signatureMessage passingEmailMereologyTelecommunicationInheritance (object-oriented programming)Computer fontHacker (term)AuthorizationNumbering schemeEndliche ModelltheorieOracleComplete metric spaceContext awarenessDesign by contractBinary fileStandard deviationPublic-key cryptographyReal numberSoftware developerBitRepresentation (politics)CybersexInterior (topology)MassUniverse (mathematics)MultiplicationStudent's t-testNoise (electronics)Software bugInformationBinary codeExtension (kinesiology)Asynchronous Transfer ModeContent (media)Operator (mathematics)Information securityEmulatorResultantMixed realityBoundary value problemType theoryCodeCartesian coordinate system
07:24
OracleContent (media)EncryptionEmailContent (media)MereologyEncryptionClient (computing)Message passingComputer animation
08:01
Content (media)Data typeEncryptionOracleBoundary value problemMixed realityMessage passingTotal S.A.Clique-widthVariable (mathematics)MultiplicationMessage passingMereologyData structureClient (computing)EncryptionLeakEmailMultiplicationData miningAddress spaceTelecommunicationDemo (music)Different (Kate Ryan album)SynchronizationExistenceNetwork topologyParsingStandard deviationCryptographyLine (geometry)Arc (geometry)UnicodeRepetitionIntrusion detection systemContext awarenessComputer animation
11:26
Convex hullEmailData managementAddress spaceMereologyMessage passingComputer animation
11:49
Data typeBoundary value problemInformation managementContent (media)EncryptionOracleEmailData structureAddress spaceMereologyMessage passingEncryptionEmailClient (computing)Source codeJSON
12:13
Message passingWindowComputer fileForm (programming)EmailView (database)Online helpFile formatTelecommunicationEmailElectronic visual displayXML
12:31
Execution unitBoundary value problemIntrusion detection systemContent (media)Revision controlMessage passingEmailFlagData typeFlash memoryHydraulic jumpHeat transferCodeEncryptionASCIIConvex hullSource codeMereologyComputer animationXMLSource code
12:50
Inclusion mapHeat transferCodeContent (media)Data typeEncryptionMessage passingBlock (periodic table)ASCIIConvex hullMixed realityOracle19 (number)Performance appraisalEncryptionLeakEmailSingle-precision floating-point formatElectronic signatureDigitizingComputer fontXMLComputer animation
13:28
OracleEmailCryptographyMessage passingClient (computing)Sign (mathematics)System callFlagForcing (mathematics)String (computer science)Computer animation
14:24
Electronic signatureOracleContent (media)HypermediaClique-widthMobile WebEmailHypermediaSign (mathematics)EmailTouchscreenString (computer science)Message passingRule of inferenceDifferenz <Mathematik>Condition number2 (number)Division (mathematics)Cross-site scriptingClient (computing)Computer animation
15:36
Rule of inferenceClient (computing)EmailClient (computing)Rule of inferenceCondition numberString (computer science)EmailComputer animation
16:05
Rule of inferenceDemo (music)Barrelled spaceSlide ruleOracleContent (media)Data typeDefault (computer science)Data managementEmailXMLJSON
16:24
Data typeContent (media)Default (computer science)OracleTap (transformer)EmailData managementEmailBitAddress spaceMessage passingCase moddingCodeUniform resource locatorJSON
16:47
Execution unitMessage passingMusical ensembleData managementMessage passingComputer animation
17:05
Software testingWave packetSign (mathematics)Message passingString (computer science)Electronic signaturePerformance appraisalXMLComputer animation
17:33
Rule of inferenceEmailClient (computing)Performance appraisalEncryptionSimulationElectronic signatureOracleMessage passingPauli exclusion principleAndroid (robot)Inclusion mapClient (computing)EmailSoftware developerSubsetCryptographyElectronic signatureMessage passingElectronic visual displayComputer animation
18:37
Performance appraisalEncryptionASCIIOracleCiphertextRootTerm (mathematics)Key (cryptography)SubsetIdentity managementControl flowDecision theoryEmailTelecommunicationInformation securityContext awarenessCryptographyElectronic signatureEncryptionRepetitionUnicodeOcean currentMereologyClient (computing)Communications protocolOracleMessage passingSingle-precision floating-point formatDifferent (Kate Ryan album)Computer animation
20:42
OracleCryptographyProxy serverBuildingEmailInformation securityEncryptionExploit (computer security)Information securityClient (computing)OracleCASE <Informatik>EmailStandard deviationBuildingCryptographyFile formatSign (mathematics)Software testingProxy serverExistenceComputer animation
Transcript: English(auto-generated)
00:00
Hello, hello everyone. So, um, welcome to this year's email security talk at, um, DEFCON. So, my name is Jens Müller, I'm a PhD student at the Jefra Network Data Security at the University of, uh, Bochum in Germany. And, uh, this is joint work with the University of Applied Sciences in Munster, uh, on covert content attacks targeting PGP
00:22
and asthma-based encryption and digital signatures. Okay, so, um, what happened in the world of email security last year? EFL happened, some of you may remember it. It was one of the most important attacks of last year. Uh, why was EFL so important? Because it was one of
00:42
those attacks that come with a logo. Okay, and besides some click-baiting headlines we've seen in the press, actually EFL was a real world crypto issue targeting the cipher modes of operation in both PGP and asthma, with a lot of things not fixed until today. So, when we did EFL last year, we also stumbled across some minor bugs in, in email
01:08
clients. So, we thought it would be minor bugs, but then we looked deeper and, uh, then we found out, woah, that's actually totally RC standard, uh, behavior of email. And that's
01:20
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 PGP and asthma. Um, then I'm
01:44
going to come to the attacks on encryption and digital signatures and an emulation 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 technology's promise. So, in the 90s, we've heard, um,
02:10
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
02:21
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, uh, 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,
02:44
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 those claims could be bypassed with a single reply to a benign looking email? And that's what today's talk is
03:04
going to be about. Okay, to fully understand, let me give you a brief history lesson on email. So, in the beginning, there was ASCII text messages, okay? And it was good, okay? With a great signal to noise ratio, no spam, basically. And until today, emails consist of
03:24
like a header, which contains, uh, information about maybe sender, recipient, subject 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
03:42
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 the time, okay? And
04:03
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, we use MIME email. You can, for example, send an email that contains of multiple parts of
04:23
multiple data formats, okay? Like, for example, you could have a mixed multipurpose message, uh, with multiple parts that are separated by some boundary. And in this example, we have two plain text, two ASCII text messages, okay? Resulting in a structure
04:40
like this. But you could also, of course, for example, use, uh, on 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 S-MIME. You probably have heard about it,
05:05
um, similar to PGP but more used in, like, copyright environments. So, um, S-MIME defines the content type of application PKS7, MIME, and then encrypts and base64 encodes the body of the email, which could, by itself, be a complete MIME structure. Okay, so how do you,
05:27
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 S-MIME, which
05:40
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 and is old crypto, but it's not, I'm not going to talk about crypto today, because the attacks I'm going to
06:00
present now are basically independent of the actual encryption scheme. Okay, let it be PGP or S-MIME or whatever. At least, 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 eavesdropper Eve has somehow
06:25
captured cipher 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 Eve now can do
06:43
with the, uh, captured cipher text email is she can modify the outer structure of the email. We do not do any cipher text 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
07:06
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 Eve, um,
07:29
message that is visible to Johnny. And then she, um, appends, um, um, something we called, um, um, covert content, like the hidden cipher text part, okay? Which Johnny cannot really see.
07:45
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 looking message, he will leak the plain text to the attacker. Okay, how do we do that in practice? So, assume this is, um, a captured S-MIME
08:05
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 cipher text part and wrap it
08:24
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 this encrypted part and decrypt it, okay? That's what
08:43
email clients do. So, this, uh, this message would be shown in Thunderbird like this. You have the attacker's part and the original cipher text which got translated to the plain text which got decrypted by the email client, okay? You see what I'm pointing
09:00
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
09:22
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's in a hurry, he may already reply to that message, okay? Uh, and thereby leak the, the cipher text if that, if it doesn't scroll down. We could also hide it with some, some longer communication on history or things like that. We
09:42
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, uh, counter those attacks and enforce a strong
10:02
isolation between multiple mine parts, well, we can simply break that isolation using content ideas which allow you to refer from one mine part to another part which is even an RC standard. So, supported by most email clients. Okay, you may say, well, that's
10:21
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 takeaway 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,
10:42
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.
11:28
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.
11:44
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
12:01
ciphertext 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 poor Johnny. And what Johnny 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
12:25
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, uh, you will not see anything visible, but if you look at the, if Eve looks at the source code, she will see that in the quoted, uh,
12:43
reply message, not only the visible part, but also the invisible part containing the, uh, ciphertext was, uh, quoted. Okay, so, um, the takeaway here is that, um, you cannot only, um,
13:03
leak one single ciphertext, 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, resends that email to the victim, and with one single reply, hundreds of plaintexts would be leaked. Okay, so, um, we thought, can we adapt those attacks maybe to
13:24
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
13:41
want to obtain a validly 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, therefore, both parts. And for, for, with some tricks, we will see, uh, in a second, we
14:04
can resend that signed 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, the general, will give some phone call to Johnny before
14:20
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
14:45
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
15:06
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 S1 definitely signs all his outgoing messages, okay? Because he does not want to be impersonated. But the signed
15:24
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, yeah, maybe that's not too
15:40
interesting. But we can also target, um, each and every email client. So, using the supports, uh, 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
16:03
going to show you, um, now. Okay, so, um, in this example, we have, um, only two parties, like, um, Eve directly impersonates the manager, so it's an email from the manager to
16:26
Johnny. Eve directly spoofs 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 colon double slash manager at
16:42
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,
17:00
I'm fine, blah, blah. And as said, Johnny believes in PGP and asthma and 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
17:21
signatures, that's HTML tricks, but anyway, um, if we define digital signatures as mathematically unbreakable and unforgeable, such simple stupid tricks shouldn't be working, right? Okay, so now, now let me come to an evaluation of those attacks. So, um,
17:41
we tested, uh, 24 widely used, uh, email clients, basically every client that supports either PGP or asthma or both. And regarding being misused as a decryption oracle, um, a lot of email clients, including, uh, Sander Boot and Apple Mail, for example, are vulnerable and all Linux based email clients. And, uh, my guess here is actually that email
18:04
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
18:22
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 count against. Also, the signature issues are not fixed until today. Okay, so, now let, let me come to some, uh, some countermeasures. Well, you may say, let's accept ASCII text
18:46
only. Let's finally get rid of HTML email. I'm totally on your side. Let's start getting 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
19:04
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 validly signed. Doesn't work either in the context of email, um, because attackers can simply strip the signatures and resign on their own, on their own identity. So, what a lot
19:25
of email clients now did as a countermeasure 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
19:42
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 countermeasures. Um, one thing maybe regarding
20:02
all or nothing encryption, it will break some, it 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 tradeoff between, you know, compatibility and security. Okay, also we could think about cryptographic countermeasures like, why is it even possible to use the ciphertext from one email and
20:25
years later use it in a completely different context, in a completely different email? Modern online protocols, they would have a binding of the ciphertext to the current communication session, right? Um, in here, email, this still seems hard, hard to do.
20:41
Okay, regarding signatures, uh, you may say let's drop simply support for CSS on, 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've, 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
21:04
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 super simple
21:26
bypasses exist. Sometimes we do not have to break the mask, um, and in, in this example this bypass has existed for, for decades, okay? And, and the vast majority of detested clients are vulnerable to either being misused as decryption oracles or, or signing oracles
21:42
or both. Um, and, and PGP and SRAM, 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
22:03
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, the decryption oracle issues are fixed now. Uh, the signing issues are not fixed. Um, anyway, we're
22:23
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.