carloscastilla - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Efail flaws highlight risky implementations of PGP and S/MIME

The messy disclosure of the Efail flaws raised questions about the security of email encryption, while experts said S/MIME may be more at risk than some PGP implementations.

Another bungled disclosure has left the infosec community scrambling for answers regarding the branded Efail flaws concerning email encryption processes.

The vulnerabilities affect two popular protocols -- Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME) -- for encrypting email and allow threat actors to reveal the plaintext of encrypted messages. Sebastian Schinzel, professor of computer security at the Münster University of Applied Sciences in Germany and part of the research team that discovered the Efail flaws, tweeted a teaser about the issue at 8 a.m. Central European Time -- 2 a.m. Eastern Standard Time.

The disclosure was planned for Tuesday, May 15. However, just as information leaked out early regarding the Spectre and Meltdown vulnerabilities before disclosure, this teaser provided enough information for the infosec community to find the link for the research paper, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels."

The Efail flaws

According to the research team -- a combination of researchers from the Münster University of Applied Sciences, the Catholic University of Leuven and Ruhr-University Bochum in Germany -- the Efail flaws would allow an attacker to "abuse back channels to create plaintext exfiltration channels that allow sending plaintext [messages] directly to the attacker" from affected email clients.

Bob Rudis, chief data scientist at Rapid7, based in Boston, described two areas of impact for the Efail flaws.

"The main vulnerability is that attackers can specially craft an email message 'sandwich' where messages contain one malformed HTML component, one encrypted text component, and another malformed HTML component with specially formatted remote resource links that ultimately cause it to send the plaintext (decrypted) version of the message back to the attacker, thus providing them with both the ciphertext and plaintext, while making your email encryption setup pretty moot," Rudis said via email. "The secondary weakness [or] vulnerability lies in the technical specification and implementations of OpenPGP and S/MIME."

Kevin O'Brien, CEO of GreatHorn, a cloud email security firm based in Waltham, Mass., said the issue appears to be dependent on whether or not email clients properly implement authenticated encryption (AE) standards such as Modification Detection Code (MDC) packets.

"MDC resolves the issue, but only for mail clients and implementations of PGP (such as OpenPGP) that support it. For GPG [aka GnuPG], MDC is automatically enabled with PKI [public key infrastructure] encryption. With symmetric encryption algorithms, it can be forced assuming the blocksize and algorithm supporting it," O'Brien said via email. "S/MIME does not currently support MDC. It's a much larger issue here, as AE is the best fix; this is why the original white paper notes that the standards themselves need to be modified in order to resolve this issue systematically."

Jesse Victors, security expert at Synopsys, based in Mountain View, Calif., said Efail "appears to affect more clients that use S/MIME, rather than OpenPGP directly. But most of the discussion appears to be centered around PGP."

"S/MIME is primarily used in the corporate environments that use an organization-wide certificate system, whereas OpenPGP is more common within the technical communities," Victors said via email.

"S/MIME only uses the cipher block chaining (CBC) mode for encrypting messages with little additional processing. Efail is more effective against S/MIME because attackers can exploit the properties of CBC-based encryption to inject the attack into messages," he continued. "This is more difficult with OpenPGP, which employ compression, support other encryption techniques, and have additional standards and implementations that make Efail more difficult to exploit in practice."

Mitigations for the Efail flaws

The researchers noted that attackers exploiting the Efail flaws could also bypass MDC, meaning there would need to be more systemic fixes to PGP and S/MIME protocols in order to truly patch the issues.

Robert J. Hansen, evangelist for GnuPG, or GPG, said on Twitter that the default is to show a warning when GnuPG sees a message without MDC, and "it's up to your email client to do the right thing."

"Your email client should refuse to render the message. If it ignores the warning or does the wrong thing in response to it, then yes, the Efail attack is very real. So it's really more fair to say this is an attack on poorly-written clients, not OpenPGP," Hansen wrote. "The OpenPGP spec does technically allow for non-MDCed messages. It has to for backwards compatibility reasons. But no modern OpenPGP client should silently ignore missing/malformed MDCs. No modern email client should ignore the OpenPGP client's warnings."

Because relying on developer implementation can be tricky, the research authors suggested disabling PGP decryption in an email client. But Victors said that advice was "excessive."

"Automatic PGP encryption [and] decryption is crucial [to] the usability of PGP. A modern and properly configured email client should properly handle HTML parsing and avoid external links. Those that do not will soon be patched against this issue," Victors said. "It's important to note that the authors have published a table of affected clients and not everyone is affected. This is an implementation issue, so keep your tools up to date."

Matthew Green, cryptography expert and professor at Johns Hopkins University's Information Security Institute, wrote on Twitter there are major email clients that are susceptible to the Efail flaws, like Apple Mail and Thunderbird.

Rudis said there were other mitigation options for the Efail flaws.

"First: reject all mail with HTML attachments. This is good advice in general, though many organizations use HTML email for enhanced formatting capabilities. Second: disable remote resource loading (which are usually images). If your client or environment does not support that, consider switching to a client [or] environment that does as this will have other benefits -- such as disabling tracking via invisible images," Rudis wrote. "Finally, if you work in a sensitive profession such as academic research or journalism and rely on encryption for confidentiality, consider manual processing of PGP encrypted email until the vendors have a time to catch up and issue patches or enhanced configurations to mitigate these weaknesses."

Steve Malone, director of security product management at Mimecast, headquartered in London, said these suggestions may not be realistic for many.

"Long term, the standards will need to be revised, but that helps little right now. Advice such as disable HTML email, don't use email for confidential communication, use Signal or Telegram, or use a different email client, just won't fly in the real world," Malone said. "Organizations should consider how S/MIME and PGP fit into their email strategy as a whole and think about a way to provide a more joined-up cybersecurity and resilience posture."

Dan Guido, co-founder of security firm Trail of Bits, based in New York, suggested on Twitter that there may also soon be scripts that could easily scan email archives for evidence of exploit.

Dig Deeper on Email and messaging threats

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

Does your organization use PGP or S/MIME implementations? How worried are you about Efail?
Cancel
At some finite date in the (hopefully) near future, most email client over GnuPG users will have an EFAIL-reading safe system setup, if they don't already.  MDC will be strictly enforced.

However, the situation for a secret message sending is not so good. There is no way to guarantee that the reader/receiver has updated their software and/or settings. Statistically speaking security updates are not enforced uniformly; there are always laggards. Therefore, without adequate additional precautions, there will always exist the possibility of a secret message writer/sender's message being read by an EFAIL attacker.

A solution to this problem is proposed in

"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


Because each block is vulnerable, the solution works by individually protecting each block against being wholly included as part of an HTML attribute.  It is possible because the attacker is restricted to dividing the message along 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 obfuscating string *o*, and the second part is 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*.

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.

More detail is included in the above github document.

Because alignment of the obfuscation part with the encryption block boundary is critical, the implementation should be done in the base module, e.g. GnuPG, rather than an email client.  Of course it is not a GnuPG (or other OpenPGP implementor) fault, it just happens that's the obvious safe place for this proposed solution.

Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close