Registros DNS pendientes: un riesgo de seguridad que se pasa por alto y cómo eliminarlo

¿Qué son los registros DNS colgantes?

Un registro DNS colgante se refiere a cualquier entrada DNS que permanece en la zona DNS de su dominio aunque el destino al que apunta ya no sea válido o esté en uso. Esta situación suele surgir debido a cambios en la infraestructura o los servicios que no van acompañados de las correspondientes actualizaciones del DNS. Entre los escenarios más comunes se incluyen:

• Servicios fuera de servicio: por ejemplo, es posible que tenga un subdominio service.example.com configurado como un CNAME (alias) que apunta a un servicio en la nube (como un host de Azure o Amazon AWS). Si más adelante cierra ese servicio en la nube o lo traslada a otro lugar, pero olvida eliminar o actualizar el registro DNS, service.example.com ya no apunta a nada (el host en la nube ya no existe). Esta entrada huérfana es un registro colgante.
  
  
• Dominios caducados o transferidos: supongamos que su organización tenía un registro DNS que apuntaba a un dominio externo (por ejemplo, el dominio de un proveedor externo) para una función o campaña que ya ha finalizado. Si ese dominio externo caduca o usted ya no lo controla, cualquier registro DNS que siga haciendo referencia a él se convierte en colgante. Lo mismo puede ocurrir si solía ser propietario de un dominio (para un proyecto, etc.) y lo dejó caducar mientras que los registros de otra zona siguen apuntando a él.
  
  
• Cambios en la dirección IP: Los registros A asignan un nombre a una dirección IP. Si la IP de un servidor cambia o se desprovisiona una instancia en la nube, la IP antigua podría volver a liberarse en el grupo. Cualquier registro DNS A que siga apuntando a la IP antigua podría acabar dirigiendo al servidor de otra persona si esa IP se reasigna. La entrada DNS apunta a una IP que no controlas, lo que constituye otra forma de referencia colgante.
• Servidores de nombres o servidores de correo heredados: a veces, las organizaciones cambian de proveedor de DNS o de correo electrónico, pero se olvidan de limpiar todos los registros. Un ejemplo es un registro NS que sigue incluyendo un servidor de nombres antiguo que ya no es autoritativo, o un registro MX que apunta a un host de correo electrónico que ha sido retirado. Estos registros NS o MX no utilizados también son entradas colgantes.

En todos estos casos, las entradas DNS en cuestión ya no están vinculadas a un recurso legítimo y activo bajo su control. Permanecen en sus configuraciones DNS como una puerta trasera desbloqueada, y los atacantes saben cómo encontrarlas y explotarlas.

Para ilustrarlo, imagine que una agencia gubernamental tiene un subdominio app.agency.gov configurado como un CNAME que apunta a app.cloudprovider.com para un servicio web. Si la agencia cierra posteriormente ese servicio y app.cloudprovider.com queda libre, pero el CNAME app.agency.gov se mantiene, un atacante podría registrar un nuevo servicio en app.cloudprovider.com. De repente, el atacante ahora controla app.agency.gov, un subdominio que sigue perteneciendo al dominio de la agencia gubernamental. No se trata de un escenario teórico; estas configuraciones erróneas se han producido en la práctica, lo que pone de relieve cómo los registros DNS colgantes conducen directamente al secuestro de subdominios si no se solucionan.

Por qué son peligrosos los registros DNS pendientes

Los registros DNS pendientes plantean riesgos de seguridad significativos. Cuando un atacante logra hacerse con el control del recurso al que apunta un registro pendiente, obtiene un control parcial de la identidad de su dominio. Estas son las principales amenazas y repercusiones que hay que tener en cuenta:

• Apropiación y suplantación de subdominios: este es el riesgo más notorio. Un actor malintencionado que detecta un registro DNS colgante puede registrar el servicio o dominio no asignado y, por lo tanto, apropiarse de su subdominio. A continuación, podría alojar cualquier cosa en ese subdominio, desde un sitio web de phishing que parece legítimo porque está en su dominio oficial, hasta páginas de inicio de sesión falsas o servicios fraudulentos. A los ojos de los usuarios (o incluso de los filtros de seguridad automatizados), el contenido que se sirve desde un nombre de dominio legítimo del gobierno o de una empresa hereda un nivel de confianza. Los atacantes abusan de esa confianza para suplantar a la organización, lo que puede engañar a los ciudadanos, clientes o empleados.
  
  
• Phishing y distribución de malware: una vez que un atacante controla uno de sus subdominios, puede enviar correos electrónicos de phishing convincentes o distribuir malware bajo la apariencia de su dominio. Por ejemplo, imagine que recibe un correo electrónico de noreply@service.agency.gov: si service.agency.gov fue secuestrado a través de un registro colgante, los atacantes pueden utilizarlo para eludir muchas protecciones contra la suplantación de identidad. Incluso las medidas de seguridad de correo electrónico más robustas, como DMARC, que impiden que personas ajenas suplanten su dominio exacto, pueden no detener los correos electrónicos procedentes de un subdominio legítimo (pero secuestrado). Esto significa que los ataques de phishing pueden parecer más auténticos, lo que aumenta las tasas de éxito.
  
  
• Interceptación de datos y secuestro de sesiones: si el subdominio colgante se utilizó anteriormente para alojar una aplicación, una API o cualquier contenido que intercambiara datos con los usuarios, un atacante puede explotarlo para robar información. Por ejemplo, si api.example.com era un punto final de API que se olvidó, un atacante que lo controle puede recopilar cualquier dato o solicitud enviada a esa API. Del mismo modo, si se toma el control de un subdominio web, cualquier cookie o token de sesión vinculado a ese subdominio (o cookies comodín para *.example.com) podría quedar expuesto. Esto puede dar lugar al secuestro de la sesión del usuario o a la exposición de datos confidenciales sin que el usuario se dé cuenta, ya que está interactuando con un dominio legítimo.
  
  
• Secuestro de correo electrónico a través de registros MX: Un registro MX (registro de intercambio de correo) colgante es especialmente peligroso. Los registros MX dirigen el correo electrónico de su dominio a servidores de correo específicos. Si tenía un MX que apuntaba a un servidor de correo como mail.provider.com y ese dominio caduca o no está bajo su control, un atacante puede hacerse con el control de ese dominio. En consecuencia, podrían empezar a recibir correos electrónicos destinados a su organización (para ese subdominio o dominio). Los correos electrónicos confidenciales podrían ser interceptados, y el atacante podría incluso enviar correos electrónicos como si fueran de la dirección de su organización. Este tipo de violación puede provocar una pérdida significativa de datos y violaciones de la confidencialidad.
  
  
• Manipulación de la zona DNS (registros NS pendientes): Una situación que a menudo se pasa por alto es cuando un antiguo registro DNS NS (delegación del servidor de nombres) queda pendiente. Usted cambió de proveedor de DNS, pero nunca se eliminó el registro NS del servidor del antiguo proveedor, o delegó una subzona a un servidor de nombres que ya no existe. Si un atacante configura un servidor de nombres en ese antiguo nombre de host, puede empezar a responder a las consultas DNS de su dominio o subdominio. Esto supone, en la práctica, el control total del dominio para la parte afectada de su DNS: el atacante puede dirigir cualquier host de ese subdominio a donde quiera (por ejemplo, redirigir el tráfico web o redirigir las comprobaciones de validación). Incluso si tiene varios registros NS, muchos resolutores podrían aceptar respuestas del comprometido, lo que lo convierte en una amenaza grave.
  
  
• Daño a la reputación y erosión de la confianza: Más allá de los peligros técnicos directos, considere el impacto en la reputación. Si un dominio oficial del gobierno o de una empresa de repente sirve malware o phishing, se erosiona la confianza del público. Los usuarios pueden perder la confianza en la seguridad de sus servicios. Para las entidades del sector público, un subdominio secuestrado podría incluso convertirse en un problema de seguridad nacional si se utiliza para desinformación o espionaje. El coste para la credibilidad de la organización puede ser elevado y la recuperación (tanto técnica como de reputación) suele llevar mucho tiempo.

Los registros DNS colgantes no son un error trivial de mantenimiento, sino una vulnerabilidad de seguridad que los adversarios buscan activamente. De hecho, los investigadores de seguridad han descubierto que este problema está muy extendido. Estudios realizados en los últimos años han revelado la existencia de cientos de miles de registros DNS colgantes en Internet, que afectan a organizaciones de todos los tamaños. Se ha descubierto que incluso los dominios bien gestionados de los sectores gubernamental y educativo tienen numerosas entradas pendientes que los atacantes podrían aprovechar. Esto subraya un punto clave: ninguna organización es demasiado grande o demasiado pequeña para pasar por alto la higiene del DNS. La diferencia entre un dominio seguro y uno comprometido a menudo se reduce a un mantenimiento diligente.

Higiene del DNS: prevención y detección de registros pendientes

La buena noticia es que los registros DNS pendientes se pueden prevenir por completo con las prácticas adecuadas, lo que podemos llamar higiene del DNS. Al igual que la higiene regular previene las enfermedades, la higiene del DNS implica limpiar y supervisar regularmente las configuraciones del DNS para mantenerlas sanas y seguras. A continuación se indican las mejores prácticas y medidas para ayudarle a resolver los problemas existentes y prevenir los futuros:

• Auditorías periódicas de DNS: programe revisiones periódicas de todos los registros DNS de sus dominios (incluidos los dominios secundarios y los subdominios). El objetivo es identificar cualquier entrada que apunte a destinos obsoletos o desconocidos. Busque registros que devuelvan un error o no respondan (por ejemplo, CNAME a dominios que no se resuelven o registros A a direcciones IP no utilizadas). Muchas organizaciones realizan estas auditorías trimestral o semestralmente, dependiendo de la frecuencia con la que cambie su infraestructura. Las herramientas modernas de gestión de DNS o los escáneres externos de superficie de ataque pueden ayudar a señalar los registros rotos o sospechosos. Mediante auditorías rutinarias, puede detectar un registro colgante antes que un atacante.
  
  
• Supervise los ciclos de vida de los dominios y los servicios: Es fundamental realizar un seguimiento del ciclo de vida de los servicios y dominios vinculados a su DNS. Mantenga un inventario de los servicios de terceros, los recursos en la nube y los dominios utilizados por su organización. Cuando se desactive un servicio o un dominio esté a punto de caducar, disponga de un proceso para actualizar o eliminar inmediatamente las entradas DNS relacionadas. Por ejemplo, si cierra un servicio de Azure App, asegúrese de que el CNAME de DNS que apunta a él se elimine al mismo tiempo. Si deja de utilizar un producto SaaS que requería una entrada DNS, elimine dicha entrada. Y, por supuesto, esté atento a las fechas de caducidad de los dominios; nunca deje que un dominio caduque si su DNS todavía hace referencia a él.
  
  
• Integre los cambios de DNS en la gestión de cambios: muchos registros pendientes persisten simplemente porque la eliminación de entradas DNS no figuraba en la lista de comprobación cuando se produjo un cambio. Para solucionar esto, incorpore el mantenimiento de DNS en su proceso de gestión de cambios. Cada vez que se migra un servidor, se cambia una dirección IP o se apaga un servicio, debe haber un paso obligatorio para verificar los registros DNS pertinentes. Una política sencilla podría ser que ningún recurso o servicio en la nube se desactive sin confirmar que se han gestionado sus entradas DNS. Esto puede implicar la coordinación entre los equipos de aplicaciones y los administradores de DNS, pero es un paso necesario. Contar con este procedimiento reduce considerablemente la probabilidad de que se pase por alto un registro obsoleto.
  
  
• Utilice las funciones de seguridad del proveedor de nube: Muchos proveedores de nube son conscientes de los problemas de apropiación de subdominios y ofrecen funciones para mitigar las referencias pendientes. Aproveche estas funciones siempre que sea posible. Por ejemplo, Azure DNS ofrece registros «alias» que vinculan una entrada DNS al ciclo de vida de un recurso de Azure: si se elimina el recurso, el registro DNS pasa automáticamente a un estado seguro (o es más fácil de detectar como no resuelto). Azure App Service también proporciona un registro TXT de verificación de dominio opcional (a menudo denominado asuid) que, si se configura, impide que otros clientes de Azure reclamen su nombre DNS en sus servicios. Del mismo modo, algunos proveedores reservan el nombre DNS de un servicio eliminado recientemente durante un breve periodo de tiempo para darle la oportunidad de eliminar las entradas DNS o recuperarlo en su propia cuenta. Aproveche estas funciones cuando estén disponibles, ya que añaden una red de seguridad adicional. Sin embargo, no confíe plenamente en ellas, ya que son un complemento, pero no sustituyen a una buena higiene manual.
  
  
• Escaneo y alertas automatizados: Considere la posibilidad de utilizar herramientas de seguridad o scripts que escaneen automáticamente los registros DNS pendientes. Por ejemplo, los scripts pueden consultar todos sus subdominios para ver si se resuelven en los destinos esperados o si devuelven respuestas NX (dominio inexistente). Algunas plataformas avanzadas de inteligencia sobre amenazas y servicios de seguridad DNS pueden supervisar continuamente su DNS y alertar sobre anomalías, como enlaces rotos recientemente. Si usted es una organización con una gran huella DNS (como muchos subdominios en diferentes proyectos), este tipo de automatización es muy valiosa. Incluso algunas soluciones de seguridad en la nube (como el centro de seguridad del proveedor de nube o las herramientas de gestión de la superficie de ataque de terceros) señalarán específicamente los posibles riesgos de apropiación de subdominios en su DNS. La detección temprana le permite solucionar un problema antes de que un atacante lo encuentre.
  
  
• Limpieza de registros heredados: A lo largo de los años, especialmente en organizaciones grandes o del sector público, las zonas DNS acumulan muchos registros «polvorientos», creados por predecesores o para proyectos olvidados hace tiempo. Es comprensible que los administradores duden a la hora de eliminar algo si no están 100 % seguros de que no se utiliza. Sin embargo, esto conduce a un cementerio de registros colgantes. Cultive la práctica de documentar los propósitos de las entradas DNS y podar aquellas que ya no sean necesarias. Si es posible, implemente un sistema de etiquetado o descripción para los registros DNS (algunas interfaces de gestión de DNS permiten comentarios) para indicar su propietario o función. Si el propósito de un registro no está claro, investigue. En muchos casos, es posible que descubra que, efectivamente, es seguro eliminarlo. Y si realmente no está seguro, al menos márquelo para revisarlo en el futuro o pruebe su uso. Cuantos menos registros perdidos tenga, menor será el objetivo para los atacantes.
  
  
• Mejora de la responsabilidad y la comunicación: A menudo, el DNS abarca varios equipos (desarrollo, operaciones, redes, etc.). Para evitar entradas pendientes, es útil asignar una responsabilidad clara para la gestión del DNS y fomentar la comunicación. Por ejemplo, si un equipo de desarrollo lanza un nuevo servicio externo y añade una entrada DNS para él, pídales que informen al equipo de administración del DNS y que les avisen cuando se elimine ese servicio. Algunas organizaciones aplican una política según la cual cualquier cambio en el DNS debe ir acompañado de un ticket o una solicitud de cambio que documente por qué es necesario. Esto crea un registro de auditoría y facilita la revisión posterior de los registros para determinar si siguen siendo necesarios. Romper los silos entre equipos garantiza que los registros DNS se actualicen como parte integral del despliegue o la retirada de cualquier servicio.