Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Learning from #efail
SECURITY SHELF

Learning from #efail 

A brief review of email history is necessary to understand where things came off the rails. Internet email began as a pure ASCII text exchange mechanism, and despite more than two decades of the public Internet, it still uses the same underlying Simple Mail Transport Protocol (SMTP). While the protocol has evolved to include TLS as an optional encryption layer, the actual data exchange remains printable ASCII characters.

File attachments, richer character sets, and HTML-formatted email content are included in emails using a 1990’s standard called Multipurpose Internet Mail Extensions (MIME). While it may have made sense at the time, the standard — still in use today — is a prime example of why security should be a priority.

MIME works by inserting one or more Base64-encoded blocks of data into an email, along with separators and headers that specify the content type of each block. The advantage of this scheme is that the resulting messages can pass transparently through SMTP servers just like plain ASCII text messages.

Each email client, or Mail User Agent (MUA) as they are more formally called, is responsible for separating the various components of the email, decoding them, and display them to the user.

HTML content, one of the worst things to ever happen to email, demonstrates how this feature can be turned against users by dynamically retrieving unwanted images from the Internet and presenting the user with misleading links. The fact that HTML is designed to display hyperlink text that is radically different from the link URL is the number one facilitator of phishing attacks and significantly contributes to malware infections.

S/MIME and PGP use MIME to transport encrypted payloads. Users then have the option of manually saving the attached content and decrypting it, or, more commonly, using the MUA or a third-party plug-in to automatically encrypt and decrypt emails. Unfortunately, this approach essentially consists of layering one poor security design on top of another.

The primary EFAIL vulnerability arises from the fact that an encrypted message can be sandwiched between two insecure blocks of text, and these blocks could contain parts of HTML statements such as an IMG tag. When the encrypted text is decrypted, combined with the preceding and following HTML, and rendered by the MUA, the plain text of the message could be transmitted to an attacker’s HTTP server as part of a URL.

While difficult for the average hacker, altering an email while in transit is easily within the capability of IT staff with access to mail servers, sophisticated criminals, and state-sponsored actors.

This is clearly not the result of a flaw in the PGP protocol itself. On the surface, the vulnerability arises from poor handling of MIME content, and in some cases, weak integration between the MUA and third-party encryptions plugins. However, it is important to recognize that these types of attacks are facilitated by insecure rendering of HTML content and the hack-like MIME standard.

MUAs and web browsers are two primary portals through which people access Internet content. Both are used to view potentially hostile content, and both lack adequate retrieval and rendering controls.

There is no good reason for email client software to retrieve images, or any other content, using HTTP. While marketers will cry foul over the inability to send image-rich emails and monitor opens in real-time, these features provide no benefit to users. While disabling HTML email altogether would please many security professionals, a less intrusive option is to prevent email content from interacting with Internet resources and force the display of the actual URL in hyperlinks.

Similarly, web browsers, often used to access email, should include an option to communicate only with the domain from which the HTML page is served. This may complicate advertising delivery, but it would result in a significant security posture improvement. For example, when using a browser for banking, there is no requirement for the browser to retrieve content from any domain other than that of the bank.

At a deeper design level, the ability to mix encrypted and unencrypted content has often proven — as with EFAIL — to have serious security consequences. Since SMTP email has no integrity protection mechanism, it is trivial to modify an email in transit. Rendering insecure, plain-text content in the same window as secure decrypted content is asking for trouble, especially in light of known HTML weaknesses.

The EFAIL team deserves credit for shining light on this vulnerability. In the short term, MUAs and plug-ins need to be fixed. But in the long term, paying more attention to security is seriously overdue.

Have a security question you’d like answered in a future column? Eric would love to hear from you.

Related posts