As vulnerabilidades atopadas en Dnsmasq permitiron falsificar contido na caché DNS

Recentemente, información sobre o identificou 7 vulnerabilidades no paquete Dnsmasq, que combina un resolver DNS na caché e un servidor DHCP, aos que se lles asignou o nome en clave DNSpooq. O problemaPermiten ataques de caché DNS desbordados ou desbordamentos de búfer que podería levar á execución remota do código dun atacante.

Aínda que hai pouco Dnsmasq xa non se usa por defecto como solucionador nas distribucións normais de Linux, aínda se usa en Android e distribucións especializadas como OpenWrt e DD-WRT, así como firmware para routers sen fíos de moitos fabricantes. Nas distribucións normais, o uso implícito de dnsmasq é posible, por exemplo cando se usa libvirt, pódese comezar a proporcionar servizo DNS en máquinas virtuais ou pódese activar cambiando a configuración no configurador de NetworkManager.

Dado que a cultura de actualización de enrutador sen fíos deixa moito que desexar, Os investigadores temen que os problemas identificados poidan seguir sen resolverse durante moito tempo e estará involucrado en ataques automatizados a routers para conseguir control sobre eles ou redirixir usuarios a sitios maliciosos canallas.

Hai aproximadamente 40 empresas baseadas en Dnsmasq, incluídos Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE e Zyxel. Pódese advertir aos usuarios destes dispositivos de non usar o servizo regular de redirección de consultas DNS que se lles proporciona.

A primeira parte das vulnerabilidades descuberto en Dnsmasq refírese á protección contra ataques de envelenamento da caché DNS, baseado nun método proposto en 2008 por Dan Kaminsky.

Os problemas identificados fan que a protección existente sexa ineficaz e permiten falsificar a dirección IP dun dominio arbitrario na caché. O método de Kaminsky manipula o tamaño insignificante do campo de ID de consulta DNS, que é só 16 bits.

Para atopar o identificador correcto necesario para falsificar o nome do servidor, só tes que enviar preto de 7.000 solicitudes e simular unhas 140.000 respostas falsas. O ataque resúmese en enviar unha gran cantidade de paquetes falsos vinculados á IP ao resolver DNS con diferentes identificadores de transaccións DNS.

As vulnerabilidades identificadas reducen o nivel de entropía de 32 bits Espérase que teña que adiviñar 19 bits, o que fai que un ataque de intoxicación por caché sexa bastante realista. Ademais, o manexo de rexistros CNAME de dnsmasq permítelle falsificar a cadea de rexistros CNAME para falsificar de xeito eficiente ata 9 rexistros DNS á vez.

• CVE-2020-25684: falta de validación do ID de solicitude en combinación co enderezo IP e o número de porto ao procesar respostas DNS de servidores externos. Este comportamento é incompatible con RFC-5452, que require que se empreguen atributos de solicitude adicionais ao coincidir cunha resposta.
• CVE-2020-25686: Falta de validación de solicitudes pendentes co mesmo nome, o que permite o uso do método de aniversario para reducir significativamente o número de intentos necesarios para falsificar unha resposta. En combinación coa vulnerabilidade CVE-2020-25684, esta característica pode reducir significativamente a complexidade do ataque.
• CVE-2020-25685: uso de algoritmo de hash CRC32 non fiable ao verificar respostas, en caso de compilación sen DNSSEC (SHA-1 úsase con DNSSEC). A vulnerabilidade podería usarse para reducir significativamente o número de intentos permitíndolle explotar dominios que teñen o mesmo hash CRC32 que o dominio de destino.
• O segundo conxunto de problemas (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 e CVE-2020-25687) é causado por erros que provocan desbordamentos de búfer ao procesar determinados datos externos.
• Para as vulnerabilidades CVE-2020-25681 e CVE-2020-25682, é posible crear exploits que poidan levar á execución de código no sistema.

Finalmente menciónase que as vulnerabilidades son abordadas na actualización de Dnsmasq 2.83 e como solución alternativa, recoméndase desactivar DNSSEC e consultar a caché mediante opcións da liña de comandos.

Fuente: https://kb.cert.org