FastMail.FM is an email service established in 1999 and purchased by Opera Software in 2010. I recently discovered a couple of criticial security vulnerabilities in their webmail offering. I disclosed them responsibly and they were fixed before I published this blog post.
It all began when a user of a web application I wrote (The Email Privacy Tester) contacted me. They’d run a test against their fastmail.fm email address and it had automatically, “exploited,” their account.
The Email Privacy Tester sends a specially crafted email to your address. It is designed such that when you open the email, it tries to load remote content in dozens of different ways, in order to report back that you’ve opened the email and what IP and mailer you’re using. The most well known and commonly used method for doing this, is by placing an tag in an HTML email. This sort of tracking is widespread; even your bank does it.
Anyway, back to the original report. The person who ran the test opened the email and nothing happened. FastMail seemed to be secure and was preventing the email from loading all remote content (unless he hit the load remote content link of course). However, when he clicked “View” next to one of the email attachments, an ominous alert popped up on the screen saying:
"1.0" standalone="no" xml version= <svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg"> <polygon id="triangle" points="0,0 0,50 50,0" fill="#990000" stroke="#440000"/> </svg>
The first vulnerability
There are two different ways of retrieving the content of an attachment in webmail. “View” and “Download”. “Download” is always safe, as it opens a dialogue box and lets you choose where to save the content. “View” can be dangerous because it displays the content under the www.fastmail.fm domain. It’s for this reason that attachments like HTML only have the “Download” link, and not the “View” link available. It’s not safe to display certain types of user submitted content under your own domain. The problem is, developers assume that files with an “image/*” content-type are safe, because they’re not familiar with SVG.
The fix which exposed a second flaw
I reported this vulnerability to FastMail, and they attempted to fix it by adding “image/svg+xml” to the list of files that can only be downloaded, and not viewed. This should have fixed the issue, but didn’t. It turns out the Email Privacy Tester was specifying a content type of “application/octet-stream” instead of “image/svg+xml”, and FastMail was guessing the content type by looking at the filename extension. The method of filtering out unsafe file types was only working on the declared content type of “application/octet-stream”. What this meant was that you could sneak any file type through their “Download only” filter, by setting the content type to “application/octet-stream” and then giving the filename an appropriate extension. I tested this by attaching some HTML to an email, and it worked. This flaw was subsequently fixed too.
A much worse security flaw
By this point, I’d already signed up for a guest account with FastMail so I could verify the original report and help them test fixes. So I thought I may as well have a little poke around to see if I could see any other low hanging fruit.
The vulnerabilities so far relied on a user clicking an attachment to view it. A much worse attack would be one that executes as soon as you open an email to read it, rather than waiting for you to click “View” next to an attachment. Well, I found one of these too. When you open an email, it displays a list of attachments underneath it, along with their filenames. I found that the filenames weren’t being escaped before they were added to the HTML. So by attaching a file to an email with a name like:
Additional recommendations/changes to the site
When I made the original report, I also made a few recommendations about how the security of the site could be generally improved. Some of these have been implemented, some are being investigated and planned for the future.
HTTP Strict Transport Security
They already use SSL to encrypt access via webmail. HSTS allows you to send a policy to the browser, through the use of a HTTP response header, to tell it that it should always use SSL for your site (with an expiration period). I advised that they implement this in order to help prevent SSL stripping attacks, where a MITM can trick your browser into not using encryption. My understanding is that there are some complications for them here, but that they’re hoping to implement it at some point.
Content Security Policy
Third party content on different domains
If I’m on mail.google.com and I view an email attachment, it doesn’t open it on mail.google.com. It opens it on mail-attachment.googleusercontent.com. Why? If the user supplied content has a vulnerability, that vulnerability can only be used to attack other pages on mail-attachment.googleusercontent.com, and not pages on mail.google.com. This sort of isolation is basically damage limitation, and it’s very effective. FastMail doesn’t do this, it loads all content directly on www.fastmail.fm. If they’d separated their attachment viewing onto a different domain, then the attack would still have existed, but it wouldn’t have been able to do anything useful like reading the users email. Apparently, implementing this is on their “longer term TODO list”.
My recommendations to you
If you can, use a real IMAP client instead of Webmail. Even Gmail fell for an attack similar to the SVG one a few years ago. Also, test your email configuration using https://emailprivacytester.com/. It has helped to uncover a huge number of privacy and security flaws in many major IMAP and Webmail clients over the past couple of years.