The EFAIL  attacks take use of flaws in the OpenPGP and S/MIME protocols to reveal the plaintext of encrypted emails. In short, EFAIL abuses the active content in HTML emails, such as externally loaded images or styles, and leaks plaintext via the requested URL. To create these exfiltration channels, the attacker must first access encrypted emails by, for example, eavesdropping on network traffic, destroying email accounts, email servers, backup systems or client computers. These emails may even have been collected many years ago. The attacker modifies the encrypted email in some way and sends the modified encrypted email to the victim. The victim’s email client decrypts the email and loads all external content to reveal the plaintext to the attacker.
This documentation concentrates on the three official CVE numbers for the CBC-/CFB-Gadget-Attacks:
- CVE-2017-17688: OpenPGP CFB-Gadget-Attacks 
- CVE-2017-17689: S/MIME CBC-Gadget-Attacks 
- CVE-2019-14664: Direct Exfiltration 
There are more vulnerabilities that target the OpenPGP protocol's specifications. Some OpenPGP implementations may be broken as a result of this public certificate poisoning. CVE-2019-13050 is another name for this vulnerability: PGP Keyservers are being targeted for certificate spamming attacks.
Damian Poddebniak et al. from the Muenster University of Applied Sciences and the Ruhr University Bochum discovered the EFAIL vulnerabilities on November 24, 2017, submitted a paper to the 27th USENIX Security Symposium in Baltimore on May 13, 2018 and published it. The symposium was held on August 15-17, 2018. The researchers carry out attacks on email communication. The most important blocks for such attacks are backchannels, which are functions that interact with the network. They are used to create exfiltration channels for the plaintext. They enable to forward the plaintext to the attacker. The paper also examines what options attackers have to convert a backchannel into an exfiltration channel in order to get the plaintext. The researchers show that 23 out of 35 tested S/MIME and 10 out of 28 tested OpenPGP email clients are vulnerable .
Email Encrpytion can be done in different ways. The two most common standard for email end-to-end encryption are OpenPGP and S/MIME. The messages are decrypted on the recipient's device after they have been encrypted on the sender's device. A public key is used for encryption and a private key for decryption. The communication partners exchange their public keys before using the encryption and then encrypt the emails with the respective public key of the recipient. Only the recipient can decrypt the message with his private key. Since the protection of the private key is elementary, it is kept on your own end device and must not be passed on.
PGP  is an end-to-end encryption standard that was developed by Phil Zimmermann in 1991 and is mainly used in email communication. Emails as well as directories, files and documents are signed and encrypted with it. In email communication, PGP is based on a hybrid encryption method in which the public keys are exchanged by the communication partners without a central certification authority standing in between. Compression, public-key encryption, symmetric encryption, digital signatures and the Web of Trust (WoT) are important technologies on which PGP is built. PGP allows users to send encrypted messages and to check whether a message is authentic. This prevents information from being modified unnoticed and enables secure and private email communication.
S/MIME  is an extension of the MIME standard with which emails are encrypted, signed or both operations are carried out using hybrid algorithms in email communication. This standard includes cryptographically secure features such as email authentication, message integrity, non-repudiation of the sender, privacy and data security. S/MIME is based on the X.509 Public Key Authority to exchange and validate the public keys of the communication partners. S/MIME uses the X.509v3 certificate and is defined in RFC 2311. All users require a valid X.509 public key certificate signed by a Certificate Authority (CA). This certificate is embedded in all outgoing messages from the sender to distribute the sender's public key. Therefore, the recipient's email client decrypts messages encrypted with S/MIME and extracts the sender's certificate, which contains the public key. Well-known email clients that support S/MIME are MS Outlook, Mozilla Thunderbird and Apple Mail.
Direct Exfiltration Channels in Email Clients
Direct-Exfiltration-Attacks exploit vulnerabilities in Apple Mail, iOS Mail, and Mozilla Thunderbird to directly leak the plaintext of encrypted emails. These vulnerabilities can be fixed in the corresponding email client. The attacker creates a new multipart email with three paragraphs of text, as shown in "Modified Direct-Exfiltration-S/MIME-Email". The first paragraph contains a piece of HTML text that is essentially an HTML image tag. Note that the src attribute of this image tag is opened with quotes, but not closed. The second body contains PGP or S/MIME ciphertext. The third paragraph is also an HTML body part that disables the src attribute of the first body part.
This email is then sent to the victim by the assailant. The victim's client decrypts the second encrypted body part and inserts the three body parts into the HTML email as illustrated in "Client's modified Direct-Exfiltration-S/MIME-Email". Note that the src attribute of the image tag in line 1 is disabled in line 4, so the URL includes all four lines.
Then, the email client URL encodes all non-printable characters (e.g. ”20” is a space) and requests the image from that URL. Because the plaintext of the encrypted email is contained in the URL route, the victim’s email client delivers the plaintext to the attacker. Direct exfiltration EFAIL attacks are applicable to PGP and S/MIME encrypted emails.
First, the new CBC-/CFB-Gadget-Attacks, which take use of flaws in the OpenPGP and S/MIME specifications to steal plaintext, are described.The concept of CBC gadgets in S/MIME is depicted in the diagram below. Attackers can precisely edit plaintext blocks if they know specific plaintext parts due to the characteristics of the CBC mode of operation. As seen in "Modified Direct-Exfiltration-S/MIME-Email", S/MIME-encrypted emails frequently begin with ”Content type: multipart/signed,” indicating that the attacker has at least one complete plaintext block. It can then create a canonical plaintext block with zeros as its content, as seen in "Client's modified Direct-Exfiltration-S/MIME-Email". The block pair X and C 0a is referred to as a CBC device. It then appends CBC gadgets to the encrypted plaintext to insert an image tag as shown in "Decrypted Ciphertext". When the user opens the attacker's email, this creates a single piece of encrypted text that exfiltrates its own plaintext. OpenPGP employs the CFB mode of operation, which has cryptographic features that are extremely similar to CBC and allows the same attack to be carried out with CFB gadgets. The distinction is that any standard-conforming client will be vulnerable, and each vendor will be free to devise their own mitigations, which may or may not prevent the attacks. As a result, it will be important to update the specification in the long run in order to uncover and record changes that address the underlying primary causes of the vulnerabilities.
Despite the fact that the CBC-/CFB-Gadget-Attacks on PGP and S/MIME are theoretically similar, the conditions for a successful attack differ significantly. Attacking S/MIME is simple, because by sending a single designed S/MIME email to the target, an attacker can break several S/MIME encrypted emails. Modern OpenPGP implementations, unlike S/MIME, include a Modification Detection Code (MDC) that may identify modified plaintext blocks and so prevent the CFB-Gadget-Attack. However, several clients only displayed the updated plaintext after issuing a warning to the user for invalid MDCs.
Despite the MDC, the CFB-Gadget-Aattack was possible. PGP also compresses the plaintext before encrypting it, making guessing known plaintext bytes more difficult. Based on current findings, the CFB device attack against PGP has a success rate of about one out of every three attempts. Plaintext compression is more of a technical snag than a fundamental restriction of the EFAIL attacks. Further research will make the attacks more efficient.
To continue using email encryption securely, users must implement the following points to prevent EFAIL attacks. This section is divided in to three terms to visualize the urgency of each implementation.
Active content in the email client must be disabled. This includes HTML code execu- tion and the reloading of external material, which is frequently authorized for aesthetic reasons. Email servers and email clients must be secured against unauthorized access attempts. Moreover, in the case of OpenPGP, the emails can be decrypted in an external program instead of in the mail client, so that an attack comes to nothing.
No decryption in the email client. Decrypting S/MIME or PGP emails in a separate program outside of the email client is the easiest strategy to avoid EFAIL attacks. Decrypt incoming encrypted emails by copying and pasting the ciphertext into a different program that handles the decryption after deleting the S/MIME and PGP private keys from the email client. In this manner, email clients are unable to initiate exfiltration channels. This is currently the safest option with the downside that the process gets more involved.
Disable HTML rendering. The EFAIL attacks target active content, which is often in the form of HTML pictures, styles, and other elements. The most common approach of fighting EFAIL is to disable the rendering of incoming HTML emails in the email client. It is worth noting that email clients have other possible backchannels that aren’t linked to HTML, but they’re more difficult to attack.
Update the email clients. Vendors of the email clients have published patches that either fix the EFAIL vulnerabilities or make them much harder to exploit.
Update: Enigmail and GPG Tools have been patched for EFAIL .
Update the OpenPGP and S/MIME standards. The EFAIL attacks exploit flaws and undefined behavior in the MIME, S/MIME, and OpenPGP standards. As a result, standards must be changed, which will take time.
Update OpenPGP: The advice of Poddebniak et al. to dep- recate the SE packet type and not show updated ciphertext is reflected in the current draft of OpenPGP RFC 4880  [CalAD].
Update S/MIME: Since EFAIL the S/MIME-Standard is updated continously in order to minimize the risks. The email cerntificate standard has been udpated to version 4. The IETF even mentions EFAIL in RFC 8551  and recommends migrating to AES-GCM to fix the EFAIL vulnerabilites. Furthermore, the decrypted content shall not be edited prior to the completion of an integrity check.
The CFB-Gadget-Attacks can also be prevented by updates, the programs just have to evaluate the MDC correctly and reject the outdated SE packets so that the attacks are no longer possible. GnuPG used MDCs since the 2000s and sent out alterts when integrity issues were detected. When the email clients did not ignore such warnings and did not display the message due to the warning, user's were fully protected against EFAIL attacks. The problem was, that some email clients ignored the warning and displayed the message. Nowadays an error in the MDC check leads to termination.
Further individual developers can develop their own solutions to prevent such attacks.
After the two EFAIL security threats were published, media reported that experts advise against email encryption with OpenPGP and S/MIME. The topic was luridly taken up and the encryption algorithms of OpenPGP and S/MIME were described as compromised. Furthermore, the Electronic Frontier Foundation released information on EFAIL earlier than agreed with Poddebniak et al. and advised against the use of the two standards. This caused significant damage to the image of S/MIME and OpenPGP and prompted numerous users to dispense email encryption. The EFAIL vulnerabilities did not cause any significant economic damage. However, the signaling effect of the two vulnerabilities and how they were communicated is problematic. Damian Poddebniak et al. are strongly criticized by security experts for the way EFAIL was published. The media boycott by the researchers and their website make it appear that the researchers wanted to attract lot of attention.
Security experts have been recommending encrypting emails for years. EFAIL has contributed to questioning the confidence of many users in encryption methods, although the root causes of EFAIL are not the encryption methods. The problem with the two vulnerabilities is the outdated implementation of the two email standards. Data of different data types are not properly separated from each other and this leads to risky misinterpretations by the email client .
Encryption with PGP and S/MIME is not nearly as reliable as thought. Due to insufficient standards, outdated technology and faulty programs, attackers could gain possession of encrypted emails sent. Neither S/MIME nor OpenPGP can sufficiently ensure the security of encrypted messages sent. An attacker who intercepts and manipulates encrypted emails can acquire access to at least some of the plaintext of the communication. In reality, this flaw, known as EFAIL, affects all email encryption applications, rang- ing from Outlook and Windows Mail to Thunderbird and Apple Mail. The situation is particularly dramatic for S/MIME bebcause it is mainly used in corporate environments. However, even the basic PGP has serious problems that can be used to carry out quite targeted at- tacks. Updates from OpenPGP extension vendors (like Enigmail [MKP+17]) can alleviate the EFAIL consequences, at least in the medium term. This article delves into the technical details of the vulnerabilities, which may be seen through electronic bug assaults. The best way to protect oneself is to avoid sending very sensitive data via email. Preventative steps such as deactivating HTML content display and refreshing external elements such as photos can greatly reduce the severity of the problem. Messenger communications can be encrypted end-to-end as a simple alternative. Unlike OpenPGP and S/MIME, it uses cutting-edge encryption and is unaffected by current email-related difficulties. It may also be used to securely transmit files. Signal’s effectiveness in managing sensitive data communicated over the Internet has been demonstrated several times in practice.
Leading experts share the opinion that such threats can be avoided in the future by reducing the complexity of email standards and by being more diligent in developing new and evolving existing standards. Security threats like EFAIL do not occur because of the cryptographic algorithms, but because extensive requirements are placed on email communication. The OpenPGP and S/MIME security protocols are outdated and overly complicated .
The ten most common questions regarding EFAIL are addressed below .
- What is PGP and S/MIME?
They are email standards which add an additional layer of security to email communication. When they are used properly, both standards should guarantee confidentiality and authenticity of emails. The EFAIL threats break this additional encryption layer.
- What are the EFAIL threats?
The EFAIL threats break OpenPGP and S/MIME email encryption forcing clients to send the plaintext of emails to an by an attacker controlled server.
- Who is affected?
Often journalists, political activists or whistleblowers use an additional security layer, like OpenPGP or S/MIME because they fear consequences and that someone gets access to their sensitive email data. The EFAIL threats can be used to break the additional security layer.
- Is my email client affected?
EFAIL plaintext exfiltration channels were identified for 25 of the 35 tested S/MIME and 10 of the 28 tested OpenPGP email clients. It is necessary to change the OpenPGP and S/MIME standards to reliably fix these vulnerabilites.
- Can you read my emails?
No. The EFAIL threats require the attacker to have access to your by S/MIME or OpenPGP encrypted emails. You are only affected by EFAIL if an attacker has already access to your private email messages.
- I do not send emails with HTML content, am I Safe?
No, the attacker can change encrypted text/only emails to HTML emails. You should disable viewing HTML emails to increase security protection.
- My data are encrypted with OpenPGP or S/MIME and I will not decrypt it in the email client. Am I safe?
- I have disabled HTML content in my email client, am I safe now?
It depends, if all participants use secure email clients, you are safe. Emails which are encrypted by OpenPGP or S/MIME are encrypted with the public keys of all recipients and the sender. The attacker can perform the EFAIL threats if only one of the participants is vulnerable.
- Can my own encrypted emails be decrypted when I lost my private key?
No, if the private key is lost, the EFAIL threats will not help to recover the encrypted messages.
- Should I revoke my certificate or public key?
No, EFAIL allows the attacker to retrieve the plaintext of encrypted OpenPGP and S/MIME messages. Attackers do not get direct acccess to the private key.
- How did the EFAIL attacks influence the developments in the current email standards?
S/MIME recommends the usage of authenticated encryption with AES-GCM. It also warns that different parts in multipart/mixed emails should be treated as being of different origins.
OpenPGP deprecates symmetrically encrypted 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 sensitive data.
Ausgewählte Kapitel der IT-Security ILV
- ↑ https://efail.de/media/img/logo.svg/
- ↑ https://www.efail.de/
- ↑ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17688
- ↑ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17689
- ↑ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14664
- ↑ https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak/
- ↑ https://www.ietf.org/rfc/rfc4880.txt/
- ↑ https://www.ietf.org/rfc/rfc2311.txt/
- ↑ https://efail.de/media/img/exfil1
- ↑ https://efail.de/media/img/exfil2
- ↑ https://efail.de/media/img/exfil3
- ↑ https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak
- ↑ https://efail.de/media/img/smime-attack
- ↑ https://www.eff.org/de/deeplinks/2018/05/pgp-and-efail-frequently-asked-questions/
- ↑ https://www.ietf.org/rfc/rfc4880.txt/
- ↑ https://www.ietf.org/rfc/rfc8551.txt/
- ↑ https://www.dfn-cert.de/aktuell/efail.html/
- ↑ https://www.schneier.com/essays/archives/2018/05/what_efail_tells_us_.html/
- ↑ https://efail.de/