FALSIFICAÇÃO DE ENDEREÇOS IP: UM PERIGO QUE - INF

FALSIFICAÇÃO DE ENDEREÇOS IP: UM PERIGO QUE RONDA OS SERVIÇOS DE RESOLUÇÃO
DE NOMES NA INTERNET
Claudio de Castro Monteiro
CEULP – Centro Universitário Luterano de Palmas
Curso de Bacharelado em Sistemas de Informação
Vagner José Sacramento
CEULP – Centro Universitário Luterano de Palmas
Curso de Bacharelado em Sistemas de Informação
GPARC – Grupo de Pesq. Aplicada em Redes de Computadores
GPARC – Grupo de Pesq. Aplicada em Redes de Computadores
RESUMO
O serviço DNS é amplamente utilizado, e extremamente necessário na Internet para resolução de nomes. Mesmo as
redes que possuem firewalls e outros mecanismos de defesas não ignoram este serviço, aceitando e permitindo a passagem
de pacotes que se destinam a aplicação DNS. Sendo assim, técnicas minuciosas podem ser utilizadas para explorar
vulnerabilidades ou facilidades existentes neste serviço, ocasionando grandes transtornos e prejuízos para os
administradores de rede e usuários finais. Esta pesquisa foi realizada com a finalidade de comprovar a veracidade da
falsificação de endereços IP's na resolução de nomes de domínios, em servidores DNS configurados sob os sistemas
operacionais Linux e WindowsNT. Após a implementação da falsificação de endereços IP's em servidores DNS, rodando nos
sistemas operacionais citados, concluímos que eles se encontram vulneráveis, podendo ter seu cache poluído.
ABSTRACT
The service DNS is used thoroughly, and extremely necessary in the Internet for resolution of names. Even the nets that
possess firewalls and other mechanisms of defenses don't ignore this service, accepting and allowing the passage of packages
that are destined the application DNS. Being like this, meticulous techniques can be used to explore vulnerabilidades or
existent means in this service, causing great upset and damages for the net administrators and final users. This research was
accomplished with the purpose of checking the truthfulness of the falsification of addresses IP's in the resolution of names of
domains, in servers DNS configured under the operating systems Linux and WindowsNT. After the implementation of the
falsification of addresses IP's in servers DNS, rotating in the mentioned operating systems, we concluded that they meet
vulnerable, could have its polluted cache.
1 INTRODUÇÃO
A maioria das redes que compõem a Internet
usufruem dos serviços de DNS (Domain Name
System) para resolução de nomes de domínios. As
redes que possuem sistemas defensivos não ignoram
estes serviços, aceitando e permitindo a passagem de
pacotes que se destinam a aplicação DNS. A partir
da afirmação de que a maioria das redes não
restringem o tráfego de pacotes destinados aos
serviços de DNS, técnicas de ataques mais
sofisticadas podem ser aplicadas, fazendo com que
uma simples requisição de resolução de nome
aparentemente normal, possa ocasionar um ataque
ao servidor DNS da rede.
A partir do estudo realizado sobre os protocolos
que compõem a suite1 TCP/IP, podemos identificar
uma série de falhas na implementação de diversos
protocolos[1], permitindo que certos tipos de ataques
sejam aplicados, inclusive o que envolve a
falsificação de endereços IP fornecidos por
servidores DNS na resolução de nomes de
domínios(DNS SPOOF). O DNS SPOOF utiliza
diversos recursos para realizar a falsificação de IP na
resolução de nomes de um determinado servidor
DNS. Um recurso utilizado é o IP SPOOF, que
consiste nas facilidades que o protocolo IP oferece
no preenchimento de pacotes IP, de acordo com as
necessidades de um atacante, técnicas como DNS
SPOOF, BLIND SPOOF, HIJACKING SPOOF,
ICQ SPOOF e outros, simplesmente utilizam essa
facilidade.
Essa pesquisa tem o propósito de expor pontos
vulneráveis em um dos serviços mais utilizados na
Internet(DNS), mostrando aspectos práticos das
conseqüências e da implementação da falsificação
de endereços IP's na resolução de um determinado
nome de domínio fornecido por servidores DNS,
disponibilizando a informação para sociedade, para
que todos saibam da existência de algumas
vulnerabilidades que podem ser exploradas nos
serviços de nomes, e possam aprimorar as medidas
de segurança implantadas em suas redes, não
permitindo que os únicos possuidores de tais
conhecimentos sejam os invasores.
2 CONSIDERAÇÕES SOBRE OS PROTOCOLOS
IP E UDP
Cada host2 na Internet é identificado de forma
unívoca através do endereço IP atribuído na sua
configuração. Os endereços IP's estão associados às
2
1
Conjunto de protocolos
Equipamento com uma ou mais interface de
comunicação interligado na rede.
interfaces de rede e não aos hosts que as contêm O
protocolo IP defini o esquema de endereçamento
desses hosts. Este protocolo se encontra na camada
de rede da arquitetura TCP/IP conforme mostrado na
figura abaixo.
Fig. 1 - Arquitetura TCP/IP
O protocolo IP carrega consigo informações
necessárias para identificar um host tais como
origem ou destino de um pacote. Na figura abaixo é
mostrado a estrutura deste protocolo [8].
0
4
Vers
8
Hlen
16
Identification
Time to Live
19
Service Type
Flags
Protocol
24
31
Total Length
Fragment Offset
Header Checksum
struct pseudo_udp_header *pseudo=NULL;
Source IP Address
Destination IP Address
Options (if any)
Padding
Data
...
Fig. 2 Estrutura do Protocolo IP
O protocolo IP transfere dados entre os hosts
através de datagramas. Esses datagramas são
entregues para o endereço referenciado no campo
destination address do protocolo IP [8].
Em conjunto com o protocolo IP podemos
utilizar o protocolo UDP da camada de transporte
para gerenciar o processo de transmissão dos pacotes
pela rede. O UDP é um protocolo não orientado a
conexão e não confiável, não tendo controle de
envio de datagramas entre uma aplicação e outra. A
aplicação assume toda a responsabilidade pelo o
controle de erros, dentro do nível de qualidade de
serviço que a mesma requer.
A figura abaixo mostra a estrutura do pacote
UDP.
Porta origem Porta destino
Tamanho
Checksum
DATA
Fig. 3 Estrutura do protocolo
UDP
Um datagrama UDP pode conter opcionalmente
uma soma de checksum que irá testar a integridade
dos datagramas recebidos. Os datagramas
corrompidos são descartados e devem ser
recuperados pela aplicação [8].
Para identificar para qual aplicação destina-se
um pacote recebido, é utilizado na camada de
transporte o conceito de porta (port). Essa porta é
representada por um número inteiro que é associado
a uma aplicação a partir da negociação com o
sistema operacional. Existem aplicações que tem o
número da sua porta padronizada, conhecida
mundialmente. Algumas dessas aplicações são :
DNS, FTP, TELNET, HTTP etc.
Para calcular o checksum conforme o exigido
pelos padrões de implementação do protocolo
UDP(RFC 768) é necessário utilizar um pseudo
cabeçalho que contém algumas informações do
protocolo IP.
Como podemos ver no código transcrito abaixo
os tipos de informações tratadas pelo pseudo
cabeçalho são: endereço IP de origem, endereço IP
de destino, tipo de protocolo utilizado e o tamanho
do pacote UDP.
...
pseudo = (struct pseudo_udp_header *)
((char *)udp2 - 12);
bzero((char *)pseudo,sizeof(struct
pseudo_udp_header));
pseudo->source.s_addr = source;
pseudo->dest.s_addr = dest;
pseudo->zero = 0;
pseudo->protocol = IPPROTO_UDP;
pseudo->length = htons(UDPHDRSIZE);
udp->source = htons(sport);
udp->dest
= htons(dport);
udp->len
= htons(UDPHDRSIZE +
datasize);
udp->check = in_cksum((u_short
*)pseudo,20);
/*Desfazendo do Pseudo Cabeçalho*/
bzero((char
*)pseudo,sizeof(struct
pseudo_udp_header));
...
3 O SERVIÇO DE NOMES
Os serviços de nomes são utilizados para facilitar
a identificação da origem de uma determinada
informação. É mais simples a utilização do nome
www.cade.com.br do que o endereço IP
200.244.248.128, sendo que ambos referenciam a
mesma máquina. Os responsáveis por traduzir o
nome de domínio para o seu respectivo endereço IP
são os servidores DNS [6].
A comunicação entre as máquinas pertencente as
diversas redes que compõem a Internet, ocorre
baseando-se nos endereços IP's e não nos nomes de
domínios. Sendo assim, podemos requisitar algum
serviço que esteja disponível em uma determinada
máquina localizada em algum lugar do mundo, tanto
digitando o seu endereço IP quanto digitando o seu
nome, pois ambos referenciam a mesma máquina. A
única diferença é que quando for digitado o nome
da máquina, será requisitado os serviços do servidor
DNS na resolução do nome de domínio para o seu
respectivo endereço IP [5].
Abaixo são mostradas algumas informações
sobre as máquinas citadas no exemplo logo a seguir.
201.5.2.198 = mascote.mydomain.com
201.5.2.195 = dns.mydomain.com
31.30.4.7 = dns.ola.com
115.58.5.7 = ns.internic.net
204.10.53.9 = ns.com
31.33.7.4:53 = dns.ola.com
Formato do pacote enviado:
Endereço IP: Porta Endereço IP: Porta
Æ
No exemplo a ser detalhado, o cliente
mascote.mydomain.com tenta acessar o site
www.ola.com. O primeiro passo realizado foi
questionar o servidor DNS primário da rede
(dns.mydomain.com) pelo endereço IP da máquina
www que pertence ao domínio ola.com, para que
logo em seguida seja possível requisitar a página
web.
[mascote.mydomain.com]
[dns. mydomain.com]
201.5.2.198:2000
201.5.2.195:53
[A?www.ola.com]
No exemplo acima foi enviado uma requisição
para resolução do nome (www.ola.com) a fim de
obter o endereço IP correspondente. Essa requisição
foi enviada para o servidor DNS primário da rede
utilizando a porta de origem 2000 e a porta de
destino 53 (Porta padrão em que todos servidores
DNS atendem requisições).
Logo em seguida, o servidor DNS tentará
resolver
o
nome
informado
por
mascote.mydomain.com.
[dns.mydomain.com]
[ns.internic.net]
201.5.2.195:53
115.58.5.7:53
[dns?www.ola.com]
Como o servidor DNS (dns.mydomain.com) não
tem autoridade sob o domínio ola.com ele pergunta
ao servidor ns.internic.net qual é o servidor de
nomes que responde pelo domínio ola.com, caso ele
não saiba ele envia uma resposta para
dns.mydomain.com informando o servidor DNS que
tem autoridade sob todos domínios '.com'.
[ns.internic.net]
[dns.mydomain.com]
115.58.5.7:53
201.5.2.195:53
[ns para .com é 204.10.53.9]
Logo em seguida, dns.mydomain.com enviará
uma requisição para o servidor de nomes
responsável por todos domínios '.com' perguntando a
ele qual é o endereço IP do servidor DNS que tem
autoridade sob o domínio ola.com.
[dns.mydomain.com]
[ns.com]
201.5.2.195:53
204.10.53.9:53
[dns?ola.com]
Resposta de ns.com é mostrada abaixo:
[ns.com]
[dns.mydomain.com]
204.10.53.9:53
201.5.2.195:53
[O dns de ola.com é: 31.33.7.4]
Note que agora o servidor dns.mydomain.com
conhece o endereço IP do servidor de nomes
responsável pelo domínio ola.com. Em seguida, ele
enviará uma pergunta para este servidor
questionando qual é o endereço IP da máquina
www.ola.com.
[dns.mydomain.com]
[dns.ola.com]
201.5.2.195:53
31.33.7.4:53
[A?www.ola.com]
Resposta de dns.ola.com será então:
[dns.ola.com]
[dns.mydomain.com]
31.33.7.4:53
201.5.2.195:53
[www.ola.com == 31.33.7.44]
Agora que o servidor dns.mydomain.com sabe o
endereço IP da máquina www.ola.com, ele
armazena esta informação em cache por um
determinado tempo, enviando logo em seguida uma
resposta para o cliente mascote.mydomain.com.
[dns.mydomain.com]
[mascote.mydomain.com]
201.5.2.195:53
201.5.2.198:2000
[www.ola.com == 31.33.7.44]
A
partir
do
momento
em
que
mascote.mydomain.com conhece o endereço IP de
www.ola.com, ele pode requisitar a página web.
[mascote.mydomain.com]
[www.ola.com]
201.5.2.198:2001
31.33.7.44:80
[pede página web - GET /index.htm]
Os passos mostrados acima, demostram o
funcionamento básico de um servidor DNS, para
resolução de um nome de domínio em que ele não
tem autoridade. Logo após a resolução do nome de
domínio questionado, o servidor DNS está apto a
responder para qualquer cliente DNS que, o
endereço IP da máquina www.ola.com é 31.33.7.44
enquanto esta informação não expirar em seu cache.
3.1 Formato do Pacote DNS e Descrição da sua
Estrutura
Estrutura do Cabeçalho DNS de acordo com a
RFC 1035:
Todas comunicações que envolvem o protocolo
DNS, apresentam um simples formato de mensagem
dividida em 5 seções [4]:
ID - O ID permite identificar cada pacote DNS. Ele
é utilizado somente para reconhecer as diferentes
requisições enviadas ou recebidas.
Cabeçalho
Pergunta(s)
Resposta(s)
Autoridade(s)
Adicional
Fig. 4 Formato de uma
mensagem enviada por
um servidor DNS
a)
A seção de cabeçalho sempre está presente. O
cabeçalho inclui campos que especificam quais
das seções restantes estão presentes, e também
especifica se a mensagem é uma pergunta ou
uma resposta.
b) A seção de pergunta contém campos que
descrevem uma pergunta a um servidor de
nome. Estes campos descrevem um tipo de
pergunta(TIPO DE QUERY), uma classe da
pergunta (TIPO DE CLASSE), e um nome de
domínio (Nome a ser resolvido).
As últimas três seções têm o mesmo formato.
c)
A seção de resposta contém registros que
responde uma pergunta;
d) Seção de autoridade contém registros que aponta
para um ou mais servidor(es) de nome(s) que
tem autoridade sob o domínio em questão;
e) A seção de registros adicional contém
informações adicionais sobre a pergunta
realizada, mas não é estritamente respostas para
a pergunta.
Como todos protocolos da suíte TCP/IP, o
protocolo DNS possui vários campos para
desempenhar suas funcionalidades, sendo assim,
passaremos a descrever a função de cada um dos
campos que compõem as cinco seções do pacote
DNS, de acordo com o padrão de implementação
deste protocolo (RFC 1035).
DNS packet header (Cabeçalho do Pacote DNS)
O cabeçalho do pacote DNS contém os seguintes
campos:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ID
QR Opcode AA TC RD RA
Z
RCODE
QDCOUNT
ANCOUNT
NSCOUNT
ARCOUNT
Fig. 5 Formato do cabeçalho DNS
Flags - Os flags são divididos em várias partes :
FLAGS
QR
Opcode
AA
TC
RD
RA
ZERO
RCODE
Tamanho em Bits
1
4
1
1
1
1
3
4
QR - Se o bit = 0 significa que o pacote é uma
pergunta, se =1 ele é uma resposta.
opcode - O valor é = 0 para uma requisição normal
e, 1 para uma requisição reservada.
AA - Se igual a 1, significa que o servidor de nomes
tem autoridade sob o domínio informado.
RD - se o flag for = 1, significa que "Requisição
Recursiva" está sendo imposta na pergunta.
RA - Este flag é = 1 se a recursão está disponível.
Este flag é setado com valor 1 quando a resposta do
servidor de nomes suporta recursão.
Zero - Inicializado com valor 0 (zero);
Rcode - Contém a mensagem de erro de retorno do
DNS.
0 significa que nenhum erro foi encontrado
1 "Erro no Formato " significa que o
servidor foi incapaz de interpretar a
pergunta enviada.
2 "Servidor Falhou" O servidor falhou na
resolução da pergunta enviada
3 "Erro no Nome" O nome de domínio
perguntado não existe
4 "Não Implementado" O servidor de
nomes não suporta o tipo de requisição
especificada na pergunta
5 "Recusado" O servidor de nomes recusa
processar a informação da pergunta enviada
devido as políticas de segurança
configurada.
QDCOUNT - Informa a quantidade de pergunta.
ANCOUNT - Informa a quantidade de resposta.
NSCOUNT - Informa a quantidade de servidores de
nomes que tem autoridade sob o domínio informado.
ARCOUNT - Quantidade de informações adicionais.
Seção de pergunta do pacote DNS
Logo abaixo é mostrado o formato da seção de
pergunta enviada em uma requisição para resolução
de nomes ou endereço IP.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Nome a ser resolvido
Tipo de Query
Tipo de Classe
Fig. 6 Formato da Seção de Pergunta
Descrição dos campos:
Nome a ser resolvido: é representado por uma
seqüência de caracteres que juntos irão compor
rótulos intercalados por um número que representa o
seu tamanho.
Ex: O nome www.ola.com é representado em uma
pergunta da seguinte forma: 3|w|w|w|3|o|l|a|3|c|o|m|0
Tipo de query: Neste campo conterá o tipo de
requisição a ser resolvida, se é de um nome ou de
um endereço IP (reverso).
Nome Valor
Descrição
A
1
Resolver um nome de domínio
PTR 12
Resolver endereço IP
Fig. 7 Tipos de Query
Tipo de classe: Especifica a classe que compõem a
Pergunta.
Seção de Resposta, de Autoridade, de Adicionais do
pacote DNS
A seção de resposta, autoridade e adicionais
apresentam o mesmo formato, a mesma estrutura em
uma resposta enviada por um servidor DNS.
O formato destas seções é mostrado abaixo:
Nome a ser resolvido
TIPO
CLASSE
TTL (Tempo de validade da resposta)
Tamanho da Resposta
Dados da Resposta
Fig. 8 Formato da Seção de Resposta
Nome a ser resolvido: O nome de domínio contido
na seção de resposta do servidor DNS é o mesmo
enviado
na
seção
de
pergunta.
Ex.:
3www3ola3com0
Tipo: Este campo especifica o significado dos
dados no campo "Dados da Resposta".
classe: Especifica a classe dos dados no campo
"Dados da Resposta". A classe é igual a 1 para dados
da Internet.
Tempo de validade (TTL): Este campo guarda um
valor em segundos informando por quanto tempo a
informação vai ter validade no cache.
Tamanho da resposta: Informa o tamanho do
campo "dados da resposta". Se o campo "tamanho da
resposta" for igual a 4, significa que os dados da
resposta são 4 bytes longo.
Dados da resposta: Aqui é colocado o endereço IP
ou o nome obtido na resposta do servidor DNS.
Contém a resposta da pergunta realizada.
Um exemplo do preenchimento de um pacote DNS
enviado em uma pergunta é mostrado logo abaixo:
dns.mydomain.com:53
dns.ola.com:53
[A?www.ola.com]
ID = 2005 QR = 0 AA = 0 TC = 0 RD = 1 RA = 0
OPCODE = 0
RCODE = 0
QDCOUNT = htons(1)
ANCOUNT = 0
NSCOUNT = 0
ARCOUNT = 0
Seçao de Pergunta
Nome a ser resolvido = [3|w|w|w|3|o|l|a|3|c|o|m|0]
tipo de questão = htons(1)
Tipo de query=htons(1)
Fig. 9 Formato de uma Pergunta enviada por um servidor DNS
Está é a pergunta, agora será mostrado a resposta
de dns.ola.com.
dns.ola.com:53
dns.mydomain.com:53
[www.ola.com=31.33.7.44]
ID = 2005 QR = 1 AA = 1 TC = 0 RD = 1 RA = 1
OPCODE = 0
RCODE = 0
QDCOUNT = htons(1)
ANCOUNT = htons(1)
NSCOUNT = 0
ARCOUNT = 0
Seção de Pergunta
Nome a ser resolvido = [3|w|w|w|3|o|l|a|3|c|o|m|0]
Tipo de questão = htons(1)
Tipo de query=htons(1)
Seção de Resposta
Nome a ser resolvido = [3|w|w|w|3|o|l|a|3|c|o|m|0]
Tipo = htons(1)
Classe = htons(1)
TTL = 3600
Tamanho da Resposta = htons(4)
Dados da Resposta = inet_addr("31.33.7.44")
Fig. 10 Formato de um pacote de resposta enviado por um
servidor DNS
Podemos perceber que algumas informações são
iguais tanto no pacote de pergunta quanto no pacote
de resposta enviado por dns.ola.com. Um dos
campos que apresenta a mesma informação tanto na
pergunta quanto na resposta é o ID. Como foi
explicado anteriormente o campo ID do pacote DNS
serve para identificar as diferentes perguntas e
respostas enviadas por ele. Sendo assim, para cada
pergunta enviada contendo uma requisição de
resolução de um domínio, o servidor DNS a
identifica com um número específico, e fica
aguardando uma resposta que tenha o mesmo
identificador(ID).
No exemplo abaixo é mostrado uma pergunta de
resolução do nome www.ola.com enviada para o
servidor dns.ola.com com ID = 2005.
dns.mydomain.com:53
dns.ola.com:53
[A?www.ola.com[2005]]
Resposta de dns.ola.com.
dns.ola.com:53
dns.mydomain.com:53
www.ola.com=31.33.7.44[2005]]
Para gerar o pacote de resposta corretamente,
tem que ser tratado algumas particularidades de
implementação do protocolo DNS, conforme o
exigido pelo padrão de implementação deste
protocolo, detalhados nas RFC's 1034 e 1035. Uma
informação de extrema importância, relatada pela
RFC 1035, é que o campo "Nome a ser resolvido" da
seção de resposta do pacote DNS, não tem o mesmo
conteúdo do campo "Nome a ser resolvido" da seção
de pergunta. Para reduzir o tamanho da mensagem, o
serviço DNS utiliza uma compressão, que elimina a
repetição de nomes de domínios na mesma
mensagem. A entrada de nomes de domínios, mais
especificamente o campo "Nome a ser resolvido" da
seção de resposta, da seção de autoridade e da seção
de adicionais, são sobrepostos por um ponteiro para
ocorrência anterior de mesmo nome, que no caso é o
campo "Nome a ser resolvido" da seção de pergunta.
Sendo assim, o campo "Nome a ser resolvido" da
seção de resposta, da seção de autoridade e da seção
de adicionais são representados por um offset1 que
tem a seguinte formação:
0 1 2 3 4 5
1 1
6 7
8 9 10 11 12 13 14 15
OFFSET
A partir da depuração de pacotes de respostas
enviadas por servidores DNS, percebemos através
do tcpdump e de uma outra ferramenta conhecida
como ethereal, (excelente ferramenta gráfica para
depurações de pacotes), que o valor de offset 0xc00c
é padrão em todos os pacotes. Sendo assim,
definimos que este valor de offset deve ser utilizado
em todos pacotes de respostas. O preenchimento do
campo "Nome a ser resolvido" da seção de resposta
do pacote DNS é mostrado no código abaixo.
1
offset - Endereço de memória.
...
u_short offset = -1;
offset = 0xc00c;
PUTSHORT(offset,answer);
...
4 IP SPOOFING: A FALSIFICAÇÃO DE
ENDEREÇOS IP
O IP SPOOFING é um recurso utilizado para
falsificar a origem do pacote. Consiste nas
facilidades que o protocolo IP oferece no
preenchimento de pacotes IP, de acordo com as
necessidades de um atacante. Técnicas como DNS
SPOOF, BLIND SPOOF, HIJACKING SPOOF,
DOS e outros, simplesmente utilizam essa facilidade
[6].
O IP SPOOFING é a técnica de preencher
pacotes IP com um endereço de origem qualquer a
fim de completar a ilusão de um pacote válido
recebido em uma conexão ou sessão [1].
As facilidades de aplicar o IP SPOOFING em
uma determinada ocasião, é mostrado no código a
seguir, onde é preenchido o pacote IP de acordo com
a necessidade.
...
ip_header->ip_v
= IPVERSION;
ip_header->ip_tos = 0;
/*Informando o IP DE ORIGEM*/
ip_header->ip_src.s_addr = source;
ip_header->ip_dst.s_addr = dest;
ip_header->ip_p
= IPPROTO_UDP;
ip_header->ip_ttl = MAXTTL;
ip_header->ip_hl = 5;
...
5 COMO ACONTECE O SPOOFING DE IP EM
SERVIDORES DNS
O SPOOFING DE IP em servidores DNS ocorre
quando é enviado uma resposta falsa para um
servidor de nomes, utilizando o mesmo ID do pacote
DNS de uma pergunta enviada, fazendo com que
este servidor DNS aceite uma informação falsa
contendo um endereço IP qualquer como resposta da
resolução do nome de domínio questionado.
Quando um servidor DNS faz uma pergunta para
outro servidor, questionando o endereço IP de um
determinado nome de domínio, ele fica aguardando
uma resposta do mesmo. Caso ele receba uma
resposta contendo as informações esperadas, ele
simplesmente as retém.
Os detalhes verificados na resposta recebida pelo
servidor DNS são:
➤ se o campo ID e o campo "Nome a ser
resolvido" do pacote DNS são iguais aos
enviados na pergunta;
➤ se a porta de origem é igual a porta de destino
do pacote UDP enviado na pergunta;
➤ se o endereço IP de origem é igual ao
endereço IP de destino enviado na pergunta.
Mas suponhamos que esta resposta tenha sido
enviada por um terceiro que está se passando pelo
servidor DNS questionado, as informações da
resposta recebida como resolução do nome de
domínio questionado podem estar incorretas,
fazendo com que o servidor DNS armazene em
cache um endereço IP falso sobre o domínio em
questão.
A figura 11 abaixo demonstra a aplicação da
falsificação de IP em uma resolução de nomes com o
ID do cabeçalho DNS igual a 2005.
inicialização. A linha de execução deste programa
ficou definida da seguinte forma:
DNShide <interface [eth0/ppp0]> <IP do
servidor DNS vítima> <IPSPOOF
invertido> <URL a ser "spoofada">
Ex.:
DNShide eth0 20.111.50.1 4.3.2.1
www.ola.com
Esta linha de comando informa que o programa
DNShide deverá "sniffar" a interface de
comunicação eth0 e enviar uma resposta para o
servidor DNS que tem o endereço IP 20.111.50.1,
fornecendo ao mesmo uma informação incorreta
dizendo que o nome de domínio www.ola.com tem
Qual é o IP de
www.ola.com
dns.mydomain.com
dns.ola.com
[A?www.ola.com[2005]]
201.5.2.195:53
31.33.7.4:53
Responde
primeiro tentando
ser passar por
dns.ola.com
[[2005]www.ola.com = 1.2.3.4
DNShide
201.5.2.15
mascote.mydomain.com
Fig. 11 FALSIFICAÇÃO DE IP em
servidores de nomes
Podemos perceber que a falsificação de IP na
resolução de nomes de domínios, mais conhecido
como DNS SPOOF, tem a finalidade de enviar uma
resposta falsa para o servidor de nomes, fazendo
com que ele armazene em cache, por um
determinado tempo, um endereço IP falso sobre um
determinado nome de domínio, desviando a origem
da informação.
Para comprovarmos a veracidade da falsificação
de endereços IP's na resolução de nomes de domínio
em servidores DNS configurados sob os sistemas
operacionais Linux e WindowsNT, implementamos
um programa que envia uma resposta de resolução
de nomes com endereços IP's falsos. Este programa
ficou conhecido como DNShide.c .
Para executar este programa é necessário entrar
com alguns parâmetros para sua correta
endereço IP 1.2.3.4 .
Devido a aplicação implementada (DNShide),
desempenhar a funcionalidade de um sniffer para
capturar os pacotes da rede, e a funcionalidade de
enviar uma resposta falsa para um servidor DNS, é
necessário que ela esteja rodando em uma máquina
que se encontre na mesma rede do servidor DNS
que irá receber a resposta falsa. Sendo assim o
DNShide deverá está rodando na máquina P, na
tentativa de enviar uma resposta falsa para o
servidor Y.
Uma das informações que teremos que saber
para formular o pacote de resposta é o ID do
cabeçalho DNS enviado na pergunta pelo servidor
Y. Para adquirirmos esta e outras informações
necessárias foi implementado um sniffer no próprio
DNShide, que tem a funcionalidade de pegar todos
pacotes que estão transitando pela rede local e filtrá-
los de modo a selecionar somente aqueles que se
destinam a um servidor DNS, ou seja, filtrar todos
pacotes que tenham a porta de destino do protocolo
UDP igual a 53. Após identificado o pacote de
pergunta do servidor DNS que irá receber uma
resposta falsa, deverá ser retirado dele, as
informações necessárias para formular o pacote de
resposta. Estas informações são: O "ID" do
cabeçalho DNS, "Nome a ser resolvido" da seção de
pergunta, "porta de origem" e "porta de destino" do
pacote UDP, "IP de origem" e "IP de destino" do
pacote IP. Parte código utilizado para colocar a
interface no modo promiscuo, identificar a pergunta
enviada pelo servidor Y e formular o pacote da
resposta a ser enviado para este servidor é mostrado
abaixo:
/*COLOCAR A INTERFACE DE COMUNICAÇÃO NO MODO
PROMISCUO*/
...
int fd;
struct ifreq ifr;
fd=socket(AF_INET,SOCK_PACKET, htons(0x800));
if(fd < 0)
{
perror("cant get SOCK_PACKET socket");
exit(0);
}
strcpy(ifr.ifr_name, d);
s=ioctl(fd, SIOCGIFFLAGS, &ifr);
if(s < 0)
{
close(fd);
perror("cant get flags");
exit(0);
}
ifr.ifr_flags |= IFF_PROMISC;
s=ioctl(fd, SIOCSIFFLAGS, &ifr);
if(s < 0) printf("A interface nao pode ser setada no modo
promiscuous)");
...
/*FILTRO UTILIZADO PARA IDENTIFICAR A
PERGUNTA DO SERVIDOR DNS VÍTIMA */
...
if(ip->ip_p == IPPROTO_UDP)
if(ip->ip_src.s_addr == dnsvitima)
if(ntohs(udp->dest)==53)
if(dns->qr == 0)
return(TRUE);
...
// PREENCHENDO O PACOTE DNS DE RESPOSTA
...
offset = 0xc00c;
dns2->id
= dns->id; /*Identificador do pacote*/
dns2->qr = 1;
dns2->opcode = QUERY;
dns2->aa = 0;
dns2->tc = 0;
dns2->rd
= 1;
dns2->ra = 1;
dns2->unused = 0;
dns2->rcode = 0;
dns2->qdcount = htons(1);
dns2->ancount = htons(1);
dns2->nscount = htons(0);
dns2->arcount = htons(0);
question = (char *)packet2 + IPHDRSIZE + UDPHDRSIZE
+ DNSHDRSIZE;
question += sizelabel+1;
...
Após retirar as informações necessárias do
pacote enviado na pergunta realizada pelo servidor
DNS vítima, é então montado um pacote de resposta
manipulando as camadas de rede, transporte e
aplicação, preenchendo os pacotes IP,UDP e DNS,
com as devidas particularidades de implementação
pertinentes de cada protocolo.
O último passo é enviar este pacote de resposta
para o servidor DNS vítima, aplicando a falsificação
de endereço IP na resolução de um nome de
domínio.
Para testarmos o programa implementado,
simulamos um ambiente baseado na figura 11, onde
temos duas máquinas ligadas no mesmo barramento
ethernet, pertencentes a mesma rede local, sendo
elas a máquina Y e a máquina P. A máquina Y é o
servidor DNS primário da rede local, e a máquina P
é uma estação qualquer com sistema operacional
Linux, interligada na mesma rede de Y. A máquina
X é qualquer outro servidor DNS situado em algum
lugar do mundo.
Nos experimentos realizados, utilizamos um
servidor DNS(máquina Y), que trabalha sob o
sistema operacional Linux com kernel 2.2.16 ou
WindowsNT 4.0 com service pack 6. Em nosso
caso, foi configurado uma máquina com dual boot1
bastando iniciá-la com o sistema operacional
desejado.
Preparado o ambiente, realizamos vários
experimentos. Primeiro enviamos uma resposta de
resolução de nome, contendo informações falsas a
fim de poluir o cache do servidor DNS da máquina
Y, rodando sob o sistema operacional WindowsNT
4.0. Os passos realizados neste experimento estão
detalhados a seguir.
Baseado na figura 11 conseguimos falsificar o
endereço IP em uma resposta de resolução de nome,
enviando uma pergunta para dns.mydomain.com
questionando qual é o endereço IP da máquina
www.ola.com. No entanto, como este servidor não
tem autoridade sob o domínio informado, ele enviou
uma pergunta para o servidor de nomes que tem
autoridade sob o domínio ola.com. Neste exato
momento o DNShide estava rodando na máquina P
"sniffando" os pacotes da rede local, capturando
assim o pacote enviado pelo servidor DNS(máquina
Y) destinado a máquina dns.ola.com(máquina X), e
retirando deste pacote as informações necessárias
para montar uma resposta("ID" do cabeçalho DNS,
"Nome a ser resolvido" da seção de pergunta, "porta
de origem" e "porta de destino" do pacote UDP, "IP
de origem" e "IP de destino" do pacote IP. Logo em
seguida, o DNShide preenche o pacote IP atribuindo
ao campo source IP address o endereço IP do
servidor dns.ola.com com intuito de fazer com que o
pacote pareça estar vindo desta máquina, preenche o
pacote UDP conforme o esperado por
dns.mydomain.com e preenche o pacote DNS com
uma informação incorreta sobre a resolução do nome
1
dual boot - Informa as opções de inicialização da
máquina, tendo a disponibilidade de optar por um
dos dois sistemas operacionais instalados.
de domínio questionado, informando que o endereço
IP da máquina de nome www.ola.com é 1.2.3.4, e
envia uma resposta contendo estas informações para
o servidor dns.mydomain.com.
Quando o servidor Y envia uma pergunta para o
servidor X, ele fica aguardando uma resposta do
mesmo, ou seja, ele fica aguardando uma resposta
que tenha o mesmo ID do cabeçalho DNS enviado
na pergunta, o endereço IP de origem do pacote IP
igual ao endereço IP de destino enviado na pergunta
e as portas de origem e destino do protocolo UDP
igual a 53.
Ao testamos o servidor DNS do WindowsNT e
do Linux enviando duas respostas com conteúdos
diferentes.
Na primeira tentativa, o DNShide rodando na
máquina P, envia uma resposta para Y tentando se
passar por X. As informações do pacote na resposta
enviada são as seguintes: ID do cabeçalho DNS
igual 2005, "Nome a ser resolvido" da seção de
pergunta
do
pacote
DNS
igual
a
[3|w|w|w|3|o|l|a|3|c|o|m|0], porta de origem do
protocolo UDP = qualquer uma acima de 1024, porta
de destino do protocolo UDP igual a 53, source IP
address (ENDEREÇO IP DE ORIGEM) = qualquer
endereço IP diferente de 31.33.7.4. Logicamente não
deveria funcionar, pois a máquina Y está
aguardando uma resposta que tenha o campo source
IP address do pacote IP igual a 31.33.7.4, conforme
explicado no parágrafo anterior.
No entanto, o servidor DNS do WindowsNT
aceitou a resposta enviada pela máquina P,
demonstrando que o único detalhe analisado e
exigido por este servidor para autenticar um pacote
DNS é que a resposta tenha o mesmo ID e o mesmo
"Nome a ser resolvido" da pergunta que ele enviou,
desprezando boa parte das informações do protocolo
IP e do protocolo UDP. Ex: o endereço IP de
origem(pacote IP) e a porta de origem(pacote UDP).
Quando tentamos realizar os mesmos testes
exemplificados acima com um servidor DNS
rodando sob sistema operacional Linux, não
obtivemos nenhum sucesso, pois ele checa além do
ID do cabeçalho DNS, todas informações do pacote
recebido, analisando todos os campos do protocolo
IP e UDP. Caso as informações do pacote recebido
não estejam dentro das exigências esperadas, ele
simplesmente o despreza.
Ficamos surpresos com o fato do WindowsNT
aceitar um pacote DNS sem realizar uma checagem
de autenticidade da origem da informação, não
verificando se o endereço IP de origem da resposta
recebida é igual ao endereço IP de destino da
pergunta enviada.
Na segunda tentativa, o DNShide rodando na
máquina P envia uma resposta para Y tentando se
passar por X com as seguintes informações: ID do
cabeçalho DNS igual 2005, "Nome a ser resolvido"
da seção de pergunta do pacote DNS igual a
[3|w|w|w|3|o|l|a|3|c|o|m|0], portas de origem e de
destino do protocolo UDP igual a 53, source IP
address do pacote IP(ENDEREÇO IP DE
ORIGEM) = 31.33.7.4.
Após o envio da resposta com o conteúdo
mostrado acima, concluímos que os servidores DNS
configurados sob os sistemas operacionais Linux ou
WindowsNT aceitaram a resposta sem nenhuma
restrição, armazenando em seu cache uma
informação incorreta, especificando que o endereço
IP do nome de domínio www.ola.com é igual a
1.2.3.4 e não 31.33.7.4.
Para testar se a resposta enviada pelo DNShide
foi armazenada em cache pelos servidores DNS do
Linux e do WindowsNT realizamos os os seguintes
passos:
1º Executamos a aplicação nslookup
#> nslookup
2º Ativamos o servidor dns.mydomain.com para
responder todas perguntas do nslookup
#> server=dns.mydomain.com
3ºPerguntamos
para
o
servidor
dns.mydomain.com qual é o endereço IP da
máquina www.ola.com .
#> www.ola.com
4º Conferimos a resposta enviada para o
nslookup, que foi o endereço IP = 1.2.3.4
confirmando a aceitação da resposta enviada pelo
DNShide.
#>1.2.3.4
6 CONSEQÜÊNCIAS
Após certificado que o servidor DNS armazenou
em cache uma informação incorreta sobre um
determinado nome de domínio, várias conseqüências
poderão ser explorados.
Uma das conseqüências da falsificação do
endereço IP na resolução de um nome de domínio é
a alteração da origem da informação requisitada na
abertura de uma página web. Por exemplo: Quando
o usuário digitar no browser de navegação(Internet
Explorer, Netscape, lynx ou outro qualquer), o
endereço da página www.ola.com, irá aparecer uma
página que está armazenada no servidor Web de
endereço IP 1.2.3.4 e não a página do servidor Web
de endereço IP 31.33.7.4.
Uma outra conseqüência que pode ser explorada
é a tentativa de driblar mecanismos de defesas
baseados em wrappers1.
É muito comum administradores de rede
permitirem a execução de certas aplicações somente
para determinadas máquinas ou somente para uma
única máquina da sua rede, especificando o nome ou
o endereço IP da mesma. Abaixo é mostrado um
exemplo de configuração do TCP_WRAPPER
liberando a aplicação TELNET somente para uma
única máquina na rede.
Dois arquivos precisam ser editados: hosts.allow
e hosts.deny.
/etc/hosts.allow : libera a execução dos serviços.
/etc/hosts.denny: inibe a execução dos serviços.
1
wrappers – Mecanismos de software usados para
filtrar a utilização de alguns serviços: telnet, ftp,
talk, etc.
# Esta configuração foi realizada na máquina
#mascote.mydomain.com
# configuração do arquivo hosts.allow
serviços de nomes na Internet, relatando os detalhes
da aplicação da falsificação de endereços IP's em
respostas enviadas para servidores DNS e as
conseqüências que podem ser exploradas após o
servidor DNS ter seu cache poluído.
in.telenetd: bandit.ola.com
# a linha acima informa que o TELNET está
#aberto
somente
para
a
máquina:
#bandit.ola.com
7 REFERÊNCIAS BIBLIOGRÁFICAS
[1]
#configuração do arquivo hosts.denny
in.telenetd:ALL
# A linha acima está negando a aplicação
#TELNET para todos exceto os permitidos
# no arquivo hosts.allow.
Caso um intruso consiga poluir o cache do
servidor DNS utilizado por mascote.mydomain.com,
informando para este servidor que o endereço IP da
máquina bandit.ola.com é o endereço IP da sua
máquina, ele terá a sua disposição uma seção de
telnet disponível em mascote.mydomain.com.
Isso pode acontecer porque, todas as vezes que o
serviço TELNET for requisitado na máquina
mascote.mydomain.com, ela irá perguntar ao
servidor DNS primário da rede qual é o endereço IP
de bandit.ola.com e, após a resposta do servidor
DNS, mascote irá verificar se o endereço IP da
máquina que está requisitando o serviço TELNET é
igual ao endereço IP respondido pelo servidor DNS,
se for igual ela libera a seção de TELNET, caso
contrário ela simplesmente reporta que o serviço não
está acessível.
7 REFLEXÕES FINAIS
Devido o serviço DNS ser um dos mais
utilizados na Internet, e extremamente necessário em
uma rede que requer os serviços de resolução de
nomes, realizamos essa pesquisa com fins de
comprovar as vulnerabilidades ou facilidades
existente neste serviço, que permitem a falsificação
de endereços IP's em pacotes de respostas de
resolução de nomes, enviados por servidores DNS.
Após a implementação de um programa que realiza
a falsificação de endereços IP's em pacotes de
respostas enviados para servidores DNS, realizamos
vários experimentos, que nos permitiram concluir
que servidores DNS configurados sob os sistemas
operacionais Linux e WindowsNT se encontram
vulneráveis, podendo ter seu cache poluído com
uma resposta falsa. No entanto, podemos afirmar
que tivemos maiores facilidades de comprovar a
situação exposta, em servidores DNS que trabalham
sob o sistema operacional WindowsNT 4.0. E o pior
de tudo, é que mesmo as redes que se encontram
configuradas abaixo de firewall's, podem ser
vítimas da aplicação da falsificação de endereços
IP's em pacotes de respostas enviados para os seus
servidores DNS. Temos o propósito de divulgar para
sociedade os perigos sem barreiras que cercam os
[2]
[3]
[4]
[5]
[6]
[7]
[8]
Monteiro, Claudio. Estudo e Verificação da
Segurança em Sites Internet. Dissertação de
Mestrado Defendida em Dezembro de 1997
no Departamento de
Sistemas
e
Computação da Universidade Federal da
Paraíba.
Farrow, Rik. UNIX System Security.
Reading, MA: Addison Wesley, 1991.
Ferbrache, David e Gavin Shearer. Unix
Instalation,
Security
e
Integrity.
Englewood Cliffs, NJ: Prentice Hall, 1993.
Wood, Patrick H. e Stephen G. Kochan.
UNIX System Security. Camel, IN: Hayden
Books, 1986.
M. Bishop. A Taxonomy of UNIX System
and Network Vulnerabilities. Technical
Report CSE-95-10, Univ. of California at
Davis, Sept, 1995.
G. Simson and S. Gene. Pratical Unix &
Internet Security. O´Reilly & Associates,
1996.
C. D. Brent and Z. D. Elizabeth. Building
Internet Firewalls. O´Reilly & Associates,
1996.
Comer, D. E. and D. L. Stevens.
Internetworking with TCP/IP Vol I Architecture e Protocols. Prentice-Hall,
1994.