EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails.
Email is a plaintext communication medium whose communication paths are partly protected by TLS (TLS). For people in hostile environments (journalists, political activists, whistleblowers, ...) who depend on the confidentiality of digital communication, this may not be enough. Powerful attackers such as nation state agencies are known to eavesdrop on email communications of a large number of people. To address this, OpenPGP offers end-to-end encryption specifically for sensitive communication in view of these powerful attackers. S/MIME is an alternative standard for email end-to-end encryption that is typically used to secure corporate email communication.
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
There are two different flavors of EFAIL attacks. First, the direct exfiltration attack abuses vulnerabilities in Apple Mail, iOS Mail and Mozilla Thunderbird to directly exfiltrate the plaintext of encrypted emails. These vulnerabilities can be fixed in the respective email clients. The attack works like this. The attacker creates a new multipart email with three body parts as shown below. The first is an HTML body part essentially containing an HTML image tag. Note that the src attribute of that image tag is opened with quotes but not closed. The second body part contains the PGP or S/MIME ciphertext. The third is an HTML body part again that closes the src attribute of the first body part.
The attacker now sends this email to the victim. The victim's client decrypts the encrypted second body part and stitches the three body parts together in one HTML email as shown below. Note that the src attribute of the image tag in line 1 is closed in line 4, so the URL spans over all four lines.
The email client then URL encodes all non-printable characters (e.g., %20 is a whitespace) and requests an image from that URL. As the path of the URL contains the plaintext of the encrypted email, the victim's email client sends the plaintext to the attacker.
The direct exfiltration EFAIL attacks work for encrypted PGP as well as S/MIME emails.
The CBC/CFB Gadget Attack
Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext. The diagram below describes the idea of CBC gadgets in S/MIME. Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email. OpenPGP uses the CFB mode of operation, which has the same cryptographic properties as CBC and allows the same attack using CFB gadgets.
The difference here is that any standard-conforming client will be vulnerable and that each vendor may cook their own mitigations that may or may not prevent the attacks. Thus, in the long term, it is necessary to update the specification to find and document changes that fix the underlying root causes of the vulnerabilities.
While the CBC/CFB gadget attacks on PGP and S/MIME are technically very similar, the requirements for a successful attack differ substantially. Attacking S/MIME is straightforward and an attacker can break multiple (in our tests up to 500) S/MIME encrypted emails by sending a single crafted S/MIME email to the victim. As opposed to S/MIME, modern OpenPGP implementations offer a Modification Detection Code (MDC) that can detect modified plaintexts, effectively preventing the CFB gadget attack. However, we found that several clients only gave a warning to the user for invalid MDCs, but still displayed the modified plaintext. This allowed the CFB gadget attack despite the MDC. Furthermore, PGP compresses the plaintext before encrypting it, which complicates guessing known plaintext bytes. Given the current state of our research, the CFB gadget attack against PGP only has a success rate of approximately one in three attempts. We feel that plaintext compression is not a fundamental limitation of the EFAIL attacks but more a technical hitch and that attacks become more efficient in future research.
Here are some strategies to prevent EFAIL attacks:
Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy&pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.
Short term: Disable HTML rendering. The EFAIL attacks abuse active content, mostly in the form of HTML images, styles, etc. Disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL. Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.
Medium term: Patching. Some vendors will publish patches that either fix the EFAIL vulnerabilities or make them much harder to exploit.
Long term: Update OpenPGP and S/MIME standards. The EFAIL attacks exploit flaws and undefined behavior in the MIME, S/MIME, and OpenPGP standards. Therefore, the standards need to be updated, which will take some time. Update: The changes in the current draft of OpenPGP RFC4880 (bis05) reflect our recommendation to deprecate the SE packet type and that modified ciphertexts should not be displayed.
Full technical paper
Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels [v0.9 Draft] [PDF]
Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky, and Jörg Schwenk.
27th USENIX Security Symposium, Baltimore, August 2018.
The team can be contacted at [email protected].
Questions and Answers
- What is PGP and S/MIME encryption?
- What are the EFAIL attacks?
- Are there CVEs for EFAIL?
- Who is affected?
- Can you read my emails?
- But my emails are TLS encrypted!
- Is my email client affected?
- Can I find out whether I have already been attacked?
- I don't send HTML emails. Am I safe?
- I have disabled HTML in my email client. Am I safe?
- Will signatures prevent these attacks?
- Can you decrypt my own encrypted emails when I lost my private key?
- Do I need to revoke my certificate or public key?
- I have encrypted data using OpenPGP or S/MIME and I won't decrypt it in the email context. Am I safe?
- What happens if there are quotes in the encrypted email?
- Will SPF/DKIM/DMARC mitigate the EFAIL attacks?
- How did EFAIL influence the developments in the current standards?
Both technologies add an additional layer of security to your email communication. If used properly, both technologies should guarantee confidentiality and authenticity of your email messages even if an attacker has full access to your email account. The EFAIL attacks break this additional encryption layer.
The EFAIL attacks break PGP and S/MIME email encryption by coercing clients into sending the full plaintext of the emails to the attacker.
Yes, there are two official CVE nummers for the CBC/CFB gadget attacks:
CVE-2017-17688: OpenPGP CFB gadget attacks
CVE-2017-17689: S/MIME CBC gadget attacks
Different vendors assigned further CVEs for specific security issues relevant to EFAIL, for example, direct exfiltration attacks.
Journalists, political activists or whistleblowers use an additional encryption layer, often PGP, because they fear that someone gets access to their email communication. The EFAIL attacks can be used to break this additional encryption layer. This leads to the situation where anyone getting access to their email communication can also read the victims emails even if they use additional PGP encryption. The same attacks apply to S/MIME which is typically used in enterprise infrastructures.
No. The EFAIL attacks require the attacker to have access to your S/MIME or PGP encrypted emails. You are thus only affected if an attacker already has access to your emails. However, the very goal of PGP or S/MIME encryption is the protection against this kind of attacker. For those users who rely on PGP and S/MIME encryption, the EFAIL attacks may be a big deal!
TLS is a transport layer encryption technology that encrypts network traffic among email clients and email servers, or between two email servers. However, the emails are processed and stored in plaintext on the servers and in the email accounts. Any attacker getting access to these emails, either via compromising an email account or an email server, can read and change these emails. PGP and S/MIME are used to protect the confidentiality and integrity of emails in case an attacker can already access the emails.
Our analysis shows that EFAIL plaintext exfiltration channels exist for 25 of the 35 tested S/MIME email clients and 10 of the 28 tested OpenPGP email clients. While it is necessary to change the OpenPGP and S/MIME standards to reliably fix these vulnerabilities, Apple Mail, iOS Mail and Mozilla Thunderbird had even more severe implementation flaws allowing direct exfiltration of the plaintext that is technically very easy to execute.
Not for sure. You can of course search in your inbox for malicious emails indicating EFAIL attacks. A strong indication for these attacks could be, for example, malformed emails with unclosed img tags followed by encrypted content, or encrypted content that exfiltrates the plaintext to foreign URLs. However, note that emails are encrypted with the keys of sender as well as all receivers. The attacker can target any of these parties to exfiltrate content that is important to you. In advanced attack scenarios where the attacker is in control of the email server, she could have deleted the malicious emails after the victim has processed them.
No. The attacker can change encrypted text/only emails to HTML emails. You need to disable viewing HTML email to increase protection from EFAIL attacks.
Depends. S/MIME or PGP encrypted emails are encrypted with the public keys of all recipients and the sender. The attacker can thus perform the EFAIL attacks if only one of the participants is vulnerable. In order to prevent the EFAIL attacks, all participants must use secure email clients.
No. PGP and S/MIME emails are displayed in the email program independently of whether or not they are signed or whether an existing signature is valid or not. Even if signatures did matter: an attacker can copy the altered ciphertext into a separate email and create a valid signature under his own name.
No. The EFAIL attacks target a victim, who is in possession of the private key and who decrypts our prepared emails in an email client. If the private key is lost, the EFAIL attacks won't help recovering encrypted messages.
No. Using the EFAIL attacks, the attacker can retrieve the plaintext of encrypted OpenPGP and S/MIME messages. She does not get direct access to the private key.
I have encrypted data using OpenPGP or S/MIME and I won't decrypt it in the email context. Am I safe?
For now yes. There may be edge cases though that we hadn't looked into. For example, if you encrypted a directory with sensitive files, an attacker could change these encrypted files to contain false information or even malware. If a victim decrypts the directory and opens any of the files, malware or even just an HTML file could be used to exfiltrate plaintext or even compromise the system.
Quotes in the plaintext might end the URL that is used to exfiltrate the plaintext so that either the bytes after the quote are not exfiltrated or that the exploit may not work at all. Because of the properties of the CBC and CFB modes of operation, an attacker can split a single S/MIME or PGP ciphertext into multiple parts and exfiltrate each independently with separate HTML tags (but still in one email). If one part contains quotes then only the residual plaintext bytes in that part are missing. There is a whole zoo of techniques that the attacker can use to exfiltrate the full plaintext despite these technical obstacles.
No. These technologies offer message authenticity and protection against email sender spoofing. Our EFAIL attacker would copy the S/MIME or PGP ciphertext from the original email and past the changed ciphertext into a new message. The attacker now sends the message under his own name with valid values for SPF/DKIM/DMARC.
There is an ongoing work on two new email security standards. Both considered countermeasures presented in our paper.
The S/MIME standard draft references our EFAIL paper and recommends the usage of authenticated encryption with AES-GCM. Furthermore, it warns that different parts in multipart/mixed emails should be treated as being of different origins.
The OpenPGP standard draft deprecates Symmetrically Encrypted (SE) data packets which are not protected by MDCs. It proposes AEAD protected data packets and mentions that the implementation should not allow users to access erroneous data.
We have responsibly disclosed our findings to the affected vendors who have applied (or are in the process of applying) countermeasures. Please note that in general these countermeasures are specific hotfixes and we cannot rule out that extended attacks with further backchannels or exfiltrations will be found. (Update: After the disclosure, bypasses were indeed published for Thunderbird and Apple Mail.) Moreover, even if all backchannels are closed, both standards are still vulnerable to attacks where the attacker can modify email content or inject malicious code into attachments which get executed in a context beyond email client.
We informed German CERT and BSI about our attacks in December 2017. They forwarded all the relevant information to other CERTs and companies.
We disclosed our attacks to the GnuPG developers on the 24th of November 2017. Further clients are listed below. For reference we also include case numbers and CVEs if they have been assigned. Note that as of May 2018 fixes have been deployed for various mail clients, for details check the vendors' websites.
Attacks on S/MIME clients:
* Due to the amount of disclosed products we have missed communication with this vendor.
Attacks on PGP clients:
Direct exfiltration attacks:
Electronic Frontier Foundation
MAY 14, 2018
Attention PGP Users: New Vulnerabilities Require You To Take Action Now
MAY 14, 2018
Critical PGP and S/MIME bugs can reveal encrypted e-mails. Uninstall now
MAY 14, 2018
PGP und S/MIME abschalten
MAY 14, 2018
Verschlüsselte E-Mails sind nicht sicher
MAY 14, 2018
Major #eFail Vulnerability Exposes PGP Encrypted Email
MAY 14, 2018
Encrypted email has a major, divisive flaw
MAY 14, 2018
PGP und S/MIME: E-Mail-Verschlüsselung akut angreifbar
MAY 14, 2018
S/MIME artists: EFAIL email app flaws menace PGP-encrypted chats
MAY 14, 2018
People Are Freaking Out That PGP Is ‘Broken’—But You Shouldn’t Be Using It Anyway
MAY 21, 2018
Email Is Dangerous
MAY 22, 2018
Die wichtigsten Fakten zu Efail
MAY 24, 2018
What "Efail" Tells Us About Email Vulnerabilities and Disclosure