Várias implementações do protocolo DNS vulneráveis a ataques de cache poisoning

Categoria: Alertas

quinta, 24 julho 2008 08:22

Deficiências no protocolo DNS e nas implementações mais comuns deste protocolo podem permitir que utilizadores mal intencionados efectuem ataques de envenenamento da memória temporária (cache).

Sistemas Operativos Implicados:	Windows XP/NT/2K/Me/98/95, Linux, FreeBSD/OpenBSD, Solaris, Cisco IOS
Aplicações Implicadas:	BIND

I. Descrição

O serviço DNS (Domain Name System) é responsável por traduzir nomes de nós na rede para os respectivos endereços IP (e vice versa) e é um serviço crítico para a normal operação dos sistemas que utilizam a internet como meio de comunicação.

O envenenamento da memória temporária é uma técnica que permite a um utilizador mal intencionado a introdução de informação de DNS (pares nome/endereço) forjada na memória temporária de um servidor de nomes. O conceito do envenenamento da memória temporária já é conhecido à algum tempo e já foram publicados vários artigos que descrevem as várias deficiências inerentes ao protocolo DNS e os vários defeitos em algumas implementações do DNS que facilitam este tipo de ataques. Alguns exemplos destas vulnerabilidades podem ser encontrados na nota de vulnerabilidade VU#800113 publicada pelo US-CERT. 

Pesquisas relativas a estas e outras vulnerabilidades relacionadas produziram métodos de exploração eficazes que permitem ataques por envenenamento da memória temporária. Foram desenvolvidas ferramentas e técnicas que permitem, com fiabilidade, o envenenamento de um domínio à escolha de um utilizador mal intencionado sobre a maior parte das implementações actuais. Por este motivo, actualmente o consenso entre os fabricantes de software DNS é para a introdução, nos seus resolvers, de aleatoriedade nos portos de comunicação, uma vez que em algumas implementações utilizam apenas o porto tradicional para o serviço DNS – porto 53/UDP. Esta situação está a ser acompanhada pelo US-CERT, através da nota de vulnerabilidade VU#800113.

Um utilizador mal intencionado que consiga levar a cabo, e com sucesso, um ataque de envenenamento da memória temporária pode fazer com que os clientes desse servidor de nome comprometido contacte um nó da rede errado, e possivelmente malicioso. Consequentemente, o tráfego web, email, e outros dados importantes que sejam enviados através da rede podem ser direccionados para sistemas controlados por esse utilizador mal intencionado.

Existem relatos que estas vulnerabilidades estão a ser activamente exploradas.

II. Solução

Aplicar as correcções e actualizações fornecidas pelos fabricantes
Vários fabricantes disponibilizaram correcções e actualizações que implementam a aleatoriedade nos portos de comunicação no servidor de nomes. Esta alteração reduz significativamente a praticabilidade de um ataque por envenenamento da memória temporária. Para mais informações sobre os sistemas afectados consulte a secção “Systems Affected” da nota de vulnerabilidade  VU#800113.

Os Stub Resolvers são igualmente vulneráveis a este tipo de ataques. Os Stub Resolvers que irão lidar com pedidos em resposta ao comportamento do atacante, e que podem receber pacotes do utilizador mal intencionado devem ser actualizados. Os administradores devem ainda estar atentos a correcções ou actualizações para sistemas operativos clientes que implementem aleatoriedade nos portos de comunicação do Stub Resolver.

Restringir o acesso
Os administradores, principalmente aqueles que não puderem aplicar as actualizações necessárias, podem limitar a exposição a esta vulnerabilidade restringindo os clientes que podem efectuar pedidos por recursividade. De notar que a restrição de acesso pode ser contornada se o utilizador mal intencionado tiver acesso (indevido ou não) a um dos nós autorizados.

Filtrar tráfego no perímetro da rede
Uma vez que é necessário mascarar os endereços IP (spoof) para lever a cabo este tipo de ataques, os administradores devem filtrar os endereços mascarados (spoof) no perímetro da rede. Os RFCs RFC 2827, RFC 3704 e RFC 3013 descrevem as melhores práticas correntes para a implementação deste tipo de defesas. Esta medida requer uma análise da configuração da rede e dos requisitos dos sistemas.

Cache de DNS local
Em vez de apostar na aleatoriedade forte dos portos de comunicação num resolver, os administradores podem proteger os seus sistemas usando resolvers de cache local full-service tanto nos clientes como nos servidores que estão topologicamente perto (na rede) dos sistemas clientes. Estes resolvers devem ser utilizados em junção com a segmentação da rede mencionada em cima.

Não permitir recursividade
Não permitir recursividade em qualquer servidor de nomes que responda a pedidos de DNS a partir de sistemas não confiáveis.

Implementar aleatoriedade nos portos de comunicação
Os fabricantes que implementem o protocolo DNS são encorajados a consultar e reverem o documento "Measures for making DNS more resilient against forged answers" do IETF para informações adicionais sobre como implementar medidas de mitigação nos seus produtos. Este documento não está ainda finalizado e pode ainda sofrer algumas alterações antes da sua publicação como RFC, caso seja aprovada. 

III. Referências

US-CERT:
http://www.kb.cert.org/vuls/id/800113

SANS - Interenet Storm Center:
http://isc.sans.org/diary.html?storyid=4765

CERT.PT - Pharming:
http://www.cert.pt/download/REC-PHARM.pdf