DNS colgante: cómo encontrarlo y solucionarlo antes de una apropiación

El DNS colgante es uno de esos problemas que es fácil de crear y genuinamente difícil de detectar. Un registro sigue apuntando a un recurso en la nube después de que dicho recurso ha desaparecido, y a menos que algo lo esté vigilando, nadie se da cuenta hasta que se convierte en un problema. La buena noticia es que no tienes que resolver esto desde cero. Dos de las fuentes más creíbles en seguridad, OWASP y AWS, documentan por qué ocurre el DNS colgante y qué hacer al respecto. Este blog cubre el riesgo, lo que dice cada uno, cómo poner en práctica sus recomendaciones y dónde se encuentran las brechas de herramientas que dejan expuestos a la mayoría de los equipos.

Resumen ejecutivo: Los registros DNS colgantes permiten a los atacantes apropiarse de un subdominio sin vulnerar nada. Tanto OWASP como AWS documentan el problema y la solución, y la guía actualizada de NIST ahora lo menciona directamente. La solución es sencilla por registro. La parte difícil es encontrar registros colgantes de forma continua en un entorno real con múltiples registradores y nubes, que es la brecha que Red Sift puede cubrir.

Puntos clave:

• Un registro DNS colgante apunta a un recurso en la nube que ha sido eliminado. Si el nombre del recurso puede reclamarse, un atacante puede servir su propio contenido en tu subdominio.
• Esto no es señal de un equipo descuidado. Es un efecto secundario estructural de la rapidez con la que se crean y retiran los recursos en la nube.
• Tanto OWASP como AWS documentan el problema, por lo que existe una guía clara y creíble a seguir.
• AWS es sincero al reconocer que su plataforma no cierra esta brecha por ti: nombres de recursos reclamables, sin un mecanismo universal de verificación de dominio, y atacantes que ya escanean en busca de registros colgantes.
• La solución es sencilla por registro. Lo difícil es el descubrimiento continuo en un entorno con múltiples registradores y múltiples nubes, que es donde ayuda Red Sift Attack Surface Management.

Un registro DNS colgante es una entrada DNS, normalmente un CNAME (Canonical Name, que crea un alias de un nombre a otro), que sigue apuntando a un recurso en la nube después de que ese recurso ha sido eliminado. El servicio ha desaparecido. El registro, no. En muchas plataformas de nube, el nombre del recurso vuelve entonces a un grupo compartido que cualquier cliente puede reclamar. Un atacante que recrea un recurso con ese nombre hereda tu subdominio, porque tu DNS sigue enviando tráfico allí.

Sin vulneración, sin contraseña robada. El registro simplemente sobrevive al recurso, y el hueco que deja es reclamable.

El motivo por el que esto importa más que una página rota es la confianza que tu dominio ya conlleva. Un subdominio que tus clientes, navegadores y sistemas de correo tratan como tuyo pasa a estar controlado por el atacante. Esto abre la puerta al phishing en un dominio que la gente reconoce, al robo de cookies de sesión con alcance al dominio principal, al secuestro de flujos de inicio de sesión OAuth y SSO, y a certificados TLS válidos emitidos a tu nombre mediante comprobaciones de validación de dominio. Si la cadena del registro afecta al correo, también puede significar restablecimientos de contraseña interceptados. Este es el escenario de "apropiación".

OWASP, la comunidad de estándares neutral respecto a proveedores, trata la apropiación de subdominios como un problema operativo más que como un fallo de software, y su punto más útil es también el más sencillo. La mayoría de las organizaciones no tienen forma de detectar cuándo el objetivo de un registro DNS deja de existir en silencio. Ese es el estado por defecto, no un fallo de diligencia. El registro y el recurso se desvían el uno del otro, nada los reconcilia, y el hueco permanece abierto hasta que alguien tropieza con él.

La guía de prevención de OWASP es clara y práctica: mantén un inventario de a qué apuntan tus registros, elimina los registros antes que los recursos de los que dependen, y vigila las cadenas de error del proveedor que devuelve un recurso muerto antes de que alguien lo reclame. Es un buen consejo, aplicable, y además es gratis.

AWS documenta esto en su propia guía de seguridad, y vale la pena reconocer su franqueza. Reconoce abiertamente que la plataforma no cierra esta brecha por ti, y da tres razones para ello:

• Muchos servicios de AWS permiten que un nuevo cliente reclame un nombre de host o de recurso previamente utilizado.
• AWS actualmente no ofrece un mecanismo universal de verificación de dominio en todos sus servicios.
• Los equipos de respuesta a incidentes de AWS observan atacantes escaneando activamente el DNS público en busca de registros CNAME que apuntan a recursos que ya no existen.

Ese último punto importa. No es un riesgo teórico esperando en una lista de pendientes. Es un comportamiento de escaneo activo, que ocurre ahora mismo.

Aquí está la distinción útil entre las dos voces. OWASP no es AWS, así que puede aconsejar pero no puede cambiar cómo funciona la nube. AWS podría añadir controles universales, como la verificación de dominio, que neutralizarían la mayor parte de esto, pero por ahora no ha optado por hacerlo. Eso deja una brecha real entre lo que los proveedores te entregan y lo que necesitas para permanecer protegido. No es una brecha que tú hayas creado, y cerrarla no requiere esperar a que un proveedor actúe. Requiere visibilidad, y la visibilidad es algo que puedes añadir hoy mismo.

Seguir este consejo para un registro en el que estás pensando activamente es fácil. Aplicarlo en todo un entorno que no puedes ver por completo es la parte difícil. La nube cambió para qué se usa el DNS, y los entornos crecieron con ella. En una empresa real, un solo dominio raíz reveló más de 25.000 subdominios, con la propiedad repartida entre infraestructura, marketing, desarrolladores, proveedores SaaS y proveedores de nube. Ningún equipo puede ver todo eso manualmente.

Así que la respuesta no es una limpieza puntual. Es un modelo operativo repetible. Estas cinco etapas, alineadas con los temas de NIST, convierten la guía en algo que realmente puedes ejecutar.

1. Inventario. Descubre cada dominio, cada zona, cada registro, sin importar quién lo gestione: múltiples registradores, múltiples proveedores DNS, multi-nube y múltiples autoridades de certificación. No puedes proteger lo que no has encontrado.
2. Línea base. Caracteriza cómo se ve lo correcto: los registradores y proveedores DNS que apruebas, tus rangos de nube y autoridades de certificación aprobados, tu postura de autenticación de correo electrónico, y dónde firmas con DNSSEC. Sin una línea base, todos los cambios parecen iguales y nada parece sospechoso.
3. Detectar y clasificar. Saca a la luz cambios inesperados y suprime el ruido esperado. Aproximadamente el 1% de los nombres cambia diariamente, lo que equivale a unos 375 eventos al día. La clasificación es lo único que hace esto operable.
4. Evaluar continuamente. Ejecuta el entorno contra los temas de NIST SP 800-81r3: proteger el servicio DNS, amenazas de transferencia de zona, contenido y consistencia de zona, minimizar la fuga de información, integridad de dominio externo, y firma y validación DNSSEC.
5. Priorizar. Clasifica el entorno por niveles para que el modelo se mantenga sostenible. No todo necesita la misma atención.

Haz esto y el consejo de inventario de OWASP y el consejo de "elimina el registro antes que el recurso" de AWS dejan de ser aspiraciones. Se convierten en pasos que puedes medir y repetir.

La etapa que hace tropezar a todos es la primera, porque no puedes inventariar ni monitorizar lo que no puedes ver, y ni los proveedores ni las herramientas gratuitas te dan una visión completa. Las comprobaciones de configuración nativas de la nube son útiles, pero están diseñadas para una sola cuenta y una sola nube. Los escáneres de código abierto cubren más terreno, pero solo se ejecutan cuando te acuerdas de ejecutarlos. Los registros que acaban siendo apropiados raras veces son aquellos en los que estás pensando. Son los que olvidaste, los que heredaste en una adquisición, o los que nunca supiste que existían.

Red Sift ASM (Attack Surface Management) cubre las brechas que dejan abiertas las plataformas. Descubre dominios y subdominios en toda tu huella externa, inspecciona configuraciones de DNS, web y nube, y marca registros colgantes y recursos reclamables en cuanto aparecen, en todos los registradores y nubes en lugar de una cuenta a la vez. En efecto, te ofrece la capa de verificación continua que AWS no ofrece, aplicada a todo tu entorno.

Una buena higiene DNS, eliminar el registro antes que el recurso, es la primera línea de defensa, y tanto OWASP como AWS te ofrecen un buen manual para lograrlo. El descubrimiento continuo es lo que atrapa los registros que se escapan de todos modos. No necesitas esperar a que un proveedor cierre la brecha para adelantarte a ella.

Descubre a qué apunta tu DNS con Red Sift ASM o explora el conjunto completo de guías de Red Sift para saber más sobre la gestión del riesgo de DNS y certificados.