hacktricks/pentesting-web/domain-subdomain-takeover.md

Toma de control de dominio/subdominio

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• ¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
• Descubre The PEASS Family, nuestra colección de exclusivos NFTs
• Obtén el oficial PEASS & HackTricks swag
• Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
• Comparte tus trucos de hacking enviando PRs al repositorio de hacktricks y al repositorio de hacktricks-cloud.

Usa Trickest para construir y automatizar flujos de trabajo con las herramientas de la comunidad más avanzadas del mundo.
Obtén acceso hoy:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Toma de control de dominio

Si descubres algún dominio (dominio.tld) que está siendo utilizado 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 hacer saber a la empresa. Si este dominio está recibiendo alguna información sensible como una cookie de sesión a través del parámetro GET o en la cabecera Referer, esto es sin duda una vulnerabilidad.

Toma de control de subdominio

Un subdominio de la empresa apunta a un servicio de terceros con un nombre no registrado. Si puedes crear una cuenta en este servicio de terceros y registrarte con el nombre que se está utilizando, puedes realizar la toma de control del subdominio.

Existen varias herramientas con diccionarios para comprobar posibles tomas de control:

• https://github.com/EdOverflow/can-i-take-over-xyz
• https://github.com/blacklanternsecurity/bbot
• https://github.com/punk-security/dnsReaper
• https://github.com/haccer/subjack
• https://github.com/anshumanbh/tko-sub
• [https://github.com/ArifulProtik/sub-domain-takeover](https://github.com

HTTP/1.1 200 OK
Set-Cookie: name=value

Si esta cookie es emitida por un servidor web que reside en example.com, solo este servidor puede acceder a esta cookie más adelante. Sin embargo, la cookie puede ser emitida para un dominio comodín (por las razones explicadas anteriormente) de la siguiente manera:

HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com

La cookie será incluida en las solicitudes HTTP a example.com pero también a cualquier otro subdominio como subdominio.example.com. Este comportamiento crea una posibilidad de ataques de alta severidad usando subdominio takeover. Supongamos que un dominio en particular está usando cookies de sesión para un dominio comodín. Si hay un subdominio vulnerable a subdominio takeover, lo único que se necesita para recopilar el token de sesión del usuario es engañarlo para que visite el subdominio vulnerable. La cookie de sesión se envía automáticamente con la solicitud HTTP.

El navegador también implementa mecanismos de seguridad adicionales para las cookies:

• Cookie HttpOnly - Las cookies pueden ser accedidas por defecto por el código Javascript que se ejecuta en el contexto del sitio web que creó las cookies. Javascript puede leer, actualizar y eliminar las cookies. La bandera de cookie HttpOnly (establecida por el servidor web) indica que la cookie en particular no puede ser accedida por el código Javascript. La única forma de obtenerla es a través de las cabeceras de solicitud y respuesta HTTP.
• Cookie segura - Cuando la cookie tiene la bandera Secure establecida por el servidor web, puede ser comunicada de vuelta al servidor web sólo si se utiliza HTTPS.

Si el dominio es vulnerable a subdominio takeover, un atacante puede recopilar cookies emitidas por ese dominio en el pasado sólo engañando a los usuarios para que visiten ese sitio web. Las banderas HttpOnly y Secure no ayudan ya que la cookie no está siendo accedida usando Javascript y el certificado SSL puede ser fácilmente generado para el dominio tomado.

El robo de cookies usando takeover fue explicado en el informe de recompensa por errores report por Arne Swinnen. El informe explica el problema con uno de los subdominios de Ubiquiti Networks (ping.ubnt.com). Este subdominio era vulnerable a subdominio takeover, apuntando a una distribución de AWS CloudFront no reclamada. Dado que Ubiquiti Networks está usando SSO con cookies de sesión comodín, todos los usuarios que visiten ping.ubnt.com podrían tener sus cookies de sesión robadas. Aunque este dominio apunta a AWS CloudFront, la configuración de la distribución de CloudFront permite registrar cookies con cada solicitud. Por lo tanto, el escenario de extracción de cookies de sesión es completamente posible incluso con subdominios que apuntan a AWS CloudFront. En 2017, Arne también demostró un vector de ataque similar contra el sistema SSO de Uber.

El comportamiento explicado anteriormente no se limita a las cookies. Dado que los scripts de Javascript tienen control total sobre los sitios web en los que se ejecutan, tener la capacidad de reemplazar dichos scripts en el sitio web legítimo podría llevar a consecuencias catastróficas. Supongamos que un sitio web está usando código Javascript del proveedor externo usando la etiqueta script y el atributo src. Cuando el dominio del proveedor externo expira, el navegador falla en silencio, es decir, no activa ninguna alerta visible para los usuarios regulares. Si el código externo no está haciendo nada importante (por ejemplo, se utiliza sólo para el seguimiento), dicho proveedor externo puede permanecer en el sitio web durante un período prolongado. Un atacante puede tomar el control de este dominio caducado, igualar la ruta de URL del código Javascript proporcionado y así obtener el control sobre cada visitante que visite el sitio web original.

Sin embargo, hay una forma de proteger la integridad de los archivos de Javascript en un navegador. Subresource Integrity fue propuesto como un mecanismo para incluir el hash criptográfico como un atributo integrity a la etiqueta script en HTML5. Cuando el hash criptográfico proporcionado no coincide con el archivo de descarga, el navegador se niega a ejecutarlo.

Correos electrónicos

Cuando es posible el subdominio takeover de CNAME, los registros MX pueden ser configurados por un atacante a un servidor web arbitrario también. Esto permite recibir correos electrónicos a un subdominio legítimo de alguna marca, lo que es particularmente útil de nuevo en ataques de (spear) phishing donde es necesaria la interacción entre un atacante y una víctima. Los atacantes suelen falsificar la cabecera Return-Path para recibir una respuesta al correo electrónico. Con los registros MX correctos, este problema se evita.

Por otro lado, también es posible enviar correos electrónicos. Aunque es trivial falsificar la cabecera From para incluir cualquier dirección de correo electrónico, los filtros SPF suelen comprobar la cabecera Return-Path y los hosts permitidos para enviar correos electrónicos para el dominio. SPF almacena la configuración en los registros DNS TXT. Con el subdominio takeover, los registros TXT también están bajo el control del atacante - las comprobaciones SPF pueden ser superadas fácilmente