# FastMail.FM Security Vulnerabilities

[FastMail.FM](https://www.fastmail.fm/) is an email service established in 1999
and purchased by [Opera Software](https://www.opera.com/) 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](https://www.emailprivacytester.com/)) 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 <img> 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](https://www.mozilla.org/thunderbird/ "Mozilla Thunderbird") 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://www.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
<?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
<?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:

```text
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](https://owasp.org/www-community/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 <abbr title="Secure Socket Layer">SSL</abbr> to encrypt access
via webmail. [HSTS](https://wikipedia.org/wiki/HTTP_Strict_Transport_Security
"HTTP Strict Transport Security") 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 <abbr title="Man in
the middle">MITM</abbr> 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP "Content Security
Policy") 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](https://wikipedia.org/wiki/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://www.emailprivacytester.com/](https://www.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.