Cut-and-paste goof reveals HackerOne session cookie, and earns bug hunter $20,000

Graham Cluley
@gcluley

Maybe you’ve heard of HackerOne.

It helps some of the world’s most famous companies and organisations run bug bounty programs – Starbucks, Goldman Sachs, Uber, Instagram, Twitter, Slack, the United States Department of Defense… the list goes on and on.

Researchers find a security vulnerability in a product, service or website and HackerOne helps co-ordinate the report to the company concerned – and ultimately the person who found the bug ends up being rewarded financially.

Sign up to our newsletter
Security news, advice, and tips.

Better that bugs are reported responsibly this way and fixed, than discovered by malicious hackers who exploit them with criminal intent.

So there’s some irony in reading that HackerOne’s own security has been found lacking.

HackerOne has paid out a US $20,000 bounty after a researcher called Haxta4ok00 discovered he was able to access some other users’ bug reports on the website.

The reason Haxta4ok00 was able to access the data? One of the HackerOne’s own staff had accidentally disclosed one of their own valid session cookie – granting the external bug-hunter access to vulnerability reports related to other HackerOne customers:

HackerOne triages incoming reports for HackerOne’s own bug bounty program. On November 24, 2019, a Security Analyst tried to reproduce a submission to HackerOne’s program, which failed. The Security Analyst replied to the hacker, accidentally including one of their own valid session cookies.

Why was a cookie included?

When a Security Analyst fails to reproduce a potentially valid security vulnerability, they go back and forth with the hacker to better understand the report. During this dialogue, Security Analysts may include steps they’ve taken in their response to the report, including HTTP requests that they made to reproduce. In this particular case, parts of a cURL command, copied from a browser console, were not removed before posting it to the report, disclosing the session cookie.

In short, a sloppy cut-and-paste leaked information which should never have been shared outside of HackerOne. And that mistake ended up costing the company $20,000 – much to Haxta4ok00’s undoubted delight.

Let’s hope that they and other organisations put measures in place to make such human errors less potentially damaging in future.

Interestingly, HackerOne notes that its response to the bug report about its own site might have been faster if it hadn’t occurred at the weekend:

Why did it take two hours to notice the report?

HackerOne aims to reply within 24 hours to any submission, including over the weekend. For high and critical severity vulnerabilities, HackerOne tries to respond within a couple of hours. The report to HackerOne’s bug bounty program was submitted on Sunday morning at 05:00am PST (where the majority of HackerOne’s security team resides). For critical submissions, HackerOne’s security team automatically receives a notification on Slack. This works during business hours but is unreliable over the weekend. Security Analysts who work over the weekend noticed the report two hours after the submission, after which they immediately followed Incident Response procedures.

Bug bounty expert Katie Moussouris criticised HackerOne’s failure to treat weekend bug reports as well as it might handle them during regular office hours.

HackerOne says that it revoked the session cookie two hours and three minutes after the breach was reported, and a subsequent investigation determined that other cookies have not been leaked in similar communications in the past.

I would feel churlish if I didn’t at least applaud HackerOne for its transparency in owning up to its goof, and rewarding Haxta4ok00 for finding it. So well done for that.

But those platforms storing the details of vulnerabilities in major companies – and indeed organisations such as the United States Department of Defense – better be confident that they are doing everything possible to ensure that those critical security holes aren’t at risk of being viewed by unauthorised parties.

Found this article interesting? Follow Graham Cluley on Twitter to read more of the exclusive content we post.


Graham Cluley is a veteran of the anti-virus industry having worked for a number of security companies since the early 1990s when he wrote the first ever version of Dr Solomon's Anti-Virus Toolkit for Windows. Now an independent security analyst, he regularly makes media appearances and is an international public speaker on the topic of computer security, hackers, and online privacy. Follow him on Twitter at @gcluley, or drop him an email.

What do you think? Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.