Domain/Subdomain takeover

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Domain takeover

Si descubres algún dominio (domain.tld) que está siendo usado por algún servicio dentro del alcance pero la empresa ha perdido la propiedad del mismo, puedes intentar registrarlo (si es lo suficientemente barato) y avisar a la empresa. Si este dominio está recibiendo información sensible como una session cookie vía parámetro GET o en el header Referer, esto es sin duda una vulnerabilidad.

Subdomain takeover

Un subdomain de la empresa apunta a un servicio de terceros con un nombre no registrado. Si puedes crear una cuenta en ese servicio de terceros y registrar el nombre en uso, puedes realizar el subdomain takeover.

Hay varias herramientas con diccionarios para comprobar posibles takeovers:

Subdomain Takeover Generation via DNS Wildcard

Cuando se usa un wildcard DNS en un dominio, cualquier subdominio solicitado de ese dominio que no tenga otra dirección explícita será resuelto con la misma información. Esto puede ser una dirección A, un CNAME…

Por ejemplo, si *.testing.com está wildcarded a 1.1.1.1. Entonces, not-existent.testing.com apuntará a 1.1.1.1.

Sin embargo, si en lugar de apuntar a una IP, el sysadmin lo apunta a un servicio de terceros vía CNAME, como un subdominio de GitHub por ejemplo (sohomdatta1.github.io). Un atacante podría crear su propia página en ese servicio de terceros (en GitHub en este caso) y declarar que something.testing.com apunta allí. Debido a que el CNAME wildcard lo permitirá, el atacante podrá generar subdominios arbitrarios para el dominio de la víctima apuntando a sus páginas.

Puedes encontrar un ejemplo de esta vulnerabilidad en el write-up del CTF: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Exploiting a subdomain takeover

Subdomain takeover es esencialmente DNS spoofing para un dominio específico en Internet, permitiendo a los atacantes establecer registros A para un dominio, llevando a los navegadores a mostrar contenido desde el servidor del atacante. Esta transparencia en los navegadores hace que los dominios sean proclives al phishing. Los atacantes pueden emplear typosquatting o Doppelganger domains para este propósito. Son especialmente vulnerables los dominios donde la URL en un email de phishing parece legítima, engañando a los usuarios y eludiendo los filtros de spam debido a la confianza inherente del dominio.

Consulta este post para más detalles

SSL Certificates

Los certificados SSL, si son generados por atacantes mediante servicios como Let’s Encrypt, añaden legitimidad a estos dominios falsos, haciendo los ataques de phishing más convincentes.

La transparencia del navegador también se extiende a la seguridad de las cookies, gobernada por políticas como la Same-origin policy. Las cookies, usadas frecuentemente para gestionar sesiones y almacenar tokens de login, pueden ser explotadas mediante subdomain takeover. Los atacantes pueden recopilar session cookies simplemente dirigiendo usuarios a un subdominio comprometido, poniendo en riesgo datos y la privacidad de los usuarios.

CORS Bypass

Podría ser posible que cada subdominio esté permitido para acceder a recursos CORS del dominio principal u otros subdominios. Esto podría ser explotado por un atacante para acceder a información sensible mediante peticiones CORS.

CSRF - Same-Site Cookies bypass

Podría ser posible que el subdominio esté autorizado a enviar cookies al dominio o a otros subdominios lo cual fue prevenido por el atributo Same-Site de las cookies. Sin embargo, ten en cuenta que los anti-CSRF tokens aún impedirán este ataque si están implementados correctamente.

OAuth tokens redirect

Podría ser posible que el subdominio comprometido esté permitido como parte del redirect_uri en un flujo OAuth. Esto podría ser explotado por un atacante para robar el token OAuth.

CSP Bypass

Podría ser posible que el subdominio comprometido (o cada subdominio) esté autorizado para, por ejemplo, el script-src del CSP. Esto podría ser explotado por un atacante para inyectar scripts maliciosos y explotar posibles vulnerabilidades XSS.

Emails and Subdomain Takeover

Otro aspecto del subdomain takeover involucra servicios de correo. Los atacantes pueden manipular los registros MX para recibir o enviar correos desde un subdominio legítimo, aumentando la eficacia de los ataques de phishing.

Higher Order Risks

Riesgos adicionales incluyen la toma de registros NS. Si un atacante obtiene control sobre un registro NS de un dominio, puede potencialmente dirigir una porción del tráfico a un servidor bajo su control. Este riesgo se amplifica si el atacante establece un alto TTL (Time to Live) para los registros DNS, prolongando la duración del ataque.

CNAME Record Vulnerability

Los atacantes pueden explotar registros CNAME no reclamados que apuntan a servicios externos que ya no se usan o que han sido desmantelados. Esto les permite crear una página bajo el dominio de confianza, facilitando phishing o distribución de malware.

Mitigation Strategies

Las estrategias de mitigación incluyen:

  1. Eliminar registros DNS vulnerables - Esto es efectivo si el subdominio ya no es necesario.
  2. Reclamar el nombre de dominio - Registrar el recurso con el proveedor correspondiente o recomprar un dominio expirado.
  3. Monitoreo regular en busca de vulnerabilidades - Herramientas como aquatone pueden ayudar a identificar dominios susceptibles. Las organizaciones también deben revisar sus procesos de gestión de infraestructura, asegurando que la creación de registros DNS sea el último paso al crear recursos y el primer paso al destruirlos.

Para los proveedores cloud, verificar la propiedad del dominio es crucial para prevenir subdomain takeovers. Algunos, como GitLab, han reconocido este problema e implementado mecanismos de verificación de dominio.

Detection techniques

  • Find dangling DNS records: buscar registros CNAME/A/AAAA/ALIAS/ANAME que apunten a recursos inexistentes (buckets eliminados, apps, pages, load balancers).
  • Check provider error signatures: emparejar respuestas HTTP, certs TLS, o errores DNS con patrones conocidos de takeover (ver can-i-take-over-xyz).
  • Look for orphaned cloud assets: verificar S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian, y servicios similares.
  • Passive DNS and historical records: los CNAMEs antiguos a menudo revelan servicios de terceros previamente usados que pueden seguir siendo vulnerables.
  • Wildcard pitfalls: confirmar wildcard DNS vs. registros explícitos para evitar falsos positivos y entender la amplificación del takeover.

APIs and data sources

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks