segunda-feira, 4 de agosto de 2008

Dns e o Caos da Internet

Bom dia pessoal. Pra quem não vêm acompanhando as últimas notícias sobre a internet, é bom se preocupar a partir de agora. O motivo disso têm a ver com uma falha descoberta em um serviço essencial da internet. Trata-se do serviço de tradução de nomes, converte nomes faceis de se lembrar (como tocadoelfo.blogspot.com) para números que a rede pode tratar (no caso, do blogger: 209.85.193.191).

A falha, descoberta recentemente pelo pesquisador Dan Kaminsky ainda não foi revelada em sua totalidade, pois este vêm trabalhando junto com os desenvolvedores das implementações mais usadas hoje, para resolver em definitivo a falha. Nesse interstício, várias empresas já fizeram o patch de seus DNSs para corrigir a falha, que apesar de não ter sido revelada por inteiro, é baseada no conceito de cache poisoning (Wikipédia; SecureWorks)...


Este tipo de ataque consiste em um atacante introduzir dados forjados no cache de um servidor de nomes DNS.

Um atacante que consiga realizar um ataque de envenenamento de cache com sucesso pode fazer com que clientes de um servidor DNS sejam direcionados para um host malicioso, sob controle do atacante. Qualquer tipo de serviço pode ser redirecionado com a exploração desta técnica, web e e-mail por exemplo.

Este tipo de ataque é particularmente preocupante porque explora um problema não previsto pela maioria massiva dos usuários, que naturalmente não confere se o host que responde por determinado serviço é legítimo, embora o domínio esteja correto.

Para você entender, simplificadamente, como acontece o ataque, ele ocorre das seguintes formas. Em todas as formas de ataque a seguir, as entradas para o servidor ns.wikipedia.org poderiam ser envenenadas e redirecionadas para o servidor de nomes do atacante, no ip x.y.z.w. Estes ataqques assumem que o servidor de nomes do site google.com.br é ns.google.com.br. Para ter sucesso nos ataques, o atacante precisa forçar o servidor de nomes alvo a fazer uma requisição a um servidor que esteja sob controle do atacante:

Redirecionando o servidor de nomes alvo:

Esta primeira variação do envenamento de cache envolve o redirecionamento do servidor do atacante para o servidor alvo e, então, informar para este servidor um ip especificado pelo atacante.

Requisição DNS do servidor: quais são os registros de endereço para subdominio.exemplo.com.br?
subdominio.exemplo.com.br. IN A

Resposta do atacante:
Resposta:
(sem resposta)

Seção de Autorização:
exemplo.com.br. 3600 IN NS ns.google.com.br.

Seção Adicional:
ns.google.com.br. IN x.y.z.w

Um servidor vulnerável pode armazenar em cache o registro (endereço de ip) para ns.google.com.br, permitindo o atacante a resolver consultas para o domínio google.com.br inteiro.

Redirecionando o registro NS para outro domínio alvo:

A segunda variação do ataque de envenamento de cache envolve redirecionar o servidor de nomes para outro domínio não relacionado com a requisição original para um ip especificado pelo atacante.
subdominio.exemplo.com.br. IN A

Resposta do atacante:
Resposta:
(sem resposta)

Seção de Autorização:
google.com.br. 3600 IN NS ns.exemplo.com.br.

Seção Adicional:
ns.exemplo.com.br. IN x.y.z.w

Um servidor vulnerável pode armazenar a informação não relacionada para o registro NS do endereço google.com.br, permitindo o atacante a resolver consultas para o domínio google.com.br inteiro.

Respondendo antes do servidor de nomes real:

Esta terceira variante do envenamento de cache, chamada DNS Forgery, envolve enviar uma resposta real para uma consulta recursiva de dns de volta para o próprio servidor. As requisições dns contêm um inteiro de 16 bits, usado para identificar a resposta associada com uma dada requisição. Se o atacante consegue predizer com sucesso o valor desse inteiro e retorna um resultado primeiro, o servidor aceitará a resposta do atacante como válida.

O ataque tão falado desses últimos dias é relacionado justamente a este terceiro tipo de variante e é essencialmente uma falha de projeto do protocolo DNS. Ou seja, todas as implementações estão, teoricamente, sujeitas a esta categoria de envenamento de cache.

Concluindo

Agora, saindo um pouco da questão técnica do ataque, os sites de notícias e blogs estão fazendo muito alarde em um ponto que considero menos perigoso que outro, menos visível mas que infelismente não é percebido pela maioria pois, verificar se um site é fake ou não é mais fácil que verificar se um provedor de serviço de aplicativo e ou não. Pense, por exemplo, se fazem o ataque em um serviço de atualização de software (Windows Update ou mesmo os serviços de antivírus, entre outras inúmeras possibilidades). Isso permitira a introdução de código malicioso dentro do sistema atualizado sem que possa ser percebido diretamente.

E o pior de tudo é que não adianta em nada se as correções forem aplicadas somente nos servidores replicadores se os provedores de acesso também não atualizarem seus servidores, já que a consulta de nomes parte do servidor do usuario até os servidores TLD (Top-Level Domain) e caso o primeiro esteja envenenado, ele não irá fazer uma requisição acima para buscar algo que ele já têm em cache.

Espero que isso não fique mais crítico que uma simples ameaça pois eu não conseguiria viver sem internet hehehe

P.S.: Pra quem quiser ver, aqui há uma código que explora essa última vulnerabilidade descoberta: http://www.milw0rm.com/exploits/6130

Fonte: CNet News

Flws povo !!