Site icon Sophos News

The EFAIL vulnerability – why it’s OK to keep on using email

  • Paul Ducklin

    • 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:

    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:

    Assume that, after decryption, the message comes out as:

    Now, replay the encrypted message wrapped up as follows:

    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:

    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:

    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?


    Exit mobile version