How to remediate – PowerDNS Version Detection

1. Introduction

The PowerDNS Version Detection vulnerability allows an attacker to determine the version number running on a remote DNS server. This information can assist attackers in identifying known vulnerabilities within specific versions of PowerDNS, potentially leading to targeted attacks. Systems affected are typically those running publicly accessible PowerDNS instances, including authoritative and recursive servers. A successful exploit could lead to information disclosure, but does not directly impact confidentiality, integrity or availability.

2. Technical Explanation

PowerDNS is configured by default to respond to DNS requests for the ‘version.pdns’ text record in the ‘chaos’ domain with its version number. This allows anyone querying the server to identify the installed PowerDNS software. An attacker can use this information to search for public exploits or known weaknesses associated with that specific version.

• Root cause: The default configuration of PowerDNS exposes the version string via a DNS query.
• Exploit mechanism: An attacker sends a DNS request for ‘version.pdns’ in the ‘chaos’ domain to the target server and analyses the response. For example, using dig chaos TXT version.pdns.
• Scope: All PowerDNS installations are affected by default, regardless of platform or service type (authoritative or recursive).

3. Detection and Assessment

You can confirm if a system is vulnerable by checking for the exposed version string. A quick check involves querying the DNS server directly. More thorough assessment includes reviewing the PowerDNS configuration files.

• Quick checks: Use dig chaos TXT version.pdns to query the DNS server. If a version number is returned, the system is vulnerable.
• Scanning: Nessus plugin ID 162798 can detect this issue. Other scanners may have similar capabilities.
• Logs and evidence: Examine PowerDNS logs for queries related to ‘version.pdns’ in the ‘chaos’ domain. Log locations vary depending on configuration, but are often found in /var/log/syslog or dedicated PowerDNS log files.

dig chaos TXT version.pdns

4. Solution / Remediation Steps

To fix this issue, hide the version number of PowerDNS by modifying the configuration file.

4.1 Preparation

• The change is relatively simple and can be rolled back by restoring the original configuration file.
• A short maintenance window may be needed, depending on DNS cache propagation times. Approval from a senior IT administrator may be required.

4.2 Implementation

1. Step 1: Open the PowerDNS configuration file (pdns.conf for authoritative servers or recursor.conf for recursive servers) with a text editor.
2. Step 2: Add or modify the ‘version-string’ option to an empty string.
3. Step 3: Save the changes to the configuration file.
4. Step 4: Restart the PowerDNS service to apply the new configuration.

4.3 Config or Code Example

Before

version-string=PowerDNS Recursor 4.7.1

After

version-string=""

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of information disclosure. Least privilege limits the impact if an attacker gains information, and secure defaults reduce the need for manual configuration.

• Practice 1: Least privilege – restrict access to PowerDNS configuration files to only authorised personnel.
• Practice 2: Secure defaults – configure new installations with minimal exposed information by default.

4.5 Automation (Optional)

Ansible can be used to automate the configuration change across multiple servers.

---
- hosts: pdns_servers
  become: true
  tasks:
    - lineinfile:
        path: /etc/pdns/recursor.conf # Adjust path as needed
        regexp: '^version-string='
        line: 'version-string=""'
      notify: restart_pdns
  handlers:
    - name: restart_pdns
      service:
        name: pdns
        state: restarted

5. Verification / Validation

Confirm the fix by querying the DNS server again and verifying that no version number is returned. A service smoke test ensures basic DNS resolution still works.

• Post-fix check: Run dig chaos TXT version.pdns. The query should return an empty response or a ‘no such domain’ error.
• Re-test: Re-run the initial detection method (dig chaos TXT version.pdns) to confirm that no version information is exposed.
• Smoke test: Verify basic DNS resolution by querying a known hostname, for example dig google.com A.

dig chaos TXT version.pdns

6. Preventive Measures and Monitoring

Regularly update security baselines to include this configuration setting. Consider adding checks in your CI/CD pipeline to prevent accidental exposure of sensitive information.

• Baselines: Update your security baseline or policy to require ‘version-string=””‘ in PowerDNS configurations.
• Pipelines: Add a check during deployment to ensure the ‘version-string’ option is set correctly in pdns.conf or recursor.conf.
• Asset and patch process: Review PowerDNS configuration changes as part of your regular asset management and patching cycle.

7. Risks, Side Effects, and Roll Back

Changing the version string should not cause any service disruption. However, it may make troubleshooting more difficult if you need to identify the exact PowerDNS version running on a server.

• Risk or side effect 1: Reduced visibility into PowerDNS versions across your infrastructure.
• Roll back: Restore the original pdns.conf or recursor.conf file and restart the PowerDNS service.

8. References and Resources

• Vendor advisory or bulletin: PowerDNS Documentation – version-string
• NVD or CVE entry: No specific CVE is associated with this information disclosure, as it’s a configuration issue rather than a code flaw.
• Product or platform documentation relevant to the fix: PowerDNS Recursor Configuration