DNS Configuration

5 automated security scanners

Domain-based Security Policies

Purpose: The Domain-based Security Policies Scanner is designed to analyze DNS TXT records for domain-based authentication mechanisms such as SPF, DMARC, DKIM, and CAA. This tool aims to detect email spoofing vulnerabilities and certificate mis-issuance risks by evaluating the presence and configuration of these policies.

What It Detects:

SPF Record Analysis: The scanner queries DNS for TXT records containing SPF declarations, parses various mechanisms (ip4, ip6, include, mx, a), checks for dangerous qualifiers (+all, ?all), verifies the syntax validity, and flags overly permissive policies.
DMARC Policy Assessment: It examines _dmarc.{domain} TXT records to extract policy details like p=, sp=, and pct=. The scanner also checks for reject/quarantine enforcement, verifies reporting addresses (rua, ruf), and flags weak or monitoring-only policies.
DKIM Selector Detection: By testing common DKIM selectors, the tool queries DNS for public keys associated with DKIM and assesses their presence and validity, including key strength (1024-bit vs 2048-bit RSA).
CAA Record Validation: The scanner checks CAA records to ensure only authorized certificate authorities can issue certificates by parsing tags like issue, issuewild, and iodef. It flags missing or permissive records.

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com)

Business Impact: The absence or misconfiguration of these domain-based security policies can significantly compromise email security, making it easier for attackers to spoof emails and issue unauthorized certificates, thereby facilitating phishing attacks and other malicious activities.

Risk Levels:

Critical: Missing SPF records allow complete email spoofing, while missing DMARC leads to unrestricted use of the domain in phishing campaigns. Weak or non-existent CAA policies permit any CA to issue certificates.
High: Misconfigured SPF (e.g., using +all) and weak DMARC configurations can lead to similar outcomes as critical risks but are less severe due to specific conditions.
Medium: Missing DKIM selectors reduce email authentication effectiveness, which is a medium risk if the domain relies heavily on authenticated emails for business operations.
Low: Informal CAA policies might not directly impact security severely unless the organization frequently issues certificates or interacts with numerous CAs.
Info: Additional TXT records like mta-sts and _smtp._tls are informative about specific email delivery enhancements but do not pose immediate critical risks without proper configuration.

Example Findings:

A domain lacking an SPF record might be susceptible to email spoofing, allowing any sender to represent the domain.
DMARC policies set to “p=none” provide no enforcement and are highly vulnerable to phishing attacks due to lack of protection against unauthorized use of the domain name.
Inadequate CAA records can lead to unauthorized certificate issuance, potentially compromising security by allowing untrusted entities to issue certificates for the domain.

DNS Record Consistency

Purpose: The DNS Record Consistency Scanner is designed to validate the consistency of DNS records across authoritative nameservers. It aims to detect propagation issues, cache poisoning indicators, and zone transfer security gaps that could enable DNS-based attacks. By ensuring that all nameservers for a given domain have identical DNS record sets, TTL values, and SOA serial numbers, this scanner helps maintain the integrity and availability of DNS configurations.

What It Detects:

Nameserver Record Comparison: The scanner queries all authoritative nameservers for a domain to retrieve A, AAAA, MX, TXT records and compares these record sets across all nameservers, flagging any inconsistencies in responses.
TTL Consistency Check: It extracts TTL values for each record type and compares them across nameservers, flagging mismatches that could cause cache issues and identifying dangerously low or high TTL values.
SOA Serial Number Validation: The scanner queries the SOA record from all nameservers and compares serial numbers, flagging nameservers with outdated serial numbers and detecting zone transfer failures.
Record Completeness Assessment: It verifies whether all expected record types are present on all nameservers, flagging missing records on specific nameservers and identifying partial zone data.
Response Time Analysis: The scanner measures query response time from each nameserver and flags slow or unresponsive nameservers, potentially indicating DDoS or load issues.

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com)

Business Impact: DNS record inconsistencies can lead to availability and security vulnerabilities such as split-brain DNS, cache poisoning, unpredictable failover behavior, partial denial of service, and IPv4/IPv6 dual-stack issues. Ensuring the consistency of DNS records is crucial for maintaining a secure and reliable network infrastructure.

Risk Levels:

Critical: Different NS responses indicate split-brain DNS or cache poisoning.
High: TTL mismatches cause unpredictable failover behavior, missing records on some nameservers enable partial denial of service, and inconsistent A/AAAA records break IPv4/IPv6 dual-stack deployments.
Medium: Zone serial number mismatches indicate replication failures.
Low: Slow or unresponsive nameservers could be a sign of potential DDoS or load issues.
Info: Inconsistencies in DNS record types and TTL values can provide informational insights but generally do not pose significant risks unless they escalate into more critical issues.

Example Findings:

A domain configured with different NS records across its nameservers, which could be a sign of cache poisoning or split-brain DNS configuration.
Nameservers with significantly low TTL values might lead to rapid propagation of outdated information and potential security risks if not promptly corrected.

Purpose: The Cross-domain Cookie Controls Scanner is designed to analyze DNS and HTTP configurations in order to detect cross-domain cookie exposure vulnerabilities. This includes assessing the SameSite attribute implementation, identifying cookie security gaps that can enable CSRF (Cross-Site Request Forgery) and session hijacking attacks across domain boundaries.

What It Detects:

Cookie Attribute Analysis: The scanner makes HTTPS requests to a specified domain, extracts Set-Cookie headers, parses attributes such as SameSite, Secure, HttpOnly, Domain, and Path. It flags cookies with missing or misconfigured security attributes.
SameSite Implementation Check: This involves verifying the presence of the SameSite attribute in cookies, checking if it is set to Strict, Lax, or None, and flagging cookies with SameSite=None without the Secure flag, as well as identifying legacy cookies missing the SameSite attribute entirely.
Domain Scope Assessment: The scanner extracts the Domain attribute from cookies and checks for overly broad domain scoping (e.g., .example.com), identifies wildcard domain usage, and flags cookies accessible across unrelated subdomains.
Secure Flag Validation: This includes verifying that all HTTPS cookies have the Secure flag, flagging cookies missing this flag on HTTPS domains, and checking for mixed-content cookie exposure.
HttpOnly Flag Assessment: The scanner checks the HttpOnly flag on session/auth cookies, identifies JavaScript-accessible authentication tokens, and flags XSS (Cross-Site Scripting)-exploitable cookie configurations.

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com), which is the primary input required for the scanner to perform its analysis.

Business Impact: Improper cross-domain cookie controls can create significant authentication and session vulnerabilities, potentially leading to unauthorized access and data leakage across different domains. This poses a serious threat to the security of user sessions and sensitive information.

Risk Levels:

Critical: Cookies with missing SameSite attribute or cookies set with SameSite=None without the Secure flag pose a critical risk as they are highly susceptible to CSRF attacks from external sites.
High: Overly permissive Domain attributes (e.g., .example.com) and wildcard domain usage can lead to unauthorized data exposure across security boundaries, significantly compromising the integrity of user sessions.
Medium: Cookies missing the Secure flag on HTTPS domains are at risk of being intercepted via downgrade attacks, posing a medium severity threat.
Low: HttpOnly flag missing might not directly affect critical systems but still poses a risk for XSS-based cookie theft and should be addressed to enhance overall security posture.
Info: Informational findings such as mixed-content cookies that are exposed on HTTP can lead to potential vulnerabilities if accessed by unintended parties, though the risk is considered low due to the inherent security of HTTPS connections.

Example Findings:

“Cookie ‘session_id’ missing SameSite attribute” - This indicates a critical vulnerability where an attacker could exploit the cookie for CSRF attacks without requiring user interaction.
“Cookie ‘auth_token’ has overly broad domain scope” - A high severity issue that allows unauthorized access to authentication tokens across multiple subdomains, posing significant security risks.

Subdomain Takeover Vulnerability

Purpose: The Subdomain Takeover Vulnerability Scanner is designed to identify and assess vulnerabilities where dangling DNS records point to unclaimed cloud resources. This can lead to subdomain takeover, allowing attackers to claim abandoned infrastructure and serve malicious content on legitimate subdomains.

What It Detects:

Dangling CNAME Detection: The scanner queries all subdomains for CNAME records and checks if the targets exist and respond. It also tests for common takeover signatures such as “NoSuchBucket” errors or 404 patterns, identifying unclaimed CNAME destinations.
Cloud Service Provider Detection: By parsing CNAME targets, the scanner identifies specific cloud provider patterns including AWS (s3, cloudfront, elasticbeanstalk), Azure (azurewebsites, blob.core.windows.net), GitHub Pages (github.io), and others like Heroku, Shopify, Fastly.
Resource Availability Check: The scanner makes HTTP/HTTPS requests to subdomains, analyzes response codes and error messages, and looks for provider-specific 404 patterns or errors indicating resource unavailability.
A/AAAA Record Validation: It queries A and AAAA records for subdomains, checks if IPs are still allocated to the organization, performs reverse DNS to verify ownership, and tests HTTP connectivity to IP addresses.
Takeover Exploitability Assessment: The scanner classifies vulnerability severity, checks if a cloud resource can be claimed, verifies provider allowance for public resource creation, and calculates a takeover risk score.

Inputs Required:

domain (string): The parent domain to scan (e.g., ekkatha.com)

Business Impact: Subdomain takeovers pose a serious threat as they bypass domain reputation filters, potentially facilitating phishing attacks and serving malicious content under legitimate domains. This can lead to significant damage in terms of brand reputation and security risks.

Risk Levels:

Critical: CNAME pointing to an AWS S3 bucket that allows “NoSuchBucket” errors or a 404 status code indicates critical severity, as it directly enables subdomain takeover for malicious use.
High: DNS records pointing to deallocated cloud IPs or GitHub Pages that can be claimed indicate high risk, as they provide easy access points for attackers to hijack functionality.
Medium: Vulnerabilities with partial claims (e.g., Azure CNAMEs) are at medium risk, requiring immediate attention to prevent full takeover by unauthorized parties.
Low: Informational findings about subdomains that do not directly point to any known cloud provider or resources can be considered low risk unless they show signs of being easily exploitable.
Info: Any DNS configuration issues that do not pose an immediate threat but should still be monitored for potential changes are marked as informational.

Example Findings:

A subdomain “old-blog.ekkatha.com” has a CNAME record pointing to “myblog.s3.amazonaws.com”, which returns a “NoSuchBucket” error, indicating it can potentially be taken over by an attacker to serve malicious content under the blog domain.
Another example is a subdomain with an A record targeting an IP that has been deallocated, suggesting potential exposure for takeover or unauthorized use.

This scanner plays a crucial role in enhancing security posture by proactively identifying and mitigating risks associated with subdomain takeovers, ensuring that organizations can protect their digital assets effectively.

Domain Fronting Potential

Purpose: The Domain Fronting Potential Scanner is designed to detect potential vulnerabilities in DNS and CDN configurations that could be exploited for domain fronting attacks. These attacks involve masking traffic destinations by exploiting shared TLS certificates and Host header manipulation on CDN infrastructure, potentially enabling traffic obfuscation and censorship evasion.

What It Detects:

Shared Certificate Detection: The scanner retrieves the TLS certificate for a given domain and checks if it covers multiple unrelated domains. It also identifies CDN-issued wildcard certificates and flags those shared across customer domains.
CDN Infrastructure Identification: The scanner resolves the domain to its IP addresses, checks if these IPs belong to known CDN providers such as Cloudflare, AWS CloudFront, Akamai, or Fastly, and flags any shared CDN edge nodes.
Host Header Validation: The scanner makes HTTPS requests with mismatched Host headers to test if the server accepts arbitrary values. It also checks if the CDN forwards requests based on SNI (Server Name Indication) vs. Host header.
SNI Manipulation Testing: The scanner connects with valid SNI but incorrect Host headers to verify if TLS handshake succeeds despite the mismatch. It identifies weak Host header validation and flags any vulnerabilities that enable SNI-based fronting.
Reverse DNS Analysis: The scanner performs reverse DNS on resolved IPs to check for shared infrastructure indicators, particularly multi-tenant CDN endpoints.

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com)

Business Impact: Detecting and mitigating domain fronting vulnerabilities is crucial as it can lead to significant security risks, including traffic obfuscation that might bypass censorship or allow unauthorized access to sensitive information. This poses a threat to both data confidentiality and network integrity.

Risk Levels:

Critical: Conditions where the certificate covers multiple unrelated domains, servers accept arbitrary Host values without validation, or TLS handshake succeeds with mismatched SNI/Host values.
High: Conditions where IPs are shared with other domains and indicate multi-tenant CDN infrastructure.
Medium: Conditions where there is a potential for traffic obfuscation through domain fronting.
Low: Informative findings about the use of CDN providers like Cloudflare, AWS CloudFront, Akamai, or Fastly without evidence of shared certificates or misconfigured Host headers.
Info: General information about DNS resolution and SSL certificate retrieval processes.

Example Findings:

A domain using a TLS certificate that covers multiple unrelated domains might be susceptible to SNI-based fronting attacks where traffic can be redirected unknowingly by attackers.
A CDN provider like Akamai identified for an IP address shared with other domains could indicate a misconfiguration allowing host header manipulation and potential privacy risks.