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.
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
CurtirCurtir
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. :)
CurtirCurtir