Posted by Martijn Grooten on Aug 28, 2017
Researchers at Mimecast have published details (pdf) of an email exploit they call 'ROPEMAKER' (short for 'Remotely Originated Post-delivery Email Manipulation Attacks Keeping Email Risky'), which allows an email sender with malicious intentions to modify the appearance of an email after it has been delivered.
The idea is rather simple: a lot of emails use CSS, and it is not uncommon for part of the stylesheet to be loaded from an external source. This external CSS can then be modified post-delivery to change the email as it appears to the user, for example by hiding one ('good') link and making another ('bad') link visible, or more complex variants of this technique.
Although Mimecast says the technique doesn't work on any of the major webmail providers, it does work in Microsoft Outlook, Apple Mail and Mozilla Thunderbird; I was easily able to reproduce the technique in the latter case.
But I don't think this is a huge issue. A typical email is 'scanned' twice on the recipient's side: first at delivery time by an email security product, which looks for various kinds of spammy and/or malicious behaviour, and then again by the human user when they open the email and they make a decision as to whether or not to trust its content.
Spam filters scanning emails don't load any external sources and only look at the raw content, thus ignoring the visual appearance of the email; from their point of view there is no difference between hidden and visible links.
Mimecast's paper includes details of a more complex technique that uses CSS to change the appearance of an email, which reminded me of the many techniques listed in Virus Bulletin's Spammers' Compendium. This Compendium rarely gets updated these days – not because there aren't new ways to obfuscate the raw content of a spam email, but because spammers have stopped bothering: exciting though they may sound, these techniques are barely better at bypassing spam filters than having the content clearly visible.
As for the human user, the appearance of the email only matters when it is opened; whatever the email looked like when it was delivered doesn't make a difference to them.
That doesn't mean that there won't be (limited) cases in which it does matter that an email's appearance changes as it sits in someone's mailbox, and Mimecast's paper serves as an important warning that this is indeed possible. This is one of many reasons why having mail clients load content from external sources is a bad idea, and this option should be turned off for all but a limited set of trusted senders. Thankfully, having the option turned off is the default for most mail clients; indeed, I had to explicitly enable downloading of remote content for my test email before the ROPEMAKER exploit worked in Thunderbird.
Systems administrators may consider it an issue that their users are able to change the default, thus making themselves 'vulnerable' to the ROPEMAKER exploit. But this issue is not limited to email and is part of a wider problem where corporate users are able to change the settings of their software, thus reducing its security. The solution to this would be for software makers targeting the corporate market to let administrators set organization-wide policies that cannot be overwritten. This seems a lot better than scaring users about email 'vulnerabilities' that can easily be avoided.
