How to remediate – Attack Surface Discovery

1. Introduction

Attack Surface Discovery identifies DNS records and subdomains associated with your internet-facing domains. This vulnerability helps attackers map your external infrastructure, potentially revealing hidden services and weaknesses. It primarily affects organisations using public DNS servers for their top level domains, impacting confidentiality by exposing information about internal systems.

2. Technical Explanation

This plugin passively collects publicly available DNS records to build a view of an organisation’s attack surface. There is no direct exploitation path; however, the discovered information can be used in reconnaissance attacks. The main precondition for this vulnerability is having public DNS records associated with your domains.

• Root cause: Publicly accessible DNS records exist for a domain.
• Exploit mechanism: An attacker queries DNS servers to enumerate subdomains and related services, building a map of the target’s infrastructure. For example, an attacker could use tools like `dig` or `nslookup` to identify potential targets.
• Scope: Any organisation with publicly registered domains is affected.

3. Detection and Assessment

You can confirm exposure by manually querying DNS records for your domain. A thorough method involves using a dedicated reconnaissance tool.

• Quick checks: Use the `dig` command to query for subdomains. For example, `dig yourdomain.com`.
• Scanning: Tools like Amass (https://github.com/OWASP/Amass) can be used to discover subdomains. This is an example only.
• Logs and evidence: DNS server logs may show queries for your domain from unknown sources, though this is not specific to this vulnerability.

dig yourdomain.com

4. Solution / Remediation Steps

The following steps aim to reduce the attack surface by minimising unnecessary DNS records and subdomains.

4.1 Preparation

• Backups are not required for this vulnerability. No services need to be stopped.
• Dependencies: Access to your domain registrar or DNS provider is needed. Roll back involves reverting any changes made to DNS records.
• Change window needs and approval may depend on the size of your organisation and change control policies.

4.2 Implementation

1. Step 1: Review all existing DNS records for your domain, identifying any unnecessary or outdated entries.
2. Step 2: Remove any identified unnecessary subdomains or records from your DNS configuration.
3. Step 3: Ensure that wildcard DNS records are used cautiously and only when necessary.

4.3 Config or Code Example

Before

# Example DNS record with unnecessary subdomain
*.testdomain.com.  IN A 192.0.2.1

After

# Unnecessary subdomain removed
testdomain.com. IN A 192.0.2.1

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help reduce the attack surface and mitigate risks associated with this vulnerability type.

• Practice 1: Least privilege – limit access to DNS configuration to only authorised personnel.
• Practice 2: Regular review – periodically audit DNS records for unnecessary or outdated entries.

4.5 Automation (Optional)

Automation scripts can be used to scan and identify potentially problematic DNS records, but manual verification is still recommended.

#!/bin/bash
# Example script to list all DNS records for a domain
domain="yourdomain.com"
dig +short $domain | sort -u

5. Verification / Validation

Confirm the fix by re-running the initial detection methods and verifying that unnecessary subdomains have been removed.

• Post-fix check: Run `dig yourdomain.com` and confirm that only expected subdomains are listed.
• Re-test: Re-run a subdomain enumeration tool like Amass to verify the reduction in discovered subdomains.
• Monitoring: Monitor DNS server logs for unexpected queries or changes to DNS records as an example alert.

dig yourdomain.com

6. Preventive Measures and Monitoring

Regularly reviewing and updating security baselines can help prevent this issue.

• Baselines: Update a security baseline to include regular DNS record audits as an example control.
• Pipelines: Integrate subdomain enumeration tools into CI/CD pipelines to identify new or unexpected subdomains.
• Asset and patch process: Implement a regular asset inventory process to track all internet-facing assets, including domains and subdomains.

7. Risks, Side Effects, and Roll Back

Removing necessary DNS records can cause service disruptions. Always test changes in a non-production environment first.

• Roll back: Revert any changes made to the DNS configuration if issues arise.

8. References and Resources

Links only to sources that match this exact vulnerability. Use official advisories and trusted documentation. Do not include generic links.

• Vendor advisory or bulletin: Not applicable for this general issue.
• NVD or CVE entry: Not applicable for this general issue.
• Product or platform documentation relevant to the fix: Your DNS provider’s documentation on managing DNS records.