Esta página ou seção foi marcada para revisão devido a incoerências ou dados de confiabilidade duvidosa. Se tem algum conhecimento sobre o tema, por favor, verifique e melhore a coerência e o rigor deste artigo. Considere colocar uma explicação mais detalhada na discussão.
Envenenamento de cache DNS (DNS cache poisoning) é o comprometimento na segurança ou na integridade dos dados em um Sistema de Nomes de Domínios (Domain Name System DNS). Esse problema acontece quando os dados que são introduzidos na cache de um servidor de nomes DNS não se originam do servidor de nomes DNS com autoridade real. Tal problema pode ser uma tentativa de ataque malicioso em um servidor de nomes, mas também pode ser o resultado de um erro não intencional de configuração na cache do servidor DNS.
Quando um servidor DNS recebe dados não autenticados e armazena os mesmos em sua cache para otimizar o desempenho, tais dados podem ser falsos e, portanto, podemos ter o envenenamento da cache do servidor que fornece os dados não autenticados para seus clientes.
Um Servidor DNS tem como uma de suas funções realizar a tradução de um nome de domínio (como exemplo.com) em um endereço IP que um host na internet usa para obter conteúdo disponível na internet. Se um servidor DNS é envenenado, este pode retornar o endereço IP incorreto, desviando o tráfego para outro computador.
Ataques de envenenamento de cache
Normalmente, um computador na rede usa um servidor DNS fornecido pelo computador da organização do usuário ou um provedor de acesso à Internet (ISP - Internet service provider). Os servidores DNS são geralmente implantados na rede das organizações melhorando o desempenho pelo uso de caches que armazenam os resultados de consultas que foram realizadas recentemente. Ataques de envenenamento de cache em um único servidor DNS pode afetar os usuários atendidos diretamente pelo servidor comprometido.
Para executar um ataque de envenenamento de cache, o invasor explora uma falha no software DNS. Se o servidor não valida corretamente as respostas DNS para assegurar que elas são de uma fonte com autoridade (por exemplo, através do uso de DNSSEC) o servidor vai acabar armazenando localmente em sua cache as entradas incorretas e fornecer aos seus usuários tal resultado incorreto quando os mesmos realizarem as requisições DNS.
Esta técnica pode ser usada para direcionar os usuários de um site para outro site de escolha do atacante. Por exemplo, um atacante falsifica o endereço IP das entradas DNS para um website alvo em um dado servidor DNS, substituído-os com o endereço IP de um servidor controlado por ele. Em seguida, o atacante cria arquivos no servidor que ele controla com nomes que casam com os que estão no servidor alvo. Esses arquivos poderiam conter conteúdo malicioso, tal como um worm ou um vírus de computador. Um usuário cujo computador referencie o servidor DNS envenenado seria conduzido a aceitar o conteúdo vindo do servidor não autenticado e sem saber que o conteúdo baixado se trata de conteúdo malicioso.
Neste ataque o atacante pode injetar dados falsos no cache de um servidor de nomes, permitindo que informações falsas sejam passadas para os clientes. Porém, não é tão simples enviar um pacote aleatório para um servidor de nomes, pois o mesmo só aceita respostas de consultas realizadas. Caso contrário, a resposta que não é esperada é descartada. Assim o servidor de nomes se baseia nos seguintes aspectos do pacote de resposta: (1) A resposta deve chegar na mesma porta UDP; (2) A seção ‘QUESTION’ do pacote DNS corresponde a pergunta na consulta pendente; (3) O QUERY ID ‘casa’ com a consulta pendente; (4) As seções AUTHORITY e ADDITIONAL, representam nomes que estão no mesmo domínio da consulta. Satisfeitas essas condições o servidor de nome aceitará um pacote como resposta verdadeira a uma consulta.
Temos que o ‘QUERY ID’ é simplesmente incrementado por um em cada requisição, sendo fácil adivinhar o próximo valor do ‘QUERY ID’. Uma forma que o atacante tem de obter o ‘QUERY ID’ é sniffando o tráfego de rede e verificando qual seria o valor atual do ‘QUERY ID’, ou o atacante pode enviar ao servidor vítima uma consulta por um nome em um domínio para um servidor de nomes que o atacante controla. O servidor de nomes vítima recebe o pedido e faz o processo habitual de resolução de nomes, consultando a partir de um servidor de nomes raiz. Desta forma o servidor de nomes da vítima será direcionado ao servidor de nomes do atacante que tem autoridade sobre o domínio consultado. O atacante então pode descobrir a ‘porta de origem’ e o ‘query ID’ utilizado. Neste ponto o atacante conhece tanto o último ‘query ID’ como a ‘porta fonte’ utilizada pela vítima. O servidor de nomes da vítima sempre envia consultas da mesma porta UDP.
Em posse dessas informações o atacante poderá envenenar o servidor de nomes da vítima com um endereço IP falso para o domínio consultado pela vítima e cujo servidor DNSSEC ‘S’ não é capaz de resolver. Os passos são os seguintes: o atacante de posse da informação da ‘porta fonte’ e do último ‘QUERY ID’ obtido, ao perceber que a vítima realiza uma consulta ao servidor, começa a inundar a vítima com pacotes de respostas DNS forjadas, incrementando o ‘QUERY ID’ (numa tentativa de adivinhar o ‘QUERY ID’ correto). Todos os pacotes se passam pelo servidor de nomes ‘S’, mas o endereço IP corresponde ao endereço do atacante. Isso ocorre, porque como o servidor de nomes ‘S’ não assina sua mensagem, a vítima não tem meios de garantir que a mensagem é falsa. Assim, quando a resposta verdadeira do servidor de nomes ‘S’ chegar, a vítima irá ignorar.
Variantes
Nas seguintes variantes do ataque, as entradas para o servidor ns.target.example seriam envenenadas e redirecionadas para o servidor de nomes do atacante no endereço IP w.x.y.z. Esse ataque assume que o servidor de nomes para target.example é ns.target.example.
Para realizar os ataques o atacante deve forçar o servidor DNS alvo a fazer uma requisição a um domínio controlado por um dos servidores de nome do atacante.
Redirecionar o servidor de nomes do domínio alvo
A primeira variante do envenenamento de cache DNS envolve o redirecionamento do servidor de nomes do atacante para o servidor de nomes do domínio alvo, atribuindo, em seguida, ao servidor de nomes um endereço IP especificado pelo atacante.
Requisição do servidor DNS: qual é o registro do endereço para subdomain.attacker.example?
subdomain.attacker.example. IN A
Resposta do atacante:
Answer:
(no response)
Authority section:
attacker.example. 3600 IN NS ns.target.example.
Additional section:
ns.target.example. IN A w.x.y.z
Um servidor vulnerável armazenaria em sua cache o registro A (endereço IP) para ns.target.example, permitindo que o atacante resolva consultas para o domínio target.example inteiro.
Redirecionar o registro NS para outro domínio alvo
A segunda variante do envenenamento de cache DNS envolve o redirecionamento do servidor de nomes para outro domínio não relacionado coma requisição original para um endereço IP especificado pelo atacante.
Requisição do servidor DNS: qual o registro para subdomain.attacker.example?
subdomain.attacker.example. IN A
Resposta do atacante:
Answer:
(no response)
Authority section:
target.example. 3600 IN NS ns.attacker.example.
Additional section:
ns.attacker.example. IN A w.x.y.z
Um servidor vulnerável armazenaria em sua cache a informação não relacionada ao registro NS do ns.target.example, permitindo que o atacante resolva consultas para o domínio target.example inteiro.
Prevenção e Mitigação
Muitos ataques de envenenamento de cache podem ser evitados em servidores DNS, desde que os mesmos passem a confiar menos nas informações que são passadas para eles por outros servidores DNS, e ignorando qualquer registro DNS que não são relevantes para consulta. Por exemplo, as versões do BIND 9.5.0-P1 [1] e acima, realizam esse tipo de checagem. [2] Como dito acima, randomização da porta fonte para consultas DNS, combinado com o uso de criptografia segura para selecionar ambos, a porta fonte e o nonce 16-bit, pode reduzir bastante a probabilidade de que esses ataques sejam bem sucedidos.
Contudo roteadores, firewalls, proxies, e outros dispositivos gateways que realizam tradução de endereços de rede (NAT), ou mais especificamente, tradução de endereço de portas (PAT), frequentemente reescrevem as portas fontes em ordem, a fim de acompanhar o estado da conexão. Quando modificam a porta de origem, os dispositivos PAT removem a aleatoriedade da porta de origem implementada por servidores de nome.
Este tipo de ataque pode também ser mitigado na camada de transporte ou na camada de aplicação por realizar uma validação fim a fim, uma vez que uma conexão é estabelecida. Um exemplo comum disso é o uso da Transport Layer Security e das assinaturas digitais. Por exemplo, ao usar uma versão segura de HTTP, HTTPS, os usuários podem checar se o certificado digital do servidor é válido e pertence ao proprietário esperado do site. Da mesma forma, a segurança do Shell de programas de login remoto checam o certificado digital nos terminais (se conhecido) antes de proceder com a sessão. Para aplicações que baixam atualizações automaticamente, a aplicação pode incorporar um cópia do certificado assinado localmente e validar a assinatura armazenada na atualização do software.
Secure DNS (DNSSEC) usa criptografia de assinaturas eletrônicas assinadas com um certificado de chave públicas confiável para determinar a autenticidade dos dados. DNSSEC pode conter ataques de envenenamento de cache, porém a partir de 2008 ainda não era amplamente implantado. Em 2010 o DNSSEC foi implementado nos servidores root zone da Internet.
