The View from the Other Side: A Security Analyst's Perspective on Bug Bounty Triage

I was always intrigued about how things work on the other side of bug bounty. Well, the month of June, 22 made that possible for me when I started my day one as a Product Security Analyst with HackerOne. Now, I am on the flip side triaging your reports.

During my initial days, I came across multiple areas where some researchers may lack clarity. There are elite researchers that are very active on the platform, but many researchers still lack full awareness of how triage works. I felt a sense of responsibility to write about it so the whole hacker community benefits.

Disclaimer

This post is all about my experiences, analysis, and opinions around the Product Security Analyst role. The sole purpose of the post is to educate everyone about things that you may not be knowing.

Let's get started!

The Definition of Triage

In simple terms, every report that is submitted to a “HackerOne Managed Program” passes through the triage team. The triage team performs the first report validation and pulls out any Informative, Duplicate, Not Applicable reports. The valid reports get assigned to the program’s team for further analysis and remediation. 

The small label beside our handles like `HackerOne triage` can help you determine if the person is from the triage team or the program team. For instance, If a person from the program ‘ABC’ comments on a report, they will have the banner of `ABC staff` beside their handles.

Fact Check

Let’s talk about some quick facts about triage

1. As security analysts (aka triagers) we always try to be objective and not incline towards any specific side of either the researcher or the program. We always wish that a researcher is rewarded for their efforts. A simple ask is to be patient with us throughout the process as we try to make sure that a valid report is always rewarded through platform reputation points/swags/ hall of fame/CVE/ bounty. Most of the security analysts have been active bug bounty hunters themselves, so we understand the efforts that you put into every single report.
2. We enjoy talking to the researchers who are super nice with their words. Even through reports, it's still a back-and-forth conversation that goes on with researchers. Being nice is something that helps on both the ends, and it works like a great motivation. Being nice makes validating your reports fulfilling to us and also helps you stand out as a professional researcher in the world of Cybersecurity. Win, win! I bet you feel good too when security analysts appreciate your work and reports.
3. As a company specialized in human powered report validation, it's important to remember that disagreements may sometimes occur in the changing of initial decision made by a security analyst on reports. We are eager to learn and ready to have another look at a report where you may disagree with our handling of it. Our Mediation Team is there to assist with ensuring reports are being treated fairly in these types of situations. Whenever you are confident about the report you submit, always share additional reasoning and/or explanation, and we would be more than happy to re-evaluate your findings.
4. A triaged report can still get closed as Duplicate/ Informative. But why does that happen? There can be multiple reasons here. Either the program is already aware of the bug that you submitted or based on their internal analysis the bug shares the same root cause as another bug already reported, hence can be remediated with the same fix. In these scenarios the program will respond on the report with details of their analysis and close out the reports as Informative. 

That was some quick fact check. Up next, I want to cover some points that I observed during the first few months of the triage. These are few of my learnings and observations around different reports.

1. There Are Some Great Reports on the Platform to Learn From

I keep saying this role is a gem in terms of learning. It is a gold mine of useful tricks, techniques, and bug classes to learn from. Everyday something novel comes up as a report, and I feel glad to be able to learn from all the security researchers out there.

There are not just web reports, but a whole range of web, mobile, desktop apps reports. All the reports cover diverse tech stack and techniques. I got better at analyzing the CVSS for reports based on the impact the bug actually has.

2. Not All Security Analysts are Men

Yes! You read that right. One of them is me, btw. :)

While working on a report, we don't know the gender of the researcher on the other side of the screen, so we prefer to use neutral pronouns everywhere.

Likewise, you will never know if you are talking to a female or a male security analyst, so it's better to use a neutral pronoun ‘they’ instead of ‘He/She’. I am not trying to enforce anything here, but it feels weird when a researcher calls me by ‘He’ or ‘Sir’, so take it as a suggestion from a security analyst who is not ‘He’

3. Researchers Asking for Multiple Updates

Hey! Do you have any updates on my report?

Once you submit a report to a program with HackerOne managed triage, It will always be reviewed by a HackerOne security analyst. So after the report submission, just sit back and relax. I agree that there may be a delay sometimes, but it will surely be reviewed.

Updates After First Response

Now that's a tricky thing. There may be scenarios when a report in ‘triaged’ or ‘pending program review’ state has no updates for more than a month. There can be multiple reasons behind that, however it is out of scope for this post. 

Though I want to note here that there is no point in asking for multiple updates (example 2-3 times a week). Following up multiple times within few days doesn’t prioritize your report. It's also worth noting that spamming reports for updates can also be considered unprofessional behavior in the hacker Code of Conduct and may warrant an outreach from our Mediation Team. 

It's Important to Ask for Updates

When should you actually ask for updates?

The ideal time would be in a gap of two weeks. Most likely there will be updates within that duration, and if you haven't heard back within two weeks, feel free to request a Hacker Mediation – they will ensure the report gets reviewed accordingly.

4. It’s Better to Explain your CVSS Instead of Directly Setting the Severity

On a daily basis, we come across reports that are not straightforward. When bug chaining is performed, the impact of the vulnerability changes. It is generally a best practice to explain the rationale behind your severity rating by setting and explaining the CVSS metrics. However, just explaining the impact is not enough. A statement that is theoretically possible might not be practically exploitable in a real world scenario.

For us to re-access the CVSS, you ought to provide the proof otherwise we will keep the severity corresponding to the real world impact that is demonstrated in the report.

5. Elevating the Impact

Did you find a vulnerability in the dev environment for a program? Don’t submit it yet because you may have your chances of finding the same issue in the production environment.

The question here is – How is the impact elevated actually? Let me elaborate with few examples.

• A PII disclosure in dev/stage environment may be rated as `Low` confidentiality. However, for production, a PII disclosure may be as severe as a `Critical`.
• Cache poisoning vulnerability may be rated as `Medium` in dev as no real users are impacted. But, it will surely be rated as `High` if the same issue exists in the production.

I think you got the point. You may now have chances of getting more $$$$.

Reporting

Reporting is one of the most important “skills” in bug bounty. Knowing how to write a good report, conveying your thoughts and discoveries is vital in reporting to HackerOne. Sometimes it's not the vulnerability that is interesting, but the way in which it is presented. The researchers have been rewarded for that in the past.

Read this doc to find out more about how to write quality reports.

A Report with Multiple Steps

Not all the reports are as trivial as most examples of Reflected XSS that require a single click to verify it. A report can have multiple steps right from logging in to navigating multiple pages, capturing multiple requests, and running numerous commands.

I feel happiest when a report gets triaged without multiple NMIs (Needs More Info). I agree that NMIs are sometimes unavoidable, but please understand this point that you know the application better than the security analysts. Why? You have spent time researching on it. We are just validating your research. So we may not be aware of all the navigation of the application. It is quite possible that we're maybe visiting the application for the first time just to validate your report.

Therefore, don't assume that we know everything. Please provide navigation links wherever it is possible (including things like sign in URL). You will end up saving both yours and ours time as there will be fewer NMIs :)

Additionally, It helps a lot when the links are ‘textual’ instead of being present in a proof-of- concept (PoC) screenshot or video. It helps us to easily navigate in the application by simply copying and pasting the URLs instead of typing it manually (which is error-prone and time-consuming). It eases out the process of duplicate check as well.
 

A Report with Extra Setup

There are a lot of reports where setup is more time-consuming than the actual exploitation. Scenarios here can be mobile app reports, game reports, reports requiring certain OS setup. It is considered a best practice to mention all the key details that are required to replicate the steps in order to avoid NMIs. A video PoC is always preferable in such cases where all the steps are clearly visible in the video PoC.

But like I said, NMIs are sometimes unavoidable, and we expect patience and support from the researchers.

Outputs not Snipped

We often come across reports, where the output of a command / request is copy-pasted into the report. It increases the report length significantly. All we see is just the long output and not the replicating steps. We have to scroll through the report just to find the missing pieces.

Are those long outputs really a necessary part of the report? I would answer that as `No`. It is enough if you keep the start and the trail of an output and snip the part in between.

```

This is test output start

…

[snip]

…

This is test output end

```

That looks clear and pretty, right? Keeping a report clear, crisp, and tidy makes it extremely easy for us to replicate your findings.

The Supported Video Formats on HackerOne Platform

Do you know that the HackerOne platform supports video rendering? However, there are only a few supported formats. Those are `.mp4`, `.mov` and `webm`. Please try to record videos in those formats. When you provide videos in these supported formats, there is no need for us to download each and every video that you attach. It proves to be a great time saver!

I Submitted a Report, but it got Fixed Before Getting Triaged 🥲

Have you ever faced this kind of situation? I would never want that to happen to anyone. You will be getting lucky if the program team is aware of the changes made and acknowledges it.

But if the program team isn’t aware of the change, we as security analysts can’t do anything about it, and we feel bad too when such reports gets closed out as Informative. A few reasons why the program might not be aware is that there may be a patch in the pipeline, it was already an internally known issue, an issue was knowingly created and got fixed right after the work.

To avoid getting such reports closed as Informative, make sure to always keep a PoC to claim your statement later. If there are valid proofs, we as security analysts can always check with programs and ask for more details (e.g., patch in pipeline, internally known issue, etc.)

Pending Program Review Doesn't Mean Triaged

Pending program review doesn't necessarily mean that the report has passed all the checks and is not equivalent to Triage. It means that the security analyst has been able to reproduce the issue and has sent it to the program team for review before it can be Triaged. If anything comes up like an issue is already known internally, the report might still get closed as Informative.

The Words of Motivation

For those who are getting started or are beginners in the world of bug bounties, I want to let you know that finding bugs is totally possible and achievable. In my early days in this field, someone said to me that if your reports are getting closed as duplicates, you are still in the right direction. You just need to be patient.

If a few exceptional reports are kept aside, please know that everyone submits the good old XSS, SQLi, CSRF bugs.

Reputation plays a major role here that gives top researchers the priority in invites for private programs so yes they already have leverage. But it's fair enough, as they too have put hours of work to reach there. In a nutshell, just spend some time around applications, and you will see the results soon. 

That’s all for this post. Hope you found this post insightful around how triage works, some facts around triage, or it motivated you to dive into bug bounty.

Let me know if you have anything in mind about the triage that can be addressed here.

See you in the next one. Until then, happy hunting 😇