How to remediate – DNS Server BIND version Directive Remote Version Detection

1. Introduction

The DNS Server BIND version Directive Remote Version Detection vulnerability allows attackers to obtain the version number of a remote DNS server. This information can be used to identify vulnerable systems and target them with specific exploits. Affected systems are typically those running BIND or other DNS servers configured to respond to version queries. A successful exploit could lead to information disclosure, potentially impacting confidentiality.

2. Technical Explanation

The vulnerability occurs because BIND, by default, reports its version number when receiving a special request for the text ‘version.bind’ in the ‘chaos’ domain. This response is not necessarily accurate and can be forged if configured to do so. An attacker could send a DNS query requesting the TXT record for ‘version.bind.chaos’ to reveal the server’s version information.

• Root cause: BIND reports its version number in response to specific DNS queries by default.
• Exploit mechanism: An attacker sends a DNS query for ‘version.bind.chaos’ and analyzes the response. For example, an attacker could use nslookup or dig to send the query.
• Scope: BIND versions prior to those with the fix implemented are affected. Other DNS servers may also be vulnerable if similarly configured.

3. Detection and Assessment

You can confirm whether a system is vulnerable by checking its DNS server configuration and testing for version reporting. A quick check involves querying the DNS server directly, while thorough assessment requires examining the named.conf file.

• Quick checks: Use dig chaos txt version.bind to query the DNS server. If a TXT record is returned containing version information, the system is likely vulnerable.
• Scanning: Nessus ID 16829 or OpenVAS scan can identify this vulnerability. These are examples only and may require updates.
• Logs and evidence: Examine DNS query logs for requests to ‘version.bind.chaos’.

dig chaos txt version.bind

4. Solution / Remediation Steps

The issue can be fixed by hiding the version number of BIND using the ‘version’ directive in the ‘options’ section of named.conf.

4.1 Preparation

• Ensure you have access to edit the named.conf file and restart the DNS service. A roll back plan is to restore the backed-up named.conf file.
• A change window may be required depending on your organization’s policies. Approval from a system administrator might be needed.

4.2 Implementation

1. Step 1: Open the named.conf file in a text editor.
2. Step 2: Add the line ‘version “none”;’ within the ‘options { … }’ section.
3. Step 3: Save the changes to the named.conf file.
4. Step 4: Restart the DNS service for the changes to take effect.

4.3 Config or Code Example

Before

options {
  directory "/var/cache/bind";
};

After

options {
  directory "/var/cache/bind";
  version "none";
};

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of vulnerability. Least privilege reduces the impact if exploited, and secure defaults minimize unnecessary exposure.

• Practice 1: Implement least privilege principles to limit access to DNS server configuration files.
• Practice 2: Use safe defaults whenever possible to reduce the attack surface.

4.5 Automation (Optional)

# Example Ansible snippet
- name: Hide BIND version number
  lineinfile:
    path: /etc/named.conf
    regexp: '^options {'
    insertafter: '^options {'
    line: '  version "none";'
  notify: Restart named service
handlers:
  - name: Restart named service
    service:
      name: named
      state: restarted

5. Verification / Validation

• Post-fix check: Run dig chaos txt version.bind. No TXT record containing version information should be returned.
• Re-test: Re-run the earlier detection method (dig chaos txt version.bind) to confirm that no version information is exposed.
• Smoke test: Verify that DNS resolution continues to function normally for other domains.
• Monitoring: Monitor DNS query logs for unexpected requests or errors.

dig chaos txt version.bind

6. Preventive Measures and Monitoring

Update security baselines to include the ‘version “none”;’ directive in BIND configurations. Implement CI/CD pipeline checks to enforce secure configuration settings.

• Baselines: Update your DNS server security baseline or policy to require the ‘version “none”;’ setting.
• Pipelines: Add a check in your CI/CD pipeline to ensure that named.conf files do not expose version information.
• Asset and patch process: Establish a regular review cycle for DNS server configurations, including checking for this vulnerability.

7. Risks, Side Effects, and Roll Back

The primary risk is potential disruption to DNS service if the configuration file is modified incorrectly. A roll back can be performed by restoring the backed-up named.conf file.

• Risk or side effect 1: Incorrectly modifying the named.conf file could cause DNS resolution failures.
• Risk or side effect 2: Restarting the DNS service may briefly interrupt DNS availability.
• Roll back: Restore the backed-up named.conf file and restart the DNS service.

8. References and Resources

• Vendor advisory or bulletin: ISC Knowledge Base Article AA-0583
• NVD or CVE entry: CVE-2001-0829
• Product or platform documentation relevant to the fix: BIND 9 Options Configuration