The Art of Bug Bounty Triage and Impactful Reporting

In today's digital landscape, where cybersecurity is paramount, bug bounty programs have emerged as crucial initiatives for organizations to bolster their defense mechanisms. Bug bounty hunters, play a pivotal role in identifying vulnerabilities before malicious actors exploit them. However, the effectiveness of these programs relies not only on the skills of the hunters but also on the triaging process and the quality of bug bounty reports. In this blog, we will delve into the world of bug bounty triage and report writing, equipping you with the knowledge to excel in these domains.

Behind the Scenes of Triage

Bug bounty triage team serves as the gatekeeper to ensure that only valid vulnerabilities reach the dev team for remediation.
Each submission to the "BugBase Managed Program" undergoes initial
evaluation by the triage team to verify its validity and alignment with program policies. Moreover, comprehensive assessments are conducted to ensure the absence of duplicate bugs and to confirm their reproducibility. Only upon successful completion of these evaluations is a bug deemed valid and subsequently subjected to the triaging process.

As a bug bounty hunter it is essential to understand the different states of a submitted report.

New : This is the initial state of a report. When a bug report is submitted, it's marked as "new." This indicates that the security team has received the report and will begin reviewing it.

Not Applicable (N/A) : Some vulnerabilities might not be applicable to the organization's systems or scope. In such cases, the report is marked as "N/A" and closed.

More Context Needed : This means the security team didn’t fully understand your report, or couldn’t reproduce the issue by using the information you’ve provided. The security team will usually follow up with questions or requests for additional information about the vulnerability.

Duplicate : If the same vulnerability has been reported by multiple bug hunters or if it's already known to the organization, the report may be marked as a "duplicate." Duplicate reports are typically closed.

Informative : If a reported issue doesn't pose a security risk but still provides valuable information, it might be marked as "informative." This acknowledges the bug hunter's contribution while indicating that no security action is necessary.

Triaged : Once the security team reviews the report and confirms the validity of the vulnerability, they move it to the "triaged" state. This means the issue has been acknowledged and accepted for further investigation.

Resolved : After the vulnerability has been addressed and a fix has been implemented, the report is marked as "resolved" or "fixed." This means the security issue has been successfully remediated.

Just to make things more clear below is an example scenario.

A managed bug bounty program is being operated by Company "xyz" through BugBase. When a report is submitted by someone, notifications are sent to both the company and Bugbase. The triage process starts with a check to determine if the reported issue fits within the program's scope. If it does, the report is then tested against the program's policy. If a report doesn't conform to the rules or is beyond the program's scope, it is marked as Invalid or Not Applicable (NA). Additionally, a check is performed to ascertain whether the same issue has been reported before. If it has, it is marked as a duplicate. If it's not a duplicate, the triager attempts to recreate the problem using the information provided in the report.

In cases where the report lacks clarity, the triager asks the hacker for more details. This iterative communication continues until the triager fully comprehends and is able to recreate the bug. Once the issue is confirmed and adheres to the program's rules, the triager triages the bug and determines it's priority. Subsequently, contact is made with the program administrator from Company "xyz" to discuss the issue resolution and to decide on the rewards for the individual who reported it.

Triaging Troubles

• Vague or Incomplete Reports:

Triage teams often encounter reports lacking essential details, making it challenging to reproduce and verify the vulnerability. Numerous times the steps of reproduction are unclear.
Provide clear, step-by-step instructions and comprehensive information to avoid frustration and delays.

Moreover reports without a working PoC may be deemed less credible.
Including a PoC enhances your report's impact and helps triagers better understand the vulnerability.

Here are two different example reports. One is not very clear and lacks details, while the other is well-explained and provides clear steps to follow. These examples illustrate how good reporting can make a big difference in bug bounty programs.

Unclear report:

Title: XSS Vulnerability

Severity: Medium

Title: xss on your website

Severity: Medium

Description: There seems to be xss on your website. Please check it.

Steps:
1. go to the post page
2. submit the payload

Report with clear steps:

Title: Cross-Site Scripting (XSS) Vulnerability in the Comment Field

Severity: High

Description:

I have identified a critical Cross-Site Scripting (XSS) vulnerability within the comment field of the posts
section of your website. This vulnerability could potentially allow an attacker to execute arbitrary code in 
the context of other users' browsers, leading to the theft of sensitive information, session hijacking,
or distribution of malicious content. Here is a comprehensive breakdown of the issue.

Vulnerability Details:

Vulnerable Page: https://www.example.com/posts
Vulnerable Parameter: 'comment'
Attack Vector: The 'comment' parameter is not properly sanitized before being rendered in the HTML response.

Steps to Reproduce:

1. Access the posts at: https://www.example.com/posts
2. In the 'Comment' field, insert the following payload: <script>alert(document.cookie);</script>
3. Submit the comment & reload the page. The payload executes, triggering a pop-up alert with the user cookies.
    
Impact:

An attacker could craft malicious payloads and send them to unsuspecting users. Upon execution, these payloads
could steal session cookies, sensitive information, or perform actions on behalf of the victim.
 
Remediation:
 
To mitigate this vulnerability, I recommend implementing proper input validation and output encoding
for user-generated content. Additionally, consider utilizing Content Security Policy (CSP) headers to 
further restrict the execution of unauthorized scripts.

• Ignoring Program Guidelines:

Failing to adhere to the program's rules and scope can lead to unnecessary rejections. Thoroughly review and understand the guidelines before submitting reports.

For example, we've come across reports such as "Bypassing Rate Limit on API Endpoints Allows for Unlimited OTP Delivery." Although the issue is valid, it's explicitly stated in the program policy that "Rate limiting (unless it poses a severe threat to data or business loss)" falls out-of-scope. Consequently, this report will be marked as N/A.

• Reporting without validating:

This is something that always annoys the triagers. Sometimes bug hunters learn about a vulnerability and just blindly reports it in every program without even validating if the vulnerability exists.

For instance, let's dive into a funny story: Recently, we got bombarded with reports about an "Oauth Misconfiguration Leads to Pre-Account Takeover" vulnerability. The person reporting it seemed to be on a roll, sending it to every bug bounty program without bothering to check if it's valid. What's even more amusing is that in some programs, there wasn't even a way to use OAuth Single Sign-On. So, let's not follow in those footsteps!

We've also received numerous reports involving response manipulation vulnerability. However, hackers haven't confirmed whether these issues indeed impacted the backend, relying solely on frontend rendering.

• Noisy reports:

Avoid submitting multiple reports for vulnerabilities that stem from a common root cause, even if they appear on different endpoints.

For example, a company is using a custom comment box/widget and this can be found in various places like support portals, blogs, posts, etc. So if you find XSS in comment box, you only report the vulnerability in the comment box and mention that the issue was found there instead of reporting XSS multiple times wherever this comment widget is used. However, please note that there are exceptions, particularly when it comes to certain cases like IDORs, where separate reports might be necessary.

• Constantly asking for updates:

There is no point in asking for multiple updates continuously. When you submit a report to a managed program, the triager keeps a close watch on it. There might be ongoing communication between the triager and the program admin.
Sending follow-up messages multiple times in a short span doesn't give your report special attention. It's best to ask for an update around every two weeks.

Impactful reporting

While much of the online content focuses on teaching the skills for uncovering bugs, there is a noticeable lack of guidance on crafting effective bug reports. In the following section, we'll delve into strategies for optimizing the impact that reports can have on both the company and triagers.

1. Structure

A well-structured bug bounty report plays a pivotal role in the efficiency of the triage process. Consider the perspective of the triagers who handle numerous reports daily. When your bug bounty report is organized and coherent, it significantly accelerates their ability to comprehend the issue at hand.

A report that includes the following sections can be regarded as a well-constructed report.

• Summary

Begin with a concise summary that highlights the vulnerability's impact, affected systems, and potential risks. A clear summary helps triage teams quickly grasp the essence of the report.

• Description

Provide a detailed description of the vulnerability.

• Steps to reproduce

Provide step-by-step instructions to replicate the vulnerability, including all the necessary details.

• Proof of a concept

This component is the visual of the whole work. You can record a demonstration video or attach screenshots. A well-documented PoC simplifies the verification process.

• Impact

Clearly articulate the potential impact of the vulnerability on the target system, data, or users.
Explain how an attacker could exploit the vulnerability and the potential consequences.

• Potential Remediation

Offer suggestions or insights into how the vulnerability could be mitigated or fixed.
This showcases your expertise and helps expedite the remediation process.
This part is optional but if you are very familiar with the vulnerability then you can suggest remediation steps.

2. How to set severity correctly

After a lot of hunting, finally you found a vulnerability! Congratulations. But now you need to determine the severity of the reported bug. Blindly assigning a severity level can lead to misunderstandings and unnecessary frustrations.
This is where the Common Vulnerability Scoring System (CVSS) steps in as a valuable tool. CVSS evaluates factors like exploitability, impact on confidentiality, integrity, and availability, providing a numerical score that translates into a clear severity level. This systematic approach ensures a precise representation of risk and assists triage teams in making informed decisions. Familiarize yourself with CVSS metrics, evaluate each aspect of the vulnerability, and derive a score to indicate its true severity.
Here at BugBase we also support the use of BugCrowd Vulnerability Rating Taxonomy (VRT).

To cite an instance, consider the below case.

Imagine a reporter finding an account takeover vulnerability. In this case he can use the CVSS to determine the severity of his report as follows:

Attack Vector : Network - The attack can be carried out remotely.

Attack Complexity : Low - The attacker doesn't require specialized conditions to exploit the vulnerability.

Privileges Required : None - The vulnerability is a 0-click account takeover.

User Interaction : None - No user interaction is needed to exploit the vulnerability.

Scope : Unchanged - The vulnerable component & the impacted component is the same.

Confidentiality : High - The attacker gains unauthorized access to sensitive user data and possibly other accounts.

Integrity : High - The attacker can manipulate user data and potentially perform unauthorized actions.

Availability : High - The vulnerability allows for the deletion of user accounts, impacting system availability.

3. Clear Impact

"No Impact, No Bounty" these are the golden words spoken by my colleague Devang Solanki on a very frustrating Monday.

A strong bug bounty report needs a clear impact statement. This is your best chance to earn a higher bounty. Make sure you explain how the bug could harm the security of the targeted asset and always try to escalate your attack to create maximum impact.

If you find a vulnerability try to exploit it to the maximum before submitting the bug report. This will increase the chances of you getting a higher bounty.

Let's say you come across an IDOR vulnerability on a critical endpoint. However, the IDs in use seem a bit random, which reduces the potential impact. Instead of immediately reporting this, try to maximize the impact by checking if the IDs are leaked via some responses, other API endpoints or even some public pages of the application.
This way you can maximize the impact which in turn increases your bounty.

4. Avoid making assumptions:

To start, never presume that the security team will automatically comprehend every detail in your report. Keep in mind that while you might have devoted days to investigating a vulnerability, the security team receiving your report is encountering this information for the first time. Moreover some triagers might not be familiar with the vulnerability class you've reported. So always keep an open mind and explain the issue properly. Aim for thoroughness in your explanation, offering as much information as possible, and incorporating all specifics you can recall. Additionally, providing references in the form of links is a helpful practice.

5. Professional attitude

Maintaining a professional attitude and communication during bug bounty reporting is not just a formality; it's a strategic approach that yields significant benefits. A professional attitude enhances your credibility within the ethical hacking community. Moreover clear, concise, and respectful communication not only ensures that your findings are taken seriously but also fosters a positive relationship with the program's team. Professionalism creates a confidence in your expertise and motivates the team to address vulnerabilities promptly.

6. Language Barrier

For many hackers, English might not be their primary language and sometimes there might be communication misunderstandings just because the reporter is not familiar with the language.
However, there are now various AI chatbots like ChatGPT that can assist in creating clear and high-quality reports.

At BugBase, triagers come from diverse backgrounds, speaking languages such as Hindi, Tamil, Bengali, Malayalam, and more. If you're not confident with English, feel free to report in your preferred language, and we'll handle the translation for the program admins.

Next Steps After Reporting a Bug

The responsibility of bug bounty hunter doesn't end when he submits a report and it gets triaged.
Below are some of the steps that a bug bounty hunter should follow to ensure a productive and mutually beneficial bug bounty experience.

• Giving Adequate Time for Fixing

Giving adequate time for fixing" is a fundamental principle in the bug bounty ecosystem. This practice recognizes the complexity of resolving vulnerabilities and respects the development team's workflow. By allowing sufficient time for analysis, verification, and implementation of fixes, bug hunters contribute to more thorough and effective resolutions. This patient approach acknowledges that rushing the remediation process could potentially lead to incomplete or hasty solutions.

• Dealing with Conflict

This is a vital aspect of the bug bounty journey. As bug hunters and program teams work together to improve security, conflicts can arise due to differing perspectives or communication breakdowns. Addressing conflicts with professionalism and open communication is essential for maintaining a positive relationship. Instead of allowing conflicts to escalate, bug hunters should approach disagreements constructively, focusing on the common goal of strengthening security.

If you disagree with the security team about the validity of the bug, ensure that all the information in your report is accurate. Sometimes reports are labelled as Informative or NA due to technical or communication errors. For instance, if incorrect URLs were included in your proof of concept (POC), the security team might struggle to replicate the issue. In such instances, promptly send a follow-up report with accurate details to address the discrepancy.

However, if your original report is accurate and you still disagree with their assessment, take the next step. Submit a follow-up report elaborating on why you believe the bug indeed constitutes a security issue. If the misunderstanding persists, consider seeking resolution through the bug bounty platform's mediation process or by engaging other security engineers within the team. Open communication and persistence are key to ensuring that valid vulnerabilities are properly recognized and addressed.

• Forming a Partnership

The bug bounty journey extends beyond reporting. Aim to cultivate lasting partnerships with organizations. This can facilitate smoother issue resolution and potentially lead to interviews or job opportunities. Develop favorable relationships by submitting validated reports and respecting organizations' time and processes. Show consideration by adapting your communication style to match theirs, incorporating feedback, and tailoring your reports for clarity. Continue supporting security teams until the issue is resolved, offering advice if needed. Some organizations may request retests for a fee—seize this opportunity to both earn and expedite issue resolution.

• Coordinating Public Disclosure

Coordinating the public disclosure of vulnerabilities is a critical step in the bug bounty journey. To ensure responsible disclosure, align the timing with the organization's patching process, preventing potential harm. Follow the organization's guidelines and communicate responsibly, sharing pertinent information without aiding attackers. Collaborate with stakeholders if the vulnerability affects multiple parties. Emphasize the impact to drive user awareness and action. This approach safeguards the digital landscape while maintaining ethical standards.

Conclusion

Bug bounty hunting is difficult but by delving into the nuances of bug bounty triage, report writing, and responsible disclosure, you've embarked on a journey to become a standout bug bounty hunter. Remember that innovation and uniqueness can set you apart in this competitive landscape. Through effective communication, attention to detail, and responsible practices, you can contribute to a more secure digital world while establishing yourself as a respected and valued member of the cybersecurity community. Happy bug hunting!