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, including Twitter, Slack, and the US Pentagon. 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.
The outsider—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 parts of a cURL command that mistakenly included a valid session cookie that gave anyone with possession of it the ability to read and partially modify data the analyst had access to.
“HackerOneStaff Access,” the community member haxta4ok00 wrote in broken English on November 24. “i can read all reports @security and more program.” In a follow-up message, haxta4ok00 wrote: “i found what is you can edit private program (for test) I have not changed anything and not used , all for the sake of hacking.” On the same day, the hacker followed up again, writing: “If you need Proof, I can write a message [redacted].”
HackerOne revoked the session cookie at 7:11am Pacific time, exactly two hours and three minutes after haxta4ok00 reported the breach. The company’s incident response team then set out to investigate what happened and how much damage had been done.
Damage assessment
HackerOne isn’t saying precisely how much data was exposed. An incident report the company published on Tuesday said that all affected customers have already been privately notified. Tuesday’s report also said that the data was limited to reports the security analyst had access to, but the disclosure doesn’t provide even a rough estimate of how many customers or how much data were affected. The report and an accompanying transcript of HackerOne’s communications with haxta4ok00, however, suggest that the exposure was non-trivial.
“Something came up that we hadn’t asked you yet,” HackerOne cofounder Jobert Abma wrote to the hacker a day after the incident. “We didn’t find it necessary for you to have opened all the reports and pages in order to validate you had access to the account. Would you mind explaining why you did so to us?”
The community member said he did it to “show the impact” and that he didn’t intend any harm and reported the access immediately. “I was not sure that after the token substitution I would own all the rights,” he wrote. In a later message, haxta4ok00 went on to write:
- Three years ago I mentioned such an attack, but it was theoretical and I was not listened to( here [report] #163381 I wrote in theory find this in the future). If this will help the I am systemic moderator on one of forums on security. And we protected ourselves from such attacks by binding the session to the IP address at the entrance. We also made basic authorization for access to private sections. Perhaps this will help you.
- I understand, that saw data which should not was see, but this was only hack interest in white purposes, I wanted to watch and show you to prejudice consequence of this can lead ( I’ve always been taught to write the full impact that can be) . It was a happy white hacking for me.
- Please do not scold █████ he’s one of the best staff that help to hackerone
And sorry if I that the poorly translated, hope you me will understand. Thanks @jobert again.
Abma replied that “this became a bigger incident due to the amount of data that you accessed, not because it happened in the first place.”
Also telling is another message Abma sent. It read:
Due to the nature of the data that could’ve been accessed, systems other than hackerone.com may be accessible. Scope includes any customer assets because of the vulnerability information that could have been accessed.
The transcript and report also suggest that the breach gave the outsider other potentially more serious abilities, including paying bounties, modifying program details, adding users, and suspending customer submissions. Haxta4ok00 assured HackerOne the hacker limited the access to “read only.” In an email, HackerOne Director of Security Reed Loden said network logs also showed no changes were attempted.
The hacker also assured HackerOne that all screenshots, exports, proxy logs, browser history, and other data captured during the unauthorized access has been deleted, although the hacker admitted there was no way to prove this.
Loden denied as “incorrect” the claim made at the outset of the report, that haxta4ok00 could “read all reports @security and more program.” Loden wrote:
The hacker could access for a short time a limited subset of vulnerability reports for customer programs permitted by the session cookie. The majority of the affected reports only had their title and limited metadata viewable. Once a report is submitted, the original description cannot be altered, and we confirmed via logs that no changes to reports were attempted. This was also confirmed by the hacker.
He declined to say in megabytes or gigabytes how much data was accessed by haxta4ok00 or how many customers were affected other than to say the breach “impacted less than 5% of programs.”
Loden also said that the attack haxta4ok00 reported three years ago was a “purely theoretical scenario focused on older browsers that were not, and are still not, supported by the HackerOne Platform.” Loden said that the sharing of session cookies with community members was not previously reported.
Preventative measures
The report went on to detail the steps HackerOne has taken to prevent similar breaches in the future. As haxta4ok00 suggested, one step was to bind authentication cookies to the IP address of the user it was issued to. The move prevents the cookies from being reused by outsiders.
Tuesday’s report said: “The change was rolled out for HackerOne employees (including all HackerOne Security Analysts) on November 25, 2019.” A message Abma sent haxta4ok00 on November 26, however, stated: “We’re postponing the rollout to all users due to people having legitimate use cases for using multiple IP addresses (e.g. ISPs with DHCP).”
Other short-term measures include blocking access from specific countries and moving from notifications over Slack to paging an on-call security person when critical reports are submitted. The company has also implemented controls that automatically detect and redact session cookies and other sensitive data submitted in comments. Other preventative measures HackerOne plans to put into place include adding new logging of information around data access, binding sessions to specific devices, improving employee education, and overhauling the security analyst permission model.
There’s no indication that any of the data exposed in the breach was modified, stored, or passed on to parties besides haxta4ok00. Still, the event shows the risks companies take when trusting an outside party with some of their most sensitive business secrets.
Katie Moussouris, HackerOne’s chief policy officer from 2014 to 2016, told me that she left the company as it began a pilot program that she had spearheaded for the Department of Defense. Dubbed Hack the Pentagon, it wasn’t just the first federal bug bounty program. It was also HackerOne’s first foray into vulnerability triage on behalf of a customer.
Now the CEO and founder of Luta security, a vulnerability consultancy that worked with HackerOne on the Hack the Pentagon program, Moussouris said of HackerOne:
They had never attempted triage for any customers before the Pentagon. I warned them that triage labor that we could trust would be incredibly hard to find. And that the platform as designed would need much stricter granular controls on the back end, to restrict access per program, especially if contractors would be used to do triage.
I advise my customers not to outsource triage for vulnerability disclosure or bug bounty programs that are targeted towards sensitive systems, since contractors are often the ones doing triage on these managed bug bounty platforms. [Customers] should also fix these bugs as quickly as possible, since an insider threat from the bug bounty platforms, or an outside attacker that gains access, would potentially see a treasure trove of unpatched vulnerabilities stored in these systems.
I feel like all the things I’ve been warning about on the risks of current bug bounty platform implementations over the past couple of years are in this report.
For HackerOne’s part, Loden said that the resolution and detailed disclosure of the unauthorized access—a practice he said is standard for every security event affecting the company—is proof of HackerOne’s commitment to protecting its customers’ secrets.
“Security incidents will always exist, and the way a company responds can be more telling than the vulnerability itself,” he wrote. “We aim to show the community and our customers through our actions the steps we are actively taking to enhance our security.”
