Hace poco se dio a conocer información sobre la identificaron de 7 vulnerabilidades en el paquete Dnsmasq, que combina un sistema de resolución de DNS en caché y un servidor DHCP, a los que se les asignó el nombre en clave DNSpooq. Los problemas permiten ataques de caché de DNS falsos o desbordamientos de búfer que podrían conducir a la ejecución remota del código de un atacante.

A pesar de que recientemente Dnsmasq ha dejado de utilizarse por defecto como solucionador en distribuciones regulares de Linux, sigue utilizándose en Android y distribuciones especializadas como OpenWrt y DD-WRT, así como en el firmware de routers inalámbricos de muchos fabricantes. En distribuciones normales, el uso implícito de dnsmasq es posible, por ejemplo, cuando se usa libvirt, se puede iniciar para brindar servicio DNS en máquinas virtuales o se puede activar al cambiar la configuración en el configurador de NetworkManager.

Dado que la cultura de actualización de enrutadores inalámbricos deja mucho que desear, los investigadores temen que los problemas identificados puedan permanecer sin resolver durante mucho tiempo y se verán involucrados en ataques automatizados a los enrutadores para obtener control sobre ellos o para redirigir a los usuarios a sitios maliciosos falsos.

Hay aproximadamente 40 empresas basadas en Dnsmasq, incluidas Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE y Zyxel. Se puede advertir a los usuarios de dichos dispositivos que no utilicen el servicio regular de redirección de consultas DNS que se proporciona en ellos.

La primera parte de las vulnerabilidades descubiertas en Dnsmasq se refiere a la protección contra ataques de envenenamiento de caché de DNS, basada en un método propuesto en 2008 por Dan Kaminsky.

Los problemas identificados hacen que la protección existente sea ineficaz y permiten falsificar la dirección IP de un dominio arbitrario en la caché. El método de Kaminsky manipula el tamaño insignificante del campo de identificación de la consulta de DNS, que es solo de 16 bits.

Para encontrar el identificador correcto necesario para suplantar el nombre de host, basta con enviar unas 7.000 solicitudes y simular unas 140.000 respuestas falsas. El ataque se reduce a enviar una gran cantidad de paquetes falsos vinculados a IP al resolutor de DNS con diferentes identificadores de transacciones de DNS.

Las vulnerabilidades identificadas reducen el nivel de entropía de los 32 bits esperados a la necesidad de adivinar 19 bits, lo que hace que un ataque de envenenamiento de caché sea bastante realista. Además, el manejo de los registros CNAME por parte de dnsmasq le permite falsificar la cadena de registros CNAME para falsificar de manera eficiente hasta 9 registros DNS a la vez.

• CVE-2020-25684: falta de validación del ID de solicitud en combinación con la dirección IP y el número de puerto al procesar las respuestas de DNS de servidores externos. Este comportamiento es incompatible con RFC-5452, que requiere que se utilicen atributos de solicitud adicionales al hacer coincidir con una respuesta.
• CVE-2020-25686: Falta de validación de solicitudes pendientes con el mismo nombre, lo que permite que el uso del método de cumpleaños reduzca significativamente el número de intentos necesarios para falsificar una respuesta. En combinación con la vulnerabilidad CVE-2020-25684, esta característica puede reducir significativamente la complejidad del ataque.
• CVE-2020-25685: uso del algoritmo hash CRC32 poco confiable al verificar las respuestas, en el caso de una compilación sin DNSSEC (SHA-1 se usa con DNSSEC). La vulnerabilidad podría usarse para reducir significativamente el número de intentos permitiéndole explotar dominios que tengan el mismo hash CRC32 que el dominio de destino.
• El segundo conjunto de problemas (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 y CVE-2020-25687) es causado por errores que provocan desbordamientos de búfer al procesar ciertos datos externos.
• Para las vulnerabilidades CVE-2020-25681 y CVE-2020-25682, es posible crear exploits que podrían conducir a la ejecución de código en el sistema.

Finalmente se menciona que las vulnerabilidades se abordan en la actualización de Dnsmasq 2.83 y como solución alternativa, se recomienda deshabilitar DNSSEC y el almacenamiento en caché de consultas usando las opciones de línea de comando.

Fuente: https://kb.cert.org