How to remediate – Exclude top-level domain wildcard hosts

1. Introduction

This plugin prevents scanning of top-level domain wildcard hosts. These hosts have IP addresses that are known to be a wildcard record for a top-level domain (TLD) or within the ‘nessus.org’ domain, and have been blacklisted from scans. This can prevent accurate vulnerability assessments as these hosts will not be checked for weaknesses. A successful scan bypass could lead to undetected vulnerabilities on critical systems. Confidentiality, integrity, and availability may all be impacted if a system behind a wildcard record is compromised due to an unpatched vulnerability.

2. Technical Explanation

The vulnerability occurs because Nessus attempts to scan hosts that resolve to top-level domain wildcard records. These records indicate that any subdomain of the TLD should resolve to the same IP address, and scanning them can lead to inaccurate results or unexpected behaviour. The plugin blacklists these hosts to avoid this issue. There is no direct exploit path; rather, it’s a prevention against potentially misleading scan data.

• Root cause: Nessus scans wildcard DNS records without specific exclusion rules.
• Exploit mechanism: An attacker could control a subdomain within the TLD and host malicious content or services that would be missed by a scan if the blacklist is bypassed.
• Scope: Systems using top-level domain wildcard DNS records, particularly those managed through common DNS providers.

3. Detection and Assessment

Confirming whether a system is affected involves checking its DNS configuration for wildcard entries. A thorough method would involve reviewing the entire DNS zone file.

• Quick checks: Use nslookup or dig to check if subdomains resolve to the same IP address as the main domain.
• Scanning: Nessus itself will flag these hosts during a scan, indicating they are excluded due to being wildcard records.
• Logs and evidence: Review DNS server logs for queries related to subdomains of the affected TLD.

nslookup example.com
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   example.com
Address: 192.0.2.1
Name:   *.example.com
Address: 192.0.2.1

4. Solution / Remediation Steps

The solution involves ensuring the correct name or IP address is entered when configuring scans in Nessus. This prevents scanning of blacklisted wildcard hosts.

4.1 Preparation

• Backups are not required for this fix, as it relates to scan configuration. No services need to be stopped.
• Dependencies: Ensure you have access to the Nessus scanner and appropriate permissions to modify scan configurations. Roll back is simple – correct any incorrect entries in the scan settings.
• Change window needs are minimal; however, approval may be required depending on internal change management policies.

4.2 Implementation

1. Step 1: Log into the Nessus scanner web interface.
2. Step 2: Navigate to the scan configuration settings for the affected scan.
3. Step 3: Verify that the target hostnames or IP addresses are entered correctly, without any wildcard characters.
4. Step 4: Save the updated scan configuration.

4.3 Config or Code Example

Before

*.example.com

After

example.com

4.4 Security Practices Relevant to This Vulnerability

Input validation is a key practice relevant to this vulnerability type. Ensuring that only valid and expected input is used in scan configurations prevents unintended behaviour, such as scanning blacklisted hosts. Least privilege can also reduce the impact if an attacker were able to bypass the blacklist.

• Practice 1: Input validation to block unsafe or incorrect data from being entered into system settings.
• Practice 2: Least privilege to limit the scope of any potential scan errors or misconfigurations.

4.5 Automation (Optional)

Automation is not directly applicable for this specific vulnerability, as it relates to manual configuration within Nessus.

5. Verification / Validation

Confirm the fix by re-running the scan and verifying that the blacklisted hosts are no longer flagged as excluded. A simple service smoke test would involve checking if other valid targets within the same network are scanned successfully.

• Post-fix check: Re-run the Nessus scan; confirm that wildcard hosts are not listed in the results or are scanned without exclusion messages.
• Re-test: Run a new scan with corrected target configuration and verify no exclusions are reported.
• Smoke test: Verify other systems within the network are still scanned as expected, confirming the change did not impact valid targets.
• Monitoring: Review Nessus scan logs for any unexpected exclusion messages or errors related to DNS resolution.

nslookup example.com
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   example.com
Address: 192.0.2.1

6. Preventive Measures and Monitoring

For example, update security baselines to include checks for valid DNS configurations. Implement input validation in any systems that accept hostnames or IP addresses as configuration parameters. A sensible patch cycle should be maintained for Nessus itself to ensure the latest fixes are applied.

• Baselines: Update a security baseline or policy to enforce correct DNS configuration and prevent wildcard entries where not required.
• Pipelines: Add checks in CI/CD pipelines to validate hostnames and IP addresses used in infrastructure code.
• Asset and patch process: Maintain a regular review cycle for Nessus updates and apply patches promptly.

7. Risks, Side Effects, and Roll Back

There are minimal risks associated with this fix, as it relates to scan configuration only. Incorrectly configured scans may lead to incomplete vulnerability assessments. Roll back involves correcting any incorrect entries in the Nessus scan settings.

• Roll back: Navigate to the affected scan configuration in Nessus and correct any invalid entries. Save the updated settings.

8. References and Resources

• Vendor advisory or bulletin: https://www.tenable.com/plugins/nessus/plugin-details?id=16832
• NVD or CVE entry: Not applicable, as this is a preventative measure within Nessus itself.
• Product or platform documentation relevant to the fix: https://docs.tenable.com/nessus/Content/ConfigureScanTargets.htm