You are here

You are here

HackerOne hacked, pays bounty on its own white-hat platform

Richi Jennings Industry analyst and editor, RJAssociates

Isn’t it ironic? Bug-bounty-as-a-service platform HackerOne had to pay out a big bounty for its own bug. A staff member carelessly leaked a session cookie, which gave a white-hat hacker the keys to the kingdom.

But is there a good way to protect against this? It’s not as simple as some commentators believe.

Defense in depth means there are no majick silver bullets. In this week’s Security Blogwatch, we go deep.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Star Wars IX.

[ Get up to speed with TechBeacon's Guide to Application Security Testing. Plus: Get Gartner's 2020 Magic Quadrant for App Sec Testing and Critical Capabilities for App Sec Testing ]

10,000 spoons

What’s the craic? Dan Goodin reports—HackerOne breach lets outside hacker read customers’ private bug reports:

As a leading vulnerability reporting platform, HackerOne has paid hackers more than $23 million on behalf of more than 100 customers. … The company’s position also gives it access to unimaginable amounts of sensitive data. Now, the company has paid a $20,000 bounty out of its own pocket after accidentally giving an outside hacker the ability to read and modify some customer bug reports.

A HackerOne community member who had a proven track record of finding and privately reporting vulnerabilities through the platform had been communicating late last month with one of the company’s security analysts. In one message, the HackerOne analyst sent the community member … a cURL command that mistakenly included a valid session cookie.

HackerOne revoked the session cookie … two hours and three minutes after haxta4ok00 reported the breach. [It] gave the outsider other potentially more serious abilities, including paying bounties, modifying program details, adding users, and suspending customer submissions.

The event shows the risks companies take when trusting an outside party with some of their most sensitive business secrets.

You could say that. Graham Cluley calls it a Cut-and-paste goof:

HackerOne … helps some of the world’s most famous companies and organisations run bug bounty programs. … 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. [But] 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.

I heard you like hackers. Roland Moore-Colyer has more—What can a hacker hack if a hacker hacks hackers?:

While the whole thing looks a bit embarrassing for HackerOne, it does showcase that no one organisation is infallible to hacking, and even with the best security stuff in place, human error can still bork cybersecurity.

What does the firm have to say for itself? HackerOne’s Jobert Abma—discloses their actions:

HackerOne is conducting an internal review and analysis of the incident. HackerOne is taking the following actions to address the underlying causes of issues and to help prevent future occurrence:

[We now] bind the user’s session to the IP address used at initial sign-in. If an attempt is made to utilize the session from a different IP address, the session is terminated.

A limitation of binding to IPs is that they change for legitimate reasons and will unauthenticate the user, creating a poor user experience. Additionally, IP addresses do not uniquely identify a user (such as with NAT).

To improve usability and security, HackerOne will investigate binding the session to a specific device that the user is using. Sessions bound to the device will only be usable on that device and using the session elsewhere will terminate the session.

The HackerOne Security Analysts have access to HackerOne customers’ sensitive data in order to triage incoming vulnerability reports. [We will] restrict security analyst access in programs, as well as overhaul the allocation of security analysts to a more restrictive list of programs to keep these users to the least privilege required.

Wait. Pause. Does that second point make any sense? MaxGabriel sounds the last trumpet:

They say they will "investigate binding the session to a specific device"—is there a known good way to do this? I could imagine attempts to do this breaking legitimate use cases like Apple's Handoff between iOS and Mac.

My instinct is that the admin functionality could be put run behind a VPN, and that would be a good defense against a HackerOne employee's credentials or sessions cookie being leaked.

And sigmasirrus agrees:

As a developer I’m interested in what sort of possible mitigations you’d have in this case. As far as I’m aware, if someone gets your session cookie, you’re kind of toast.

By definition the web host doesn’t know that the you who clicked the edit button is the same you who just logged in on the last request, each request has to contain all the information needed to tie it to the previous user’s session. That’s why you have session cookies, and that’s why if someone gets the cookie, they get your session, because that’s all the proof you have that you are you.

Tying the session to a particular device is the purpose of the session cookie to begin with. … If anyone knows any other industry standards I’d love to hear it.

This isn’t exactly a little-known class of vulnerability. Here’s DyslexicAtheist, denying there’s a dog: [You’re fired—Ed.]

If a platform which stores information about current 0days … gets pwned by an OWASP top-10 it should be considered gross negligence on their part. … We should agree to a system that auto-pwns (takes offline) anything that has an OWASP top-10 in it.

But some are blaming the reporter. mickohea plays defense:

The hacker reported the issue 20 minutes after the session cookie was leaked. In the two hours before they got a response, they continued to explore the scope of the issue and seemed open and up front in all communications with HackerOne.

I'm sure it was a pain for HackerOne having to tell customers that someone had accessed their data. But blaming a reporting party who acted in good faith is definitely going to end up counter-productive.

Meanwhile, Eusebiu Blindu—@testalways—is testy:

[HackerOne] uses a lot of ****** as 'triage' [staff, who] abuse their roles and spy on bugs and submissions. … Also the manipulation of rewards, invites, data sharing—it's much worse than this breach.

The moral of the story?

Defense in depth: Protect your session cookies, and do what you can to validate their use.

[ Find out how to scale your application security program in this Webinar. Plus: Learn how to build application security into your software with TechBeacon's guide ]

And finally

“We’ll still take your money.”

Previously in “And finally”

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Justin Higuchi (cc:by)

[ Take a deep-dive with our Application Security Trends and Tools Guide. Plus: Get TechBeacon's App Sec Buyer's Guide. ]