Recently there has been a hullabaloo about a vulnerability called EFAIL, that, as is the fashion these days, came with its own website, and logo, here. EFAIL generated intense media interest and also copped a fair amount of criticism for the way it was disclosed and the ensuing hype. There were calls from some that email encryption was broken, and to disable it. Such hasty advice was wide of the mark. So what really was the fuss about? And what does it mean?
EFAIL is an attack that targets encrypted emails, achieved through peculiarities of encryption standards and certain vulnerable email clients. The attack works under a fairly narrow set of circumstances:
You are using end-to-end email encryption with PGP or S/MIME
Attacker already has access to samples of your encrypted messages
Your email client is vulnerable, and your email client is set up to render HTML and load remote content
The first, and obvious point is, if you are not using end-to-end email encryption, then you are not affected. Nothing to see here. But, of course, some privacy-conscious people do use email encryption.
The second important point is, for the attack to work, the attacker must somehow have access to your encrypted email samples, whether it is through compromised accounts or access to email servers or client machines, or eavesdropping on network traffic. If this applies to you, then you already have some serious security issues to attend to, before we get to a potential EFAIL attack.
Thirdly, your email client must be vulnerable. The attack works because of the way certain email clients process email messages and render HTML. Vulnerable email clients can be tricked into decrypting the message content and then exfiltrating cleartext data back to the attacker via loading remote content. Apple Mail, iOS Mail and Mozilla Thunderbird were among clients found to be vulnerable.
The EFAIL Attacks
There are two types of EFAIL attacks:
Direct Exfiltration Attack
Here an attacker, having previously got samples of your encrypted messages, modifies the structure of the email to include a specially crafted HTML image tag, and another MIME HTML body. The images below from the EFAIL siteillustrate the manipulated message, note the image tag is open-ended, it has no end quote. The message and encrypted data immediately follows the image tag, and the ending quote and tag appears in the new HTML body.
The attacker sends this manipulated message to the victim. In the process of rendering the HTML, a vulnerable email client inadvertently sends decrypted data back to the attacker's webserver via the image tag "backchannel".
Malleability Gadget Attack
With this more technical attack, the message MIME structure is not changed, but the attacker uses peculiar features of the encryption block cipher modes to inject specially crafted HTML tags into the decrypted text. These kind of attacks have been known about in cryptographic circlesfor many years, and there are mitigations built into some systems. Essentially, the attackers alter the encrypted data in a special way, without breaking the encryption, that allows for insertion of plaintext of the attackers choosing. The final result is the same, the insertion of HTML tags into a message that cause a vulnerable email client to decrypt the message content and send data to the attackers' webserver via a backchannel.
These attacks are interesting, and indeed clever. However, they are also applicable in a narrow set of circumstances. PGP and S/MIME protocols are not broken. More than anything else, these attacks highlight a range of issues in email clients with their decryption and loading of HTML data.
Use plain text only when viewing email messages. Disable HTML rendering in the email client if possible. Of course, the downside of this may cause some emails based on HTML to look weird, but if your concern is privacy, it is a valid option.
Disable loading of remote HTML content in the email client. This *may* help, but a word of caution here - there are many ways in which HTML can be crafted which could sidestep standard protections in email clients.
What it means for Trustwave Secure Email Gateway (SEG)
This issue does not impact the Trustwave SEG directly. The SEG inspects and relays such encrypted email onto its final destination, it does not attempt to decrypt or render html content like an email client does. As explained, the root of the issue is the failure of some email clients parse email, render HTML, and decrypt content. However, we have released detection logic for the direct exfiltration type of email manipulation tricks in the SEG's Advanced Malware and Exploit Detection (AMAX) filter, and continue to research other aspects of these attacks.