MaginotDNS es un poderoso ataque de envenenamiento de caché contra servidores DNS

Durante la conferencia de «Black Hat USA 2023» que se celebro hace pocos días, un grupo de investigadores dieron a conocer información sobre una vulnerabilidad que descubrieron y que tiene como nombre clave «MaginotDNS».

Sobre la vulnerabilidad «MaginotDNS» se menciona que permite la sustitución de registros NS incorrectos en el caché de los servidores DNS, que se utilizan simultáneamente para redireccionar solicitudes y resolución de nombres. Un ataque exitoso puede dar lugar al acceso a servidores DNS incorrectos que brindan información falsa sobre el dominio de destino, y el atacante puede reemplazar zonas DNS completas, incluidas las de los dominios de nivel superior.

A través de pruebas de campo, encontramos que el ataque es potente, lo que permite a los atacantes apoderarse de zonas DNS completas , incluidos los dominios de nivel superior (p. ej., .com y .net ). A través de un estudio de medición a gran escala, también confirmamos el uso extensivo de CDNS en redes del mundo real (hasta el 41,8 % de nuestros servidores DNS abiertos probados) y descubrimos que al menos el 35,5 % de todos los CDNS son vulnerables a MaginotDNS.

Los investigadores mencionan que la posibilidad de spoofing de registros NS para otro dominio se origina por un error en el algoritmo de validación de Bailiwick utilizado en los servidores DNS, el cual no permite la aceptación de servidores de nombres que no estén directamente asociados al dominio solicitado.

En una situación en la que el servidor DNS puede funcionar en los modos de resolución y reenvío al mismo tiempo, la verificación de Bailiwick se realiza solo en el modo de resolución, pero no se usa en el modo de «forwarder». Dado que ambos modos usan una caché de servidor DNS común, esta función se puede usar para falsificar registros de solicitudes en el modo de resolución a través del envenenamiento de la caché cuando se manipulan solicitudes y respuestas en el modo «forwarder».

Nuestro estudio llama la atención sobre la inconsistencia en la implementación de la lógica de verificación de seguridad en diferentes modos de servidor y software de DNS (es decir, resolutores y reenviadores recursivos), y solicitamos la estandarización y los acuerdos entre los proveedores de software.

Dentro de las pruebas de concepto, los investigadores propusieron dos variantes del ataque:

1. La primer variante es «off-path», y puede ser viable cuando el atacante no puede interceptar el tráfico entre el servidor DNS atacado y el servidor DNS ascendente utilizado como «forwarder-а»
2. El segundo ataque propuesto es «on-path» y este puede ser viable cuando un atacante puede interceptar solicitudes de DNS entre el servidor DNS atacado y el forwarder.

En el modo «on-path», cuando el atacante recibió información sobre el número de puerto de red de la solicitud de DNS saliente durante el análisis de tráfico, el ataque realizó una solicitud para el dominio controlado por el atacante, lo que lleva a una llamada al servidor DNS de los atacantes y, al mismo tiempo, se envían respuestas ficticias con datos sobre registros NS para el dominio «.com», que se almacenan en caché.

En marzo de 2022, los investigadores realizaron un análisis de red global que identificó 154 955 servidores DNS de acceso público potencialmente atacables que operan simultáneamente en modo de redirección y resolución. De estos, 54949 servidores DNS (35,5%) usaban software vulnerable.

Todos los servidores DNS vulnerables fueron objeto de un ataque «on-path», que se llevó a cabo cuando se pudo interceptar el tráfico entre el servidor DNS y el forwarder. La variante de ataque «off-path», en la que el atacante no controlaba el tráfico, afectó al 88,3% de los servidores vulnerables.

Ademas de ello, se informa que el ataque ha sido confirmado para servidores DNS tales como BIND, Knot, Technitium y Microsoft DNS, mientras que por la parte de los servidores Unbound, MaraDNS y PowerDNS no se ven afectados por el ataque. En BIND (CVE-2021-25220) y Knot (CVE-2022-32983), las vulnerabilidades de ataque se corrigieron a principios de 2022.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.