Before we delve into the main explanation of creating Effective Vulnerability Report with additional explanations about Bug Hunter and Bug Bounty Program, there is a disclaimer and basic explanation about bug bounty programs and Bug Hunters as individuals who hunt or search for bugs to earn bounties.

DISCLAIMER: This article is written specifically as an educational resource for bug hunter. To learn more about Cyber Security, you can read Convert Cyber Security Into MONEY, and for Bug Bounty, you can read Bug Bounty: An Introduction to Earning Money as an Ethical Hacker.

What is Bug Bounty Program ?

A Bug Bounty Program is a company initiative to reward Bug Hunter or ethical hackers for discovering security vulnerabilities, offering various rewards. Enthusiasts of bug bounty programs are also called bug hunter. Their job is to search, research, and test security vulnerabilities in applications, systems, or specific services.

Bug bounty programs are incredibly beneficial for companies as developers. Through these programs, companies can discover vulnerabilities earlier before irresponsible parties find and exploit them, causing significant losses for the company. Additionally, these programs enable companies to implement continuous security controls.

Besides being useful for companies, bug bounty programs also benefit bug hunter. The primary goal of these programs for a bug hunter is to receive certain bug bounty rewards. These rewards are not only in the form of financial compensation but can also be in the form of certificates of appreciation, recognition through recommendations (usually via LinkedIn), or experience.

What is Bug Hunter ?

In the vast realm of cybersecurity, there exists a group of individuals who possess a unique set of skills and a relentless passion for uncovering vulnerabilities in software systems. They are known as bug hunters, and they play a crucial role in ensuring the security and integrity of digital platforms.

Bug hunters are essentially ethical hackers who actively search for flaws, or “bugs,” in software applications, websites, and other digital systems. Their primary objective is to identify and report these vulnerabilities to the respective organizations or developers, allowing them to patch and fortify their systems against potential cyber threats.

Benefit of Bug hunter Ethically Report a Vulnerability

When conducted properly and ethically, this activity can provide many benefits. However, if bug hunter done carelessly and irresponsibly, it can be dangerous, as it can be categorized as cybercrime. Not a few bug hunter have ended up behind bars due to this.

Some bug bounty programs are organized by companies independently, usually referred to as private bug bounty programs, or they can be hosted through specific platforms. There are several well-known bug bounty platforms that have proven to offer rewards, such as HackerOne, Bugcrowd, Redstorm.io, cyberarmy.id, cobalt.io, bugbounty.jp, hackenproof, antihack.me, zerocopter, and many more.

The Importance of Good Communication Skills in Creating Effective Vulnerability Report

Communication between bug hunter and developers in bug reports is crucial when reporting vulnerabilities, whether it is in a contribution to an official bug bounty program or in a more legal job such as a pentester or similar.

Information about the function of a feature, accompanied by the location of the vulnerability of the feature, is a basic element that testers need to present to developers in order to provide optimal information in understanding the impact and remediation recommendations available.

Unfortunately, many bug hunter struggle to communicate effectively with developers. This can happen when bug hunter first discover a security flaw and need to contact developers, or when they struggle to articulate a report that leads to less than optimal results, such as a lack of understanding by the report recipient about the vulnerability or its impact. For example, if a bug hunter creates a report that is too general and does not provide guidance on the root cause of a problem.

In addition, in some cases, testers fail to establish good communication with developers because they do not adhere to ethical principles when reporting security issues related to the product scope.

Developers, as report recipients, will typically have difficulty identifying a problem, as previously discussed. Sometimes, the security team, as a recipient, is not the same team as the developer who created the product. Therefore, in reality, they will still need time to understand the contents of the report and the flow of the vulnerable object.

Decrease in Bounty and Some Terms in Bug Bounty Programs: Triaged, Not Applicable, Informative, and Duplicate

When a bug hunter fails to communicate a security flaw effectively, it is possible that the bounty value obtained will be reduced from what should have been received. In other situations, it is even possible that the opportunity to receive a bounty is lost entirely. And the worst-case scenario is when the developer considers the bug hunter’s actions to be illegal.

Other problems may arise if the report is in-effective vulnerability report or if it allows new vulnerabilities to appear. And there are many other possibilities that can arise, such as a decrease in priority for reports to be responded to by program owners or even a lack of trust in the bug hunter to conduct security testing, which could threaten the career and reputation of the bug hunter.

In bug bounty program, there are terms for closing reports with indications that a bug report cannot be accepted, is invalid, not too dangerous, or not worthy of receiving a bounty, commonly referred to as closed report states. These terms include:

1) Triaged

Triaged – is  a status in bug bounty programs, which means that the submitted vulnerability report is currently under review by the security team or program manager. During this status, the team will determine the validity and severity of the report based on various factors, such as impact on the system, ease of exploitation, and likelihood of exploitation.

Once the team has completed their review, they will either move the report to a higher priority status for remediation, or mark it as closed with a different status, such as informative, not applicable, or duplicate, depending on the outcome of their review.

2) Informative

Informative – This status is given when a bug report contains useful information but does not guarantee immediate action or fixes. Examples of informative reports include:

• • Notification of broken links
  • The issue cannot be consistently reproduced
  • The reported security flaw does not pose a significant threat to the main system.

In this status, a program may consider providing an alternative risk assessment or other mitigating factors. The report then becomes disclosed (made public) based on mutual agreement after the bug is deemed to be resolved and no longer requires additional information from the bug hunter.

3) Duplicate

Duplicate – This status is given when a bug report has already been reported by another bug hunter. The program can build trust by linking the issue to its original discoverer and linking it to the previous report or providing additional details about the discovery. Public disclosure is not available for this status.

Note: If a bug hunter archives a duplicate public report, their reputation may be negatively affected.

4) Not Applicable

Not Applicable – Not Applicable or N/A is a status that occurs when a report does not contain a valid issue and has no security implications. In this case, the security team or the program’s hosting company must explain why the report is invalid so that the hacker can improve their hacking skills.

In some cases, a bug report is marked as N/A not necessarily because the report is invalid, but because of the bug hunter’s lack of skills to properly report the bug, causing the bug to fail to be reproduced and marked as Not Applicable or N/A.

Tips for Reporting or Writing Effective Vulnerability Report in Bug Bounty

When reporting or writing Effective Vulnerability Report for some security vulnerabilities. There are several things to consider to ensure that the report we submit is an effective report an can understood and considered valid by developers or bug hosting companies, including:

1) Providing a Title That Briefly Describes the Security Vulnerability

In the bug bounty world, some hosting companies only require brief information details from the title to know where the security vulnerability exists.

In some situations, the title can save time for developers or security teams to identify a vulnerability in the system. Although not all developers prefer this, it does not hurt to provide a slightly descriptive title.

For example: “IDOR in Application Server **** Leads to Disclosure of User Data and Account Takeover.”

2) Including the Vulnerable URL, Endpoint, and Parameters

When including the vulnerable URL, endpoint, and parameters in a security report, it is important to provide clear and concise information to help the developer or security team understand the vulnerability. For example, if a Unautohorized Access vulnerability is found in API Endpoint of a website, the report should include the URL of the API, the spesific  endpoint where the Unautohorized Access vulnerability occurs, and the parameters that are vulnerable.

A clear and concise example of this type of information would be:

• • Vulnerable URL: https://api.example.com/v1/users
  • Vulnerable Endpoint: /v1/users/profile
  • Vulnerable Parameters: id=1234

In this example, the vulnerable endpoint is “/v1/users/profile“, and the vulnerable parameter is “id=1234“.

This information can help the developer or security team to identify and reproduce the vulnerability, which could be a security flaw in the user profile endpoint that allows unauthorized access to sensitive information.

By including this information in the report, the developer or security team can take appropriate action to fix the issue more quickly  to protect the users’ data.

3) Providing a Brief Explanation of the Type of Bug

This is something that can be considered important because the security team or developers may not understand the bug being reported and its potential impact. By providing a brief explanation of the bug, the team will be better informed and become more aware, prioritizing the bug report we submitted.

For example: “IDOR stands for Insecure Direct Object References, which is a type of access control vulnerability that occurs when an application uses user-supplied input to access objects directly.”

4) Including Videos or GIFs

When creating a bug report, it is common to use screenshots or screen captures in the “steps to reproduce” section. However, it would be even better to include a GIF or video to help the security team or developer understand how to reproduce the bug and verify whether it is valid or not.

5) Providing Information About the Vulnerable Application or System Version and Device Used

When a bug hunter tests a system or application that has a version, it is important to include the version of the application or system being tested, along with details about the device used to perform the testing.

The application or system that we test may use a certain framework or CMS, so information about the version will be very useful for the security team or developer to perform mitigation and fix the vulnerability.

For example: “The SSRF vulnerability here exists in the urlgetreq/0.19.2 library and has been tested using Chrome version n 96.0.4664.110 (Official Build) (64-bit) with Windows 10 Single Language.”

6) Clearly Describe the Impact and Include the CVSS Score

When reporting a security vulnerability, the most important factor in determining the amount of reward or the validity of our report is the impact of the vulnerability we found. The greater the impact of the bug on the system or its users, the more prioritized our report will be, and the greater the reward we can receive. Bug hunter need to emphasize this impact information by creating a specific subsection that explains each impact in detail and with specificity.

Additionally, including the Common Vulnerability Scoring System (CVSS) score can help the security team or developer understand the severity of the vulnerability and prioritize their response accordingly.

Closing

Perhaps these are the experiences and tips that I can share. In brief, I hope that the benefits of this article about “Bug Hunter, Bug Bounty Program and Tips for Creating Effective Vulnerability Report” can be obtained well by both the bug hunter as a tester and the company as a developer.

Which is a means of sharing knowledge that can bring new knowledge for every bug hunter, building a positive personal branding for testers for career advancement in the future, improving the ability to build good relationships and cooperation with developers, and being able to establish sustainable cooperation through comprehensive security vulnerability reports.