BIND de 2015 na lista da CISA: o DNS que ninguém atualizou

O que a CISA publicou

Em 8 de outubro de 2026, a CISA incluiu no catálogo KEV um lote de falhas antigas, entre elas a CVE-2015-5477 do ISC BIND, com prazo de 3 dias para as agências americanas. A descrição da CISA é curta: o BIND tem um erro de processamento de dados que permite a atacantes remotos causar negação de serviço com consultas TKEY.

TKEY é um tipo de registro do DNS usado para negociar chaves secretas entre servidores. A consulta TKEY chega por UDP ou TCP na porta 53, como qualquer outra consulta.

Como a falha funciona

Segundo o aviso da ISC, a organização que mantém o BIND, um erro no tratamento de consultas TKEY faz o named encerrar com uma falha de asserção do tipo REQUIRE. Em português simples: o programa encontra uma situação que "não deveria acontecer", se recusa a continuar e termina. O DNS para.

Três pontos do aviso explicam por que ela é tão perigosa:

• Basta um pacote. Não é preciso inundar o servidor; uma consulta forjada derruba o processo.
• Vale para os dois papéis. Servidores recursivos (os que os clientes usam) e autoritativos (os que respondem pelas zonas) são afetados.
• Lista de acesso não protege. O código vulnerável roda no início do processamento do pacote, antes das restrições de configuração. Limitar quem pode fazer consultas recursivas não impede o ataque.

A ISC não indicou contorno: a solução é atualizar.

Versões afetadas

Qualquer BIND de uma linha mantida hoje está fora da faixa afetada. O problema não é quem atualiza: é o servidor que ninguém lembra que existe.

A conta do estrago

Como a falha derruba o processo com uma consulta, o custo para o atacante é quase zero. Imagine um provedor com 4 resolvedores antigos atendendo os clientes:

E isso se repete: se o named é reiniciado automaticamente, o atacante manda de novo. Para o cliente, não importa que o enlace esteja funcionando. Sem DNS, a internet "caiu".

Reiniciar sozinho não é proteção

Muitos servidores têm o named configurado para voltar sozinho quando cai (pelo systemd, por exemplo). Ajuda contra falhas acidentais, mas não contra um ataque repetido. Suponha (valores de exemplo) que o named leve 10 segundos para reiniciar e carregar as zonas, e que o atacante mande uma consulta a cada I segundos. A fração do tempo com DNS funcionando é:

Com uma consulta a cada 10 segundos, o servidor passa o tempo todo reiniciando. Para o atacante, isso custa um pacote a cada 10 segundos, ou 8.640 pacotes por dia: tráfego desprezível, impossível de perceber no gráfico de banda. Um servidor de zonas grandes, que demora mais para carregar, fica ainda mais tempo fora.

Por isso, além de atualizar, vale monitorar quantas vezes o named reiniciou. Mais de um reinício inesperado no mesmo dia merece investigação: procure nos registros mensagens de falha de asserção (REQUIRE) logo antes de cada parada.

Onde o BIND antigo se esconde

Servidores Linux bem administrados recebem o BIND corrigido da distribuição; a Red Hat, por exemplo, publicou a correção em 2015 (RHSA-2015:1513). Os riscos estão em outros lugares:

• Equipamentos de rede com BIND embutido. A própria CISA cita um boletim da Juniper de 2016 sobre o BIND no Junos. Roteadores, firewalls e appliances podem levar um servidor DNS interno, e a versão dele depende do firmware.
• Servidores esquecidos. O DNS secundário instalado por um fornecedor anos atrás, a máquina virtual de laboratório que virou produção, o servidor de uma filial.
• Sistemas fora de suporte. Distribuições Linux sem atualizações há anos, que ainda rodam o BIND da época.

Para encontrar, dois comandos ajudam:

• named -v, no próprio servidor, mostra a versão instalada.
• dig @<servidor> version.bind CHAOS TXT pergunta a versão pela rede. Muitos administradores escondem essa resposta, então a ausência dela não prova nada; mas, se a resposta vier com 9.9 ou anterior, é sinal de alerta.

Faça a varredura nas suas faixas de endereços internas e externas, procurando qualquer coisa que responda na porta 53.

Roteiro rápido

1. Liste todos os servidores e equipamentos que respondem DNS na porta 53.
2. Descubra a versão do software de DNS de cada um.
3. Atualize ou desligue qualquer BIND da faixa afetada.
4. Para equipamentos de rede, confira os boletins do fabricante e a versão de firmware.
5. Monitore reinícios inesperados do named.

Perguntas frequentes

Uso Unbound, PowerDNS ou outro software. Estou exposto?

Esta falha é do BIND. Outros softwares de DNS têm as suas próprias falhas e avisos; mantenha-os atualizados do mesmo jeito.

Por que uma falha de 2015 entra no catálogo só agora?

O catálogo reúne falhas com exploração confirmada, não importa a idade. A inclusão em 2026 indica que a CISA reuniu evidência de exploração dessa falha. A data de inclusão não diz quando os ataques começaram.

Meu DNS autoritativo é terceirizado. Preciso fazer algo?

Confira com o fornecedor qual software e qual versão ele usa, e se a falha foi avaliada. O risco maior costuma estar nos servidores que ficaram dentro de casa: o secundário antigo, o resolvedor da filial, o DNS interno de um equipamento.

Bloquear consultas TKEY no firewall resolve?

Pode reduzir o risco como medida temporária, se o seu equipamento consegue filtrar pelo tipo de consulta DNS. A solução definitiva, segundo a ISC, é atualizar.