Today, a group of security researchers from Germany and Belgium published a vulnerability affecting two email encryption systems: S/MIME and OpenPGP. Dubbed “EFAIL,” this vulnerability has received notable press coverage and we wanted to provide a summary and guidance for DigiCert customers using S/MIME email certificates and other users of secure email.
This research raises some interesting discussions around the true cause of the vulnerability and how secure systems are designed, but we know that our customers’ top priority is mitigating the risk on their systems as soon as possible. We will cover what the risk is and what measures you should take to protect your organization, and then discuss more about the S/MIME protocol.
The EFAIL attack affects emails encrypted with the S/MIME (or PGP, including OpenPGP & GPG) protocols. When successfully executed the attacker is able to read targeted emails without obtaining the private key used to encrypt them.
The simplest form of this attack uses a novel trick—it appends malicious HTML tags to an encrypted email and hopes the email client will unsafely parse that HTML. The attack is executed once the recipient’s email client decrypts the email, processes the injected HTML tags, and then exfiltrates the email, which is now in plaintext, to a URL specified by the attacker.
However, this requires that the attacker can intercept and modify the emails. This requires at least one of the following:
Note that even if your email server is secured with HTTPS, the recipients email server may not be. However, even with this condition met, it still requires that the attack have a privileged position on the network, such as someone connected to your local network, or an ISP/government with control over internet infrastructure.
Neither of these conditions are trivial to achieve for an attacker. If you are using best practice security on your network, you should already have an email server secured by HTTPS, which mitigates one attack vector. If you are not using an HTTPS-secured email server (or are unsure), you should do this immediately by obtaining SSL certificates for them.
There is a risk to emails already sent that are stored in your email client or server if they are compromised.
Note that there are other variations of the EFAIL attack detailed in the published research. These variations require that the attacker knows some of the data of the encrypted message before being able to read it—in the cryptography field this is called a “known ciphertext” attack—and is considerably more difficult to execute. However, in the most high-risk scenarios and settings, the only way to be entirely protected from EFAIL including these less likely variants, is to disable the decryption of S/MIME emails in your email client/server altogether (and use a separate application altogether to decrypt and read them).
This vulnerability does not compromise private keys. Instead, it leverages flaws in how email clients parse emails to retrieve emails that have already been decrypted. You do not need to reissue your S/MIME certificates or private keys to protect yourself from this vulnerability.
This attack can be executed any time the attacker is able to modify the desired emails. Because of this, there are two types of mitigations to account for: protecting individual users and their email accounts/clients, and protecting the email server.
On the client side, the default security settings in Outlook 2013 and 2016 prevent this attack from being executed unless one of the recipients choses to allow external images via the dialog option presented by Outlook. This prevents automatic exploitation of the attack but many users could accidentally or habitually enable this option.
In Outlook 2007 and 2010, external images are allowed by default and can allow for automatic exploitation of this attack as soon as the email is opened. For these email clients, and for all email clients, you can prevent the most common form of the EFAIL attack by disabling HTML emails altogether.
Apple Mail and the iOS Mail app are also vulnerable to automatic exploitation of this attack and should have HTML emails disabled.
We again want to note that executing this attack requires that the attacker has the ability to intercept and modify emails, which is not a trivial precondition.
Note that due to the nature of email, you can only guarantee safety of a specific email if the sender and every recipient of that email has applied these mitigations—this principle is true in general with email security, not just with this specific vulnerability.