Bug Bounty Programs
As mentioned in this module's summary, we usually consider a bug bounty program as a crowdsourcing initiative through which individuals can receive recognition and compensation for discovering and reporting software bugs.
Bug bounty programs are more than that, though. A bug bounty program (also called a vulnerability rewards program - VRP) is continuous and proactive security testing that supplements internal code audits and penetration tests and completes an organization's vulnerability management strategy.
HackerOne aptly describes their bug bounty platform (that can host bug bounty programs) as "Continuous testing, constant protection" and as something that can be integrated seamlessly into an organization's existing development life cycle.
Bug Bounty Program Types
A bug bounty program can be private or public.
- Private bug bounty programs are not publicly available. Bug bounty hunters can only participate in a private bug bounty program upon receiving specific invitations. The vast majority of bug bounty programs start as private ones and become public after getting the hang of receiving and triaging vulnerability reports.
- Public bug bounty programs are accessible by the entire hacking community.
- Parent/Child Programs also exist where a bounty pool and a single cyber security team are shared between a parent company and its subsidiaries. If a subsidiary launches a bug bounty program (child program), this program will be linked to the parent one.
Something important to note is that the terms Bug Bounty Program (BBP) and Vulnerability Disclosure Program (VDP) should not be used interchangeably.
A vulnerability disclosure program only provides guidance on how an organization prefers receiving information on identified vulnerabilities by third parties. A bug bounty program incentivizes third parties to discover and report software bugs, and bug bounty hunters receive monetary rewards in return.
If you want to study the anatomy of a vulnerability disclosure program, refer to the following resource. VDP vs. BBP
Bug Bounty Program Code of Conduct
The violation record of a bug bounty hunter is always taken into consideration. For this reason, it is of paramount importance to adhere to the code of conduct/policy of each bug bounty program or bug bounty platform. Spend considerable time reading the code of conduct as it does not just establish expectations for behavior but also makes bug bounty hunters more effective and successful during their bug report submissions.
If you want to become an established bug bounty hunter, you will have to strike a balance between professionalism and technical capability.
We strongly suggest that you go over HackerOne's Code of Conduct to familiarize yourself with such documents.
Bug Bounty Program Structure
It is about time we see what a bug bounty program looks like. Navigate to HackerOne's bug bounty program list to go over some bug bounty programs. Take Alibaba BBP and Amazon Vulnerability Research Program as examples and go through their "Policy."
According to HackerOne: The policy section enables organizations to publish information about their program to communicate the specifics about their program to hackers. Organizations typically publish a vulnerability disclosure policy with guidance on how they want to receive information related to potential vulnerabilities in their products or online services. The policy also includes the program’s scope, which lists items hackers can test and send reports in for. It is often defined by the domain name for web applications or by the specific App Store / Play store mobile apps that a company builds.
A bug bounty program usually consists of the following elements:
In HackerOne's case, the above are usually included inside the Policy part of each program.
Please go over a bug bounty program's description/policy meticulously. The same goes for any "code of conduct" documents they may include. By doing so, you can meet expectations and avoid unnecessary back and forth that could cause significant time loss. In bug bounty hunting, time is of the essence!
Finding Bug Bounty Programs
One of the best online resources to identify bug bounty programs of your liking is HackerOne's Directory. HackerOne's directory can be used for identifying both organizations that have a bug bounty program and contact information to report vulnerabilities you have ethically found.
Writing a Good Report
By documenting our findings clearly and concisely, we get straight to our point in a way that the security or triage team can comprehend. Most importantly, bug reports should include information on how exploitation of each vulnerability can be reproduced step-by-step.
Please note that when reporting to less mature companies, we may have to translate technical security issues into more understandable/business terms for them to understand the actual impact of each vulnerability.
The essential elements of a good bug report are (the element order can vary):
Readable and well-formatted bug reports can drastically minimize both vulnerability reproduction time and time to triage.
Why CWE & CVSS?
MITRE describes Common Weaknesses Enumeration (CWE) as a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. In the case of a vulnerability chain, choose a CWE related to the initial vulnerability.
When it comes to communicating the severity of an identified vulnerability, then Common Vulnerability Scoring System (CVSS) should be used, as it is a published standard used by organizations worldwide.
Using CVSS Calculator
Let us now see how we can use the CVSS v3.1 Calculator identify the severity of an identified vulnerability.
We will focus on the Base Score area only.
Attack Vector
Shows how the vulnerability can be exploited.
- Network (N): Attackers can only exploit this vulnerability through the network layer (remotely exploitable).
- Adjacent (A): Attackers can exploit this vulnerability only if they reside in the same physical or logical network (secure VPN included).
- Local (L): Attackers can exploit this vulnerability only by accessing the target system locally (e.g., keyboard, terminal, etc.) or remotely (e.g., SSH) or through user interaction.
- Physical (P): Attackers can exploit this vulnerability through physical interaction/manipulation.
Attack Complexity
Depicts the conditions beyond the attackers' control and must be present to exploit the vulnerability successfully.
- Low (L): No special preparations should take place to exploit the vulnerability successfully. The attackers can exploit the vulnerability repeatedly without any issue.
- High (H): Special preparations and information gathering should take place to exploit the vulnerability successfully.
Privileges Required
Show the level of privileges the attacker must have to exploit the vulnerability successfully.
- None (N): No special access related to settings or files is required to exploit the vulnerability successfully. The vulnerability can be exploited from an unauthorized perspective.
- Low (L): Attackers should possess standard user privileges to exploit the vulnerability successfully. The exploitation in this case usually affects files and settings owned by a user or non-sensitive assets.
- High (H): Attackers should possess admin-level privileges to exploit the vulnerability successfully. The exploitation in this case usually affects the entire vulnerable system.
User Interaction
Shows if attackers can successfully exploit the vulnerability on their own or user interaction is required.
- None (N): Attackers can successfully exploit the vulnerability independently.
- Required (R): A user should take some action before the attackers can successfully exploit the vulnerability.
Scope
Shows if successful exploitation of the vulnerability can affect components other than the affected one.
- Unchanged (U): Successful exploitation of the vulnerability affects the vulnerable component or affects resources managed by the same security authority.
- Changed (C): Successful exploitation of the vulnerability can affect components other than the affected one or resources beyond the scope of the affected component's security authority.
Confidentiality
Shows how much the vulnerable component's confidentiality is affected upon successfully exploiting the vulnerability. Confidentiality limits information access and disclosure to authorized users only and prevents unauthorized users from accessing information.
- None (N): The confidentiality of the vulnerable component does not get impacted.
- Low (L): The vulnerable component will experience some loss of confidentiality upon successful exploitation of the vulnerability. In this case, the attackers do not have control over what information is obtained.
- High (H): The vulnerable component will experience total (or serious) loss of confidentiality upon successfully exploiting the vulnerability. In this case, the attackers have total (or some) control over what information is obtained.
Integrity
Shows how much the vulnerable component's integrity is affected upon successfully exploiting the vulnerability. Integrity refers to the trustworthiness and veracity of information.
- None (N): The integrity of the vulnerable component does not get impacted.
- Low (L): Attackers can modify data in a limited manner on the vulnerable component upon successfully exploiting the vulnerability. Attackers do not have control over the consequence of a modification, and the vulnerable component does not get seriously affected in this case.
- High (H): Attackers can modify all or critical data on the vulnerable component upon successfully exploiting the vulnerability. Attackers have control over the consequence of a modification, and the vulnerable component will experience a total loss of integrity.
Availability
Shows how much the vulnerable component's availability is affected upon successfully exploiting the vulnerability. Availability refers to the accessibility of information resources in terms of network bandwidth, disk space, processor cycles, etc.
- None (N): The availability of the vulnerable component does not get impacted.
- Low (L): The vulnerable component will experience some loss of availability upon successfully exploiting the vulnerability. The attacker does not have complete control over the vulnerable component's availability and cannot deny the service to users, and performance is just reduced.
- High (H): The vulnerable component will experience total (or severe) availability loss upon successfully exploiting the vulnerability. The attacker has complete (or significant) control over the vulnerable component's availability and can deny the service to users. Performance is significantly reduced.
Examples
Find below some examples of using CVSS 3.1 to communicate the severity of vulnerabilities.
Good Report Examples
Find below some good report examples selected by HackerOne:
- SSRF in Exchange leads to ROOT access in all instances
- Remote Code Execution in Slack desktop apps + bonus
- Full name of other accounts exposed through NR API Explorer (another workaround of #476958)
- A staff member with no permissions can edit Store Customer Email
- XSS while logging in using Google
- Cross-site Scripting (XSS) on HackerOne careers page
Please refer to the Submitting Reports section of HackerOne's docs portal for the actual process a bug bounty hunter has to follow to submit a bug report.