Tomada de domínio/subdomínio

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Tomada de domínio

Se você descobrir algum domínio (domain.tld) que está sendo usado por algum serviço dentro do scope mas a empresa perdeu a propriedade dele, você pode tentar registrá-lo (se for barato o suficiente) e avisar a empresa. Se esse domínio estiver recebendo alguma informação sensível como um session cookie via GET parameter ou no cabeçalho Referer, isso com certeza é uma vulnerabilidade.

Tomada de subdomínio

Um subdomínio da empresa está apontando para um serviço third-party com um nome não registrado. Se você puder criar uma conta nesse serviço third-party e registrar o nome em uso, você pode executar a tomada do subdomínio.

Existem várias ferramentas com dicionários para checar possíveis takeovers:

Subdomain Takeover Generation via DNS Wildcard

Quando um wildcard DNS é usado em um domínio, qualquer subdomínio requisitado desse domínio que não tenha um endereço explícito diferente será resolvido para a mesma informação. Isso pode ser um endereço A, um CNAME…

Por exemplo, se *.testing.com estiver wildcarded para 1.1.1.1. Então, not-existent.testing.com estará apontando para 1.1.1.1.

No entanto, se em vez de apontar para um endereço IP, o sysadmin apontar para um serviço third party via CNAME, como um GitHub subdomain por exemplo (sohomdatta1.github.io). Um atacante poderia criar sua própria página third party (no GitHub neste caso) e dizer que something.testing.com está apontando para lá. Como o CNAME wildcard concordará, o atacante poderá gerar subdomínios arbitrários para o domínio da vítima apontando para suas páginas.

Você pode encontrar um exemplo dessa vulnerabilidade no write-up do CTF: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Explorando um subdomain takeover

Subdomain takeover é essencialmente DNS spoofing para um domínio específico através da internet, permitindo que atacantes definam registros A para um domínio, levando navegadores a mostrar conteúdo do servidor do atacante. Essa transparência nos navegadores torna domínios suscetíveis a phishing. Atacantes podem empregar typosquatting ou Doppelganger domains para esse propósito. Domínios especialmente vulneráveis são aqueles onde a URL em um email de phishing parece legítima, enganando usuários e evitando filtros de spam devido à confiança inerente do domínio.

Check this post for further details

SSL Certificates

SSL certificates, if generated by attackers via services like Let’s Encrypt, add to the legitimacy of these fake domains, making phishing attacks more convincing.

Browser transparency also extends to cookie security, governed by policies like the Same-origin policy. Cookies, often used to manage sessions and store login tokens, can be exploited through subdomain takeover. Attackers can gather session cookies simply by directing users to a compromised subdomain, endangering user data and privacy.

CORS Bypass

It might be possible that every subdomain is allowed to access CORS resources from the main domain or other subdomains. This could be exploited by an attacker to access sensitive information abusing CORS requests.

CSRF - Same-Site Cookies bypass

It could be possible that the subdomain is allowed to send cookies to the domain or other subdomains which was prevented by the Same-Site attribute of the cookies. However, note that anti-CSRF tokens will still prevent this attack if they are properly implemented.

OAuth tokens redirect

It might be possible that the compromised subdomain is allowed to be used in the redirect_uri URL of an OAuth flow. This could be exploited by an attacker to steal the OAuth token.

CSP Bypass

It might be possible that the compromised subdomain (or every subdomain) is allowed to be used for example the script-src of the CSP. This could be exploited by an attacker to inject malicious scripts and abuse potential XSS vulnerabilities.

Emails and Subdomain Takeover

Another aspect of subdomain takeover involves email services. Attackers can manipulate MX records to receive or send emails from a legitimate subdomain, enhancing the efficacy of phishing attacks.

Higher Order Risks

Further risks include NS record takeover. If an attacker gains control over one NS record of a domain, they can potentially direct a portion of traffic to a server under their control. This risk is amplified if the attacker sets a high TTL (Time to Live) for DNS records, prolonging the duration of the attack.

CNAME Record Vulnerability

Attackers might exploit unclaimed CNAME records pointing to external services that are no longer used or have been decommissioned. This allows them to create a page under the trusted domain, further facilitating phishing or malware distribution.

Mitigation Strategies

Mitigation strategies include:

  1. Removing vulnerable DNS records - This is effective if the subdomain is no longer required.
  2. Claiming the domain name - Registering the resource with the respective cloud provider or repurchasing an expired domain.
  3. Regular monitoring for vulnerabilities - Tools like aquatone can help identify susceptible domains. Organizations should also revise their infrastructure management processes, ensuring that DNS record creation is the final step in resource creation and the first step in resource destruction.

For cloud providers, verifying domain ownership is crucial to prevent subdomain takeovers. Some, like GitLab, have recognized this issue and implemented domain verification mechanisms.

Detection techniques

  • Find dangling DNS records: look for CNAME/A/AAAA/ALIAS/ANAME records pointing to non-existent resources (deleted buckets, apps, pages, load balancers).
  • Check provider error signatures: match HTTP responses, TLS certs, or DNS errors to known takeover patterns (see can-i-take-over-xyz).
  • Look for orphaned cloud assets: verify S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian, and similar services.
  • Passive DNS and historical records: old CNAMEs often reveal previously used third-party services that may still be vulnerable.
  • Wildcard pitfalls: confirm wildcard DNS vs. explicit records to avoid false positives and understand takeover amplification.

APIs and data sources

References

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks