FONTE: FreeBSD Brasil
Recentemente foram publicados dois alertas de segurança oficiais do BIND 9, o CVE-2007-2925 e o CVE-2007-2926 de 24 de Julho. A FreeBSD Brasil LTDA não compartilha da classificação de risco médio, oficialmente publicada pelo ISC, e considera, em especial o problema descrito no CVE-2007-2926 de alto risco, e recomenda fortemente atualização imediata de todos os servidores de nomes de seus clientes.
Recentemente foram publicados dois alertas de segurança oficiais do BIND 9, o CVE-2007-2925 e o CVE-2007-2926 de 24 de Julho, que podem ser observados em referência oficial neste endereço. A FreeBSD Brasil LTDA não compartilha da classificação de risco médio, oficialmente publicada pelo ISC, e considera, em especial o problema descrito no CVE-2007-2926 de alto risco, e recomenda fortemente atualização imediata de todos os servidores de nomes de seus clientes para a versão 9.3.4-P1, em produção.
Nenhum dos dois problemas de segurança permite execussão arbitrária de comandos ou exploração ao sistema, seja remota ou localmente. Todavia, o problema afeta a natureza principal do serviço de nomes, a validação e integridade das respostas em solicitações (queries) de nomes. Dessa forma, através de ataques de envenenamento de cache, é possível que um servidor de nomes BIND 9 vulnerável responda de forma adulterada informações, enviando domínios para outros endereços, de forma distinta da resposta de autoridade inicial.
O primeiro problema é uma vulnerabilidade na geração de queries de identificação em análises criptográficas, que possibilita com estatísticas de sucesso de chance de 8 pra 1 de adivinhar 50% de todos os ID de consultas ao servidor. Isso torma o envenenamento de cache muito fácil.
Esse bug afeta apenas servidores de nomes recursivos. O que não é na verdade, um grande alívio, já que 90% dos servidores de nomes atual como recursivos, fazendo a resolução de nomes de outros domínios, e não exclusivamente como encaminhadores (forwarders) ou como servidores de autoridade. Ainda os servidores de autoridade podem ser afetados por este problema, quando atuando como servidores primário (slave name servers) ao enviar notificação de mudança nos domínios, para os servidores slave, que por sua vez se atuarem como resolvedores recursivos podem estar vulneráveis, e completar a corrente, afetando o servidor master. Esse segundo tipo de exploração é apenas teórica, mas possível.
Como o ataque acontece.
A essência primária é que o atacante deve ter uma zona de internet adequadamente configurada e de autoridade plena. Dessa forma esse servidor fará a resposta por qualquer consulta sobre essa sua zona (domínio). A segunda etapa é, teoricamente, mais difícil. Algum cliente de um servidor de nomes vulnerável deve fazer uma requisição sobre a zona de internet de quem realiza o ataque. Se o servidor de nomes é mal configurado e resolve DNS recursivamente a qualquer estação, realizar o ataque é extremamente simples.
A partir desse ponto a principal proteção contra envenenamento de cache DNS, passa a ser explorada. Essa proteção conta com a impossibilidade prática de prever o ID formal da próxima transação DNS, que é um ID de 16 bits. Se for possível prever o ID de próximas transações/consultas, é possível responder com esse ID futuro ao servidor, e ele fará cache da resposta, a resposta a uma consulta ainda não realizada.
Devido a um problema de engenharia de software na implementação da criação de números aleatóreos do BIND 9, o ID das transações que são final par (número final par) são seguidos de quase dez outros IDs das transações seguintes, calculados com base no número par conhecido da consulta alteriormente realizada.
Assim, o atacante desempenha um ataque conhecido como encadeiamento de respostas canônicas (apelidos CNAME) para terminar o ID de uma transação de forma simples, rápida e eficiente. Esse procedimento consiste-se na consulta a um servidor, fazendo esse servidor realizar uma consulta ao próprio servidor DNS de quem faz o ataque, através de um domínio sobre o qual o atacante detém autoridade. O servidor de autoridade em questão recebe a consulta, e portanto passa a conhecer o ID da transação. Se tal ID for número de final par, uma resposta é enviada, e esta resposta é de um registro DNS do tipo CNAME, que aponta para outro nome do próprio domínio (zona) que o atacante detém autoridade. Assim o servidor de nomes recursivo automaticamente fará outra consulta, e esta por sua vez, com um nov ID de transação.
Ao determinar a lógica das requisições, com duas ou três consultas no máximo, todos os próximos ID passam ser conhecidos, podendo estes ser até 8 dos próximos 10 (já que 2 consultas foram utilizadas durante o ataque). Sendo assim, há chances das próximas consultas não serem de ID final par, mas sim, final ímpar. Todavia, a probabilidade de ser par é 50%. Então sobre as próximas 8 consultas, ao menos 4 possivelmente estarão entre as respostas que agora o servidor atacante pode enviar, mesmo as consultas ainda não tendo sido feitas.
O servidor de nomes vulnerável fará cache dessas respostas, e as enviará quando as queries acontecer, resultando em respostas que potencialmente apontam para endereços que não são a informação correta, mas sim, a informação cacheada adulterada (envenenada). O ataque conta ainda com a performance do servidor sendo atacado, pois a velocidade de processamento faz diferença, para garantir que as consultas de CNAME acontecam logo depois da consulta original. Assim sendo um servidor de nomes sobrecarregado e que responde milhares de requisições simultâneas, do tipo recursivas, torna o ataque menos fácil. Porém, não prevê que ele aconteça.
A segunda condição todavia, passa a ser cada vez mais explorada recentemente. Alguns worm começam a se espalhar, e pior, mensagens de SPAM e também URLs furtivas em websites e em mensagens de e-mail estão apontando para zonas de nomes afim de desempenhar tal ataque, e usuaŕios passam a, sem ter consciência, fazer consultas sobre zonas nocivas em seus servidores de nomes recursivo.
Não há solução para o problema, a não ser modificações no código. Portanto, a atualização para a última versão do BIND 9 é imperativa.
Curiosamente, 10 anos atrás, Theo De Raadt, hoje líder do Projeto OpenBSD previu que o BIND 9 pudesse ser explorado de tal maneira, e fez uma variação do algorítimo de criação dos ID de transações, usando geraçao linear dos números aleatórios, com LCG (Linear Congruential Generation) , que não é vulnerável a este problema. O Projeto FreeBSD ao importar os novos fontes do BIND 9 passa a aplicar também uma pequena variação do LCG, para evitar problemas futuros de mesma natureza.
Para complementar, um outro problema, teoricamente menor, ajuda a exploração ser mais viável. O BIND 9 não valida a autorização de consulta à informações cacheadas, e permite que mesmo estações sem permissão de recursão possam tirar proveito de informações já cacheadas por outros hosts com privilégio de recurssão. Felizmente para evitar tal problema, basta uma pequena modificação na configuração, adicionando ao bloco options do named.conf(5) a entrada
allow-query-cache { };
Apontando para as mesmas redes/estações que tem privilégio de recursão. Esse último problema todavia, afeta apenas série 9.4 e 9.5 do servidor de nomes.
Resolução do Problema
Para resolver o(s) problema(s), atualize seu servidor de nomes para uma dessas versões:
BIND 9.2.8-P1
BIND 9.3.4-P1
BIND 9.4.1-P1
BIND 9.5.0a6.
No FreeBSD o BIND 9.3.4-P1 já foi incorporado, e foi feito MFC da correção, com as devidas customizações e padronização para o sistema aplicados. Para atualizar, siga as instruções:
Sincronize os fontes de seu sistema com o mais recente, usando csup (se for FreeBSD 6.2) ou cvsup:
cvsup -g -L 2 -h cvsup2.freebsd.org /usr/share/examples/cvsup/stable-supfile (FreeBSD anterior ao 6.2)
Ou
cvsup -g -L 2 -h cvsup2.freebsd.org /usr/share/examples/cvsup/stable-supfile (FreeBSD 6.2-RELEASE ou superior)
Após completa a sincronia, recompile o named(8) e o instale:
# cd /usr/src/lib/bind
# make clean
# make
# make install
# cd /usr/src/usr.sbin/named
# make clean
# make
# make install
Em seguida reinicie o sistema de nomes:
# /etc/rc.d/named restart
Ou
# killall -HUP named
Confira a versão do novo daemon de nomes:
# /usr/sbin/named -v
BIND 9.3.4-P1
E após ter reiniciado o serviço confira se ele levantou-se adequadamente, em /var/log/messages, os indícios de sucesso serão como este:
Jul 30 15:30:05 dns1 named[66932]: starting BIND 9.3.4-P1 -u bind -t /var/named
Confira em seguida com sockstat -4l e faça queries (consultas) com nslookup(1) e dig(1) para conferior se o serviço foi plenamente restabelecido.
Clientes FreeBSD Brasil
Todos os clientes Service Level Agrement de nível 2 ou superior já tiveram seus servidores de nomes principais atualizados. Pedimos por gentileza que todos entrem em contato conosco caso existem outros servidores de nomes em uso, que não conhecemos, nos informe, para que os atualizemos também, ou atualizem seguindo as instruções acima.
Clientes de outros níveis de suporte se não conseguirem atualizar como acima entrem em contato também. Se preferirem nos informe explicitamente, que atualizaremos.
Correções Binárias
Clientes FreeBSD Brasil podem também fazer atualização binária usando o bspatch(1). Para isso, disponibilizamos neste endereço:
Área de Download Portal Corporativo
Os diff binários das principais versões do bind para a versão corrigida. Para facilitar, os patch binários tem seu nome padronizado, chama-se:
named_X.Y.Z_9.4.3_P1
Onde X.Y.Z variará de acordo com a versão original. Por exemplo, named_9.3.1-9.4.3_P1 representa o patch binário da versão 9.3.1 para 9.4.3_P1. Faça download de seu patch de acordo com a versão adequada. Para descobrir qual sua versão digite
named -v
Para aplicar a correção, você deve seguir as seguintes instruções:
Faça backup de seu named atual:
mv /usr/sbin/named /usr/sbin/named.old
E com bspatch(1) aplique o patch binário
bspatch /usr/sbin/named.old /usr/sbin/named /tmp/named_X_Y
Redefina as permissões com chmod 555 /usr/sbin/named e reinicie o serviço. Teste, como mencionado na atualização por fontes.
Mais detalhes ou revisões futuras dessa nota de segurança podem sempre ser observadas no Portal Corporativo, neste endereço
Nenhum comentário:
Postar um comentário