BIND 9 Bug Bounty Program
Bounty Range
$100 - $10,000
external program
Bounty Range
$100 - $10,000
external program
BountyHall of fame
€100 Low €500 Medium €3,000 High €5,000 Critical €10,000
Avg reward €2,212.85
Max reward €3,600
Scope1
Supported languagesEnglish
Reports110
1st response < 1 day
Reports last 24h2
Reports last week6
Reports this month39
Program description
Program activity
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".
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).
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.
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.
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.
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.
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.
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.
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.
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
Asset value | CVSS Low | CVSS Medium | CVSS High | CVSS Critical | Medium | €500 | €3,000 | €5,000 | €10,000 |
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
Scope | Type | Asset value | Expand rewards grid | https://gitlab.isc.org/isc-projects/bind9 | Open Source | Medium | | Low €500
Medium €3,000
High €5,000
Critical €10,000
|
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
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
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