Um erro de pesquisadores de segurança revelou vários detalhes a respeito de uma brecha em várias implementações do DNS nesta segunda-feira (21/07), quando um post apareceu por acidente no Chargen, o blog mantido pela empresa de segurança Matasano. O post possuía informações detalhadas sobre como a falha pode ser explorada e já foi retirado do ar.

A vulnerabilidade foi inicialmente divulgada no dia 8 deste mês, quando a Microsoft, a Internet Systems Consortium (ISC) e outras empresas corrigiram um problema de segurança nos servidores de DNS, os computadores responsáveis pela transformação de “nomes” (como http://www.linhadefensiva.org) em endereços IPs. Por meio da falha, um criminoso pode, com facilidade, envenenar o cache do DNS, isto é, redirecionar websites para computadores controlados por ele, sendo possível, por exemplo, falsificar sites de bancos e outras instituições para roubar credenciais.

Dan Kaminsky, que descobriu o problema, manteve sigilo e afirmou que só iria publicar informações detalhadas sobre sua descoberta durante a conferência de segurança Black Hat, que ocorre nos dias 2 a 7 de agosto. Kaminsky pediu que outros pesquisadores não especulassem sobre a vulnerabilidade.

Como o problema ganhou atenção de grandes veículos mídia, como a BBC, Kaminsky foi atacado por outros pesquisadores, que desconfiavam que tudo era apenas uma tentativa de ganhar publicidade.

Os especialistas Thomas Ptacek (Matasano Security) e Dino Dai Zovi conversarem por telefone com Kaminsky, que explicou o problema em privado aos dois. Ptacek confirmou a descoberta e afirmou que a atenção que ela recebeu era merecida. Ptacek, com outros especialistas da Matasano, mantém o blog Chargen.

Outros pesquisadores, porém, não tiveram o mesmo privilégio. Halvar Flake, CEO e diretor de pesquisa da alemã SABRE Security, escreveu um post em seu blog em que critica a postura de Kaminsky por pedir que não especulem a respeito do problema e, em seguida, publicou uma hipótese, admitindo “não entender muito” sobre DNS.

Não muito depois, um post apareceu no Chargen, o blog da Matasano. Nele, os pesquisadores diziam que Flake estava correto. Detalhavam todo o funcionamento do DNS, as falhas que já se conhece e estão corrigidas e, depois, mostravam como as duas correções podem ser burladas por meio de uma nova técnica — a mesma sugerida por Flake e, supostamente, a mesma desenvolvida por Kaminsky.

O post foi removido do Chargen e, em seu lugar, um pedido de desculpas foi publicado por Thomas Ptacek. Ptacek afirmou que tratava-se de um rascunho, cuja publicação só deveria ocorrer depois que Kaminsky já tivesse divulgado sua descoberta na Black Hat.

Em seu blog, Kaminsky publicou um post intitulado 13>0, em referência ao fato que “13 dias é melhor do que zero (dia)”, isto é, que, apesar do vazamento, seria pior se a brecha fosse uma “dia zero”. No post, o pesquisador pede, àqueles que ainda não o fizeram, que apliquem o patch aos seus servidores imediatamente, o que significa que é bem provável que a hipótese de Halvar Flake e as informações publicadas por engano pela Matasano estão corretas.

Apesar do post ter sido removido pela Matasano pouco tempo depois de sua publicação, agregadores e leitores de RSS o armazenaram, o que significa que não deve ser difícil encontrar uma cópia em outros websites.

Provedores é que precisam aplicar o patch para o problema. Usuários nada podem fazer, a não ser utilizar um servidor de DNS alternativo ou pedir ao provedor que instale a correção o quanto antes. No blog de Kaminsky, disponível em DoxPara.com, é possível clicar em um botão para efetuar um teste e descobrir se o servidor DNS usado já possui o patch aplicado.

Escrito por Altieres Rohr

Editor da Linha Defensiva.

2 comentários

  1. Senhores, se me permitem gostaria de acrescentar que uma recomentação do CERT.BR[1] para mitigar outra vulnerabilidade também resolve por completo o ataque sugerido pelo Halvar Flake e que tem boas chances de estar relacionado com o ataque original.

    Parabens pelo texto e pelo bom trabalho que veem desenvolvendo.

    [1] – http://www.cert.br/docs/whitepapers/dns-recursivo-aberto

    Curtir

    Responder

  2. Nelson

    Pelo o que entendi, a sugestão do CERT resolve o problema porque limita os clientes que o servidor de DNS atende, impedindo que clientes de outras redes façam solicitações ao servidor. Isso significa que o invasor precisa estar na rede interna, o que é menos provável e possibilita que ele seja descoberto…

    Mas, tratando-se de UDP, não é possível fazer IP spoof? Ou, pelo fato de atender somente uma rede controlada pelos mesmos administradores, é possível bloquear o IP spoof (porque, pelo que entendo, não faz sentido que o roteador de uma rede esteja recebendo um pacote originado da própria rede para a própria rede…)

    Porém, mesmo com isso, o problema não é resolvido (nem com o patch é, na verdade, apenas é aumentado a entropia ao se usar outra chave de 16 bits (a porta)). Mas explorá-lo fica mais difícil.

    Se puder confirmar ou negar meu entendimento, agradeço. :)

    Curtir

    Responder

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.