How to remediate – Subdomain Takeover

1. Introduction

Subdomain Takeover is a vulnerability where an attacker gains control of a subdomain, potentially redirecting traffic and impersonating legitimate services. This can damage brand reputation, steal sensitive information, and disrupt service availability. It typically affects web applications that use third-party services configured with DNS records.

2. Technical Explanation

A Subdomain Takeover occurs when a DNS record pointing to a third-party service is removed from that service but remains in the target domain’s DNS zone. If an attacker creates an account on the same third-party service, they can then control the subdomain associated with that record. This allows them to host malicious content or redirect users to phishing sites.

• Exploit mechanism: An attacker identifies an orphaned DNS record, creates an account on the associated third-party service, and configures their own content for that subdomain. For example, if blog.example.com points to a defunct blogging platform, an attacker can claim it and host a fake blog.
• Scope: Any domain using third-party services with CNAME or NS records is potentially affected.

3. Detection and Assessment

Confirming vulnerability involves checking DNS records against active service configurations. A quick check identifies potential issues, while thorough methods verify control.

• Quick checks: Use dig to list all subdomains and then manually check if they resolve to an expected service.
• Scanning: Tools like subfinder or online subdomain enumeration services can identify subdomains for review. These are examples only, results require manual verification.
• Logs and evidence: DNS logs may show queries for orphaned subdomains. Reviewing web application provisioning documentation can reveal third-party service dependencies.

dig example.com ANY

4. Solution / Remediation Steps

Fixing this issue requires removing the incorrect DNS records and improving the web application provisioning process.

4.1 Preparation

• Ensure you have access to modify your domain’s DNS settings. A roll back plan involves restoring the original DNS records from the backup.
• Change windows may be needed for larger deployments, requiring approval from relevant IT teams.

4.2 Implementation

1. Step 1: Remove the DNS record (CNAME or NS) associated with the vulnerable subdomain from your DNS zone file.
2. Step 2: Verify that the change has propagated by using a tool like dig to confirm the record is no longer present.
3. Step 3: Review web application provisioning documentation and processes for similar configurations.

4.3 Config or Code Example

Before

blog CNAME defunct-blogging-platform.com.

After

; Remove blog record - no longer in use

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Least privilege access to DNS records limits the impact if an account is compromised.
• Practice 2: Regular review of DNS configurations ensures orphaned records are identified and removed promptly.

4.5 Automation (Optional)

# Example Bash script to check for orphaned DNS records
#!/bin/bash
domain="example.com"
subdomains=$(dig $domain ANY | grep NAME | awk '{print $5}' | sort -u)
for subdomain in $subdomains; do
  if ! dig +short $subdomain A >/dev/null 2>&1; then
    echo "Warning: Subdomain $subdomain may be orphaned"
  fi
done

5. Verification / Validation

Confirm the fix by verifying DNS records and testing service access.

• Post-fix check: Run dig subdomain.example.com ANY. The output should not resolve to any active IP address or third-party service.
• Re-test: Re-run the initial dig command to confirm the record is no longer present in DNS.
• Smoke test: Access other services on the domain (e.g., www.example.com) to ensure they are still functioning correctly.
• Monitoring: Monitor DNS logs for unexpected queries related to the affected subdomain.

dig blog.example.com ANY

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update security baselines to include regular DNS record reviews as a standard practice.
• Asset and patch process: Implement a clear process for decommissioning third-party services, including immediate DNS record removal.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the original DNS zone file from your backup if any issues occur.

8. References and Resources

• Vendor advisory or bulletin: Not applicable in this case, as it is a configuration issue.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2019-6945
• Product or platform documentation relevant to the fix: https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers