Guías de seguridad
Toma de control de subdominios (DNS colgante): cómo un registro DNS olvidado permite a un atacante usar tu dominio
Si borras un recurso en la nube pero dejas el CNAME, cualquiera puede apropiarse de ese subdominio sin tocar tus servidores. Por qué se filtran las cookies de sesión, por qué un certificado no te salva y el orden de borrado que lo evita.
Un día un subdominio tuyo empieza a servir contenido de un atacante, y nadie ha tocado tus servidores. Los parches, la autenticación y la monitorización no ayudan aquí. La causa no es una intrusión. Es algo que olvidaste borrar.
Qué pasa en realidad (tres fases)
1. Creación
Creas un recurso en la nube con un nombre de dominio completo (app-xxxx.<dominio del proveedor>) y añades un registro CNAME en tu zona para quesub.example.comapunte a él.2. Baja (a medias)
El recurso se borra cuando ya no hace falta. En ese momento también debería eliminarse el CNAME desub.example.com, y no se hace. Sigue anunciado como dominio activo mientras no apunta a nada: un registro DNS colgante (dangling DNS).3. Toma de control
Un atacante descubre el subdominio colgante y crea un recurso con el mismo FQDN que antes controlabas tú. A partir de ahí, el tráfico asub.example.comllega a su recurso, donde él decide el contenido.
Tu zona DNS (sin cambios)
sub.example.com CNAME→ app-xxxx.provider.example
↓ solo se eliminó el destino
Recurso en la nube: borrado
el nombre vuelve a estar disponible para cualquiera
↓ el atacante crea el mismo nombre
Recurso del atacante (en su cuenta)
él decide qué sirve sub.example.com. Tus servidores nunca se tocaron
Los CNAME son el punto débil porque apuntan a un nombre
A diferencia de un registro A, que apunta a una dirección, un CNAME apunta a un nombre, y en muchos servicios en la nube ese nombre está disponible para quien lo reclame primero. En cuanto lo sueltas, otra persona puede quedárselo. La documentación dice que los registros CNAME son «especialmente vulnerables a esta amenaza». La misma lógica se aplica a los registros MX, donde la consecuencia es que otra persona puede recibir el correo dirigido a ese subdominio.
El daño no es solo una página con aspecto falso
- Pérdida de control del subdominio
- Se sirve desde tu propio dominio contenido que no gestionas: daño a la marca y pérdida de confianza
- Robo de cookies
- Las aplicaciones web suelen exponer las cookies de sesión a los subdominios mediante un comodín (
*.example.com), y en ese caso cualquier subdominio puede acceder a ellas. Una página convincente en el subdominio secuestrado puede recogerlas de los visitantes, incluidas las cookies marcadas como Secure - Uso para phishing
- Como el dominio se comprueba como auténtico, el phishing desde él es mucho más convincente
La mayor idea equivocada: «es HTTPS, tenemos certificado»
La documentación la señala como una idea equivocada frecuente y la rechaza: un atacante que controla el subdominio secuestrado puede solicitar y recibir un certificado válido para él. Un certificado validado por dominio comprueba que el solicitante controla el nombre en ese momento, así que no detecta que el control cambió de manos.
El resultado es que un certificado válido trabaja para el atacante: aparece el candado, las cookies marcadas como Secure se siguen enviando y el sitio falso parece más legítimo, no menos. Lee un certificado como «quién controla este nombre», nunca como «con quién estoy hablando».
Cómo evitarlo: haz que eliminar primero el registro DNS forme parte del procedimiento
La causa no es una dificultad técnica; es el orden de los pasos al dar de baja. Si borras primero el recurso y después el DNS, el subdominio se puede tomar en el intervalo.
El orden que produce incidentes
Borrar el recurso → el DNS después → olvidarlo
Mientras tanto, el DNS sigue anunciando un subdominio activo y legítimo. La monitorización no te avisará de que un servidor se cayó, porque no se cayó nada.
El orden seguro
Eliminar primero el registro DNS → después borrar el recurso
La documentación recomienda aplicar bloqueos de borrado a los recursos que tienen una entrada DNS personalizada, porque el propio bloqueo indica que hay que eliminar la asignación antes de dar de baja el recurso, aunque advierte de que medidas así solo funcionan junto con formación interna.
Pon «eliminar la entrada DNS» en la lista de baja de servicios
Es el primer paso de prevención que da la documentación: ponerlo en la lista de comprobaciones obligatorias al dar de baja un servicio, y enseñar a los desarrolladores a eliminar los registros DNS siempre que borren recursos. La idea es no dejar el orden a la memoria de nadie.
Liga el ciclo de vida del registro al del recurso
Algunos proveedores ofrecen tipos de registro vinculados al propio recurso (registros de alias y similares). Si borras el recurso, el registro queda vacío, así que no puede quedarse atrás un registro que no apunta a nada. Solo cubre ciertos servicios, pero úsalo donde se pueda: evita los registros olvidados por diseño y no por procedimiento.
Exige prueba de propiedad
Algunos servicios permiten publicar un registro TXT de verificación de propiedad para un dominio personalizado. Donde existe, ninguna otra suscripción puede validar ese dominio personalizado ni tomarlo. No impide que alguien cree un recurso con el mismo nombre, pero sin poder demostrar la propiedad no puede recibir tu tráfico. Solo puede usar el nombre quien demuestra que es suyo, no quien lo reclama primero.
Revisa las zonas DNS con regularidad: ¿existe y es tuyo?
La documentación da dos comprobaciones: ¿existe el destino? y ¿es tuyo? La segunda es la que más importa, porque «responde, así que está bien» no es una comprobación: una respuesta que viene del recurso de otra persona es justamente este ataque. Mantén un catálogo de servicios que relacione cada FQDN con su responsable y expórtalo de forma periódica como parte de tu inventario de activos.
Si encuentras uno, no te quedes en borrar el registro
Los pasos de corrección van más allá: actualiza las referencias obsoletas al subdominio en el código de tu aplicación, investiga si hubo un compromiso y averigua por qué no se eliminó el registro al dar de baja el servicio, para que no se repita. En particular, si la lógica de tu aplicación enviaba secretos como credenciales OAuth, o información sensible para la privacidad, a ese subdominio colgante, esos datos pueden haber quedado expuestos a un tercero.
La opinión de este sitio: la exposición viene más de lo que dejaste de usar que de lo que construiste
Las conversaciones sobre seguridad se centran en lo que se está construyendo, mientras que las intrusiones suelen empezar por lo que se retiró y se quedó atrás. Un subdominio que nadie usa, la cuenta de un compañero que se fue, un entorno de pruebas creado para un experimento, los registros de socios que se guardan tras una baja: todos comparten que «ya no lo usamos» los saca en silencio de la monitorización y la revisión. Algo que dejaste de usar sigue siendo un activo hasta que se borra. Por eso defendemos que el inventario abarque todo lo que creaste alguna vez, no solo lo que está en marcha. Las personas que quedaron afectadas por una brecha en un proveedor después de haber cancelado su servicio son un ejemplo del mismo problema (qué hacer cuando tu proveedor de hosting sufre una brecha).
Fuentes (primarias)
- Microsoft, «Prevent dangling DNS entries and avoid subdomain takeover» (Microsoft Learn / fundamentos de seguridad de Azure) — learn.microsoft.com (las tres fases, por qué los CNAME son especialmente vulnerables, el robo de cookies y los registros MX, el rechazo de la idea equivocada sobre el certificado, y los pasos de prevención y corrección (bloqueos de borrado, registros de alias, verificación de propiedad, revisión periódica) proceden de este documento)
Para seguir leyendo
- Inventario: la lista de comprobación del inventario de activos (amplíala a todo lo que creaste alguna vez)
- Ubicación: buckets públicos (la misma forma de «se filtra por configuración»)
- Glosario: qué es el phishing / qué es XSS / qué es CSRF
FAQ
Q¿Una toma de control de subdominio significa que vulneraron mis servidores?
No, y eso es lo que lo hace incómodo. Lo que se toma es el destino al que apunta el DNS, no tu servidor. Si borras un recurso en la nube pero dejas el registro CNAME en tu zona DNS, a un tercero le basta con crear un recurso con el mismo nombre de dominio completo (FQDN) en su propia suscripción, y el tráfico dirigido a tu subdominio llega al suyo. Los parches, la autenticación y la monitorización no ayudan aquí, porque ninguno interviene.
Q¿HTTPS no lo evita? ¿Un certificado no lo hace seguro?
No, y la documentación de Microsoft lo señala directamente como una idea equivocada frecuente: quien controla el subdominio secuestrado puede solicitar y recibir un certificado válido para él. Un certificado validado por dominio solo prueba que quien lo tiene controla ese nombre en ese momento; no dice nada de quién es, ni detecta que el control cambió de manos. De hecho, un certificado válido juega a favor del atacante, porque hace que el sitio falso parezca más legítimo.
QSi solo afecta a la apariencia, ¿el daño no es limitado?
Se filtran las sesiones. Las aplicaciones web suelen exponer las cookies de sesión a los subdominios mediante un comodín (*.example.com), y en ese caso cualquier subdominio puede leerlas. Si se puede llevar a los usuarios al subdominio secuestrado, incluso las cookies marcadas como Secure pueden acabar en manos del atacante. Y un registro MX colgante significa que otra persona puede recibir el correo dirigido a ese subdominio.
Q¿Cómo lo evito en la práctica?
Convierte el orden de borrado en un procedimiento y un mecanismo, no en algo que la gente recuerda. La documentación recomienda poner «eliminar la entrada DNS» en la lista obligatoria al dar de baja un servicio, aplicar bloqueos de borrado a los recursos que tienen una entrada DNS personalizada para que el propio bloqueo indique que primero hay que quitar el DNS, usar tipos de registro cuyo ciclo de vida va ligado al recurso cuando existan, y revisar las zonas DNS con regularidad para confirmar que cada destino existe y que es tuyo.