Sustaining Your Success: Mastering the Bug Bounty Journey

Even if you understand the technical information, you may still have difficulty navigating the nuances of bug bounty programs. Or you might be struggling to actually locate legitimate bugs and aren’t sure why you’re stuck.

This article explores some of the factors that go into making a successful bug bounty hunter. It covers how to write a report that properly describes your findings to the security team, build lasting relationships with the organizations you work with, and overcome obstacles during your search for bugs.

Writing a Good Report: Explaining Your Findings

A bug bounty hunter’s job isn’t just finding vulnerabilities; it’s also explaining them to the organization’s security team. Providing a well-written report will help the team you’re working with:

• Reproduce the exploit.
• Assign it to the appropriate internal engineering team.
• Fix the issue faster.

The faster a vulnerability is fixed, the less likely malicious hackers are to exploit it. The following sections break down the essential components of a good vulnerability report and introduce valuable tips.

Step 1: Craft a Descriptive Title

The first part of a great vulnerability report is always a descriptive title. Aim for a title that sums up the issue in one sentence. Ideally, it should allow the security team to immediately get an idea of:

• What the vulnerability is (e.g., IDOR, XSS).
• Where it occurred on the target application.
• Its potential severity.

Example: Instead of a report title like “IDOR on a Critical Endpoint,” use one like “IDOR on https://example.com/change_password Leads to Account Takeover for All Users.” Your goal is to give the security engineer a clear idea of the report’s content.

Step 2: Provide a Clear Summary

Next, provide a report summary. This section includes all the relevant details you weren’t able to communicate in the title, like the HTTP request parameters used for the attack, how you found it, and so on.

Example of an Effective Report Summary:

The https://example.com/change_password endpoint takes two POST body parameters: user_id and new_password. A POST request to this endpoint would change the password of user user_id to new_password. This endpoint is not validating the user_id parameter, and as a result, any user can change anyone else’s password by manipulating the user_id parameter.

A good report summary is clear and concise. It contains all the information needed to understand a vulnerability, including what the bug is, where the bug is found, and what an attacker can do when it’s exploited.

Step 3: Include a Severity Assessment

Your report should also include an honest assessment of the bug’s severity. Including a severity assessment helps the security team prioritize which vulnerabilities to fix first, ensuring that they take care of critical vulnerabilities right away.

The severity scale often used includes:

• Low severity: The bug doesn’t have the potential to cause a lot of damage (e.g., an open redirect that can be used only for phishing).
• Medium severity: The bug impacts users or the organization in a moderate way, or is a high-severity issue that’s difficult for a malicious hacker to exploit (e.g., a cross-site request forgery (CSRF) on a sensitive action such as password change).
• High severity: The bug impacts a large number of users, and its consequences can be disastrous (e.g., an open redirect that can be used to steal OAuth tokens). The team should fix this as soon as possible.
• Critical severity: The bug impacts a majority of the user base or endangers the organization’s core infrastructure (e.g., a SQL injection leading to remote code execution (RCE) on the production server). The team should fix this right away.

Study the Common Vulnerability Scoring System (CVSS) for a general idea of how critical each type of vulnerability is. The CVSS scale takes into account factors such as business impact, difficulty of exploitation, and required privileges/user interaction.

• Customization: Try to imagine what your client company cares about and which vulnerabilities would present the biggest business impact. Customize your assessment to fit the client’s business priorities. For instance, a leak of a user’s birth date might be inconsequential for a dating site but significant for a job search site. Leaks of users’ banking information are almost always considered a high-severity issue.
• Platform Tools: If unsure, use the rating scale of a bug bounty platform, such as Bugcrowd’s rating taxonomy or HackerOne’s severity calculator based on the CVSS scale.

Providing an accurate assessment of severity will make everyone’s lives easier and contribute to a positive relationship between you and the security team.

Step 4: Give Clear Steps to Reproduce

Next, provide step-by-step instructions for reproducing the vulnerability. Include all relevant setup prerequisites and details you can think of. It’s best to assume the engineer on the other side has no knowledge of the vulnerability and doesn’t know how the application works.

Example of a Better Report:

1. Make two accounts on example.com: account A and account B.
2. Log in to example.com as account A, and visit https://example.com/change_password.
3. Fill in the desired new password in the New password field, located at the top left of the page.
4. Click the Change Password button located at the top right of the page.
5. Intercept the POST request to https://example.com/change_password and change the user_id POST parameter to the user ID of account B.
6. You can now log in to account B by using the new password you’ve chosen.

Although the security team will probably still understand a less specific report, providing many relevant details avoids misunderstanding and speeds up the mitigation process.

Step 5: Provide a Proof of Concept (POC)

For simple vulnerabilities, the steps might suffice. But for more complex vulnerabilities, it’s helpful to include a video, screenshots, or photos documenting your exploit, called a Proof-of-Concept (POC) file.

• For a CSRF vulnerability, you could include an HTML file with the CSRF payload embedded.
• For an XML external entity attack, include the crafted XML file.
• For vulnerabilities that require multiple complicated steps, film a screen-capture video.

POC files save the security team time because they won’t have to prepare the attack payload themselves. You can also include any crafted URLs, scripts, or upload files you used.

Step 6: Describe the Impact and Attack Scenarios

To help the security team fully understand the potential impact, illustrate a plausible scenario in which the vulnerability could be exploited. This section is distinct from the severity assessment; it explains what the consequences would actually look like.

Put yourself in a malicious hacker’s shoes and try to escalate the impact of the vulnerability as much as possible. Give the client company a realistic sense of the worst-case scenario. This will help the company prioritize the fix and determine if any additional internal investigations are necessary.

Example of an Impact Section:

Using this vulnerability, all that an attacker needs in order to change a user’s password is their user_id. Since each user’s public profile page lists the account’s user_id, anyone can visit any user’s profile, find out their user_id, and change their password. And because user_ids are simply sequential numbers, a hacker can even enumerate all the user_ids and change the passwords of all users! This bug will let attackers take over anyone’s account with minimal effort.

A good impact section illustrates how an attacker can realistically exploit a bug. It should take into account any mitigating factors as well as the maximum impact that can be achieved. It should never overstate a bug’s impact or include any hypotheticals.

Step 7: Recommend Possible Mitigations

You can also recommend possible steps the security team can take to mitigate the vulnerability. This will save the team time when it begins researching mitigations. Since you discovered the vulnerability, you are often in a good position to suggest a comprehensive fix.

However, don’t propose fixes unless you have a good understanding of the root cause of the issue. If you’re not sure what caused the vulnerability or what a possible fix might be, avoid giving any recommendations so you don’t confuse your reader.

Example of a Possible Mitigation:

The application should validate the user’s user_id parameter within the change password request to ensure that the user is authorized to make account modifications. Unauthorized requests should be rejected and logged by the application.

You don’t have to go into the technical details of the fix, but you can provide a direction for mitigation.

Step 8: Validate the Report

Finally, always validate your report. Go through it one last time to make sure there are no technical errors or anything that might prevent the security team from understanding it. Follow your own Steps to Reproduce to ensure they contain enough details. Examine all of your POC files and code to make sure they work. By validating your reports, you can minimize the possibility of submitting an invalid report.

Additional Tips for Writing Better Reports

• Don’t Assume Anything: Don’t assume the security team will understand everything. You might have been working with this vulnerability for a week, but to the security team, it’s all new information. Be as verbose as possible and include all the relevant details you can think of. The worst consequence of being too wordy is two extra minutes of reading; the worst consequence of leaving out details is a delayed fix.
• Be Clear and Concise: Don’t include any unnecessary information, such as wordy greetings, jokes, or memes. A security report is a business document; it should be straightforward and to the point.
• Write What You Want to Read: Always put your reader in mind. Write in a conversational tone and don’t use leetspeak, slang, or abbreviations. These make the text harder to read.
• Be Professional: Always communicate with the security team with respect and professionalism. Provide clarifications regarding the report patiently and promptly. By honing your reporting skills, in addition to your hacking skills, you can save everyone’s time and maximize your value as a hacker.

Building a Relationship with the Development Team

Your job as a hacker doesn’t stop the moment you submit the report. You should help the company fix the issue and make sure the vulnerability is fully patched. Building a strong relationship with the security team will help get your reports resolved more quickly and smoothly. It might even lead to bigger bug bounty payouts or even job opportunities.

Understanding Report States

Once you’ve submitted your report, the security team will classify it into a report state, which describes its current status.

Dealing with Conflict

Conflicts inevitably happen when the hacker and the security team disagree on the validity, severity, or appropriate payout amount. Handling them professionally is key to a successful bug hunting career.

• Disagreement on Validity:
  • First, double-check that your report is technically and grammatically correct.
  • If correct, send a follow-up explaining why you believe the bug is a security issue.
  • If the issue persists, ask for mediation by the bug bounty platform or other security engineers.
• Disagreement on Severity: If the team dismisses the severity, explain potential attack scenarios to fully illustrate the issue’s maximum impact.
• Disagreement on Bounty Amount: Communicate your unhappiness without resentment. Ask for the organization’s reasoning, and explain why you think you deserve a higher reward (e.g., if the impact was underestimated). Always avoid asking for more money without explanation.

Remember, we all make mistakes. If you believe the person handling your report mishandled the issue, ask for reconsideration courteously. Once you’ve made your case, respect the company’s final decision about the fix and bounty amount.

Building a Partnership

Strive to form long-term partnerships with organizations. This can help get your reports resolved more smoothly and might even land you an interview or job offer.

• Gain Respect: Always submit validated reports. Do not break a company’s trust by spamming, pestering them for money, or verbally abusing the security team.
• Learn Communication Style: Read publicly disclosed reports or incorporate their feedback to learn how much detail they expect in their reports. Customize your reports to make your reader’s job easier.
• Support the Team: Do not abandon the security team after receiving a reward. If requested, provide advice to help mitigate the vulnerability and help confirm that the issue has been fixed (retests). Always take the opportunity to perform retests for a fee if you can.

Understanding Why You’re Failing

It’s frustrating to pour hours into looking for vulnerabilities and yet come up empty, or to have reports constantly marked as informative, N/A, or duplicate. Here are common mistakes that prevent success in bug bounties:

Why You’re Not Finding Bugs

• You Participate in the Wrong Programs: Some programs may lack the resources to deal with reports, downplay severity to avoid paying, or restrict scope severely. Avoid programs with long response times and low average bounties.
• You Don’t Stick to a Program: Jumping from program to program is a common beginner mistake. To differentiate yourself, you must either dig deep (into a single functionality for complex bugs) or search wide (discover and hack lesser-known assets). Doing these things well takes time.
• You Don’t Recon: Effective reconnaissance (recon) helps you discover new attack surfaces (subdomains, new endpoints, new functionality). Spending time on recon gives you an incredible advantage because you’ll be the first to notice bugs on all obscure assets you discover, reducing duplicates.
• You Go for Only Low-Hanging Fruit: Relying on vulnerability scanners or looking for only the most obvious bug types will rarely yield results on big targets, as companies audit them and experienced hackers already tested them. Instead, strive to gain a deeper understanding of the application’s underlying architecture and logic to develop a unique testing methodology.
• You Don’t Get into Private Programs: Most successful hackers say that their findings come from private programs because they are less crowded, meaning less competition, fewer duplicates, and easier finds.

Why Your Reports Get Dismissed

• You Don’t Read the Bounty Policy (N/A): The most common reason for reports being marked as N/A is being out of scope. Read the bounty policy carefully and repeatedly to understand which assets and vulnerability types are off-limits.
• You Don’t Put Yourself in the Organization’s Shoes (Informative): Most informative ratings occur because the company doesn’t care about the issue you’re reporting. Learn about the organization’s product, data, and priorities to tailor your hacking efforts to suit their business priorities.
• You Don’t Chain Bugs (Informative): Minor bugs classified as informative can become big issues if you learn to chain them. For example, use an open redirect in a server-side request forgery (SSRF) attack instead of reporting it immediately.
• You Write Bad Reports: Even when a vulnerability is impactful, if you can’t clearly communicate its implications to the security team, they’ll dismiss the report.

What About Duplicates?

Unfortunately, you can’t always avoid duplicates. But you can lower your chances by hunting on programs with large scopes, hacking on private programs, performing recon extensively, and developing your unique hunting methodology.

What to Do When You’re Stuck

When a person first gets started in bug bounties, they might go days or weeks without finding a single vulnerability.