Leitura Recomenda

Antes que você comece a leitura da explicação deste tipo de ataque, é recomendável que você esteja familiarizado com os seguintes termos:

Falsificação de Resposta e Substituição de Raiz

Esta página descreve dois tipos de ataques de envenenamento de cache: falsificação de resposta e substituição de raiz. O primeiro é mais comum do que o segundo.

Servidores de DNS são operados por provedores de Internet. Todo internauta, para conseguir se conectar a qualquer site usando um nome, precisa de um servidor de DNS corretamente configurado em sua conexão com a Internet.

Falsificação de Resposta

Para descobrir qual o IP de um domínio, como http://www.linhadefensiva.org, um servidor de DNS precisa conectar-se ao servidor de nomes (NS) deste domínio e requisitar a informação do IP. O uso do protocolo UDP em vez do TCP permite que um invasor interfira com este processo.

Ao contrário do TCP, o UDP não possui verificação de resposta. Quando dois computadores se comunicam por TCP, ambos precisam fazer o handshake (“aperto de mãos”) antes de iniciar a conexão. Isto garante que os dois computadores iniciem uma sessão de comunicação mútua, isto é, que um pode receber pacotes vindo do outro. No UDP, um computador envia uma informação ao outro sem precisar de um handshake, o que contribui para a velocidade da conexão, mas não garante que o sistema que enviou a informação é quem ele diz ser.

Usando uma analogia com o correio tradicional, é como se uma pessoa colocasse informações falsas no campo do remetente. Ela pode até conseguir enviar a carta, mas a pessoa que a receber não vai conseguir enviar a resposta para ela, pois a resposta será enviada para o falso remetente. O handshake do TCP exige uma primeira “correspondência” para garantir que aquele remetente foi quem enviou a primeira carta.

O UDP não tem esta exigência. Assim, um invasor pode tentar fazer uma requisição ao servidor de DNS e falsificar a resposta do NS antes que o verdadeiro possa responder. O ataque funciona desta forma:

  1. O invasor faz uma requisição ao servidor de DNS alvo para que ele descubra o IP de “www.example.com”
  2. O DNS alvo envia um pedido de “Me informe o IP de http://www.example.com” para o NS de “example.com”
  3. Antes que o NS de example.com responda o pedido do DNS alvo, o invasor o responde, falsificando o remetente como se ele fosse o NS de example.com, dizendo “O IP de http://www.example.com é este”
  4. Como a resposta recebida pelo DNS alvo é armazenada em cache, ele não tentará descobrir o IP de http://www.example.com novamente por algum tempo
  5. Durante este tempo, todos os usuários que fizerem uso do servidor de DNS alvo serão redirecionados ao IP informado pelo invasor e não ao IP real

Esta situação é especialmente perigosa se for bem-sucedida para falsificar o endereço IP de um banco, por exemplo. Todos os usuários que fizerem uso daquele servidor de DNS serão redirecionados ao site falso (controlado pelo invasor) toda vez que tentarem acessar o banco. Todos os dados enviados pelos usuários ao site falso serão recebidos pelo invasor, que poderá usá-los para, por exemplo, roubar as contas das vítimas.

Servidores de DNS modernos tentam dificultar que um atacante tenha sucesso neste tipo de ataque, gerando um “identificador” único para cada requisição. Quando ele faz a requisição ao NS, ele envia junto este identificador, que o NS usará também na resposta.

Para conseguir realizar o ataque, o invasor precisa “adivinhar” este número, o que é possível se ele tiver tentativas o suficiente. Para conseguir estas tentativas, invasor pode, por exemplo, efetuar um ataque de negação de serviço para derrubar o servidor NS responsável pelo domínio que ele quer redirecionar. O servidor de DNS falso não vai conseguir receber uma resposta do servidor de NS verdadeiro e, por isso, o invasor poderá continuar tentando descobrir o identificador usado até que o servidor NS volte ao ar para responder legitimamente o pedido.

Como este problema tira proveito de uma limitação da rede e não no sistema de DNS, todos os softwares para servidores de DNS podem ser vítimas deste ataque. Alguns deles, como as versões mais recentes do BIND, tentam dificultar a tarefa do invasor usando números bem aleatórios para a geração do identificador da conexão, além de opções de configuração que dificultam a falsificação da resposta.

O DNSSEC também promete adicionar verificação de autenticidade às respostas para que um invasor não consiga falsificá-las.

Substituição de Raiz

Os servidores de DNS necessitam de diversas informações para resolver um domínio. Ao resolver um domínio, o servidor de DNS automaticamente coloca em cache as informações do servidor que o enviou a informação do IP para o domínio que ele procurou, inclusive as informações do servidor raiz.

O que pode acontecer é que um servidor de nomes (NS) malicioso envie uma informação incorreta sobre os endereços dos servidores raiz. Se o servidor de DNS estiver configurado corretamente, nada deve acontecer. Se o servidor estiver configurado de forma incorreta, a entrada do servidor raiz será substituída pela entrada enviada pelo servidor malicioso, ignorando aquela que está em cache e colocando a nova como endereço verdadeiro.

Dessa forma, é possível substituir, por exemplo, o servidor raiz dos domínios .COM e fazer com que todos os domínios finalizados com .COM sejam resolvidos para um IP malicioso. Isso ocorre porque o servidor raiz falso está em cache e ele não enviará a informação correta dos domínios, a não ser que o servidor de DNS seja reiniciado, pois assim o cache será limpo e ele vai buscar a informação correta dos servidores raiz para colocá-as em cache. Porém, se o servidor de DNS estiver configurado incorretamente, o problema pode voltar. Como um servidor DNS é utilizado por diversos usuários, todos eles são afetados.

Para que um ataque seja realizada, é necessário que um servidor DNS vulnerável conecte em um servidor NS malicioso. Em um cenário onde o “example.com” possui servidores maliciosos, o servidor de DNS vai procurar o servidor raiz dos “.com” e este lhe enviará a informação do servidor NS do domínio “example.com”. Quando o servidor DNS vulnerável conectar no NS malicioso para receber o endereço IP do “example.com”, o NS malicioso enviará também um pacote especial contendo novas entradas para o servidor raiz dos domínios “.com”.

Quando este servidor DNS vulnerável tentar novamente se conectar em um servidor raiz dos “.com”, a entrada maliciosa enviada pelo NS será usada e o domínio será resolvido para um IP incorreto, fazendo com que as páginas exibidas em todos clientes que utilizam aquele DNS sejam páginas falsas.

Para que um invasor consiga fazer com que um servidor de DNS tente resolver o domínio malicioso, uma onda de spam pode ser enviada contendo uma figura ou foto. Se esta foto estiver hospeda no domínio “example.com”, o cliente precisará do IP deste servidor para obter a foto e, caso o servidor de DNS deste cliente que recebeu o e-mail seja vulnerável, o servidor será afetado pelo problema.

Atualmente os problemas mais comuns de substituição de raiz estão presentes somente em servidores de DNS rodando en Windows NT4 e Windows 2000. A correção é uma mudança de configuração no registro:
http://support.microsoft.com/default.aspx?scid=kb;en-us;241352

É possível que um invasor utilize a falsificação de resposta também para substituir servidores raiz ou NSes de um domínio inteiro (não somente http://www.example.com, mas qualquercoisa.example.com e e-mails @example.com). Este tipo de ataque é mais abrangente, mas requer que o invasor consiga interferir com passos anteriores do processo de descobrimento do IP. Este tipo de ataque também pode afetar o BIND e outros servidores DNS, pois funciona da mesma forma que a falsificação de resposta acima.

Veja também

Atualizado em 27/07/2007

Escrito por Altieres Rohr

Editor da Linha Defensiva.

Todos os posts Website