BIND 9 Bug Bounty Program

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 here. 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:

1. RCE
2. Remote crash, such as a packet-of-death
3. Remote DoS (using just a few queries - example see the KeyTrap attack
4. 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 in ISC's Gitlab repository. Source code is posted on ISC's Downloads page and packages built by ISC may be found here: Debian, Ubuntu, RHEL/Fedora. 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:

1. that are possible over the Internet (attacks over local network are not interesting as you can just exhaust the link).
2. that are worse than a simple pseudo-random sub-domain attack
3. 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

Documentation

• You may find our project documentation on ReadtheDocs.
• The list of published CVEs in BIND 9 is available here
• ISC's disclosure process is described here.
• Guidelines for CVSS scoring for BIND 9 are here.

Specific exclusions

There are some basic requirements for a secure deployment outlined here.
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 here. 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 documentation.

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
• 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).

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