Reward

BountyHall of fame

€100 Low €500 Medium €3,000 High €5,000 Critical €10,000

Program

Avg reward €2,212.85

Max reward €3,600

Scope1

Supported languagesEnglish

Hacktivity

Reports110

1st response < 1 day

Reports last 24h2

Reports last week6

Reports this month39

Program description

Program activity

IMPORTANT

Read the full fine scope for this project. This program is about the BIND 9 source code only. Every report is evaluated by a human with deep understanding of DNS protocol and deep understanding of the BIND 9 source code. If your report is wildly out of scope, e.g. reporting issues in something that isn't BIND 9 source code, you will be given negative points immediately, e.g. your report will be marked as "Out of Scope".

About this project

BIND 9 is widely used open-source DNS server software maintained by the Internet Systems Consortium (ISC). ISC is a non-profit dedicated to providing open source software and services in support of Internet infrastructure. We are committed to a borderless Internet that is open, safe and free, allowing users to protect their own data and privacy.

BIND 9 supports authoritative and recursive DNS, DNSSEC, and a range of DNS protocols. BIND 9 is deployed globally across critical infrastructure, enterprises, and service providers, making its security a high priority. Since our interfaces and source code are publicly documented and exposed, we rely on strong authentication, crypto implementations and do not support the concept of security by obscurity.

At the same time, we have some expectations for operators to maintain some security best practices. These are outlined https://bind9.readthedocs.io/en/stable/chapter7.html. If anything that should not be exposed to the Internet is exposed to the Internet, that is not a software vulnerability. In addition, we consider DNSSEC and DNS Cookies to be industry standards/best practices to secure DNS traffic: rewards will be lower for attacks that require disabling these features.

For this program you need to install our software on your premises for research.

The list of CVEs in BIND 9 that we recently published is available here: https://kb.isc.org/docs/aa-00913

Our priorities are to find:

RCE
Remote crash, such as a packet-of-death
Remote DoS (using just a few queries - example see the [https://www.athene-center.de/en/keytrap](KeyTrap attack)
Remote DoS (requires sustained high level of traffic).

About the scope

Where to find our code

This program is limited to BIND 9's latest stable version which can be found [https://gitlab.isc.org/isc-projects/bind9](in ISC's Gitlab repository). Source code is posted on [https://www.isc.org/download](ISC's Downloads page) and packages built by ISC may be found here: https://packages.sury.org, https://launchpad.net/~isc/+archive/ubuntu/bind, https://copr.fedorainfracloud.org/coprs/isc/bind. Both ISC's source code and the packages we produce are in scope.

There are many other versions and packages available from third parties: we will only consider issues that are reproducible with software provided by ISC.

There are some basic requirements for a secure deployment outlined here: https://bind9.readthedocs.io/en/v9.20.12/chapter7.html in section 7.1. If anything that should not be exposed to the Internet is exposed to the Internet, that is not a software vulnerability.

If a non-standard/uncommon configuration is required in order to be vulnerable, then the reward would be lower.

We consider DNSSEC and DNS Cookies to be industry standards/best practices to secure DNS traffic: rewards will be lower for attacks that require disabling these features.

Additionally, we are only interested in attacks:

that are possible over the Internet (attacks over local network are not interesting as you can just exhaust the link).
that are worse than a simple pseudo-random sub-domain attack
that are specific to BIND 9 implementation: while attacks on the whole DNS protocol are certainly interesting, they are out of the scope of this Bug Bounty program

If the issue only affects development version, it will not be treated as a security issue (no CVE, no private handling), and the reward would be lower.

Documentation

You may find our project documentation [https://bind9.readthedocs.io](on ReadtheDocs).
The list of published CVEs in BIND 9 is available https://kb.isc.org/docs/aa-00913
ISC's disclosure process is described https://kb.isc.org/docs/aa-00861.
Guidelines for CVSS scoring for BIND 9 are https://kb.isc.org/docs/isc-cvss-scoring-guidelines.

Specific exclusions

There are some basic requirements for a secure deployment outlined https://bind9.readthedocs.io/en/stable/chapter7.html.

If anything that should not be exposed to the Internet is exposed to the Internet, that is not a software vulnerability.

If a non-standard/uncommon configuration is required in order to be vulnerable, then the reward will be lower.

We consider DNSSEC and DNS Cookies to be industry standards/best practices to secure DNS traffic: rewards will be lower for attacks that require disabling these features.

DNS records are intended to be published: leaking information that is intended for publication on the open Internet is not a vulnerability.

Program rules

If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue and ensure you are rewarded for your discovery through this program. ISC does not offer any other bug bounty except for this specific program for critical infrastructure, which is funded via the EU.
ISC follows a managed disclosure process which is described https://kb.isc.org/docs/aa-00861. We do not guarantee any specific fix timeline. The lead time can vary widely depending on, for example, whether we need to coordinate with other open source DNS developers. Note that per our process, we may not issue CVEs for security issues that score below 7.0 on the CVSS scale. Below 7.0 we use our discretion about whether to report a CVE.
Denial of service attacks on operators are strictly forbidden, as well as any interference with ISC's infrastructure.
You can set up a lab environment for your own research based on public software packages, containers and source-code. However, we will not accept reports which are specific to your lab's configuration and cannot be reproduced with the source code or packages published by ISC.

Moreover you must avoid :

Uploading, sending or injecting malware to ISC
Using data acquired by compromising customer or ISC staff accounts
Vulnerabilities which have already been reported to us (including reports received outside YesWeHack, for example from -customers or penetration tests) are considered as "Duplicate" in case they describe a similar attack type, regardless of which component is affected.

CVSS scoring guidelines

Due to the specific context of BIND9 we defined some guidelines for CVSS scoring that may be found in our https://kb.isc.org/docs/isc-cvss-scoring-guidelines.

About your report's content

To be eligible, your reports must include this information :

General description of the issue
Details about the impacted function and specific conditions to be met, including the vulnerable code snippet
Impacted version
If you have found a crash, we will need a full core dump, with the symbols for all the binaries and libraries.
A step by step proof of concept allowing to reliably reproduce the issue, including network exploitation
A video of the PoC, demonstrating the full exploitation
Recommendations and fix suggestions

A detailed template will be provided automatically when submitting a report, please stick to it. This will help us ensure a smooth and swift processing of your reports.

Reports that do not follow the template’s guidelines won’t be eligible for reward. Abuse may lead to further sanctions (e.g. spamming or repeated submission of invalid reports).

All reports must include screenshots, video(s), logs and evidence, that show the full exploitation on your end. Providing us with a script to run ourselves will be deemed insufficient. Reports that fail to present required evidence, will likely be rejected.

Testing Policy, Responsible Disclosure

Please adhere to the following rules while performing research on this program:

Denial of service (DoS) attacks on our applications, servers, networks or infrastructure are strictly forbidden
All reports must be validated manually, submission from automated tools won't be considered and may lead to sanctions (code analysis tools, AI, …)
Targeting other users' instances is forbidden, only test against your own
DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your PoC (screenshot, server response, JSON file, etc.) as much as possible.
Same with secrets, keys and credentials
No vulnerability disclosure, full, partial or otherwise, is allowed without prior agreement from us
Please avoid submitting security issues on our repositories before reporting it to this program, your report might be considered as a duplicate if a related submission already exists on our repositories

The following topics won’t be considered as a valid finding eligible for reward nonetheless, you’re welcome to suggest improvements about it through our repositories but not our bug bounty program :

Code improvements/code quality issues without security impact
Insecure default/basic configurations
Mistakes or lack of precision in our documentation

If what you have found is actually a weaknesses in the DNS protocol, rather than a defect in the BIND implementation only, we will need to coordinate with the other open source versions impacted.

Reward Eligibility

We are happy to thank everyone who submits valid reports which help us improve the security, however only those that meet the following eligibility requirements may receive a monetary reward:

You must be the first reporter of a vulnerability
You must not break any of the testing policy rules listed above
You must not be a former or current employee nor a maintainer of our project or one of its contractors
The vulnerability must be a qualifying vulnerability
Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through yeswehack.com
The report must contain the following elements:
Clear textual description of the vulnerability, along with steps to reproduce it, how it can be exploited, the security impact it has on the application, its users and the company, and remediation advice on fixing the vulnerability
Proof of exploitation: logs demonstrating the exploit was performed, and showing the final impact
Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands and configurations used.
Identical vulnerabilities present in different versions will be considered as a single issue/will warrant a single reward
Multiple vulnerabilities caused by one underlying issue will be considered as a single issue/will warrant a single reward

If you would like to be acknowledged when we publish the vulnerability, please indicate your name and affiliation, if you wish to include an affiliation.

Reward amounts are based on:

Reward grid of the report's scope
CVSS scoring and actual business impact of the vulnerability upon performing risk analysis

Reward

Systemic issues

1st report100% 2nd report100% 3rd report75% 4th report50% 5th report25% 6th+ report10%

In the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program’s scope and policy. To summarize our policy, you may refer to the below table:

More info

Scopes

Medium €3,000

High €5,000

Critical €10,000

Out of scopes

gitlab.isc.org
lists.isc.org
Any asset that is not explicitly included in our program's scope
Any third parties’ or Community’s assets (e.g. packages or versions not created and published by ISC).
Any depreciated versions and other versions than the current stable/official version are considered out of scope.
Any local implementation of the project/implementation belonging to third parties
Vulnerabilities in the DNS protocol that are not specific to the BIND 9 implementation (while we are interested in these, they are out of scope of this Bug Bounty program).

Vulnerability types

Qualifying vulnerabilities

SQL Injection (SQLi)
Cross-Site Scripting (XSS)
Remote Code Execution (RCE)
Insecure Direct Object Reference (IDOR)
Horizontal and vertical privilege escalation
Authentication bypass & broken authentication
Business Logic Errors vulnerability with real security impact
Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
Cross-Origin Resource Sharing (CORS) with real security impact
Cross-site Request Forgery (CSRF) with real security impact
Open Redirect
Cryptographic flaws (e.g. using insecure crypto primitives, insufficient randomness, incorrect handling of keys, …)
Memory corruption or safety issues (e.g. use-after-free, double free, aliasing, out-of-bounds access, …)
Missing validations of untrusted inputs (e.g. injection of unescaped markup in output, following untrusted symlinks, …)
Undefined behavior leading to a security vulnerability (e.g. integer overflow)
Race conditions (e.g. time-of-check-to-time-of-use races on file system checks)

Non-qualifying vulnerabilities

Vulnerabilities previously reported to ISC (whether or not they have yet been patched or published)
Denial of Service (DoS) attacks that amplify traffic by <100x
Previously disclosed CVEs
CVEs without exploitable vulnerabilities and PoC
Open ports or services without exploitable vulnerabilities and PoC
Vulnerabilities affecting only outdated operating systems or platforms
Attacks that are only possible via the local (directly attached) network
Attacks that crashes server by loading crafted zone file on the primary DNS server (e.g. local attack)
Disclosure of information without exploitable vulnerabilities and PoC (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets, EXIF Metadata, Origin IP)
Physical or social engineering attempts
Recently disclosed 0-day vulnerabilities (less than 30 days ago)
Reports for outdated versions of our software (more than two minor versions old)
Findings that do not have impact on availability, confidentiality or integrity
Reports from automated vulnerability scanners (Acunetix, Vega, Burp, Nessus, etc.) that have not been validated
Vulnerabilities which have been made possible by purposely weakening the default configuration while using authorized privileged access
Vulnerabilities of third-part components, websites or DNS configuration
Vulnerabilities which are purely hypothetical or already publicly known or variations of such, including vulnerabilities that are made possible by exploiting another reported vulnerability
Stolen secrets, credentials or information gathered from a third-party asset that we have no control over
Exposed secrets, credentials or information on an asset under our control that are not applicable to the program scope
Any hypothetical flaw or best practices without exploitable vulnerabilities and PoC
SSL/TLS issues (e.g. expired certificates, best practices)
Unexploitable vulnerabilities
Reports with attack scenarios requiring MITM or physical access to victim's device
Missing security-related HTTP headers which do not lead directly to an exploitable vulnerability and PoC
Low severity Cross-Site Request Forgery (CSRF) (e.g. Unauthenticated / Logout / Login / Products cart updates...)
Session management issues (e.g. lack of expiration, no logout on password change, concurrent sessions)
Blind SSRF without exploitable vulnerabilities and PoC (e.g. DNS & HTTP pingback, Wordpress XMLRPC)
Lack or bypass of rate-limiting
Exploits that rely on non standard configurations too distant from normal use cases or official recommendations
Exploits that rely on a voluntarily downgraded configuration

Reports of leaks and exposed credentials

More info

Type of leak Source of leak is in-scope Source of leak belongs to the Organization and is out-of-scope Source of leak does not belong to the Organization and is out-of-scope

Impact is in-scope (e.g. valid credentials on an in-scope asset) Eligible Not eligible Not eligible

Impact is out-of-scope (e.g. valid credentials for an out-of-scope asset) Not eligible Not eligible Not eligible

Hunters collaboration

When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.

For more information, see [https://helpcenter.yeswehack.io/hunter/hunter-collaboration](help center). Note: For reports that have already been rewarded, it is not possible to redistribute the rewards.

To submit a vulnerability report, you need to login with your hunter account. /programs/bind-bug-bounty-program/create-report