EFAIL Opens Up Encrypted Email to Prying Eyes

The flaws threaten to expose corporate communications in Outlook as well as the messages of at-risk users like political dissidents.

A set of vulnerabilities in the encryption technologies used to secure sensitive emails threatens to expose corporate communications as well as the messages of at-risk users such as journalists, political dissidents and whistleblowers operating in hostile environments.

However, there is some debate as to how serious the issues are.

The flaws, collectively dubbed EFAIL by the team of European researchers who discovered it, affect the end-to-end encryption protocols known as OpenPGP and S/MIME.

Email confidentiality is partly protected by Transport Layer Security, but OpenPGP offers an additional layer of end-to-end encryption specifically built to avoid the prying eyes. S/MIME meanwhile is an alternative standard for email end-to-end encryption that is typically used to secure corporate email communication clients, such as Outlook.

According to the researchers, EFAIL affects clients that use a graphical user interface, including Thunderbird with Enigmail, Apple Mail with GPGTools and Outlook with Gpg4win. Secure messaging services such as Signal are not impacted, according to the Electronic Frontier Foundation, which worked with the research team to publicize the problem.

Describing the flaw in a tweet, Sebastian Schinzel, research team member and a professor of computer security at Münster University of Applied Sciences, wrote: “They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past.” The researchers further elaborated the attack methods in documentation (PDF) on EFAIL released Monday.

“EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs,” they wrote. “The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim’s email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.”

To create these exfiltration channels, the attacker needs access to the encrypted emails in the first place, so a first step in any attack would be eavesdropping on network traffic or compromising email accounts, email servers, backup systems or client computers in order to collect messages intended for decryption.

Matthew Green, assistant professor at the Department of Computer Science at Johns Hopkins University and crypto-expert broke down the attack in simpler terms: “In a nutshell, if I intercept an encrypted email sent to you, I can modify that email into a new encrypted email that contains custom HTML,” he tweeted. “In many GUI email clients, this HTML can exfiltrate the plaintext to a remote server. Ouch.”

The attack works on past trails of messages; so, for example, if a regime has been stealthily collecting emails sent by suspected dissidents in hopes of someday decrypting them, EFAIL will allow a nation-state to force the person’s email client to now do so.

How Serious?

While on its face EFAIL seems alarming, a debate is in play as to whether the danger it poses has been exaggerated, with PGP vendors noting that it was a known flaw going back for 17 years, and one that they have addressed.

Werner Koch, principle author at Gnu Privacy Guard, which is a free implementation of the OpenPGP standard, opened a discussion on the issue in which he said that the attack should not work if authenticated encryption (GnuPG’s is called modification detection code, or MDC) is in use, which is the preferred configuration. If it’s not, GnuPG returns an alert.

“In response to that, they said that they did a simple rollback to the non-MDC encryption,” he said. “This is a pretty old thing which we are aware of, and the reasons why a warning has always been printed in that case.”

Enigmail’s Robert Hansen tweeted that “GnuPG has given warnings on missing/malformed [authentication encryption] for years.” He then added that the problem also has been patched in Enigmail for some time.

“Although the EFAIL authors did find some problems in Enigmail – for which we’re deeply sorry, and plead that we’re only human — we fixed them months ago,” he tweeted, adding that users on the 1.9.9 distro should upgrade to 2.0.

Some have been arguing that EFAIL isn’t a problem for OpenPGP as long as the implementations are done correctly (in addition to the aforementioned authenticated encryption, this includes not using HTML emails, which thwarts the problem). Koch for instance said that OpenPGP’s message authentication that thwarts EFAIL (in place since 2001) can’t be made mandatory because “some implementations haven’t kept up.”

Yet others take issue with that line. “No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error,” said Google cryptographer Filippo Valsorda, writing on Twitter. “At most you can say ‘sorry we are a legacy system, no one knew better then, it’s time to migrate off.'”

“If you were using GnuPG on the command line and checking your error results, it’s absolutely true that you’re fine,” Green tweeted, adding that “If you’ve been using (one of several) GUI clients with PGP encryption, you were anything but fine.” He also noted that “PGP clients are vulnerable because 17 years after a vulnerability was known, the mitigation was not made a default in GnuPG and defense was instead left to PGP clients, which also make a convenient scapegoat when it goes pear-shaped.”

Also, Robert Graham at Errata Security examined the flaws and came away with a different take: “It only works if you’ve enabled your email client to automatically grab external/remote content,” he said in a post. “It seems to not be easily reproducible in all cases.”

Outlook Mail Most Affected

In any event, the issue appears to be more serious for S/MIME than it is for OpenPGP. The researchers said as much in detailing one type of exploitation:

“Attacking S/MIME is straightforward and an attacker can break multiple (in our tests up to 500) S/MIME encrypted emails by sending a single crafted S/MIME email to the victim,” they said in their paper. “Given the current state of our research, the CFB gadget attack against PGP only has a success rate of approximately one in three attempts. The reason is that PGP compresses the plaintext before encrypting it, which complicates guessing known plaintext bytes.”

Fixes

As for mitigations, those using HTML clients with these plug-ins have “currently no reliable fixes for the vulnerability,” Schinzel tweeted. “If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now.” Disabling the client will also prevent the ability for anyone looking over one’s shoulder to decrypt past messages.

The EFF, which in its alert published specific ways to disable it in specific clients, echoed the assessment.

“Our advice, which mirrors that of the researchers, is to immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email,” wrote the EFF. “Until the flaws described in the paper are more widely understood and fixed, users should arrange for the use of alternative end-to-end secure channels…and temporarily stop sending and especially reading PGP-encrypted email.”

Graham had a different take: “Instead of disabling PGP/S/MIME, you should make sure your email client hast remote/external content disabled — that’s a huge privacy violation even without this bug.”

 

 

Suggested articles

Using Fuzzing to Mine for Zero-Days

Infosec Insider Derek Manky discusses how new technologies and economic models are facilitating fuzzing in today’s security landscape.

Discussion

  • Craig Hicks on

    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. 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*. 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. 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 fault, it just happens that's the obvious safe place for this proposed solution.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.