Z
ZoneSanity Consola v1.3.0
Seguridad Perimetral DNS • Prevención de Apoderamiento de Subdominios

Higiene de Registros CNAME y Prevención de Apoderamiento de Subdominios

Publicado por el equipo técnico de ZoneSanity • Guía de Seguridad Perimetral

1. Anatomía del Apoderamiento de Subdominios (Dangling CNAME)

Un CNAME Huérfano (Dangling CNAME) ocurre cuando un registro Alias DNS en la zona de autoridad de una organización apunta a un nombre de dominio externo proporcionado por una plataforma de servicios en la nube (como AWS S3, GitHub Pages, Heroku, Shopify o Azure App Service), pero el recurso subyacente en dicha plataforma ha sido eliminado o dado de baja sin eliminar el registro DNS correspondiente.

En este escenario, cualquier atacante puede registrar la misma instancia dada de baja en la plataforma SaaS objetivo (reclamando el nombre de bucket o aplicación) y tomar control total del subdominio corporativo (blog.empresa.com).

2. Matriz de Fingerprints de Proveedores SaaS Vulnerables

Cada plataforma de infraestructura en la nube devuelve un mensaje de error característico (Fingerprint HTTP o DNS) cuando recibe peticiones destinadas a un dominio alias cuyo recurso interno no ha sido reclamado:

Plataforma Cloud / SaaS Patrón CNAME FQDN Objetivo HTTP Fingerprint de Vulnerabilidad
Amazon Web Services (S3) *.s3.amazonaws.com <Code>NoSuchBucket</Code>
GitHub Pages *.github.io 404 There isn't a GitHub Pages site here.
Heroku Applications *.herokuapp.com No such app - Heroku
Microsoft Azure App Service *.azurewebsites.net 404 Web App - Not Found.

3. Vector de Ataque: Extracción de Cookies y Phishing de Alta Confianza

La severidad técnica de un apoderamiento de subdominio es catalogada como Crítica (CVSS 8.5+) debido a los siguientes impactos:

Riesgos Directos de Seguridad:
  • Robo de Cookies de Sesión (Session Hijacking): Si las cookies HTTP corporativas utilizan la etiqueta Domain=.empresa.com, el atacante alojado en subdominio.empresa.com puede leer los tokens de autenticación de los usuarios.
  • Bypass de Políticas CSP (Content Security Policy): Muchos sitios principales confían implícitamente en scripts servidos desde sus propios subdominios (script-src *.empresa.com).
  • Phishing Cero-Defecto: El atacante emite un certificado SSL legítimo (Let's Encrypt) para el subdominio y aloja un portal de suplantación totalmente creíble.

4. Auditoría Automática mediante CLI (`dig` y `curl`)

Para auditar en la línea de comandos si un subdominio presenta un alias huérfano:

# 1. Obtener el destino CNAME del subdominio
$ dig +short CNAME docs.tudominio.com
tudominio.github.io.
# 2. Verificar si el destino resuelve direcciones IP en el DNS
$ dig +short A tudominio.github.io.
<Respuesta Vacía / NXDOMAIN>
# 3. Comprobar la respuesta HTTP para detectar la firma de error
$ curl -s -I https://docs.tudominio.com | head -n 5
HTTP/2 404
X-GitHub-Request-Id: 8A12:2841:4F21A

5. Procedimientos de Desaprovisionamiento DNS y Mejores Prácticas

Para eliminar completamente el riesgo de apoderamiento de subdominios, la ingeniería DevSecOps debe integrar la siguiente regla de oro en su ciclo de vida de infraestructura:

Regla de Oro DevSecOps:

"Primero elimine el registro CNAME en el DNS; sólo después proceda a eliminar la instancia o bucket en el proveedor SaaS."

Auditar Higiene CNAME & Riesgo Takeover
Escanee la zona de su dominio para detectar registros CNAME dirigidos a buckets o apps SaaS inexistentes.