26 KiB
Toma de control de Dominio/Subdominio
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si quieres ver a tu empresa anunciada en HackTricks o descargar HackTricks en PDF, consulta los PLANES DE SUSCRIPCIÓN!
- Consigue el merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección de NFTs exclusivos
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.
Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente, potenciados por las herramientas comunitarias más avanzadas.
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 de este, puedes intentar registrarlo (si es lo suficientemente barato) y hacerlo saber a la empresa. Si este dominio está recibiendo información sensible como una cookie de sesión a través del parámetro GET o en el encabezado Referer, esto es definitivamente 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 registrar el nombre en uso, puedes realizar la toma de control del subdominio.
Hay 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 Apropiables con BBOT:
Las verificaciones 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 explícitamente diferente se resolverá a la misma información. Esto podría 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 Github en este caso) y decir que something.testing.com está apuntando allí. Debido a que el CNAME comodín estará de acuerdo, 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
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 subdominio. Aunque el concepto ahora es generalmente bien entendido, noté que la gente suele tener dificultades para comprender los riesgos que la toma de subdominio conlleva. En este post, profundizo y cubro los riesgos más notables de toma de subdominio desde mi perspectiva.
Nota: Algunos riesgos son mitigados implícitamente por el proveedor de la nube. Por ejemplo, cuando la toma de subdominio es posible en Amazon CloudFront, no hay forma de configurar registros TXT para eludir las verificaciones de SPF. Por lo tanto, el post tiene como objetivo proporcionar riesgos sobre la toma general de subdominio. Sin embargo, la mayoría de estos se aplican también a los proveedores de la nube.
Transparencia Para un Navegador
Para comenzar, veamos la resolución de DNS donde se involucra CNAME:
Nota que el paso #7 solicita sub.example.com en lugar de anotherdomain.com. Esto se debe a que el navegador web no es consciente de que anotherdomain.com siquiera existe. Aunque se use un registro CNAME, la barra de URL en el navegador todavía contiene sub.example.com. Esta es la transparencia para el navegador. Si piensas en eso, el navegador deposita toda su confianza en el resolver de DNS para proporcionar información precisa sobre el dominio. Simplificado, la toma de subdominio es un spoofing de DNS para un dominio particular en todo Internet. ¿Por qué? Porque cualquier navegador que realice la resolución de DNS en un dominio afectado recibe un registro A establecido por un atacante. El navegador entonces muestra felizmente lo que sea que reciba de este servidor (pensando que es legítimo).
Un dominio así crea un escenario perfecto para el phishing. Los atacantes a menudo usan typosquatting o los llamados Doppelganger domains para imitar el dominio/sitio web legítimo con fines de phishing. Después de que un atacante toma control de algún nombre de dominio legítimo, es casi imposible para un usuario regular decir si el contenido en el dominio es proporcionado por una parte legítima o un atacante. Tomemos por ejemplo un banco aleatorio. Si uno de los subdominios del banco es vulnerable a la toma de subdominio, un atacante puede crear un formulario HTML que imita el formulario de inicio de sesión al sistema de banca por internet del banco. Luego, un atacante puede ejecutar una campaña de phishing dirigido o 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 algo malicioso sucediendo. Los filtros de spam y otras medidas de seguridad también son menos propensos a marcar 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 significativo en una campaña exitosa. Tener un subdominio de quinto nivel vulnerable a la toma de subdominio es mucho menos "legítimo" que tener un subdominio de segundo nivel con algún nombre de subdominio amigable. Vi varios ejemplos de subdominios perfectos para phishing, incluyendo:
- purchases.SOMETHING.com
- www.SOMETHING.com
- online.SOMETHING.com
- shop.SOMETHING.com
Todos ellos vulnerables a la toma de subdominio. 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). Teniendo 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, la gente tiende 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 fácilmente, potenciados por las herramientas comunitarias más avanzadas del mundo.
Obtén Acceso Hoy:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Certificados SSL
El ataque anterior puede ser mejorado generando un certificado SSL válido. Autoridades de certificación como Let's Encrypt permiten la verificación automática de la propiedad de un 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 dado. Dado que un atacante tiene control total sobre el contenido del dominio que es vulnerable a la toma de subdominio, esta verificación se puede realizar en cuestión de minutos. Por lo tanto, los atacantes también son capaces de generar un certificado SSL para dicho dominio, lo que solo disminuye la sospecha de un ataque de phishing.
Robo de Cookies
Esto va de la mano con la transparencia del navegador pero tiene consecuencias diferentes. El navegador web implementa muchas políticas de seguridad para prevenir que sitios web maliciosos causen daño. Esto incluye cosas como la Política del mismo origen. Una de las principales responsabilidades de seguridad de un navegador es asegurar las cookies guardadas. ¿Por qué? Mientras que HTTP es un protocolo sin estado, las cookies se utilizan para rastrear sesiones. Por conveniencia, los usuarios a menudo guardan cookies por un período extendido 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 el usuario es identificado. Ataques como el Secuestro de sesión evolucionaron naturalmente de este concepto.
El navegador presenta automáticamente las cookies almacenadas con cada solicitud al dominio que las emitió. Hay una excepción a eso, tal que las cookies podrían compartirse entre subdominios (leer aquí, también nota 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. Usando SSO, un usuario puede iniciar sesión usando 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 subdomain.example.com. Este comportamiento crea una posibilidad de ataques de alta severidad utilizando la toma de control de subdominios. Supongamos que cierto dominio está utilizando cookies de sesión para un dominio comodín. Si hay un subdominio vulnerable a la toma de control de subdominios, lo único necesario para obtener 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 — Por defecto, las cookies pueden ser accedidas por código Javascript ejecutándose en el contexto del sitio web que creó las cookies. Javascript puede leer, actualizar y eliminar las cookies. La bandera HttpOnly de la cookie (establecida por el servidor web) indica que la cookie en particular no puede ser accedida por código Javascript. La única forma de obtenerla es a través de las cabeceras de solicitud y respuesta HTTP.
- Cookie Secure — 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 control 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 se puede generar fácilmente un certificado SSL para el dominio tomado.
El robo de cookies utilizando la toma de control fue explicado en el informe de recompensa por errores 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 control de subdominios, apuntando a una distribución de AWS CloudFront no reclamada. Dado que Ubiquiti Networks está utilizando SSO con cookies de sesión de dominio 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 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 el 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 expira, el navegador falla silenciosamente, es decir, no activa ninguna alerta visible para los usuarios regulares. Si el código externo no está haciendo nada importante (por ejemplo, solo se utiliza para seguimiento), dicho proveedor externo podría permanecer en el sitio web durante un período prolongado. Un atacante puede tomar control de este dominio expirado, coincidir con la ruta URL del código Javascript proporcionado y así ganar control sobre cada visitante que visite el sitio web original.
Sin embargo, hay una forma de proteger la integridad de los archivos Javascript en un navegador. Subresource Integrity fue propuesto como un mecanismo para incluir un hash criptográfico como un atributo integrity a 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 la toma de control de subdominios CNAME es posible, los registros MX también pueden ser configurados por un atacante a un servidor web arbitrario. Esto permite recibir correos electrónicos a un subdominio legítimo de alguna marca, particularmente útil nuevamente en ataques de (spear) phishing donde es necesaria la interacción entre un atacante y una víctima. Los atacantes generalmente falsifican 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 el envío de correos para el dominio. SPF almacena la configuración en registros DNS TXT. Con la toma de control de subdominios, los registros TXT también están bajo el control del atacante, por lo que se pueden pasar fácilmente las comprobaciones de SPF.
Como señalé al principio, estas tácticas generalmente no funcionan con la mayoría de los proveedores de la nube ya que no tienes control directo sobre la zona DNS.
Riesgos de Orden Superior
El concepto de toma de control de subdominios puede extenderse naturalmente a los registros NS: Si el dominio base de al menos un registro NS está disponible para registro, el nombre de dominio fuente es vulnerable a la toma de control de subdominios.
Uno de los problemas en la toma de control de subdominios utilizando el registro NS es que el nombre de dominio fuente 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 control de ns.vulnerable.com, la situación desde la perspectiva del usuario que consulta sub.example.com es la siguiente:
- Dado que hay dos servidores de nombres, se elige uno al azar. Esto significa que la probabilidad de consultar el servidor de nombres controlado por un atacante es del 50%.
- Si el resolvedor 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.
- Si el resolvedor DNS del usuario elige ns.vulnerable.com (servidor de nombres propiedad de un atacante), un atacante podría proporcionar un resultado falso que también se almacenará en caché. Dado que un atacante está en control del servidor de nombres, ella puede establecer el TTL para este resultado particular, por ejemplo, una semana.
El proceso anterior se repite cada vez que expira 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 un 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 resolvedor DNS obtendrán resultados falsos hasta que se revoque la caché.
Además del control sobre el nombre de dominio fuente, también se obtiene control sobre todos los dominios de nivel superior del nombre de dominio fuente. Esto se debe a que poseer un nombre de dominio canónico de un registro NS significa poseer la zona DNS completa del nombre de dominio fuente.
En 2016, Matthew Bryant demostró una toma de control de subdominios utilizando el registro NS en maris.int. El dominio de nivel superior .INT es un TLD especial, y solo un puñado de dominios lo están utilizando. Bryant mostró que, aunque la registración de tales nombres de dominio es aprobada exclusivamente por la IANA, los servidores de nombres pueden configurarse a dominios arbitrarios. Dado que uno de los servidores de nombres de maris.int estaba disponible para registro (cobalt.aliis.be), la toma de control de subdominios fue posible incluso en este TLD restringido.
Matthew también demostró un ataque de aún mayor severidad donde fue capaz de ganar control sobre el servidor de nombres del dominio de nivel superior .IO. Controlar .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 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 nombres de dominio ya vulnerables a la toma de control 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 generalmente se utiliza 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 la nube en particular o, en caso de un dominio de Internet regular, recomprar el dominio expirado.
Para prevenir la toma de control de subdominios en el futuro, las organizaciones deberían 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 tiene que ser el último paso de este proceso. Esta condición evita que el registro DNS apunte a un dominio inexistente en cualquier momento. Para la destrucción de recursos, lo contrario es cierto: el registro DNS necesita ser eliminado como el primer paso en este proceso. Herramientas como aquatone incluyen comprobaciones para la toma de control de subdominios. Las comprobaciones deben ser realizadas periódicamente por un equipo de seguridad de una organización para verificar que no hay dominios vulnerables. Los procesos para la recopilación central 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.
La estrategia de mitigación para los proveedores de la nube también debe ser considerada. Los servicios en la nube no están verificando la propiedad del dominio. La razón detrás de esto es principalmente la conveniencia. El proveedor de la nube no está introduciendo ninguna vulnerabilidad al no verificar la propiedad de un nombre de dominio fuente. Por lo tanto, depende del usuario monitorear sus registros DNS. Otra razón es que, cuando se elimina un recurso en la nube, el usuario generalmente ya no es cliente de ese servicio. La pregunta que entonces se hacen los proveedores de la nube es: ¿Por qué deberíamos preocuparnos?
Proveedores como GitLab se dieron cuenta de que la toma de control 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!
Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente, impulsados por las herramientas comunitarias más avanzadas.
Obtén Acceso Hoy:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si quieres ver a tu empresa anunciada en HackTricks o descargar HackTricks en PDF, consulta los PLANES DE SUSCRIPCIÓN!
- Consigue el merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección de NFTs exclusivos
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud en github.