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 is a Manager at Schellman. Jacob performs and manages PCI DSS assessments. Additionally, Jacob oversees other Payment Card Industry assessment services, namely PA-DSS and P2PE. Jacob’s career spans fifteen years of information security consulting and assessment services, including network and application security assessments, penetration testing, forensic examinations, security code review, and information security expertise in support of legal matters. Jacob has performed payment card security compliance assessments since the payment card brands operated their own standards prior to the advent of PCI DSS. Jacob speaks regularly to a variety of audiences on matters of information security, incident response, and payment card compliance strategy.More Content by Jacob Ansari