Mimecast’s newly discovered email exploit isn’t a vulnerability, it’s a feature

The alleged exploit centers on the fact that HTML-based email can be malicious

knife lanyard knot untangle rope
David J. Fred (CC BY-SA 2.5)

Mimecast, a Boston-based email security firm, claims to have discovered a new email exploit. The exploit itself centers on the fact that an attacker who sends an HTML-based email linking to an external CSS file can "edit any text in the body of an email whenever they want."

Boiled down, the Mimecast advisory on their exploit / attack vector discovery – called ROPEMAKER – explains how remotely hosted CSS (meaning any code that falls outside of an organization's trusted network) is dangerous.

Mimecast says their discovery centers on the fact that an attacker can alter the CSS under their control to change email post-delivery, regardless of whether or not the message has been opened.

Mimecast email attack Mimecast

For example: If a basic email template used the DIV IDs "Good" and "Bad" in the HTML – representing harmless and harmful content - and the CSS originally calls for "Good" to have an inline display option, while "Bad" is set to none, then the email appears harmless. However, reversing those settings on the CSS hosted externally will see the email display the previously hidden malicious content instead.

"Is ROPEMAKER a software vulnerability, a form of potential application abuse/exploit, or a fundamental design flaw resulting from the intersection of Web technologies and email? Does it really matter which it is? For sure attackers don’t care why a system can be exploited, only that it can be," wrote Matthew Gardiner, Senior Product Marketing Manager, in a company blog.

Mimecast says that their newly discovered exploit undermines "the security and non-repudiation of email; even for those that use SMIME or PGP for signing…"

That sounds frightening, but the reality is completely different.

This isn't an exploit, or vulnerability. It isn't even a bug. What Mimecast describes in their advisory is a feature, and one that isn't even widely supported.

Outlook.com and Gmail for example, block external calls to CSS using the LINK attribute. Mimecast makes mention of using EMBED, OBJECT, FRAME, or IFRAME, even SVGs as alternate modes of exploitation. Again, these are all known attack methods, and once more, many of the mainstream email providers block them.

In fact, Mimecast themselves admit that Gmail, Outlook.com, and iCloud.com were not affected by their discovery. However, the desktop and mobile versions of Outlook, Apple Mail, and Thunderbird were "susceptible" to their attacks.

But the thing is, their attack was always going to work, because they controlled everything from end-to-end. If an attacker has that level of control, it's game over.

Update: In regards to the fact their attack was always going to work, a Mimecast spokesperson emailed Salted Hash with some additional thoughts.

"They feel there’s a difference between an attacker created malware with its associated C2 back-end that is also created and managed by the attacker (for sure that level of control is game over) and a standard feature of HTML which by its very nature enables remote control of email post-delivery.  Just by using the HTML as designed a bad actor can do their thing. Also, how to make things trickier to defend against ROPEMAKER doesn’t necessarily involve malware."

Most administrators limit the types of external content that can be loaded automatically via email, in their mail flow policies – severely limiting the scope of attacks using the methods Mimecast describe.

Also, Microsoft customers with the Enterprise E5 license have the Advanced Threat Protection package included, which sells for about $2.00 per user. Still, even if mail flow policies are incomplete, it's entirely possible to avoid the hypothetical attacks described by Mimecast by configuring the mail client itself.

For Outlook users, you can switch to plain text email by following the directions on Microsoft's support page.

For Apple users, it is possible to disable the loading of remote content, such as images or CSS.

On Mozilla's Thunderbird client, remote content is ignored by default, but it is possible to enable it (pro tip: don't do this).

Salted Hash reached out to a few experts and shared Mimecast's report in order to get their thoughts. None of them felt the issues raised by vendor were earth shattering or even new.

One, speaking on background, commented that changing the link after the fact wasn't all that useful to a red team, as both the harmless and malicious links would be in the source code of the email. Thus, any scanners or other tools that would normally flag the malicious link would do so even if it is "hidden" by the CSS.

mimecast example 2 Mimecast

Update: The Mimecast spokesperson also shared additional thoughts on the fact that scanners would detect attacks using their discovery.

The advisory authored by Mimecast does mention that the switch attack (where you replace one link with another) could be easy to defend against with modern email defenses. The matrix attack referenced below is also one the experts we spoke to flagged as a common spammer tactic that would be detected. An example of a matrix attack is in the image on the left.

"Of course this assumes organizations are using email security systems that handle URLs in this way. However, the “Matrix exploit” provides an example where no malicious content exists in the email at delivery and thus there is nothing for an email security system to detect. The malicious message/URL isn’t created/displayed until post-delivery.  Thus any inbound network security control would be bypassed. And thus only endpoint security controls (in the case of malware being ultimately in the picture), outbound security controls (SWG/DNS filtering), or the “savvy” user themselves would be left. Another good argument for multi-layered security."

In fact, the more interesting aspect of what Mimecast described would be to have someone take an action, and then change the message after the fact. Another expert said it's easier to just send an attack email straight-off rather than swap out content later.

There are a lot of places where an attack like the one described by Mimecast could fail or draw attention.

"Does the email client fetch the new content again or will it stick to the one that was cached with the benign content? Is the victim connected to a network to fetch the new content? If it doesn't fetch the new content then you, with your pretexting Social Engineering scenario on the phone with your victim, are going to be sweating," said Tom Van de Wiele, Principal Security Consultant at F-Secure.

"Because it might not render the content, it might throw an alert, or the web proxy or AV might catch it with your victim on the phone. Long story short, as part of red-teaming there is not a lot to gain here as an attacker, other than to raise suspicion which will ultimately skew the results of your red-teaming operation and the investment of your customer."

Mimecast reported their discovery to Microsoft and Apple, and even attempted to get a CVE assigned. However, MITRE rejected the CVE request, Microsoft said it wasn't a security issue, and Apple provided instructions for blocking remote content.

In their advisory, Mimecast said their customers would be protected against attackers attempting to leverage their discovery due to a new function called "Strip external source mode."

Moreover, the company says the attack described in their advisory hasn't been observed in the wild.

Update 2:

After this story was published, Justin Khoo, a blogger from FreshInbox, reached out with some additional thoughts.

"There are several practical benefits to externally host CSS stylesheets. Firstly, modern CSS can be hosted externally so the base email code isn't burdened with CSS that the majority of email clients can't handle and secondly to display content that are specific to mobile environments such as an iPhone (ie. a button to download an app)

"On the same note, senders always had an ability to change large blocks of content by sending a big fat image and changing it when the email is opened. And unlike the CSS exploit, live images can be used on all email clients."

Updated on 8/24/17 with additional comments from Mimecast and a reader.

NEW! Download the Fall 2018 issue of Security Smart