pogonici - Fotolia
Session cookie mishap exposed HackerOne private reports
A security researcher used a mishandled session cookie to access private HackerOne bug reports with an account takeover attack and earned a bug bounty for their efforts.
A researcher discovered a session cookie risk that could have exposed private bugs on HackerOne, and questions remain about if data may have been taken.
The risk for vulnerability coordination and bug bounty site HackerOne stemmed from a HackerOne security analyst accidentally including a valid session cookie in a communication with community member haxta4ok00. According to the HackerOne incident report attached to the original bug report, which was first reported by Ars Technica, the session cookie was disclosed due to human error and revoked exactly two hours and three minutes after the company learned of the issue.
"Session cookies are tied to a particular application, in this case hackerone.com. The application won't block access when a session cookie gets reused in another location. This was a known risk. As many of HackerOne's users work from mobile connections and through proxies, blocking access would degrade the user experience for those users," HackerOne wrote in the incident report. "A short-term mitigation of this vulnerability is to 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."
HackerOne added that longer-term mitigations will include detecting session cookies and authentication tokens in user comments and blocking submission, binding sessions to devices rather than IP addresses, improving employee education, and overhauling the permission model for HackerOne security analysts.
Craig Young, computer security researcher for Tripwire's vulnerability and exposure research team, told SearchSecurity, "The first rule of session cookies is don't share your session cookies."
"That being said, accidents and oversights can happen. The general idea here is to bind the session cookies with some other identifying attribute of the expected client. This is commonly done by associating session cookies with some additional fingerprint of the authorized user," Young said. "This can be as simple as restricting session cookies based on IP address or region. More sophisticated methods might involve client-side scripting to fingerprint a specific client browser."
After seeing "the amount of sensitive information that could have been accessed" as a result of the session cookie account takeover, HackerOne decided the submission was a critical vulnerability and awarded a $20,000 bug bounty.
Data access still in question
Haxta4ok00 wrote in the report that they had "HackerOneStaff Access" and could "read all reports" and edit private programs. However, they asserted multiple times that all actions were in the spirit of white hat hacking.
In the discussion about the issue in the bug report, Reed Loden, director of security at HackerOne, asked haxta4ok00 to "delete all screenshots, exports, etc." and confirm they had "no other copies of vulnerability data" captured as part of the report submission. While haxta4ok00 claimed they only took screenshots, they admitted they didn't understand how to prove such data was deleted. Even so, Loden thanked the member "for confirming your removal of all screenshots and other data you may have downloaded as part of your report submission."
Following this exchange, Jobert Abma, co-founder of HackerOne, joined the conversation to ask why haxta4ok00 had "opened all the reports and pages in order to validate you had access to the account," noting the HackerOne team found the extent of the member's actions unnecessary.
Again, the member claimed they meant no harm and that answer seemed to be accepted by HackerOne staff. The member went on to claim they had previously reported the session cookie risk and nothing was done.
Katie Moussouris, founder and CEO of Luta Security, pointed out on Twitter that the discussion between haxta4ok00 and HackerOne staff raised more questions.
Oh look!
— Katie Moussouris (@k8em0) December 3, 2019
They just asked the hacker if they downloaded any sensitive program data from any other HackerOne customers LIKE THE PENTAGON PERHAPS, & took their word for it!
And this hacker originally reported this issue 3 YEARS AGO.
This bug bounty platform has a $100M valuation. pic.twitter.com/E3ZiXk8Pi4
Loden told SearchSecurity that "asking the reporting hacker to validate what we are seeing on our end is one of many steps in our investigation process."
"HackerOne always conducts comprehensive investigations for all vulnerabilities reported to our own bug bounty program. In this case HackerOne's bug bounty program operated exactly as intended, it gave us a way to identify an unknown risk fast so we could safely eliminate it," he wrote via email. "Less than 5% of programs were impacted by this issue, the risk was eliminated within two hours of receipt and long-term fixes were pushed within days."
Loden also clarified why action was not taken on the first report about session cookie issues.
"HackerOne's bug bounty program is focused on identifying real-world vulnerabilities impacting the Platform, and we require hackers to provide a valid proof of concept with submissions," Loden said. "The report in question from three years ago was a purely theoretical scenario focused on older browsers that were not, and are still not, supported by the HackerOne Platform."
