Grepular

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.

Discovery

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.

One of the other things the email attempts to do is execute JavaScript. This is particular dangerous in a webmail context. If the sender of an email can execute arbitrary JavaScript in your browser under your webmails domain, there is a very good chance (much more likely than not), that they will be able to read your email, send email as you, change your settings, and generally take over your session or account. It’s one of the main reasons I use a real email client instead of webmail.

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:

Wow. JavaScript hidden inside SVG’s executes in your email client. That’s a potentially serious security problem. Please contact me using the form at https://grepular.com/contact about this

The attachment was an image, and clicking “View”, opened it in a new browser tab/window under the www.fastmail.fm domain. That should be perfectly safe right? Images can’t execute JavaScript right? Well, yes, they can. This particular image was a Scalable Vector Graphic, with a content type of “image/svg+xml”. An SVG is just a lump of XML describing a picture, but it can also contain JavaScript and CSS. You wont get anything useful if you open a JPEG in notepad or vi, but if you open an SVG, you’ll get something like this:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<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

The SVG image that is attached to all emails sent from the Email Privacy Tester contains a bit of JavaScript to pop up the alert that the reporter saw, which looks a little something like this:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
  <script type="text/javascript">alert('<abbr title="Cross Site Scripting">XSS</abbr>')</script>
</svg>

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:

Hello<script>JavaScript payload</script>.jpg

I could inject arbitrary content into the HTML, and run JavaScript as soon as an email was opened. This one was reported and quickly fixed again.

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.

HttpOnly cookies

One of the things that my exploit allowed me to do was read the users cookies to steal their session. Unless you have a particular reason to need to be able to read the content of a cookie from JavaScript, then you can disable that functionality. All you need to do is add the “HttpOnly“ flag to the cookie when you set it. FastMail has now implemented this. It wouldn’t have prevented me from performing actions as the user in the users browser, but it would have prevented me from stealing the session and accessing it from my own browser.

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

CSP allows sites to declare strict policies about what types of content are allowed to be used in a web page, and where they can be fetched from. For example, using CSP, it is possible to specify that inline JavaScript is not allowed on a page. They attempted to implement this, but it caused them a lot of problems. It can prevent browser addons from making changes to the page, for example an addon might want to convert phone numbers in an email into Skype links. My thoughts here would be that they should start with a relaxed policy allowing everything, and then slowly remove things. Do they really need to allow Flash if they don’t use it themselves? Do they really need to allow their site to be wrapped in a frame from a different domain, and thus be vulnerable to Clickjacking attacks? I don’t know if this is something they will implement any time soon, but at least it’s on their radar now.

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.