hacktricks/pentesting-web/domain-subdomain-takeover.md
carlospolop 63bd9641c0 f
2023-06-05 20:33:24 +02:00

67 lines
8.8 KiB
Markdown

# Toma de control de dominio/subdominio
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿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**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de exclusivos [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
![](<../.gitbook/assets/image (9) (1) (2).png>)
\
Usa [**Trickest**](https://trickest.io/) 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/EdOverflow/can-i-take-over-xyz)
* [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
* [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper)
* [https://github.com/haccer/subjack](https://github.com/haccer/subjack)
* [https://github.com/anshumanbh/tko-sub](https://github.com/anshumanbh/tko-subs)
* [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](https://hackerone.com/reports/172137) 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](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/).
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](https://www.w3.org/TR/2016/REC-SRI-20160623/) 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 <a href="#emails" id="emails"></a>
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