EFAIL: Email Encryption's HTML Blind Spot

The EFAIL attack wasn’t about breaking encryption directly, but rather a clever way to trick email clients into decrypting sensitive content by exploiting how they process encrypted and unencrypted parts of the same email.

Imagine an attacker receives an encrypted email. They can’t read it, but they can send a modified version of that same email back to the victim. This modified email has a few key components:

• A seemingly innocent part: This could be a regular text part of the email, or even an image tag.
• An encrypted part: This is where the attacker places the original encrypted content of the email they received.
• A malicious link or resource: This is the crucial part. The attacker crafts a URL that, when requested by the victim’s email client, will cause the client to send decrypted email content back to the attacker’s server.

When the victim’s email client receives this specially crafted email, it tries to display it. The client, following its logic, will decrypt the encrypted part. Here’s the trick: the attacker knows the structure of the encrypted email and can embed a pointer within it that, when decrypted, points to the malicious URL.

When the email client attempts to render this decrypted content, it sees the malicious URL and, thinking it’s a legitimate part of the email (like an image or a link to follow), makes a request to that URL. Crucially, the email client includes the decrypted content of the original encrypted email in the request to the attacker’s server. The attacker then receives this decrypted data and can read the sensitive information.

This attack leveraged a combination of how email clients handle multipart messages and their tendency to automatically fetch external resources (like images) when displaying emails.

Common Causes and Fixes

The EFAIL attack exploited several weaknesses in how various email clients handled OpenPGP/GPG encrypted emails. Here’s a breakdown of the most common vulnerabilities and their fixes:

1. Automatic Image Loading in HTML Emails: Many email clients, when displaying an HTML email, automatically fetch external resources like images. If the decrypted content contained an HTML <img> tag with a malicious src attribute pointing to the attacker’s server, the client would embed the decrypted content into the URL request.

   • Diagnosis: Look for email client settings that control automatic loading of external content or images in HTML emails.
   • Fix: Disable automatic image loading/fetching of external content in your email client’s settings. For example, in Thunderbird, this is under "Account Settings" -> "[Your Account]" -> "Composition" -> "HTML" and ensuring "Automatically load remote content in messages" is unchecked. For other clients, search their specific settings for "remote content," "images," or "external resources."
   • Why it works: By preventing the email client from automatically fetching external resources, you break the chain of communication that sends the decrypted content to the attacker’s server. The client simply won’t make the request.

2. MIME Type Handling for Encrypted Attachments: Some clients would incorrectly interpret encrypted content that was part of a multipart message (not a standard attachment) as something that needed to be rendered, potentially triggering the decryption and subsequent exfiltration.

   • Diagnosis: This is more inherent to the client’s MIME parsing logic. It’s less of a user-configurable setting and more of a client bug.
   • Fix: Update your email client to the latest version. Developers patched these vulnerabilities by improving how they parse and handle encrypted MIME parts. For instance, GPG Mail for Apple Mail and the Enigmail add-on for Thunderbird (which was later integrated into Thunderbird itself) received updates. Ensure you are running the patched versions.
   • Why it works: The updated clients correctly identify encrypted parts and do not attempt to render them in a way that could be exploited. They treat them as opaque encrypted blobs until explicitly told to decrypt.

3. Content Spoofing and Redirection: Attackers could craft messages where the encrypted part, when decrypted, contained JavaScript or HTML that would redirect the browser or trigger network requests.

   • Diagnosis: Check if your email client has settings for JavaScript execution within emails or if it has robust sandboxing for HTML rendering.
   • Fix: Disable JavaScript execution in emails and use a secure email client that sandboxes HTML rendering. Many clients offer options to disable JavaScript. If your client doesn’t, consider switching to one that does, like newer versions of Thunderbird or KMail.
   • Why it works: By preventing JavaScript from running or by isolating HTML rendering, the malicious redirection or network request cannot be initiated by the email client itself.

4. Insecure Handling of Decrypted Content in Preview Panes: Some email clients would decrypt and process content within the preview pane, even if the user hadn’t explicitly opened the email or chosen to decrypt it.

   • Diagnosis: Observe if your email client shows decrypted content in the preview pane without you clicking "decrypt."
   • Fix: Disable the preview pane or ensure that decryption within the preview pane is explicitly disallowed or requires user confirmation. Most modern clients have settings to disable preview panes or control what gets rendered there.
   • Why it works: If the decrypted content isn’t processed or rendered until the user actively requests it, the attack vector of automatically exfiltrating data is removed.

5. Weaknesses in Older PGP/GPG Implementations: Before EFAIL, some older versions of PGP/GPG libraries and their integrations might not have fully anticipated this type of attack, leading to vulnerabilities in how they handled the interaction between decryption and content rendering.

   • Diagnosis: This is a systemic issue tied to the software version.
   • Fix: Ensure both your email client and your PGP/GPG implementation (e.g., GnuPG) are up to date. Keep all components of your email security stack patched.
   • Why it works: Updates include patches for known vulnerabilities, ensuring that the decryption process is robust against these kinds of content-based attacks.

6. User Education and Phishing Awareness: While not a technical fix for the client, user behavior plays a role. Users might be tricked into clicking malicious links within emails, even if the encryption itself wasn’t broken.

   • Diagnosis: This is a behavioral aspect.
   • Fix: Be cautious of unexpected emails, especially those with unusual formatting or requests to click links or download attachments, even if they appear to be encrypted. Always verify the sender and the content’s legitimacy.
   • Why it works: By being vigilant, users can avoid interacting with the malicious parts of a crafted email, thus not triggering the exfiltration mechanism.

The primary takeaway is that EFAIL wasn’t about breaking the cryptographic algorithms themselves but about exploiting the application layer – how email clients chose to display and process content, especially when mixing encrypted and unencrypted parts. The fix largely involved updating email clients and PGP/GPG tools to be more security-aware about content rendering and external resource fetching.

After fixing EFAIL, the next immediate problem you’ll likely encounter is the realization that many older encrypted emails might have been compromised if you were vulnerable.