La vulnerabilidad en una frase

Si tu DNS tiene un CNAME o A apuntando a un servicio de terceros que ya no aloja tu contenido, un atacante puede registrar ese servicio bajo tu nombre y servir su contenido desde tu dominio.

Eso es subdomain takeover. Es real, generalizado y se ha usado en incidentes de seguridad serios — campañas de phishing bajo marcas confiables, robo de cookies, bypass de OAuth y más.

El ejemplo concreto

Imagina que el año pasado hiciste esto:

  1. Montaste un sitio de marketing en Heroku en marketing-yourcompany.herokuapp.com.
  2. Añadiste un CNAME: marketing.yourcompany.com → marketing-yourcompany.herokuapp.com.
  3. La campaña terminó. Borraste la app de Heroku.
  4. Olvidaste eliminar el CNAME del DNS.

Ahora cualquiera puede registrarse en Heroku, reclamar el nombre de app marketing-yourcompany, y Heroku servirá su contenido para ese hostname. Tu CNAME sigue apuntando ahí. De repente marketing.yourcompany.com muestra una página de phishing — bajo el candado verde, en tu dominio confiable.

Por qué pasa tan a menudo

Dos razones:

  • Las plataformas cloud permiten reclamar nombres en orden de llegada. Heroku, GitHub Pages, AWS S3, Azure, Bitbucket, Tumblr y decenas más te permiten registrar un hostname (o nombre de proyecto) que mapea a un subdominio estable. No verifican que realmente seas dueño del dominio padre que apunta.
  • Los registros DNS sobreviven a los recursos a los que apuntan. Los ingenieros despliegan recursos cloud, apuntan DNS y luego desaprovisionan sin limpiar DNS. El CNAME queda como reliquia.

Estudios sobre zonas DNS empresariales grandes encuentran rutinariamente decenas o cientos de CNAMEs colgantes por organización. Muchos son vulnerables al takeover.

Patrones de servicios afectados

Cualquier servicio donde:

  • Puedes registrar un subdominio personalizado bajo su dominio (tunombre.service.com).
  • La plataforma sirve tráfico para ese subdominio al registrante.
  • El subdominio vuelve a estar disponible cuando el registrante lo libera o borra.

Objetivos históricamente comunes incluyen:

  • Heroku (*.herokuapp.com)
  • GitHub Pages (*.github.io)
  • AWS S3 (*.s3.amazonaws.com)
  • AWS CloudFront (*.cloudfront.net)
  • Azure (*.azurewebsites.net, *.cloudapp.net)
  • Tumblr (*.tumblr.com)
  • Bitbucket (*.bitbucket.io)
  • Fastly, Squarespace, Helpjuice, Pantheon, etc.

La lista no es estática. Cualquier plataforma con esta arquitectura es un vector potencial. Las plataformas de bug bounty mantienen listas vigentes de servicios actualmente vulnerables.

Qué gana un atacante realmente

No es "vergonzoso". El radio de explosión es real:

  • Phishing bajo tu marca. Una página de login en tu dominio, con HTTPS válido, que envía credenciales al atacante.
  • Robo de cookies. Si tu dominio principal pone cookies para *.yourcompany.com, el atacante en el subdominio takeover puede leerlas.
  • Bypass de OAuth y autenticación. Muchos flujos OAuth confían en subdominios de un origen permitido. Un atacante puede completar flujos OAuth en navegadores de tus usuarios.
  • Daño SEO y de marca. Los buscadores indexan el contenido del atacante bajo tu dominio.
  • Bypass de SPF/DKIM. Si tu infraestructura de correo confía en la identidad del subdominio, el atacante puede enviar "desde" tu dominio pasando autenticación.

Cómo encontrar vulnerabilidades en tu DNS

  1. Exporta tu zona DNS. La mayoría de proveedores ofrecen export de zone-file.
  2. Lista todos los CNAME y ALIAS. Son los candidatos a takeover.
  3. Para cada destino CNAME, comprueba si el recurso existe. Visítalo. Si la plataforma muestra una página de "no such app" / "page not found" / "bucket does not exist" en lugar de tu contenido, tienes un candidato.
  4. Verifica si la plataforma permite re-registrar el destino. Algunas reservan los nombres usados; muchas no.

Herramientas como subjack, SubOver y can-i-take-over-xyz automatizan este escaneo contra los servicios más comunes. Open-source y se ejecutan desde una lista de tus subdominios. Para zonas DNS pequeñas, una revisión manual de 5 minutos atrapa la mayoría.

Cómo arreglarlo

Para cada registro vulnerable:

  • Borra el CNAME o A si ya no usas el recurso. Es la solución canónica.
  • Reclama el recurso si la plataforma permite re-registro. Algunos equipos "aparcan" el recurso en un placeholder seguro en lugar de borrar el registro DNS.
  • Reapunta el registro a un recurso actual y controlado si realmente quieres ese subdominio activo.

Principio general: nunca dejes registros DNS vivir más que los recursos a los que apuntan. Cuando desmantelas un recurso cloud, desmantela el DNS al mismo tiempo.

Cómo prevenirlo a largo plazo

  • Higiene DNS como parte del decommission. Al borrar app de Heroku, bucket S3 o cualquier recurso de terceros, borra también el registro DNS. Hazlo ítem de checklist.
  • Etiqueta registros DNS con su dueño / propósito. La mayoría de proveedores soportan metadata o comentarios. Saber quién creó un registro facilita la limpieza.
  • Auditorías DNS periódicas. Revisión trimestral de todos los registros, foco en CNAMEs apuntando a terceros. Para grandes orgs, escaneo automático.
  • Servicios públicos solo en el ápex. Para reducir superficie máxima, evita apuntar subdominios a terceros salvo que sea necesario activo. Usa rutas bajo tu ápex (yourcompany.com/blog) en vez de subdominios cuando sea posible.
  • Alcance estricto de cookies. Pon cookies en el subdominio que las necesita, no en .yourcompany.com (que las expone a todos los subdominios).
  • Allowlists OAuth con subdominios explícitos. Evita patrones wildcard en OAuth redirect URIs — lista cada subdominio autorizado.

La realidad bug bounty

Subdomain takeover es de las categorías más recompensadas en bug bounty. Empresas grandes pagan 500–5.000$ por vector confirmado. Si tu organización corre bug bounty, espera que investigadores escaneen tu DNS regularmente y reporten hallazgos.

Es buena noticia: hay profesionales identificando issues antes que atacantes. La respuesta correcta es arreglar pronto, no discutir alcance. El coste del bounty es drásticamente menor que un incidente real.

La lista de acción rápida

  1. Lista cada CNAME y ALIAS en tus zonas DNS.
  2. Para cada uno, verifica que el recurso destino sigue existiendo y es tuyo.
  3. Borra o reapunta los que no.
  4. Añade limpieza DNS a tu checklist estándar de decommission.
  5. Programa una revisión trimestral.

La vulnerabilidad suele describirse como "low-hanging fruit" porque genuinamente es fácil de encontrar y arreglar. El coste de no hacer la auditoría es la posibilidad de que alguien la haga por ti — y la reporte con menos responsabilidad que un investigador de bounty.