Baibhav Anand Jha


$~# whoami
Baibhav Anand Jha
I do bug-bounties
I develop
I learn
I hack
He/Him

 

      

How Often Do We Overlook Vulnerabilities?

September 09 | 4 Minutes Read



Hello Readers, “7/10 vulnerabilities are often overlooked by hackers.” -Aristotle. I don’t know if that’s true, I just made that up. Anyway, This article is based on my recent finding in HackerOne/security.

There is a feature on HackerOne which allows program managers to assign the reports to a team member of their choice.



When chosen to assign the report we get the list of team members and groups in our program to chose from, whom we want to assign this report to.

A GraphQL query was made to the server to fetch the team members and groups for our team.



The reportIds variable in this mutation immediately caught my attention and I noticed that it contained the report ID of the report of my program of which I was trying to assign a team member to.
I went to my inbox and selected a report for a program I didn’t own and copied its report ID and pasted that in the reportIds value in the graphQL mutation.
The response revealed all the team members of the program. This is the exact data I got of all team members:



I don’t see any sensitive data here but the fact that I could disclose the team members of any programs still felt like something I should report.
I reported it to them and the report gets closed as duplicate to an informative report. I was added to the original report and this is the reason why the original report was closed as informative :



I wasn’t totally satisfied with this since there was so much of data, there must be at least something that might not be publicly available information.
Now I started brute-forcing the query parameters to see if I can extract any more data from what it is already showing. When I saw the email parameter was valid. I was literally shaking because I thought I was able to reveal email address of all the team members for all the programs. But I was wrong :



Email was indeed a valid parameter but the value I got was always null for all the programs except for my own program.
At this point I didn’t want to dig in any further but still I gave a quick glance at the information I was receiving and I started to check some profiles and I noticed for some profiles I got page does not exist error. It didn’t take me to long to realize that the value for name is also null in those profiles which I was not being able to open.



Now again I switched to the data for my program and then I realized that these were actually API-Identifiers and most of them were not public. So the new report becomes API Identifiers visibility is public by default and can be queried for programs. I didn’t immediately report it and decided to report it after I am done with hunting.
I go to my profile -> edit profile -> Program preferences and I noticed that there was an option to turn off visibility for a program so that it doesn’t show in my profile that I am a part of that program.



When this is turned “on” we can see the program in the Hacker’s profile.



When turned “off” it won’t be visible.
It didn’t take me to long to realize that now I could also disclose if a Hacker belongs to certain program despite of the fact that his program visibility is turned off.
Now I had two impacts for the same information disclosure vulnerability and I reported it again with the additional impacts that I discovered and finaaaallllllyyyyy :