Los creadores de BIND, el software más utilizado en Internet para la resolución de nombres de dominio, han alertado sobre dos vulnerabilidades que permiten a los atacantes envenenar cachés enteras de resultados y redirigir a los usuarios a destinos maliciosos que son indistinguibles de los legítimos.
Las vulnerabilidades, identificadas como CVE-2025-40778 y CVE-2025-40780, se originan en un error de lógica y una debilidad en la generación de números pseudoaleatorios, respectivamente. Ambas tienen una calificación de severidad de 8.6. Por otra parte, los creadores del software de resolución del Sistema de Nombres de Dominio (DNS) Unbound advirtieron sobre vulnerabilidades similares que fueron reportadas por los mismos investigadores. La puntuación de severidad de la vulnerabilidad de Unbound es de 5.6.
Revisión del ataque de envenenamiento de caché de Kaminsky
Las vulnerabilidades pueden ser explotadas para provocar que los resolutores DNS ubicados dentro de miles de organizaciones reemplacen los resultados válidos de las búsquedas de dominio con resultados corruptos. Los resultados corruptos reemplazarían las direcciones IP controladas por el operador del nombre de dominio (por ejemplo, 3.15.119.63 para arstechnica.com) con direcciones maliciosas controladas por el atacante. Los parches para las tres vulnerabilidades estuvieron disponibles el miércoles.
En 2008, el investigador Dan Kaminsky reveló una de las amenazas de seguridad más graves a nivel de Internet. Conocido como envenenamiento de caché DNS, permitía a los atacantes enviar usuarios en masa a sitios impostores en lugar de los reales pertenecientes a Google, Bank of America o cualquier otra entidad. Con la coordinación de toda la industria, miles de proveedores de DNS en todo el mundo, en coordinación con los creadores de navegadores y otras aplicaciones cliente, implementaron una solución que evitó este escenario apocalíptico.
La vulnerabilidad fue el resultado del uso de paquetes UDP por parte de DNS. Debido a que se envían en una sola dirección, no había forma de que los resolutores DNS utilizaran contraseñas u otras formas de credenciales al comunicarse con “servidores autorizados”, es decir, aquellos que han sido designados oficialmente para proporcionar búsquedas de IP para un dominio de nivel superior dado, como .com. Además, el tráfico UDP generalmente es trivial de suplantar, lo que significa que es fácil enviar paquetes UDP que parecen provenir de una fuente distinta de su verdadero origen.
Para garantizar que los resolutores aceptaran resultados solo de servidores autorizados y para bloquear cualquier resultado envenenado que pudiera ser enviado por servidores no autorizados, los resolutores adjuntaban un número de 16 bits a cada solicitud. Los resultados del servidor eran rechazados a menos que incluyeran la misma ID.
Lo que Kaminsky se dio cuenta fue que solo había 65,536 posibles ID de transacción. Un atacante podría explotar esta limitación inundando un resolutor DNS con resultados de búsqueda para un dominio específico. Cada resultado usaría una ligera variación en el nombre de dominio, como 1.arstechnica.com, 2.arstechnica.com, 3.arstechnica.com, y así sucesivamente. Cada resultado también incluiría una ID de transacción diferente. Eventualmente, un atacante reproduciría el número correcto de una solicitud pendiente, y la IP maliciosa se alimentaría a todos los usuarios que confiaban en el resolutor que hizo la solicitud. El ataque se denominó envenenamiento de caché DNS porque contaminaba el almacén de búsquedas del resolutor.
El ecosistema DNS finalmente solucionó el problema aumentando exponencialmente la cantidad de entropía requerida para que se aceptara una respuesta. Mientras que antes, las búsquedas y las respuestas viajaban solo a través del puerto 53, el nuevo sistema seleccionaba aleatoriamente cualquiera de los miles de puertos potenciales. Para que un resolutor DNS aceptara una respuesta, tenía que viajar a través de ese mismo número de puerto. Combinado con un número de transacción, la entropía se midió en miles de millones, lo que hizo matemáticamente inviable para los atacantes aterrizar en la combinación correcta.
Al menos una de las vulnerabilidades de BIND, CVE-2025-40780, debilita efectivamente esas defensas.
“En circunstancias específicas, debido a una debilidad en el Generador de Números Pseudoaleatorios (PRNG) que se utiliza, es posible que un atacante prediga el puerto de origen y la ID de consulta que utilizará BIND”, escribieron los desarrolladores de BIND en la divulgación del miércoles. “BIND puede ser engañado para almacenar en caché las respuestas del atacante, si la suplantación tiene éxito”.
CVE-2025-40778 también plantea la posibilidad de revivir los ataques de envenenamiento de caché.
“Bajo ciertas circunstancias, BIND es demasiado indulgente al aceptar registros de respuestas, lo que permite a un atacante inyectar datos falsificados en la caché”, explicaron los desarrolladores. “Los registros falsificados se pueden inyectar en la caché durante una consulta, lo que podría afectar la resolución de futuras consultas”.
Incluso en tales casos, las consecuencias resultantes
Fuente original: ver aquí