Vulnerabilidades encontradas no Dnsmasq permitiram falsificação de conteúdo no cache DNS

Informações recentemente divulgadas referem-se à identificação de sete vulnerabilidades no pacote Dnsmasq, que combina um resolvedor DNS com cache e um servidor DHCP, codinome DNSpooq. Esses problemas permitem ataques de cache DNS falso ou estouros de buffer que podem levar à execução remota de código por um invasor.

Embora o Dnsmasq tenha sido recentemente descontinuado como resolvedor padrão nas distribuições Linux padrão, ele ainda é usado no Android e em distribuições especializadas como OpenWrt e DD-WRT, bem como no firmware de muitos roteadores sem fio. Nas distribuições padrão, o uso implícito do dnsmasq é possível; por exemplo, ao usar o libvirt, ele pode ser iniciado para fornecer serviço DNS em máquinas virtuais ou habilitado alterando as configurações no configurador do NetworkManager.

Dado que a cultura de atualização de roteadores sem fio deixa muito a desejar, os pesquisadores temem que os problemas identificados permaneçam sem solução por um longo tempo e se tornem alvo de ataques automatizados a roteadores para obter controle sobre eles ou redirecionar os usuários para sites falsos e maliciosos.

Existem aproximadamente 40 empresas que dependem do Dnsmasq , incluindo Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE e Zyxel. Recomenda-se aos usuários desses dispositivos que não utilizem o serviço de encaminhamento de consultas DNS integrado.

A primeira parte das vulnerabilidades descobertas no Dnsmasq está relacionada à proteção contra ataques de envenenamento de cache DNS, com base em um método proposto em 2008 por Dan Kaminsky.

As vulnerabilidades identificadas tornam a proteção existente ineficaz e permitem a falsificação do endereço IP de um domínio arbitrário no cache. O método de Kaminsky manipula o tamanho insignificante do campo de identificação da consulta DNS, que possui apenas 16 bits.

Para encontrar o identificador correto necessário para falsificar o nome do host, basta enviar aproximadamente 7.000 solicitações e simular cerca de 140.000 respostas falsas. O ataque se resume ao envio de um grande número de pacotes vinculados a IPs forjados para o resolvedor DNS com diferentes identificadores de transação DNS.

As vulnerabilidades identificadas reduzem o nível de entropia esperado de 32 bits para um requisito de adivinhação de 19 bits, tornando um ataque de envenenamento de cache bastante viável. Além disso, o tratamento de registros CNAME pelo dnsmasq permite que ele forje a string do registro CNAME, falsificando com eficiência até nove registros DNS simultaneamente.

  • CVE-2020-25684: falta de validação do ID do pedido em combinação com o endereço IP e o número da porta ao processar as respostas DNS de servidores externos. Esse comportamento é incompatível com o RFC-5452, que requer o uso de atributos de solicitação adicionais ao corresponder uma resposta.
  • CVE-2020-25686: Ausência de validação de pedidos pendentes com o mesmo nome, permitindo a utilização do método de aniversários para reduzir significativamente o número de tentativas necessárias para falsificar uma resposta. Em combinação com a vulnerabilidade CVE-2020-25684, esse recurso pode reduzir significativamente a complexidade do ataque.
  • CVE-2020-25685: uso de algoritmo de hashing CRC32 não confiável na verificação de respostas, no caso de compilação sem DNSSEC (SHA-1 é usado com DNSSEC). A vulnerabilidade pode ser usada para reduzir significativamente o número de tentativas, permitindo que você explore domínios que têm o mesmo hash CRC32 do domínio de destino.
  • O segundo conjunto de problemas (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 e CVE-2020-25687) é causado por erros que causam estouros de buffer ao processar certos dados externos.
  • Para as vulnerabilidades CVE-2020-25681 e CVE-2020-25682, é possível criar explorações que podem levar à execução de código no sistema.

Por fim, menciona-se que as vulnerabilidades foram corrigidas na atualização do Dnsmasq 2.83 e, como solução alternativa, recomenda-se desativar o DNSSEC e o cache de consultas usando opções de linha de comando.

Fonte: https://kb.cert.org


Adicionar como fonte preferencial no Google