Como Trudy poderia enganar o DNS

Como Trudy poderia enganar o DNS? Na verdade, é relativamente fácil. Em resumo, Trudy pode

enganar o servidor DNS no ISP de Alice, enviando-lhe uma consulta do endereço IP de Bob.

Infelizmente, como o DNS utiliza o UDP, o servidor DNS não tem nenhum meio real de verificar

quem forneceu a resposta. Trudy pode explorar essa propriedade forjando a resposta esperada e,

desse modo, injetar um falso endereço IP no ca che do servidor DNS. Por simplicidade, vamos supor

que o ISP de Alice não tem in icialmente uma entrada para o Web site de Bob, bob.com. Se tiver,

Trudy pode esperar até ele entrar em timeout e tentar mais tarde (ou usar outros truques).

Trudy inicia o ataque enviando uma solicitação de pesquisa ao ISP de Alice, pedindo o endereço IP

de bob.com. Tendo em vista que não existe nenhuma entrada correspondente a esse nome DNS, o

servidor de cache consulta o servidor de nível superior em busca do domínio com, a fim de obter

uma entrada. No entanto, Trudy invade o servidor com e envia de volta uma resposta falsa que

informa: " bob.com é 42.9.9.9" mas, na realidade, o endereço IP é o dela. Se sua falsa resposta

voltar primeiro ao ISP de Alice, ela será guardada no cache e a resposta real será rejeitada como

uma re sposta não solicitada a uma consulta que não está mais pendente. Enganar um servidor

DNS fazendo-o instalar um falso endereço IP é uma ação chamada spoofing de DNS. Um cache que

contém um endereço IP intencionalmente falso como esse é chamado cache envenenado. Na

realidade, nem tudo é assim tão simples. Primeiro, o ISP de Alice verifica se a resposta contém o

endereço IP de origem correto do servidor de nível superior. Porém, como Trudy pode colocar o que

qu iser nesse campo de endereço IP, ela pode anular com facilidade esse teste, pois os endereços

IP dos servidores de nível superior têm de ser públicos.

Em segundo lugar, para permitir que os servidores DNS saibam a resposta correspondente a cada

solicitação, todas as solicitações têm um número de seqüência. Para enganar o ISP de Alice, Trudy

tem de conhecer seu número de seqüência atual. O modo mais fácil de aprender o número de

seqüência atual é Trudy registrar um domínio ela mesma, digamos, trudy-a-intrusa.com. Vamos

supor que seu endereço IP também seja 42.9.9.9. Ela também cria um servidor DNS para seu novo

domínio, dns.trudy-a-intrusa.com. Esse servidor utiliza ainda o endereço IP de Trudy, 42.9.9.9, pois

Trudy só tem um computador. Agora, ela tem de dar ciência ao ISP de Alice de seu servidor DNS.

Isso é fácil. Tudo que ela tem de fazer é pedir ao ISP de Alice quenhe forneça foobar.trudy-aintrusa.

com. Isso fará com que o ISP de Alice descubra quem serve ao novo domínio de Trudy,

solicitando o endereço ao servidor de endereços com de nível superior.

Com dns.trudy-a-intrusa.com em segurança no cache do ISP de Alice, o ataque real pode começar.

Agora, Trudy consulta o ISP de Alice em busca de www.trudy-a-intrusa.com. Naturalmente, o ISP

envia ao servidor DNS de Trudy uma consulta solicitando essa página. Essa consulta contém o

número de seqüência que Trudy está procurando. Rápida como um coelho, Trudy pede ao ISP de

Alice que procure Bob. Ela responde de imediato à sua própria pergunta, enviando ao ISP uma

resposta forjada, supostamente do servidor com de nível superior, afirmando: "bob.com é 42.9.9.9".

Essa resposta forjada contém um número de seqüência uma unidade maior que o endereço que ela

acabou de receber. Enquanto isso, ela também pode enviar uma segunda falsificação com um

número de seqüência duas unidades mais alto, e talvez mais uma dezena de números de seqüência

crescentes. Um deles deverá corresponder. Os restantes serão simplesmente descartados. Quando

chegar a resposta forjada de Alice, ele estará no cache; mais tarde quando chegar a resposta real,

ele será rejeitado, pois não haverá nenhuma consulta pendente nesse momento.

Agora, quando Alice procurar bob.com, será informada de que deve usar 42.9.9.9, o endereço de

Trudy. Trudy mo ntou um ataque de homem em posição intermediária bem-sucedido, no conforto de

sua própria sala de estar. As várias etapas desse ataque estão ilustradas na Figura 8.47. Para

piorar, esse não é o único modo de enganar o DNS. Também existem muitos outros.

Figura 8.47: Como Trudy engana o ISP de Alice

DNS seguro

Esse ataque específico pode ser anulado fazendo-se os servidores DNS usarem IDs aleatórias em

suas consultas, em vez de simplesmente contarem; porém, parece que toda vez que um furo é

vedado, surge outro. O problema real é que o DNS foi projetado em uma época na qual a Internet

era um recurso de pesquisa para algumas centenas de universidades e nem Alice, nem Bob, nem

Trudy tinham sido convidados para a festa. A segurança não era uma questão importante naquele

tempo, mas sim fazer a Internet funcionar. O ambiente mudou de forma radical ao longo dos anos;

assim, em 1994, a IETF instalou um grupo de trabalho para tornar o DNS fundamentalmente

seguro. Esse projeto é conhecido como DNSsec (DNS security), e seu resultado é apresentado na

RFC 2535. Infelizmente, o DNSsec ainda não teve uma distribuição total, e portanto numerosos

servidores DNS ainda estão vulneráveis a ataques de spoofing.

Em termos conceituais, o DNSsec é extremamente simples. Ele se baseia na criptografia de chave

pública. Cada zona DNS (no sentido da Figura 7.4) tem um par chave pública/chave privada. Todas

as informações enviadas por um servidor DNS são assinadas com a chave privada da zona de

origem, de forma que o receptor possa verificar sua autenticidade.

O DNSsec oferece três serviços fundamentais:

1. Prova de onde os dados se originaram.

2. Distribuição de chave pública.

3. Autenticação de transação e solicitação.

O principal serviço é o primeiro, que verifica se os dados que estão sendo retornados foram

aprovados pelo propri etário da zona. O segundo é útil para armazenar e recuperar chaves públicas

com segurança. O terceiro é necessário como proteção contra ataques por reprod ução e spoofing.

Observe que o sigilo não é um serviço oferecido, pois todas as informações no DNS são

consideradas públicas. Tendo em vista que a implantação do DNSsec deverá demorar vários anos,

...