Domain Hierarchy Security

8 automated security scanners

Subdomain Trust Relationships

Purpose:
The Subdomain Trust Relationships Scanner is designed to analyze SSL/TLS certificate trust relationships between a parent domain and its subdomains. It aims to detect issues such as certificate scope mismatches, cross-subdomain certificate usage, and identify vulnerabilities in subdomain certificates.

What It Detects:

Parent-Subdomain Certificate Comparison: The scanner retrieves the SSL certificate for the parent domain and compares it with common subdomains (e.g., www, mail, api). It checks if the issuers across parent/subdomains are consistent.
Wildcard Certificate Usage Analysis: It detects whether the parent domain uses a wildcard certificate and verifies if the wildcard is properly covering all relevant subdomains.
Certificate Authority Consistency: The scanner extracts the CA for both the parent domain and each subdomain, flags inconsistencies where different CAs are used, identifies self-signed subdomain certificates, and detects breaks in the CA trust chain.
Subdomain Certificate Validity: It checks the expiration dates of all subdomain certificates, flags expired ones, and identifies subdomains with shorter validity compared to the parent domain.
SAN Coverage Assessment: The scanner parses the SAN entries of the parent certificate and verifies if all subdomains are included in the SAN field.

Inputs Required:

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

Business Impact:
Improper management of subdomain certificates can lead to trust boundary violations, which may enable lateral movement through shared wildcard certificates and increase the impact of a breach. This scanner helps in maintaining secure certificate practices that are critical for network security.

Risk Levels:

Critical: Subdomains using different CAs than the parent domain or self-signed subdomain certificates can lead to significant trust chain breaks, potentially compromising security boundaries.
High: Wildcard certificates not covering all necessary subdomains can result in incomplete coverage and potential unauthorized access through unmonitored subdomains.
Medium: Certificates expiring soon or having shorter validity periods than the parent domain may signal impending risks that could disrupt service continuity.
Low: Uncovered subdomains without proper certificate management are less likely to pose a direct threat but still indicate areas for improvement in security practices.
Info: Informational findings such as wildcard certificates not being used optimally or minor CA inconsistencies might be less critical but provide insights for better security posture.

Example Findings:

A subdomain using a different CA than the parent domain, indicating potential mismanagement of trust relationships.
Subdomains with self-signed certificates that are considered insecure in browser environments.

TLS Version Support Analysis

Purpose: The TLS Version Support Analysis Scanner is designed to evaluate the TLS (Transport Layer Security) version support of a given domain. It aims to ensure that the domain complies with security standards by identifying any insecure versions such as SSLv3, TLSv1, TLSv1.1, and ensuring the use of secure versions like TLSv1.2 and TLSv1.3.

What It Detects:

Supported TLS Versions: The scanner checks if the domain supports TLS version 1.2 and TLS version 1.3.
Insecure TLS Versions: It identifies if the domain supports SSL version 3, which is considered insecure due to its vulnerabilities. Additionally, it detects support for TLS version 1, TLS version 1.1, both of which are also deemed insecure.
Forward Secrecy: The scanner evaluates whether the domain supports TLSv1.3, a secure protocol that provides forward secrecy and enhances overall security.

Inputs Required:

Domain (string): This is the primary domain to be analyzed for its TLS version support. Users need to provide the domain name for accurate analysis.

Business Impact: Ensuring compliance with modern security standards, such as using secure versions of TLS and avoiding insecure protocols like SSLv3, is crucial for maintaining a robust security posture against potential exploits and vulnerabilities. This helps in mitigating risks associated with outdated or insecure network protocols.

Risk Levels:

Critical: The scanner flags the domain if it supports SSLv3 or any version of TLS below 1.2. These configurations are considered highly risky as they expose data to significant security threats.
High: If the domain only supports TLS versions 1.0, 1.1, or uses insecure protocols like SSLv3 without forward secrecy, it is flagged as having a high risk of compromising data integrity and confidentiality.
Medium: Support for older versions of TLS (below 1.2) but with forward secrecy can be considered medium risk if the domain does not exclusively use these less secure versions.
Low: If the domain supports only the latest stable version of TLS (TLSv1.3) and includes mechanisms like forward secrecy, it is flagged as having a low risk profile, indicating minimal exposure to known vulnerabilities in widely used protocols.
Info: Informational findings such as support for less commonly used but still secure versions of TLS might be reported at the informational level if they are not critical or high risks.

Example Findings:

A domain that exclusively supports SSLv3 and no higher version will be flagged with a critical risk, indicating severe security vulnerabilities.
A domain using only TLSv1.0 without forward secrecy might be considered medium-risk due to the lack of enhanced security features commonly found in more recent versions like TLSv1.2 and TLSv1.3.

Wildcard Certificate Risk

Purpose: The Wildcard Certificate Risk Assessment Scanner is designed to analyze wildcard certificates used in domains to identify potential security risks associated with overly broad certificate scopes, assess subdomain exposure, and detect improper deployment patterns of wildcard certificates. This tool helps organizations understand the security implications of using wildcard certificates and provides recommendations for improving their security posture.

What It Detects:

Wildcard Certificate Detection: The scanner retrieves SSL certificates for a given domain and parses the CN (Common Name) and SAN (Subject Alternative Name) fields to identify patterns like *.domain.com. It also flags multi-level wildcard attempts, which are not supported by many certificate authorities.
Wildcard Scope Assessment: It counts the subdomains covered by a wildcard certificate, enumerates known subdomains using the certificate, and calculates the potential impact of a private key compromise (the “blast radius”). Overly broad coverage (>10 subdomains) is flagged as risky.
Subdomain Enumeration: The scanner tests common subdomain patterns to verify which subdomains use wildcard certificates and identifies any dedicated certificates for those subdomains, helping map the distribution strategy of certificates across a domain’s hierarchy.
Security Boundary Violation Detection: It identifies production/staging/dev subdomains using the same wildcard certificate and flags situations where admin or internal subdomains are exposed on public wildcards, as well as cases where payment or sensitive subdomains share a wildcard certificate. This helps in assessing risks associated with cross-boundary exposure.
Certificate Sharing Analysis: It checks if multiple parent domains share a single wildcard certificate and detects SAN entries that mix wildcard and specific domain names, flagging improper combinations to prevent misuse.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com), which is the primary input for the scanner to analyze the security of its wildcard certificates.

Business Impact: Wildcard certificates, while offering convenience, can pose significant risks if not managed properly. They allow a single compromise to expose multiple subdomains simultaneously, potentially leading to unauthorized access and data breaches. This risk increases with the number of subdomains covered by a wildcard certificate and the sensitivity of those subdomains.

Risk Levels:

Critical: Overly broad wildcard certificates that cover more than 10 subdomains are critical risks as they significantly increase exposure without adequate security measures in place.
High: Wildcard certificates used for admin or internal subdomains, which should ideally have dedicated non-wildcard certificates to prevent unauthorized access to sensitive information.
Medium: Subdomains sharing a wildcard certificate with payment or sensitive data can be risky as they violate security boundaries and expose potentially valuable financial information.
Low: Informational findings about the use of multi-level wildcards that are not supported by many CA’s, which provide minimal security benefits but could lead to confusion in management practices.

Example Findings:

A wildcard certificate used for *.example.com covers 20 subdomains, significantly increasing the risk of unauthorized access to sensitive data across multiple departments within an organization.
An internal subdomain using a production wildcard exposes critical security risks by allowing lateral movement and potential theft of private keys from other subdomains.

This structured breakdown provides a clear understanding of what the Wildcard Certificate Risk Assessment Scanner detects and how it evaluates risk, helping users to prioritize actions based on the severity of identified issues.

Weak Cipher Suite Detection

Purpose:
The Weak Cipher Suite Detection Scanner is designed to identify and report on weak, deprecated, or insecure cipher suites supported by a domain’s TLS configuration. This scanner aims to detect vulnerabilities associated with cryptographic downgrade attacks and ensure compliance with modern security standards. By evaluating various aspects of the TLS configuration, including cipher suite enumeration, weak cipher detection, deprecated algorithm identification, forward secrecy assessment, and modern cipher compliance, users can gain insights into their network’s cryptographic posture and take appropriate action to enhance its security.

What It Detects:

Cipher Suite Enumeration: The scanner connects to the domain using different TLS versions to test each cipher suite for acceptance and enumerate all supported ones. It records the negotiated cipher for each attempt.
Weak Cipher Detection: This includes checking for NULL encryption ciphers, detecting EXPORT-grade ciphers (40/56-bit), flagging RC4 stream cipher support, identifying 3DES/DES usage, and detecting MD5-based authentication.
Deprecated Algorithm Identification: This involves flagging anonymous Diffie-Hellman (ADH) ciphers, detecting SSLv2/SSLv3 cipher suites, identifying CBC mode cipher usage, and noting non-ephemeral key exchange.
Forward Secrecy Assessment: The scanner checks for ECDHE key exchange support, verifies DHE availability, flags static RSA key exchange, and calculates the forward secrecy coverage percentage.
Modern Cipher Compliance: It involves verifying AEAD cipher support (GCM, ChaCha20-Poly1305), checking TLS 1.3 cipher suite availability, recommending secure cipher suites, and generating a compliance score based on these criteria.

Inputs Required:

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

Business Impact:
Weak cipher suite support can enable cryptographic attacks that could lead to data breaches or other security incidents. By identifying and mitigating the use of insecure ciphers, organizations can reduce their exposure to these risks and comply with industry standards for secure network configurations.

Risk Levels:

Critical: This risk level applies if any NULL, EXPORT, RC4, 3DES, MD5, anonymous, ADH, or CBC mode cipher suites are detected in the TLS configuration. Critical vulnerabilities can lead to plaintext transmission and immediate security concerns.
High: High risk is associated with SSLv2/SSLv3 cipher suites, indicating a significant lack of modern cryptographic practices that could be exploited by attackers.
Medium: Medium risk findings include non-ephemeral key exchange methods and unsupported AEAD ciphers, which may not pose immediate threats but are indicative of suboptimal security configurations.
Low: Low risk includes the use of TLS 1.3 and modern cryptographic algorithms that do not exhibit known vulnerabilities or weaknesses in their design.
Info: Informational findings pertain to the overall compliance score based on cipher suite usage, which can be used for continuous monitoring and improvement of network security posture.

Example Findings:

A domain supports TLS_RSA_WITH_3DES_EDE_CBC_SHA, a 3DES-based cipher that is vulnerable to the Sweet32 attack due to its use of CBC mode encryption.
The scanner identifies RC4_128 as supported, which contains biases enabling plaintext recovery and is not recommended for secure communications.

This comprehensive approach ensures that organizations can proactively address weaknesses in their TLS configurations, enhancing both security and compliance with industry standards.

Certificate Scope Analysis

Purpose: The Certificate Scope Analysis Scanner is designed to analyze SSL/TLS certificates in order to validate proper domain coverage, identify scope mismatches, assess wildcard usage risks, and verify certificate authority trust levels. This analysis helps in identifying potential vulnerabilities and misconfigurations that could lead to security breaches or compliance issues.

What It Detects:

Domain-Certificate Match Validation: Verifies whether the SSL/TLS certificate properly covers the exact domain requested by checking if the target domain appears in either the Common Name (CN) or Subject Alternative Names (SAN). Certificates that do not match the target domain are flagged as having a scope mismatch.
Subdomain Coverage Assessment: Extracts all domains listed in the SAN field to assess the total number of subdomains covered and identifies overly broad or suspiciously narrow coverage.
Wildcard Certificate Analysis: Detects wildcard certificates (e.g., *.example.com) and evaluates whether the scope of the wildcard is appropriate for the domain structure, flagging wildcards that expose excessive subdomain attack surfaces.
Certificate Authority Trust Verification: Extracts the issuer organization name from the certificate and scores the reputation of the Certificate Authority (CA). Certificates issued by trusted CAs like Let’s Encrypt or DigiCert are considered secure, while self-signed or locally-issued certificates are flagged as suspicious.
Certificate Validity Period: Calculates the number of days until a certificate expires and flags those expiring within 30 days as critical and those expiring within 90 days as warning.

Inputs Required:

domain (string): Fully qualified domain name (e.g., ekkatha.com), which is required for the scanner to analyze the SSL/TLS certificate associated with this domain.

Business Impact: Improper configuration of SSL/TLS certificates can lead to several security risks, including exposure to attacks through compromised subdomains and bypassing browser security warnings due to invalid or untrusted certificates. This directly impacts the integrity and confidentiality of data transmitted over networks protected by these certificates.

Risk Levels:

Critical: Certificates that do not match the target domain (scope mismatch) can lead to MITM (Man-in-the-Middle) attacks, exposing multiple subdomains to a single point of compromise. Wildcard certificates used too broadly also pose a critical risk by significantly increasing the attack surface.
High: Certificates expiring within 30 days are at risk of becoming invalid before they can be renewed or replaced, which could disrupt service and trust in the organization’s digital presence.
Medium: Certificates with scope mismatches might not cover all necessary subdomains, posing a medium risk as they may lead to browser acceptance of invalid certificates.
Low: Self-signed or locally-issued certificates by low-trust CAs do not trigger security warnings in browsers and could be used for less critical applications where trust is not as crucial.
Info: Informational findings about wildcard usage are considered low risk unless they lead to high or critical risks when misused.

Example Findings:

A certificate for example.com has a scope mismatch, missing subdomains that should be included in the SAN field.
A wildcard certificate for *.example.com is used excessively, potentially exposing more subdomains than intended and increasing the risk of security breaches.

Domain Delegation Security

Purpose: The Domain Delegation Security Scanner is designed to analyze DNS delegation security by examining nameserver configurations. It aims to detect vulnerabilities that could lead to DNS hijacking or subdomain takeover attacks, providing critical insights into the security of domain hierarchies.

What It Detects:

Nameserver Authority Validation: The scanner queries all NS records for a domain and verifies if each nameserver responds authoritatively. It also checks the consistency of SOA (Start of Authority) records across nameservers to ensure they are authoritative.
Nameserver Ownership Analysis: It extracts IP addresses for all nameservers, performs reverse DNS lookups, identifies nameserver hosting providers, and flags nameservers in different administrative domains.
Glue Record Verification: The scanner checks if in-domain nameservers have glue records and verifies that the glue record IPs match the actual nameserver IPs.
Delegation Chain Consistency: It queries the parent zone for NS records and compares them with child NS records to identify mismatches that could cause resolution failures.
Subdomain Takeover Risk Assessment: The scanner checks if nameserver domains are registered, verifies if the hosts are reachable, flags dangling NS records pointing to expired domains, and identifies cloud provider nameservers for deleted resources.

Inputs Required:

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

Business Impact: DNS delegation vulnerabilities create critical attack vectors that can lead to subdomain takeover, availability issues, split-authority risks, and potential denial of service (DoS) attacks. These vulnerabilities are crucial for maintaining the integrity and security of a domain’s hierarchy.

Risk Levels:

Critical: Orphaned NS records pointing to unregistered nameservers enable subdomain takeover, creating significant risk.
High: Lame delegations with non-responsive nameservers cause availability issues and can be exploited for malicious purposes.
Medium: NS records pointing to different organizations create split-authority risks and may indicate configuration drift.
Low: Missing glue records prevent resolution and can enable DoS attacks, though these are generally less severe than the high-risk findings mentioned above.
Info: Inconsistent NS records across nameservers indicate potential misconfigurations but typically do not pose immediate threats.

Example Findings:

A domain has an orphaned NS record pointing to a non-existent or unregistered nameserver, making it susceptible to subdomain takeover.
Multiple nameservers in the delegation chain are unresponsive, leading to significant availability issues for the subdomains.

This documentation provides a clear and comprehensive overview of the Domain Delegation Security Scanner’s purpose, detection points, inputs required, business impact, risk levels, and potential findings, tailored for user-facing documentation.

HSTS Implementation Analysis

Purpose: The HSTS Implementation Analysis Scanner is designed to evaluate the HTTP Strict Transport Security (HSTS) header configuration of a domain. Its primary purpose is to ensure that HTTPS is properly enforced, detect potential SSL stripping vulnerabilities, and validate whether the domain is eligible for inclusion in the HSTS preload list.

What It Detects:

HSTS Header Presence Detection: The scanner makes an HTTPS request to the domain and checks for the presence of the Strict-Transport-Security header. Domains missing this header are flagged, along with issues related to its configuration on both the www and apex domains.
Max-Age Configuration Analysis: It extracts the max-age value from the HSTS header and converts it into days for readability. Values less than 180 days or 365 days (critical and warning thresholds respectively) are flagged, with recommendations for a minimum of one year (max-age >= 31536000).
Subdomain Protection Assessment: The scanner checks for the presence of the includeSubDomains directive. Missing subdomain protection is flagged, and issues related to subdomains inheriting HSTS policies are identified.
Preload List Eligibility Check: It verifies the presence of the preload directive and ensures that the max-age is at least one year (required for preload) and includeSubDomains is present (required for preload). The scanner also checks if the domain is listed on the HSTS preload list, with flags applied to domains not yet submitted.
HTTPS Redirect Validation: The scanner tests whether HTTP redirects to HTTPS exist and verifies that the redirect status code is 301. It also checks the presence of the HSTS header in the response after a redirect. Issues related to missing or improperly configured redirects are flagged.

Inputs Required:

domain (string): A fully qualified domain name, such as “ekkatha.com”.

Business Impact: Proper implementation of HSTS is crucial for securing web communications by enforcing HTTPS connections and preventing SSL/TLS downgrade attacks. Misconfigured or missing HSTS headers can lead to significant security vulnerabilities, exposing users to potential interception and manipulation of sensitive information.

Risk Levels:

Critical: Domains without an HSTS header are vulnerable to SSL stripping attacks on the first visit, creating a critical risk for data exposure.
High: Short max-age values (< 180 days) create frequent vulnerability windows, posing a high risk that can be exploited by attackers.
Medium: Missing includeSubDomains directive exposes subdomains to downgrade attacks, introducing a medium level of risk.
Low: Misconfigured preload directives do not prevent browser preload protection but still represent an issue requiring attention.
Info: Informational findings such as incomplete or misconfigured HSTS settings are flagged for awareness and potential improvement.

If the README doesn’t specify exact risk levels, infer them based on the scanner’s purpose and impact.

Example Findings:

A domain lacks an HSTS header, making it susceptible to SSL stripping attacks.
A domain has a max-age value of less than 180 days, creating frequent security issues that need immediate attention.
Subdomains are not protected by the includeSubDomains directive, leaving them vulnerable to downgrade attacks.

DNSSEC Trust Chain Analysis

Purpose: The DNSSEC Trust Chain Analysis Scanner is designed to assess the robustness of DNSSEC (DNS Security Extensions) configurations for domains. It aims to validate the complete chain of trust from root servers through Top-Level Domain (TLD) to the target domain, identifying configuration errors and security gaps that could be exploited by attackers.

What It Detects:

DNSSEC Enablement Detection: The scanner checks whether a domain has DNSSEC records by querying for DNSKEY records and verifying if the zone is signed with DNSSEC. Domains without DNSSEC protection are flagged as vulnerable.
Chain of Trust Validation: It verifies the existence of DS records at parent nameservers, validates that DNSKEY matches DS record hash, checks RRSIG signatures for validity, and traces the validation path from root to domain.
Signature Validity Assessment: The scanner evaluates the inception and expiration dates of RRSIG signatures, flags expired or not-yet-valid signatures, and ensures that signature algorithms are current.
Algorithm Security Evaluation: It identifies cryptographic algorithms in use, flags deprecated algorithms (such as RSASHA1 and DSA) and recommends modern alternatives like ECDSAP256SHA256 and ED25519.
Configuration Consistency Check: The scanner verifies that all nameservers return consistent DNSSEC records, checks for missing NSEC/NSEC3 records, and detects any DNSSEC validation errors.

Inputs Required:

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

Business Impact: Ensuring the integrity and security of DNS infrastructure is crucial as it prevents various attacks including DNS spoofing and cache poisoning, safeguarding internet connectivity and user trust in online services.

Risk Levels:

Critical: This includes conditions where a broken chain of trust allows attackers to inject false DNS responses or where unsigned zones are vulnerable to DNS hijacking.
High: This encompasses scenarios where missing DS records at parent zone break validation, expired RRSIG signatures enable man-in-the-middle attacks, and algorithm mismatches between parent/child prevent validation.
Medium: This includes cases where deprecated cryptographic algorithms (like RSASHA1 and DSA) are in use or where there are inconsistencies in DNSSEC configurations across nameservers.
Low: This pertains to informational findings such as the presence of modern cryptographic algorithms not listed as recommended but still secure, or minor validation errors that do not significantly impact security.
Info: These are generally non-critical findings indicating the use of current cryptographic standards without any known issues.

Example Findings:

A domain is detected to be unsigned using DNSSEC, which makes it susceptible to attacks where false responses can be injected.
An expired RRSIG signature on a critical DNS record could allow an attacker to manipulate traffic destined for the affected domain.
The use of deprecated cryptographic algorithms like RSASHA1 and DSA indicates a lack of adherence to current security standards, increasing vulnerability.