How to remediate – NSD version Directive Remote Version Disclosure

1. Introduction

The NSD version Directive Remote Version Disclosure vulnerability allows an attacker to obtain the version number of a remote DNS server running Name Server Daemon (NSD). This information can aid attackers in identifying known vulnerabilities within specific versions, potentially leading to targeted attacks. Systems affected are typically those running open source DNS servers based on the NSD software. A successful exploit could lead to information disclosure, impacting confidentiality.

2. Technical Explanation

The vulnerability occurs because NSD exposes its version number through a specially crafted DNS request. An attacker can send a query for ‘version.bind’ in the ‘chaos’ domain and receive a response containing the server’s version information. There is no known CVE associated with this specific disclosure, but it represents a general risk of information leakage. An example attack involves using a tool like dig to query the DNS server directly.

• Root cause: NSD does not disable or hide its version number by default.
• Exploit mechanism: An attacker sends a DNS request for ‘version.bind’ in the ‘chaos’ domain and parses the response for the version string. Example payload: dig chaos version.bind
• Scope: Affected platforms are those running Name Server Daemon (NSD) versions prior to configuration changes to hide the version number.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking the server’s response to a specific DNS query. A quick check involves querying the server directly, while thorough assessment requires analysing DNS responses.

• Quick checks: Use dig chaos version.bind and examine the output for a version string in the ANSWER section.
• Scanning: Nessus plugin ID 16539 can identify this issue as an example.
• Logs and evidence: Examine DNS server logs for requests to ‘version.bind’ in the ‘chaos’ domain.

dig chaos version.bind

4. Solution / Remediation Steps

The issue can be fixed by configuring NSD to hide its version number. The following steps provide a precise guide to achieve this.

4.1 Preparation

• Back up the nsd.conf file before making any changes. Stopping the DNS service is not required, but restarting it after configuration is necessary.
• Ensure you have access to edit the NSD configuration file and restart the DNS service. A roll back plan involves restoring the original nsd.conf file.
• A standard change window may be appropriate depending on your organisation’s policies.

4.2 Implementation

1. Step 1: Open the nsd.conf configuration file in a text editor.
2. Step 2: Add the line hide-version: yes to the server section of the file.
3. Step 3: Save the changes to the nsd.conf file.
4. Step 4: Restart the NSD service to apply the new configuration. For example, use systemctl restart nsd or equivalent for your system.

4.3 Config or Code Example

Before

server {
  # Other server settings...
}

After

server {
  hide-version: yes
  # Other server settings...
}

4.4 Security Practices Relevant to This Vulnerability

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

• Practice 1: Least privilege – limit access to DNS configuration files to only authorised personnel.
• Practice 2: Secure defaults – configure software with the most restrictive settings possible by default.

4.5 Automation (Optional)

# Example Ansible snippet - use with caution!
- name: Hide NSD version number
  lineinfile:
    path: /etc/nsd/nsd.conf
    insertafter: '^server {'
    line: ' hide-version: yes'
  notify: Restart NSD

5. Verification / Validation

Confirm the fix by checking that the version number is no longer exposed through DNS queries. A negative test involves attempting to retrieve the version information again.

• Post-fix check: Run dig chaos version.bind and verify that the output does not contain a version string in the ANSWER section.
• Re-test: Re-run the earlier detection (dig chaos version.bind) to confirm the issue is resolved.
• Monitoring: Monitor DNS server logs for unexpected requests or errors, as an example.

dig chaos version.bind

6. Preventive Measures and Monitoring

Updating security baselines and incorporating checks into CI/CD pipelines can help prevent similar issues in the future. A regular patch review cycle is also sensible.

• Baselines: Update your DNS server baseline to include the hide-version: yes setting.
• Pipelines: Add a check in your CI or deployment pipeline to verify that the configuration file contains this setting.
• Asset and patch process: Implement a regular review cycle for DNS server configurations, at least quarterly.

7. Risks, Side Effects, and Roll Back

The change is unlikely to cause service disruption but should be tested thoroughly. Rolling back involves restoring the original configuration file.

• Roll back: Restore the original nsd.conf file and restart the NSD service.

8. References and Resources

• Vendor advisory or bulletin: https://www.nlnetlabs.nl/projects/nsd/about/