The Lessons Behind an Attack that Decodes Encrypted Email

May 17, 2018  |  By Joel Odom

A team of researchers in Germany and Belgium have just released a paper that describes ways for an attacker to recover the plaintext of encrypted emails. Not only does the class of attacks presented in the paper work against popular PGP and S/MIME encryption schemes, but it also works against multiple email clients, including Outlook, Apple Mail, and Gmail. To decrypt an intercepted email, an attacker need only craft a new email to the recipient that embeds the encrypted email in a clever way that tricks vulnerable email clients to send the plaintext of the original message back to the attacker. The research paper will be presented at the 27th USENIX Security Symposium in Baltimore in August.

 

IISP Analyst Joel Odom: "Let's admit it. Few people use encrypted email. Email security is better than it used to be because we've started using encryption for many of the hops and stops that email makes as it traverses the internet from Alice to Bob, but end-to-end encryption for email is rare. The reason I chose this story to write about is not because it's a flaw that will drastically impact society, but it's a fascinating study in how security fails in unexpected ways. This class of attacks exploits a systemic design flaw rather than a nuanced technical flaw.

How do these attacks work? Suppose that Alice sends an encrypted email message to Bob, which is intercepted by our attacker, Eve. Perhaps Eve intercepts the encrypted message by network sniffing, or perhaps Eve is a sneaky system administrator who can access the encrypted message saved on a server. The point is that the message is encrypted by Alice precisely because there are many ways to capture it as it makes its way to Bob.

In the first variant of the attack, Eve crafts a new email message to Bob in HTML format. This HTML message includes a link to a non-existent image whose pseudo location is partly specified by the encrypted message that Eve is trying to decrypt. When Bob's email client processes the specially-crafted message from Eve, the client encounters the nested encrypted message from Alice and happily decrypts the message using Bob's keys. Having been tricked into thinking that the decrypted message specifies the location of an image to fetch, the client reaches out to Eve for the image and presents Eve the decrypted message in the process.

But, wait! There's more. The paper also describes a second, similar attack whereby Eve can modify the plaintext of the encrypted message from Alice to Bob by making certain clever changes to the ciphertext. This is an application of a known problem with unauthenticated encryption schemes. Eve's modification inserts HTML elements into the message that tricks the email client into send Eve the plaintext of the entire message using a mechanism similar to the first variant described above. (My understanding is that there are optional authenticated modes of encryption available for PGP and S/MIME that I expect would mitigate this attack.)

So what are the lessons here? First, complexity is the enemy of security. HTML is a complex markup language that presents a lot of attack surface for exploitation. Second, attackers can cheat. Eve never actually broke the encryption on the message, she just tricked Bob's e-mail client into decrypting it for her. Third, encryption requires authentication. There are entire classes of attacks that can be prevented by requiring encryption schemes to check the integrity of a message before decrypting it."

 

For further reading

 

 

 


Joel Odom leads a team of researchers focused on software security as branch head for the Cybersecurity, Information Protection, and Hardware Evaluation Research (CIPHER) Laboratory at the Georgia Tech Research Institute. He and his team research static and dynamic software analysis, software testing techniques, software reverse engineering, and software vulnerability discovery and mitigation.

More by the author(s)