EFAIL - They weren't kidding about the pretty good part

June 26, 2018 Jacob Ansari

On May 15, 2018, security researchers published a paper regarding weaknesses in the end-to-end encryption used to protect email using OpenPGP with S/MIME. An attack on this weakness, now designated EFAIL, allows attackers to read the plaintext contents of PGP-encrypted emails. While it doesn’t attack the cryptography of PGP, it does exploit the active content of HTML emails to access the message content after decryption. The entire process progresses as follows: an attacker must first obtain the encrypted email—perhaps through capturing the network traffic, or from having an encrypted email even from a significant time ago. Then, the attacker makes changes to the message, specifically misusing externally loaded content, such as images or styles, and then sends it on to the intended recipient. When the recipient’s mail client receives the message and decrypts it, the modified active content sends the previously protected plain text to the attacker using the same channel as the email’s externally loaded content.

The research actually points to two separate attack types: direct exfiltration and CBC/CFB Gadget attacks. Direct exfiltration works on particular mail clients, such as Apple Mail, iOS Mail, and Mozilla Thunderbird, and allows an attacker to insert an HTML <img> tag into an encrypted email. That tag then points back to an URL under the attacker’s control. When the mail client decrypts the message, it contacts that URL to access externally loaded content, but also posts the plain text of the message back to the URL. While this breach mechanism is relatively simple and effective, it can be anticipated and prevented with software updates to the mail clients in question.

However, the CBC/CFB Gadget attack is more sophisticated. Cipher-block chaining (CBC) is a block cipher mode of operation that divides a plaintext message up into blocks, usually the same length as the key in the cipher (although AES uses 128-bit blocks, even in AES-256). CBC links these blocks sequentially, such that any given block uses the ciphertext output of the prior block as one of its inputs. This prevents certain problems, like an attacker replaying blocks or finding certain patterns in the ciphertext that might allow for some cryptanalysis, but an attacker could modify the part of the message if a specific part of the plaintext is known. Given that most encrypted email messages begin with “Content-type: multipart/signed,” this is usually sufficient for the purposes of an attack. By replacing certain known blocks with blocks containing all zeroes (called CBC Gadgets), and then inserting blocks with an HTML <img> tag that points back to a hostile URL, the attacker can force the mail client to assemble these now compromised encrypted blocks and decrypt them, which then exfiltrates the plaintext to the attacker’s hostile URL similar to a direct exfiltration attack.

Unfortunately, any standards-compliant S/MIME or OpenPGP mail client is susceptible to this, based on the widespread use of CBC as a block cipher mode. This works for both S/MIME and PGP, although such an attack requires many more attempts with PGP--at least for now.

A few short-term mitigations do exist, however—things like decrypting encrypted messages outside of a mail client or disabling HTML rendering—and these are relatively easy to implement, albeit inconvenient for users. Software vendors may be able to patch these issues, although any such CBC Gadget patch is a workaround rather than a true fix. Ultimately, the standards for OpenPGP and S/MIME will need updating to properly address these vulnerabilities.

Despite the seriousness of this kind of attack, its impact may be limited. Intercepting the encrypted emails in the first place is usually not trivial, if only because of the need for broad reach and patience. Also, encrypted email isn’t particularly widespread, due to a variety of technical and user behavior factors. Still, security and privacy remain paramount issues in constant stages of redevelopment as technology evolves, and these kind of attacks, in particular, demonstrate that the interplay between a complex cryptographic system and a complex user-facing application that has the potential for deep-seated and challenging vulnerabilities.



About the Author

Jacob Ansari

Jacob Ansari is the Chief Information Security Officer at Schellman & Company, where he develops and manages the company-wide information security program. Jacob oversees the processes for risk and security assessment, vulnerability management, software security, awareness and education, and incident response. Jacob has also performed in a client facing role as the technical lead for Schellman’s PCI services, and represents Schellman to the payments industry. Additionally, Jacob has experience with other Payment Card Industry assessment services, namely Software Security Framework, PA-DSS, P2PE, 3DS, and PIN. Jacob has extensive technical expertise on matters of information security, compliance, application security, and cryptography, and has been performing payment card security assessments since the card brands operated the predecessor standards to PCI DSS. Over the 20 years of his career, Jacob has spoken extensively on PCI-related matters, trained and mentored assessors, and contributed to groups on emerging standards, advisory bodies, and special interest groups.

More Content by Jacob Ansari
Previous Article
Five Tips to Make a More Secure Internet of Things
Five Tips to Make a More Secure Internet of Things

Originally published at www.isaca.org

Next Article
Experts Break Down GDPR Risks for Investors
Experts Break Down GDPR Risks for Investors

Privacy protection is about to change. Starting on Friday, May 25, the European Union will be enacting the...


First Name
Error - something went wrong!