HackerOne says worker stole vulns for profit – fired employee blasts ‘baseless claims’
"We have terminated the employee, and bolstered our defenses to avoid similar situations."
Bug bounty platform HackerOne says a now-ex employee stole customer vulnerabilities to report them again for profit, but the worker claimed HackerOne was making “baseless claims”.
The firm revealed details of the HackerOne insider incident on Friday evening UK time, just ahead of the long 4th of July holiday weekend in the US. In the report, the firm said the employee had access to the HackerOne vulnerability database between 4 April and 23 June 2022, and subsequently contacted seven HackerOne customers away from the bug bounty platform.
The firm said a customer notified them about a suspicious vulnerability disclosure on 22 June, which appeared to be a collision or duplicate – which “commonly occur” when multiple researchers find the same flaw, said HackerOne. But the customer “expressed skepticism” this was a genuine collision, prompting HackerOne’s investigation.
“We discovered a then-employee had improperly accessed security reports for personal gain. The person anonymously disclosed this vulnerability information outside the HackerOne platform with the goal of claiming additional bounties,” said the HackerOne insider incident report.
“In under 24 hours, we worked quickly to contain the incident by identifying the then-employee and cutting off access to data. We have since terminated the employee, and further bolstered our defenses to avoid similar situations in the future. Subject to our review with counsel, we will also decide whether criminal referral of this matter is appropriate.”
See also: HackerOne apologises to Ukrainian hackers after bounty freeze row, CEO deletes Tweet
HackerOne said it was able to eliminate the prospect of multiple insiders, as well as compromise of its own systems, or compromise of the disclosing hacker, customer or analyst. According to the timeline of the HackerOne insider incident provided by the firm, its security team was able to identify the likely culprit within 11 hours of the customer reporting their detailed concerns.
“Within 24 hours of the tip from our customer, we took steps to terminate that employee's system access and remotely locked their laptop pending further investigation,” said the firm.
That was on 23 June – HackerOne says it interviewed the “suspended threat actor” the next day, and took possession of their laptop for analysis on 27 June. By 29 June HackerOne was able to notify seven customers they knew or suspected their employee had been in contact with, and fired that employee on 30 June.
In the HackerOne insider incident report the firm named the ex-employee only as “rzlr”, and said any other customers who had been contacted by rzlr should get in touch. The firm said all off-platform communications they had found had used the rzlr handle.
Rzlr speaks out
The Stack uncovered a Twitter account using the rzlr handle, which was registered in May 2022, identifying the user as an ex-HackerOne employee. On 28 June – before the HackerOne insider incident became public knowledge – the account posted a series of tweets claiming HackerOne made “baseless claims with no details about me to ban me; and is silent when asked about examples of violation”.
Rzlr claimed this happened after they found and tried to report “3 critical big data expose vulnerabilities in a big fintech”. They also accused HackerOne of “living in a fancy dream of being a super power and being full of cringe ego” and claimed they would reveal more details of activities within HackerOne “soon”.
Tweets on 28 May from Rzlr claimed they had found an “important issue” within HackerOne, “with no response now when I caught them and others at hackerone red handed”.
“This affects hackers and programs trust in hackerone equally and is very very serious breach of trust of both on platform. Pls look into it and tell me your comments on it either on report or here.
“[IMPORTANT] I will hope this get looked at asap else I will have to assume that you are okay with what I said on the report and give me permission for the same. I am refraining from sharing much about "issue" here for now hoping that you do take a fair decision,” they added in subsequent tweets.
Rzlr said the issue was documented in HackerOne report #1572030. That report is not publicly accessible. Without additional information, it is impossible to know whether rzlr’s earlier claims are linked to the HackerOne insider incident – but the timing strongly suggests they are connected.
The Stack has approached rzlr for comment, and has also asked HackerOne to comment on rzlr’s claims on Twitter.
Earlier in May rzlr attempted to contact companies including Sage, Newegg and Workrise about vulnerabilities they claimed to have found – and also tweeted a link to a TechCrunch article about Workrise’s fixes to its API after rzlr’s disclosure. Both Sage and Newegg responded to rzlr on Twitter.
Update 4 July 2022 1625: A spokesperspon for Sage told The Stack: "The individual contacted Sage on 9 May to report a vulnerability. We informed them they could only be considered for a bug bounty if the finding was reported through HackerOne, per our Responsible Disclosure Policy. The individual then reported the finding through HackerOne but it was discovered to be a duplicate of a historical report by another security researcher, so no payment was made and this was communicated to the individual.
"Since then, we’ve been in communication with HackerOne and are satisfied that the situation has been managed," they added, saying rzlr was told on 20 May they would not receive the bug bounty.
The Stack has also contacted Newegg and Workrise for comment.
HackerOne insider incident points to critical vulnerability
The risk of insider threats is substantial, as several senior CISOs warned recently. In the case of the HackerOne incident, where someone gained employment at the firm and very quickly started abusing their position of trust, the risk of a malicious actor joining an organisation for the sole purpose of abusing their position is clear (although we cannot of course speak to rzlr’s motivations prior to joining HackerOne).
Aside from effective vetting processes, diligent monitoring and logging can help mitigate an insider issue, as HackerOne demonstrated in this case. But many organisations lack such processes or capabilities – and in the case of NASA, were subject to staff installing unauthorised equipment such as Raspberry Pis on the organisation’s network, resulting in a data breach.
See also: NASA warned on IT security over insider threat risk
In a thread on the Ycombinator message boards about the HackerOne insider incident, a user suggested the firm was irresponsible in providing database access to "tons of employees". HackerOne founder and CTO Alex Rice replied pushing back on this: "There are certainly some important lessons for us to learn here but, just for clarity, this wasn't one of them. The data access in question here was central to the individual's daily job responsibilities and done through systems explicitly built for this purpose."
In a prepared statement to The Stack, HackerOne said: “Since the founding of HackerOne, we have honored our steadfast commitment to disclosing security incidents because we believe that sharing security information is essential to building a safer internet.
“Last week, HackerOne discovered and took immediate action against an internal actor that we discovered had improperly accessed vulnerability disclosure data to attempt to solicit payment from a handful of customers outside the HackerOne platform. Thanks to a customer tip, HackerOne identified and suspended the individual within 24 hours and subsequently terminated the person’s employment shortly thereafter, following a thorough investigation. We have contacted the affected customers.
“At HackerOne, we value the trusted relationships with our customers and the hacking community. It’s important for us to continue to demonstrate transparency as a core tenant of Corporate Security Responsibility and therefore shared this Incident Report. Our Code of Conduct sets the foundation for building trust. We will continue to prioritize coordinated disclosure and to act fast to ensure we uphold these strong standards.”
