Email encryption exploits. Time to ditch HTML from your messages.

[vt100]

The ability to include rich content in the email, HTML links specifically, was always a bad idea from security point of view. This latest development making even those of us taking advantage of encryption weary of the consequences. EFAIL describes a method of circumventing S/MIME and OpenPGP encryption of the email.

I am pretty sure that if messages are signed, as well as encrypted, you are still relatively safe, as the moment original email is altered, your message is delivered preserved in its' original state as an attachment.

[denbesten]

HTML email is a good thing. It is a well-known and well-supported standard for defining how a document should look.  It enables users to communicate much more effectively, emboldening those items that are important, adding headings to various sections, using bullet lists, embedding images, etc.  Alternatives, such as .RTF creates compatibility nightmares.  Supporting only text results in a product that poorly matches the customer/user's expectations.  Just looking at the posts in this discussion group makes it obvious that HTML formatting is desired, even by security professionals.

The bigger issue is that email readers should limit the HTML they display to only the markup involved with presentation.  Supporting the interactive parts that belong more on the web and trying to display broken HTML are the areas where they get into trouble.

There is also a need to address deceiving URLs.  One possible solution is to make URLs harder to click if they do not match the domain of the sender and non-clickable if they occur on a known-bad list or fail a real-time reputation filter.

Incidentally, @vt100, the link in your posting is broken.

[vt100]

Thank you for the heads-up about the broken link. I've corrected it.
There are vendors that specialize in sandboxing web-sessions opened from URLs in email (Menlo is one of them). The problem is that the onus for implementation and overheads in costs and management are always at the end-point.
Yes, pretty formatting and media embedded in the email are eye-caching and, in some instance, more informative.
This being said, the actual informational payload contained within could, more often than not, be conveyed in a few lines of text.

[Baechle]

Gents (@vt100, @denbesten😞

Multimedia, including HTML, Rich Text, and attachments are an ongoing target of exploit in emails regardless of if they are encrypted, signed, or otherwise managed.  The analysis thus far has failed to incorporate the possibility of a co-opted client, a malicious but otherwise legitimate user, or the forwarding of a compromised email from a third party source.

The question here is, what is the level of risk you or your organization is willing to accept in exchange for permitting marked-up emails and multimedia attachments after implementing any additional mitigative controls?

The safest bet is to use plain text email from a security perspective.  Even plain text email can exploit a vulnerability in a weak mail client application.  Plain text can certainly exploit the wetware reading the message.  However, the safest bet may not be what is considered optimal for you or your organization.  That's especially true if you rely heavily on multimedia for your work or marketing campaigns.

I personally block multimedia from running in my emails, and rely heavily on plain text messages.  I enable content of marked up messages only when I absolutely have to (in other words I'm so excited by the content I can't wait to see it).  Usually these messages are some kind of marketing material that is replicated on a website, and I prefer to go directly to the website anyway.  Even if it's multimedia, I prefer to offload it somewhat.  For example, running it in a viewer through Google Docs rather than opening it directly on my computer.

What things do you do to insulate yourself from rogue code or attachments in your emails (besides Menlo)?

Eric B.

[vt100]

I am running my own email server behind Check Point firewall acting as MTA and using Threat Emulation by exploding payloads in cloud-based sandboxes.

GMAIL account forwarding messages to it as well.

Office 365 account is, ironically, the least secure, but am simply exercising common sense and using it sparingly only with my clients and few trusted vendors. Attachments are scanned before opening and sites opened from URLs contained in the email are rendered by Menlo.

[denbesten]

The safest bet is rarely the optimal one.  For example, we drive cars when public transportation safer.  We eat junk food.  We attach phones to our ears/eyes regardless of what else we might be doing, We connect our lives to the Internet, etc.    

In my company, management is more willing to invest in mitigation and less willing to tolerate reduced e-mail functionality (or availability!).  Tearing email away from them is more difficult that separating a teenager from their iPhone.

In answer to your question regarding email:

1. End-users get annual anti-phish training.
2. We use Symantec email.cloud to scan all incoming and outgoing email.
3. All links are replaced by Symantec clicktime.
4. We have a whitelist for attachment extensions.
5. Emails from the Internet get an "[Internet]" tag added to their subject.
6. Our mail client disables automatic picture download by default.
7. We have a report-a-phish tool installed in our email clients by group policy.
8. We have opportunistic encryption enabled for SMTP.
9. The AV software on our PCs again scans email heuristically watches the PC, etc. 
10. We aggressively patch OS and applications, particularly security patches.
11. We aggressively control our egress traffic (web and other), both limiting access to sites with bad reputations and monitoring which PCs attempt to access known-compromised sites.  

In spite of all this, bad things occasionally slip by, which is why we have an IR team.

[JoePete]

---

@denbesten wrote:

HTML email is a good thing. It is a well-known and well-supported standard for defining how a document should look.

---

I have to disagree, and I think the W3C would back me on this. HTML is not about how a document should look. HTML describes how parts of a document function. This allows an HTML client (and more important a user of that client) to render content in a way most appropriate for him or her. This gets to issues of usability and accessibility. For some users, it's not just a choice to ignore certain HTML elements, but a necessity due to limitations of a sight, hearing, etc. Ultimately, however, it is part of HTML standards to allow the user to control how or if certain elements are displayed.

---

 The bigger issue is that email readers should limit the HTML they display to only the markup involved with presentation.  Supporting the interactive parts that belong more on the web and trying to display broken HTML are the areas where they get into trouble.

---

This is an interesting idea, but the problem with much of HTML email, and it is illustrated in the EFAIL vulnerability is the simple img tag - if you are loading images (or a style sheet for that matter) you are essentially allowing your email client to communicate synchronously with someone's/anyone's web server without really knowing much about that someone or their server or the content being sent their way. I like the idea of restricting the HTML that gets loaded in a client - several clients already do that.

While I appreciate your embrace of HTML email, being the curmudgeon that I am, I detest it. I hail from a prior generation of the Internet where HTML email was poor netiquette - the equivalent of rolling up to a stop light, windows down, and blaring Milli Vanilli for all the neighborhood to hear. But I also realize that ship sailed long ago. Especially on mobile devices, you really have to work to set up a client to read only plain text these days.

[denbesten]

---

@JoePete wrote:
HTML is not about how a document should look. HTML describes how parts of a document function.

I do apologize if I implied HTML to be a page-definition language. I had hoped that my examples made it clear it is a semantic markup language.  However, I do hope that you embrace my bigger theme that using text/html is better than other mime types, such as application/pdf, application/rtf, or application/msword.  

if you are loading images (or a style sheet for that matter) you are essentially allowing your email client to communicate synchronously with someone's/anyone's web server.

Often, this is not the case.  Most emailed images I encounter are embedded inline either with the "<img src=data:..." or "<img src=cid:..." syntax.  These do not require anything other than that which is contained in the message itself.

The bottom line is that external resources should not automatically display.  Some email clients support this by default (e.g. Outlook 2016); others can be made to with a settings change (e.g. Gmail).

The "poor netiquette" objections mostly predate wide support for MIME in email clients. For me, that ended with the release of pine version 3.0 in 1992.

In my world, the discussion is about how to make HTML email secure; not about avoiding it due to insecurity. Both my presumed embrace (or your detest) of HTML is much less important than keeping executives happy (both productive and secure), so they sign our paychecks, and also making our companies attractive to the younger work force so that we can all retire some day.

[geniusdibya]

The problem with email is, it's an open protocol with no way to upgrade it from the core.

This is why every mailbox provider is having its own set of anti-spam policies too.

text/html is also a part of this legacy only. With the evolution of generation (to be specific - its the marketing evolution), the need of having HTML and many other multimedia increased dramatically. 

But, the core SMTP protocol was unable to change at this speed. We just get wrappers like SPF, DKIM and DMARC to protect emails from spam. 

So, in my view, we can't really discard HTML instead we can have stronger wrapper policies on top of that. Like Google recently going stricter with the support of HTTPS URL within the emails.

Another similar example is BIMI, which definitely not protects the content of the email or adding any encryption, but gives some sort of visual trust-building for the end recipient.