Daniel LeCheminant (Contact)

HackerOne's First XSS

In February 2015, I found and reported the first severe XSS vulnerability in HackerOne itself. At the request of HackerOne, the report was publicly disclosed today.

Show me the bug report!

Sure, it's right here

Background

In October 2014, Michael Pryor (the CEO of Trello Inc, where I work as a software developer) asked "Can we/do we have a bug bounty page and can we add it to hackerone?"

We didn't have a bug bounty program at the time, and I hadn't heard of HackerOne… but we had received some security related inquiries, and I'd had a bit of a history finding and reporting security vulnerabilities in other services, so I was intrigued.

The concept was a simple one; researchers have to do real work to find and submit security issues, so why not motivate them to submit issues responsibly by rewarding them for their efforts?

Before signing Trello up, I wanted to get a sense for how HackerOne worked, so I found a service we used that was running a program on HackerOne (Slack, a chat application), and spent a month finding and submitting vulnerabilities. (I was briefly in the top 10 on Slack vulnerabilities alone!)

Satisfied that having a HackerOne program was a worthwhile thing, we launched a private program for Trello. A few days ago, as we were getting ready to make our program public I thought it'd be interesting to see if HackerOne itself had any security vulnerabilities that I should be … concerned about.

The Bug

Not surprisingly, HackerOne runs a bug bounty program for their own site and offers a minimum bounty of $5000 for "any bug that might grant unauthorized access to confidential bug descriptions" I figured I'd start by looking for something severe, and I guessed that if I could find a bug in the way HackerOne rendered markdown, that might lead to one of these "severe" vulnerabilities.

I spent a couple hours trying some odd markdown inputs, and at one point found an actual bug … but I couldn't quite get it to do anything bad. However, while trying to build that bug into a vulnerability, I stumbled on the fact that

<http://\<h1\>test\</h1\>>

… was being rendered as

http://<h1>test</h1>

and quickly realized that I could use that bug to insert arbitrary HTML into a bug report (and also other places where markdown is rendered, e.g. a program description page)

Exploits

While being able to insert persistent, arbitrary HTML is often game over, HackerOne uses Content Security Policy (CSP) headers that made a lot of the fun stuff ineffective; e.g. I could insert a <script> tag or an element with an event handler, but it wouldn't run because these unsafe inline scripts were blocked by their CSP.

Fortunately (for me) not all browsers have full support for CSP headers (e.g. Internet Explorer 11), so it wasn't hard to make a case that being able to run arbitrary script when someone attempted to view a bug that I'd submitted qualified as something that "might grant unauthorized access to confidential bug descriptions"

Even without the ability to run arbitrary script, I identified several bad things you could do:

HackerOne's response

This was a fun bug to submit, because the submission itself was the proof of concept; before the bug was fixed, my report looked very differrent than most. (Now that it's fixed, it's not as impressive looking, but they attached a screenshot of how things when they originally viewed the report)

Not surprisingly, HackerOne fixed the issue very quickly. Once I'd verified their fix, they congratulated me and let me know that this was their first XSS and the first report they'd categorized as Severe. They also requested public disclosure, which is why you're reading about this now :)

About the author:

I'm Daniel LeCheminant, a developer at Trello Inc.

You can follow me on Twitter or e-mail me.

Most recent post:

The most popular things I've written: