Brool brool (n.) : a low roar; a deep murmur or humming

Single Quotes And Security And Mandrill

October 10, 2015 |  coding security

(Someone asked me for more information about a particular bug that we had hit, so this came about as an attempt at explaining it).

We ran into a bug in Mandrill in July. Basically, any subject lines with single quotes get truncated.

Wait! Wait! Check the room. Who winced? Anyone that winced very likely knows about web development, because a bug like that is indicative of something pretty serious — it is potentially the tip of a large and disgusting iceberg. Not always, but often.

Disclosures

The bug was reported in normal channels in July via Zendesk, via Twitter, and via twitterhelp. It gets reported by a bunch of people to @mandrillapp once or twice a month, e.g.:

The second one is kind of amusing; it’s a little like if someone had complained that their car would unlock after someone knocked three times, and the response from the auto manufacturer was “Well, we don’t recommend parking where people might knock on the door.” It’s responsive, but maybe not responsive to the main point.

It’s an irritating bug just on the face of it. In playing with it more, though, I found that there were more ramifications; accordingly, gave a heads-up to the security@mandrillapp.com, warned them that there were vulnerabilities and I was writing a blog article about it and that therefore the vulnerability would be exposed to both my readers, yet still no response from any of the bugs that were submitted. So, at this point I’m assuming they’ve looked at this bug, and have decided that it’s not serious enough to fix and/or respond to… but let’s play around with it a bit.

The Bug

The bug as we encountered it: Single quotes in the subject line of a template truncate everything thereafter.

This of course smells like one of two things: a SQL Injection problem or a potential XSS problem. So, trying a simple test with a subject of hello'xyzzy and then inspecting the DOM with View Source reveals:

Not SQL injection – template problem. Can we insert tags?

hello'>xyzzy

turns into

hello'>

… so at least greater-than and less-than signs are encoded properly, it’s only single quotes.

Can we execute Javascript? Try a subject line of:

' onclick='alert("doughnuts!")'

Click on the subject line, and get the alert.

(At one company I worked at, any developer that was sloppy with the coding and had a Javascript invoke bug would owe doughnuts to the QA team.)

Getting Serious

At this point we have a vulnerability that allows someone to… pop up alerts on themselves. Not the most serious thing, perhaps.

XSS attacks on your own account are less interesting than XSS accounts between different accounts. However, since Mandrill doesn’t have the notion of guest accounts, we’re in the clear! You have to be in a situation where a potentially untrusted person can do stuff to your account.

Like MailChimp sending templates over to Mandrill.

So, there’s a potential vector here, but if we use it does it get us anywhere? Let’s look at the cookie for Mandrill:

$ curl -I http://www.mandrillapp.com
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.6.0
Date: Sun, 11 Oct 2015 01:12:58 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: PHPSESSID=14ebdef113c27cdeaca4810925f5ced6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: https://www.mandrillapp.com/

See what’s missing? There’s no httponly on the cookie. This can be confirmed with Chrome, as well – no httponlys anywhere as far as the eye can see. Httponly is often a good idea, and here it would have made it a lot harder to exploit anything.

Mailchimp doesn’t allow subject lines to be set in templates… but it does allow you to set a template name. You’re limited to 50 characters, though, so it’s a bit tight. But:

  1. Attacker creates a template in Mailchimp with the template name of ' onclick='alert(document.cookie)'
  2. Send it over to Mandrill.
  3. Victim opens the new template and clicks on the subject line.
  4. Javascript is invoked.

Mandrill uses JQuery, so you can do other things – a $.post, for example. Once you’ve given up the session info the account is compromised.

It’s not an ideal exploit, since the title is weird, but all the victim has to do is click through the wrong field. Also, since every field I tried suffers from this single-quote bug, there is a fairly wide surface area to attack, as well as other avenues that seem wide open – the Mandrill API, for example, allows anyone with an API key to add templates with subject lines, so that potentially sets you up for an exploit.

At this point I’m just trying to get a bad enough scenario that Mandrill will fix the bug (so I’m hoping I’m done), but a determined attacker would have a lot of openings.

So, if you’re a Mandrill user, what do you do?

  1. Make sure you trust anyone who gives you a template.

If you’re Mandrill, what do you do?

  1. Fix that darn single-quote bug. It’s an annoying bug anyway, regardless of any security implications!
  2. Turn on httponly for cookies, if possible.
  3. Doing a security audit. Security is like the Tree of Liberty, it must occasionally be fed with the sweat of engineers. (I ran into a few other problems in the course of this article, which is why I suspect a security audit might be worthwhile).

Fixing The Process

It might sound like I’m ragging on Mandrill for this bug, but I’m not, really; security is hard, and code is hard, and humans are imperfect. You do the best you can and resolve to fix mistakes as quick as possible.

Security issues are not always obvious, and they may be reported in weird ways and weird channels, and it takes a developer to really evaluate it and see if it’s a false alarm or not.

But, if you’re going to catch ‘em, it’s really important to to make sure that there’s a good process for escalating bugs to the security team. So, what might have helped here:

  1. Letting frontline support know what type of bugs are more serious than they look (i.e., single-quote truncation).
  2. Having a clearly defined security inbox (or easy routing from support).
  3. At least having an autoresponder on that security inbox.
  4. Possibly, having an escalation path in Zendesk (or wherever) for security issues.

Updates

Updated October 11th, 2015: So, thinking a bit and googling around revealed the Mailchimp security response page. An actual security page! I sent information via this page and actually got an answer, amazingly. Unfortunately, the gist was (and I am roughly paraphrasing here):

Meh. We’ll forward it. This doesn’t count for the MailChimp Hall of Fame, by the way.

(I don’t know what the Hall of Fame does, but apparently it must be a golden ticket to all the puppies and rainbows in Silicon Valley). So, while Mandrill was started inside and is wholly owned by MailChimp, I get the sense that they are completely isolated development teams. They probably sit at different tables at the Christmas Party and the MailChimp team makes fun of the Mandrill team members behind their backs.

Discussion

Comments are moderated whenever I remember that I have a blog.

There are no comments on this article.

Add a comment