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 exclusiva de NFTs
• Obtén el swag oficial de PEASS y HackTricks
• Ú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.

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

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

Toma de control de dominio

Si descubres que algún dominio (dominio.tld) 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 hacerle saber a la empresa. Si este dominio está recibiendo alguna información sensible como una cookie de sesión a través de un 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 está en uso, puedes realizar la toma de control del subdominio.

Existen varias herramientas con diccionarios para verificar 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/SaadAhmedx/Subdomain-Takeover
• https://github.com/Ice3man543/SubOver
• https://github.com/m4ll0k/takeover
• https://github.com/antichown/subdomain-takeover
• https://github.com/musana/mx-takeover

Escaneo de subdominios secuestrables con BBOT:

Las comprobaciones de toma de control de subdominios están incluidas en la enumeración de subdominios predeterminada de BBOT. Las firmas se obtienen directamente de https://github.com/EdOverflow/can-i-take-over-xyz.

bbot -t evilcorp.com -f subdomain-enum

Generación de toma de subdominio a través de DNS Wildcard

Cuando se utiliza un comodín DNS en un dominio, cualquier subdominio solicitado de ese dominio que no tenga una dirección diferente explícitamente se resolverá a la misma información. Esto puede ser una dirección IP A, un CNAME...

Por ejemplo, si *.testing.com está comodinado 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 dirección IP, el administrador del sistema lo apunta a un servicio de terceros a través de CNAME, como un subdominio de GitHub por ejemplo (sohomdatta1.github.io). Un atacante podría crear su propia página de terceros (en este caso en GitHub) y decir que something.testing.com apunta allí. Debido a que el comodín CNAME estará de acuerdo, el atacante podrá generar subdominios arbitrarios para el dominio de la víctima que apunten a sus páginas.

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

Explotando una toma de subdominio

Esta información fue copiada de https://0xpatrik.com/subdomain-takeover/

Recientemente, escribí sobre los conceptos básicos de la toma de subdominios. Aunque el concepto ahora se comprende en general, noté que las personas suelen tener dificultades para entender los riesgos que implica la toma de subdominios. En esta publicación, profundizo y cubro los riesgos más notables de la toma de subdominios desde mi perspectiva.

Nota: Algunos riesgos se mitigan implícitamente por el proveedor de servicios en la nube. Por ejemplo, cuando es posible la toma de subdominios en Amazon CloudFront, no hay forma de configurar registros TXT para omitir las comprobaciones SPF. Por lo tanto, el objetivo de esta publicación es proporcionar riesgos sobre la toma de subdominios en general. Sin embargo, la mayoría de estos también se aplican a los proveedores de servicios en la nube.

Transparencia para un navegador

Para empezar, veamos la resolución DNS cuando está involucrado un CNAME:

Ten en cuenta que el paso #7 solicita sub.example.com en lugar de anotherdomain.com. Esto se debe a que el navegador web no sabe que anotherdomain.com existe. Aunque se utiliza un registro CNAME, la barra de URL del navegador aún contiene sub.example.com. Esta es la transparencia para el navegador. Si lo piensas, el navegador confía en el servidor DNS para proporcionar información precisa sobre el dominio. Simplificando, la toma de subdominios es un envenenamiento DNS para un dominio en particular en Internet. ¿Por qué? Porque cualquier navegador que realice la resolución DNS en el dominio afectado recibe un conjunto de registros A establecido por un atacante. El navegador luego muestra felizmente lo que recibe de este servidor (pensando que es legítimo).

Un dominio así es perfecto para el phishing. Los atacantes suelen utilizar typosquatting o los llamados Doppelganger domains para imitar el dominio/sitio web legítimo con fines de phishing. Después de que un atacante se apodera de un nombre de dominio legítimo, es casi imposible para un usuario regular saber si el contenido del dominio es proporcionado por una parte legítima o por un atacante. Tomemos como ejemplo un banco al azar. Si uno de los subdominios del banco es vulnerable a la toma de subdominios, un atacante puede crear un formulario HTML que imite el formulario de inicio de sesión del sistema de banca en línea del banco. Luego, un atacante puede ejecutar una campaña de spear phishing o phishing masivo pidiendo a los usuarios que inicien sesión y cambien sus contraseñas. En esta etapa, las contraseñas son capturadas por un atacante que tiene el control del dominio en cuestión. La URL proporcionada en el correo electrónico de phishing es un subdominio legítimo de un banco. Por lo tanto, los usuarios no son conscientes de que algo malicioso está sucediendo. Los filtros de spam y otras medidas de seguridad también tienen menos probabilidades de detectar el correo electrónico como spam o malicioso porque contiene nombres de dominio con mayor confianza.

De hecho, el nombre de dominio en sí juega un papel importante en una campaña exitosa. Tener un subdominio de quinto nivel vulnerable a la toma de subdominios es mucho menos "legítimo" que tener un subdominio de segundo nivel con un nombre de subdominio amigable. He visto varios casos de subdominios perfectos para el phishing, incluyendo:

• purchases.SOMETHING.com
• www.SOMETHING.com
• online.SOMETHING.com
• shop.SOMETHING.com

Todos ellos son vulnerables a la toma de subdominios. Todos ellos eran grandes marcas. ¿Hablando de phishing perfecto?

Sin embargo, las campañas de phishing recientes alojan contenido en dominios con nombres de dominio largos que incluyen el nombre de la marca (ver ejemplo de Apple). Al tener un certificado SSL válido (más sobre eso a continuación), una palabra clave en el nombre de dominio y un sitio web que imita el sitio web de la marca objetivo, las personas tienden a caer en estos ataques. Piensa en las posibilidades con un subdominio legítimo de esta marca.

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

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

Certificados SSL

El ataque anterior puede mejorarse generando un certificado SSL válido. Las autoridades de certificación como Let's Encrypt permiten la verificación automática de la propiedad del dominio mediante la verificación de contenido:

Es decir, si hay un contenido específico colocado en una ruta de URL específica, Let's Encrypt aprobará la emisión de un certificado para un dominio determinado. Dado que un atacante tiene control total sobre el contenido del dominio que es vulnerable a la toma de subdominios, esta verificación se puede hacer en cuestión de minutos. Por lo tanto, los atacantes también pueden generar un certificado SSL para dicho dominio, lo que reduce la sospecha de un ataque de phishing.

Robo de Cookies

Esto va de la mano con la transparencia del navegador pero tiene diferentes consecuencias. El navegador web implementa muchas políticas de seguridad para evitar que los sitios web maliciosos causen daño. Esto incluye cosas como la política de mismo origen. Una de las principales responsabilidades de seguridad de un navegador es proteger las cookies guardadas. ¿Por qué? Si bien HTTP es un protocolo sin estado, las cookies se utilizan para rastrear sesiones. Por conveniencia, los usuarios a menudo guardan las cookies durante un período prolongado para evitar iniciar sesión cada vez. Estas cookies, por lo tanto, actúan como un token de inicio de sesión que se presenta al servidor web y se identifica al usuario. Los ataques como el secuestro de sesión surgieron naturalmente a partir de este concepto.

El navegador presenta automáticamente las cookies almacenadas con cada solicitud al dominio que las emitió. Existe una excepción a esto, en la que las cookies pueden compartirse entre subdominios (leer aquí, también tener en cuenta la sección 8.7). Esto suele ocurrir cuando el sitio web utiliza un sistema de inicio de sesión único (SSO) basado en cookies. Mediante SSO, un usuario puede iniciar sesión en un subdominio y compartir el mismo token de sesión en una amplia gama de subdominios. La sintaxis para establecer una cookie regular es la siguiente:

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 se incluirá en las solicitudes HTTP a example.com, pero también a cualquier otro subdominio como subdominio.example.com. Este comportamiento crea la posibilidad de ataques de alta gravedad utilizando la toma de subdominios. Supongamos que un dominio en particular está utilizando cookies de sesión para un dominio comodín. Si hay un subdominio vulnerable a la toma de subdominios, lo único necesario 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, por defecto, pueden ser accedidas 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, solo puede ser comunicada de vuelta al servidor web si se utiliza HTTPS.

Si el dominio es vulnerable a la toma de subdominios, un atacante puede recopilar cookies emitidas por ese dominio en el pasado simplemente engañando a los usuarios para que visiten ese sitio web. Las banderas HttpOnly y Secure no ayudan, ya que la cookie no se está accediendo mediante Javascript y el certificado SSL se puede generar fácilmente para el dominio tomado.

El robo de cookies utilizando la toma de subdominios fue explicado en un informe de recompensa por errores aquí por Arne Swinnen. El informe explica el problema con uno de los subdominios de Ubiquiti Networks (ping.ubnt.com). Este subdominio era vulnerable a la toma de subdominios, apuntando a una distribución no reclamada de AWS CloudFront. Dado que Ubiquiti Networks utiliza 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 tener consecuencias catastróficas. Supongamos que un sitio web está utilizando código Javascript de un proveedor externo utilizando la etiqueta script y el atributo src. Cuando el dominio del proveedor externo caduca, el navegador falla silenciosamente, es decir, no activa ninguna alerta visible para los usuarios regulares. Si el código externo no realiza ninguna tarea importante (por ejemplo, se utiliza solo para rastrear), dicho proveedor externo puede permanecer en el sitio web durante un período prolongado. Un atacante puede tomar el control de este dominio caducado, coincidir con 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 un hash criptográfico como atributo integrity en la etiqueta script en HTML5. Cuando el hash criptográfico proporcionado no coincide con el archivo descargado, el navegador se niega a ejecutarlo.

Correos electrónicos

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

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 verificar la cabecera Return-Path y los hosts permitidos para enviar correos electrónicos para el dominio. SPF almacena la configuración en registros TXT de DNS. Con la toma de subdominios, los registros TXT también están bajo el control del atacante, por lo que las verificaciones SPF se pueden pasar fácilmente.

Como mencioné al principio, estas tácticas generalmente no funcionan con la mayoría de los proveedores de servicios en la nube, ya que no se tiene control directo sobre la zona DNS.

Riesgos de orden superior

El concepto de toma de subdominios se puede extender naturalmente a los registros NS: si el dominio base de al menos un registro NS está disponible para su registro, el nombre de dominio de origen es vulnerable a la toma de subdominios.

Uno de los problemas en la toma de subdominios utilizando registros NS es que el nombre de dominio de origen generalmente tiene múltiples registros NS. Se utilizan múltiples registros NS para redundancia y equilibrio de carga. El servidor de nombres se elige al azar antes de la resolución DNS. Supongamos que el dominio sub.example.com tiene dos registros NS: ns.vulnerable.com y ns.nonvulnerable.com. Si un atacante toma el control de ns.vulnerable.com, la situación desde la perspectiva del usuario que consulta sub.example.com es la siguiente:

1. Dado que hay dos servidores de nombres, se elige uno al azar. Esto significa que la probabilidad de consultar un servidor de nombres controlado por un atacante es del 50%.
2. Si el resolutor DNS del usuario elige ns.nonvulnerable.com (servidor de nombres legítimo), se devuelve el resultado correcto y probablemente se almacena en caché en algún lugar entre 6 y 24 horas.
3. Si el resolutor DNS del usuario elige ns.vulnerable.com (servidor de nombres propiedad de un atacante), el atacante puede proporcionar un resultado falso que también se almacenará en caché. Dado que el atacante tiene el control del servidor de nombres, puede establecer el TTL de este resultado en particular, por ejemplo, una semana.

El proceso anterior se repite cada vez que caduca la entrada de caché. Cuando un atacante elige usar un TTL con un valor alto, el resultado falso permanecerá en la caché DNS durante ese período. Durante este tiempo, todas las solicitudes a sub.example.com utilizarán el resultado DNS falso almacenado en caché por el atacante. Esta idea se amplifica aún más cuando se utilizan resolutores DNS públicos (por ejemplo, Google DNS). En este caso, es probable que los resolutores públicos almacenen en caché los resultados falsos, lo que significa que todos los usuarios que utilicen el mismo resolutor DNS obtendrán resultados falsos hasta que se revoque la caché.

Además del control sobre el nombre de dominio de origen, también se obtiene el control sobre todos los dominios de nivel superior del nombre de dominio de origen. Esto se debe a que ser dueño de un nombre de dominio canónico de un registro NS significa ser dueño de la zona DNS completa del nombre de dominio de origen.

En 2016, Matthew Bryant demostró una toma de subdominios utilizando un registro NS en maris.int. El dominio de nivel superior .INT es un TLD especial y solo unos pocos dominios lo utilizan. Bryant mostró que aunque el registro de dichos nombres de dominio está aprobado exclusivamente por IANA, los servidores de nombres se pueden configurar en dominios arbitrarios. Dado que uno de los servidores de nombres de maris.int estaba disponible para su registro (cobalt.aliis.be), fue posible la toma de subdominios incluso en este TLD restringido.

Matthew también demostró un ataque de mayor gravedad donde pudo obtener el control sobre el servidor de nombres del dominio de nivel superior .IO. Obtener el control sobre .IO significa controlar las respuestas para todos los nombres de dominio .IO. En este caso, uno de los servidores de nombres de .IO era ns-a1.io, que estaba disponible para su registro. Al registrar ns-a1.io, Bryant pudo recibir consultas DNS y controlar sus respuestas para todos los dominios .IO.

Mitigación

Las estrategias de mitigación para los nombres de dominio que ya son vulnerables a la toma de subdominios son bastante sencillas:

• Eliminar el registro DNS afectado - La solución más simple es eliminar el registro afectado de la zona DNS. Este paso se suele utilizar si la organización concluye que el nombre de dominio fuente afectado ya no es necesario.
• Reclamar el nombre de dominio - Esto significa registrar el recurso en un proveedor de nube en particular o, en el caso de un dominio de Internet regular, volver a comprar el dominio caducado.

Para prevenir la toma de subdominios en el futuro, las organizaciones deben cambiar el proceso de creación y destrucción de recursos en su infraestructura. En el caso de la creación de recursos, la creación del registro DNS debe ser el último paso de este proceso. Esta condición evita que el registro DNS apunte a un dominio que no existe en ningún momento. Para la destrucción de recursos, se aplica lo contrario: el registro DNS debe eliminarse como el primer paso en este proceso. Herramientas como aquatone incluyen comprobaciones de toma de subdominios. Estas comprobaciones deben realizarse periódicamente por parte del equipo de seguridad de una organización para verificar que no haya dominios vulnerables. Los procesos de recopilación centralizada de nombres de dominio expuestos a menudo no son eficientes dentro de las organizaciones (debido a equipos globales, etc.) y la monitorización externa suele ser la mejor opción.

También se debe considerar la estrategia de mitigación para los proveedores de servicios en la nube. Los servicios en la nube no verifican la propiedad del dominio. La razón detrás de esto es principalmente la comodidad. El proveedor de la nube no introduce ninguna vulnerabilidad al no verificar la propiedad de un nombre de dominio fuente. Por lo tanto, depende del usuario supervisar sus registros DNS. Otra razón es que cuando se elimina un recurso en la nube, el usuario generalmente deja de ser cliente de ese servicio. Entonces, la pregunta que se hacen los proveedores de la nube es: ¿Por qué deberíamos preocuparnos?

Proveedores como GitLab se dieron cuenta de que la toma de subdominios es un problema e implementaron un mecanismo de verificación de dominio.

Algunas partes de esta publicación son extractos de mi Tesis de Maestría.

¡Hasta la próxima!

Patrik

Utiliza Trickest para construir y automatizar fácilmente flujos de trabajo con las herramientas comunitarias más avanzadas del mundo.
Obtén acceso hoy mismo:

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

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

• ¿Trabajas en una empresa de ciberseguridad? ¿Quieres que tu empresa se anuncie 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 exclusiva de NFTs
• Obtén el merchandising oficial de PEASS y HackTricks
• Únete al 💬 grupo de Discord o al grupo de Telegram o sígueme en Twitter 🐦@carlospolopm.
• Comparte tus trucos de hacking enviando PR al repositorio de hacktricks y al repositorio de hacktricks-cloud.