Subdomain takeover: cómo ocurre y cómo evitarlo

Un subdomain takeover (toma de control de un subdominio) ocurre cuando un registro DNS de su zona sigue apuntando a un recurso externo que usted ya no controla y otra persona reclama ese recurso. El caso típico: shop.example.com es un CNAME a una plataforma alojada, la tienda se dio de baja y el registro se quedó. Si la plataforma permite que cualquiera registre el nombre liberado sin demostrar control sobre el dominio, un atacante lo hace y sirve su contenido en su subdominio, con un certificado válido. La solución es aburrida y eficaz: sepa qué registros apuntan fuera de su infraestructura y elimine el registro DNS antes de borrar aquello a lo que apunta. Esta guía cubre las variantes, el impacto, la detección con dig y curl y una lista de prevención.

Cómo funciona una toma de control

No se hackea nada en el sentido habitual. Su DNS dice, con su autoridad, "este nombre se sirve allí", y "allí" es un espacio de nombres compartido con todos los demás clientes de un proveedor. La secuencia:

Usted crea un recurso en un proveedor de nube o SaaS (un contenedor de almacenamiento, una aplicación en una plataforma, un sitio de soporte o una página de aterrizaje) y apunta a él un subdominio con un CNAME.
Más tarde el recurso se elimina: proyecto terminado, suscripción cancelada, cuenta cerrada.
El CNAME se queda en la zona. Nadie es su responsable, nada se lo recuerda a nadie. Esto es un registro colgante (dangling record).
El proveedor vuelve a poner disponible el nombre del recurso antiguo y no comprueba quién controla el dominio que apunta a él.
Un atacante registra ese nombre. Desde ese momento su subdominio entrega el contenido del atacante.

Que el paso 4 sea posible depende del proveedor. Muchos exigen ahora un registro TXT de verificación o reservan los nombres liberados, pero rara vez conoce usted la política de todos los servicios que alguna vez se conectaron a su dominio.

Las variantes

Registro colgante	Qué necesita el atacante	Qué obtiene
CNAME a un recurso de nube o SaaS eliminado	Reclamar el mismo nombre de recurso en el proveedor	Contenido web en el subdominio
CNAME a un host cuyo dominio ha caducado	Registrar ese dominio	Todo lo que hay bajo ese destino del CNAME
Delegación NS de una subzona a un proveedor de DNS donde la zona fue eliminada, o a servidores de nombres bajo un dominio caducado	Crear la zona en ese proveedor, o registrar el dominio del servidor de nombres	Control total de la subzona: todos los tipos de registro, todos los nombres bajo ella. El peor caso
Registro A a una dirección IP de nube liberada	Que le asignen la misma dirección IP: cuestión de suerte y repetición	Contenido web; oportunista más que dirigido
Registro MX a un servicio de correo dado de baja	Reclamar el dominio en ese servicio de correo	El correo entrante del subdominio

Por qué importa más que una página desfigurada

Un subdominio de su dominio hereda una confianza que un dominio parecido nunca consigue:

Phishing bajo su nombre real. login-help.example.com supera cualquier formación de "compruebe la barra de direcciones".
Cookies. Las cookies definidas con Domain=example.com las envía el navegador a todos los subdominios, incluido el que ahora opera el atacante. Según los atributos, eso puede incluir cookies de sesión.
Listas de permitidos que confían en *.example.com. Las configuraciones CORS, los orígenes de Content Security Policy, los URI de redirección de OAuth y los ajustes de inicio de sesión único confían a menudo en el dominio entero. Un subdominio tomado está dentro de esa confianza.
Certificados de confianza pública. Quien controla el contenido de un nombre de host puede superar la validación de dominio por HTTP y obtener un certificado válido para él.
Correo. Con un MX colgante, el correo dirigido al subdominio se entrega al atacante, incluidos los restablecimientos de contraseña de cuentas registradas con esas direcciones.

Cómo encontrar registros colgantes

Empiece por su zona, no desde fuera (los tipos de registro se explican en tipos de registros DNS). Exporte todas las zonas que tenga y liste los registros cuyo destino no es su propia infraestructura: CNAME a otros dominios, delegaciones NS, registros MX y registros A/AAAA en rangos de direcciones de proveedores de nube.

Después pruebe cada uno.

CNAME. Resuelva el destino. Un destino que no existe es la señal más clara:

$ dig +short CNAME shop.example.com
promo-example.cloudhost.example.

$ dig promo-example.cloudhost.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4711

NXDOMAIN para el destino significa que el registro apunta a nada. Si el destino resuelve (muchas plataformas responden a cualquier nombre con un comodín), mire la respuesta HTTP:

$ curl -sI https://shop.example.com | head -n 1
HTTP/2 404

Una página genérica del proveedor del tipo "no existe ese sitio", "no existe ese contenedor" o "aquí todavía no hay nada" en su subdominio significa que el recurso que hay detrás ha desaparecido. Compruebe también que el dominio de cada destino de CNAME sigue registrado y pertenece al proveedor que espera.

Delegaciones NS. Pregunte directamente a cada servidor de nombres delegado, sin recursión, si es autoritativo para la subzona:

$ dig +short NS sub.example.com
ns1.dns-host.example.
ns2.dns-host.example.

$ dig @ns1.dns-host.example sub.example.com SOA +norec
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1289

REFUSED, SERVFAIL o una respuesta sin el indicador aa significa que ese servidor no tiene su zona. Ninguna respuesta en absoluto puede ser un problema de red: repita la prueba antes de sacar conclusiones.

Nombres que olvidó. La exportación de la zona encuentra registros; no encuentra zonas que olvidó que tenía, ni nombres creados por otro equipo en otro proveedor de DNS. Aquí ayudan los registros de Certificate Transparency: todo certificado de confianza pública queda registrado, así que revelan nombres de host que alguna vez obtuvieron un certificado. También revelan certificados que usted no solicitó, que es la huella que deja una toma de control.

Prevención

Orden de las operaciones. Esta única regla evita la mayoría de los casos:

Al dar de baja: elimine primero el registro DNS, espere a que pase el TTL y después borre el recurso.
Al dar de alta: cree y verifique primero el recurso, y añada el registro DNS en último lugar.

Asigne responsables a los registros. Haga los cambios de DNS con revisión, idealmente como infraestructura como código en el mismo repositorio que el recurso al que apuntan, de modo que borrar el recurso y borrar el registro sean un solo cambio.

Elija proveedores que verifiquen el dominio. Un proveedor que exige un registro TXT de verificación de dominio antes de servir un dominio personalizado no puede ser usado por un desconocido para este ataque.

Evite los CNAME comodín hacia terceros. *.example.com CNAME something.provider.example convierte cualquier nombre posible en candidato.

Limite lo que puede hacer un subdominio. Use cookies restringidas al host (sin atributo Domain) para las sesiones. Liste orígenes exactos en las listas de permitidos de CORS, CSP y redirecciones OAuth en lugar de *.example.com.

Sepa qué hace CAA y qué no. Un registro CAA restringe qué autoridades de certificación pueden emitir para sus nombres. No detiene una toma de control: el atacante simplemente usa una CA que usted permite. El complemento útil es vigilar Certificate Transparency en busca de certificados que nadie de su lado solicitó. Los detalles están en registros CAA explicados.

Lista de comprobación

Todas las zonas en todos los proveedores de DNS están identificadas y exportadas.
Cada registro CNAME, NS, MX y A/AAAA hacia IP de nube tiene un responsable y una finalidad con nombre.
Cada destino externo de CNAME resuelve, y su dominio está registrado a nombre del proveedor esperado.
Cada subzona delegada recibe respuesta autoritativa de todos sus servidores de nombres.
El procedimiento de baja dice: primero el registro DNS, después el recurso.
Ningún CNAME comodín apunta a un tercero.
Las cookies de sesión están restringidas al host; las listas de permitidos nombran hosts exactos.
Se revisan los registros CT en busca de nombres de host desconocidos y certificados inesperados.

Si encuentra uno

Elimine el registro colgante de inmediato (o, si el servicio sigue siendo necesario, vuelva a crear primero el recurso en su propia cuenta). Eliminar el registro acaba con la exposición en cuanto expiran las cachés.
Averigüe si ya fue reclamado. ¿Qué sirve el subdominio ahora mismo?
Si lo fue: trate como expuestas las cookies con alcance en el dominio padre e invalide las sesiones. Revise las listas de permitidos que incluían el subdominio.
Revise los registros CT en busca de certificados emitidos para ese nombre durante la exposición y pida a la CA emisora que revoque los que usted no solicitó.
Corrija el proceso que dejó el registro atrás y después audite el resto de la zona: los registros colgantes rara vez vienen solos.

Ética y ley

Pruebe solo dominios de los que sea responsable o que esté autorizado por escrito a evaluar. Consultar DNS público es inofensivo. Reclamar el recurso que hay detrás del registro colgante de otra persona es un acto distinto: estaría sirviendo contenido bajo su nombre y posiblemente recibiendo las cookies o el correo de sus usuarios. Eso es acceso no autorizado, incluso con una página de "prueba" inofensiva y buenas intenciones. Si observa un registro colgante en un dominio que no es suyo, comuníqueselo al propietario a través del contacto de su archivo security.txt (el comprobador de security.txt muestra si hay uno publicado) y no vaya más allá.

Errores frecuentes

Borrar primero el recurso en la nube y "limpiar el DNS más tarde".
Auditar solo la zona principal y olvidar las subzonas delegadas.
Confiar en *.example.com en los ajustes de CORS, CSP u OAuth.
Creer que un registro CAA impide las tomas de control.

Compruébelo con OrbitProbe

El buscador de subdominios de OrbitProbe lista los nombres de host bajo un dominio que aparecen en los registros públicos de Certificate Transparency, con la fecha del certificado más reciente de cada uno. Es un registro de certificados, no de DNS: un nombre listado puede haber dejado de existir, y un nombre que solo usó certificados comodín faltará, así que complementa la exportación de la zona en lugar de sustituirla. Úselo en los dominios de los que sea responsable para detectar hosts olvidados y certificados que nadie recuerda haber pedido, y después siga cada nombre desconocido con una consulta DNS para ver adónde apunta hoy.