This blog series counts down 8 high-impact vulnerability types, along with examples of how HackerOne helped avoid breaches associated with them. This is the second in the series after we kicked things off with Privilege Escalation.
We selected these 8 vulnerability types based on a combination of OWASP Top 10 as well as HackerOne’s recent analysis of the Top 10 Most Impactful and Rewarded Vulnerability Types. Then we consulted Hacktivity, the largest directory of publicly disclosed vulnerability reports. We grabbed examples of how our ingenious security researchers helped HackerOne customers avoid costly breaches associated with each type of vulnerability.
Today’s vulnerability, Information Disclosure, gives us an opportunity to show how HackerOne “dogfoods” our own public Bounty and public disclosure. Default to Disclosure is, after all, one of HackerOne’s five company values.
According to Mitre, an Information Disclosure (or Exposure as Mitre call it in CWE 200) vulnerability happens when information is disclosed to an actor that is not explicitly authorized to access that information. There are two principal types:
- When the information disclosed is regarded as sensitive within the product’s own functionality, such as a private message
- If the disclosure provides information about the product or its environment that could be useful in an attack but is normally not available to the attacker, such as the installation path of a product that is remotely accessible.
HackerOne ranked this vulnerability third overall on our list of top ten most impactful and rewarded vulnerabilities. And as the figure below shows, the prevalence of this vulnerability is particularly high in the Federal Government sector, where it represents 27% of the total report volume.
How HackerOne Avoided an Information Disclosure Breach
On January 31st, 2019, a little over one month after the HackerOne engineering team pushed a new GraphQL feature into production, @yashrs reported that “The GraphQL endpoint doesn’t have access controls implemented properly.”
The report continues “any attacker can get personally identifiable information of users of Hackerone such as email address, backup hash codes, facebook_user_id, account_recovery_phone_number_verified_at, totp_enabled, etc.”
Thanks to the great and timely report, HackerOne was able to implement a short-term fix on January 31st, 2019 at 9:46 PM, only 2 hours after the vulnerability was reproduced. Research by the engineering team determined that the vulnerability had not been exploited by any criminals and no sensitive information had been breached.
Potential Business Impact
The HackerOne team determined that sensitive information of multiple objects was exposed by this vulnerability. The GraphQL schema enables anyone to query the users on the platform. This is an intentional design decision. However, because every User object could be accessed, a significant amount of confidential information was accessible.
It was further determined that certain Team data was inappropriately accessible via this misconfiguration. It was possible to obtain internal triage notes and the policy of a select number of private programs the user did not have access to. The reporters queried partial program information, but they did not obtain any sensitive information that warranted HackerOne to reach out to any customers.
Due to the potential impact, this report was classified as Critical and paid a bounty of $20,000.
Naval ROTC Scholarship Hopeful Helps U.S. Department of Defense Avoid an Information Disclosure Breach
Hacker Aaron Esau, who goes by the alias @arinerron2, and two additional team members, reported a Critical Information Disclosure bug through DoD’s HackerOne Response VDP on August 19, 2019. As Aaron explains in his excellent blog write-up, he has been exploring the DoD’s program on HackerOne in part because he intends to apply for the Naval ROTC scholarship when he pursues college in 2020.
Aaron performed reconnaissance by doing an unauthenticated web path scan on the subdirectory /nrotc when he discovered a page called Trace.axd that returned the HTTP status code 302 and redirected to a login page.
With a bit more digging, Aaron found that through this page he was able to access social security numbers, usernames, email addresses, plaintext passwords, session tokens, CSRF tokens, and of course, application-specific details (e.g. information about the software and filesystem), and headers for the HTTP traffic.
DoD Thanks Aaron Publicly
Next up in our series of 8 high impact vulnerabilities will look at SQL Injection and how your favorite coffee tastes much better without one—so stay tuned!