[Rio-pm] Fwd: [Cascavel-pm] [OT] Vulnerabilidade nos servidores de DNS

Sexta Agosto 1 12:53:22 PDT 2008

2008/8/1 Marco A P D'Andrade <mdacwb em gmail.com>:
>
>  Como me foi pedido para não fazer intervenção nos DNS's daqui, já
> que já tem gente suficiente trabalhando nisto, não me dei ao trabalho
> de estudar a falha (se alguem puder resumir, é bem vindo), mas entendo
> que o risco se dê por queries seguidas de um spoof de respostas, que
> devem chegar antes, em um momento que aquele servidor não tenha a
> informação cacheada...
>
>
> Me parece, em minha vâ filosofia, que se fosse utilizado um forward
> para um servidor diferente, o DNS já estaria seguro, pois as respostas
> não seriam recebidas pelo servidor consultado, mas por um central,
> desconhecido pelo atacante... mas é mera especulação sem conhecimento
> completo de causa, que eu precisava compartilhar com alguem ;)
>

Opa, eu não sou muito de contribuir em off-topics, mas o assunto
realmente é importante então talvez ajude a mostrar a necessidade de
atualizar servidores - ou simplesmente satisfazer um pouco a
curiosidade do MDA :-)

Na ocasião do lançamento do primeiro exploit público da
vulnerabilidade, mandei um email para a lista do curso de pentest da
Clavis detalhando um pouco mais a questão. O mesmo deverá ser
expandido, revisado e estruturado na forma de artigo para o GRIS/UFRJ
em um futuro próximo. Aos interessados, segue o forward:

[]s

-b

---------- Forwarded message ----------
From: Breno G. de Oliveira <breno em clavis.com.br>
Date: 2008/7/23
Subject: sobre os novos (e velhos) ataques a servidores DNS
To: curso_pentest em clavis.com.br

Oi Pessoal,

como vimos durante o curso, há duas formas clássicas de atacarmos
servidores DNS (cache poisoning):

1) A primeira envolve uma corrida contra o servidor verdadeiro, onde
torcemos para nossa resposta maliciosa chegar antes da resposta
legítima. Esse método traduz uma vulnerabilidade inerente do protocolo
DNS, sem correção evidente. O que se faz na indústria para mitigar o
problema é adicionar dificuldade em criar respostas válidas (i.e., que
serão aceitas pelo cliente que fez a consulta DNS, seja um host final
ou outro servidor DNS) usando valores aleatórios tanto para o campo ID
(de 16 bits, responsável por identificar a transação solicitada) do
header DNS quanto para a porta de origem da solicitação (a de destino
é, naturalmente, 53). Assim, a menos que vc esteja monitorando
ativamente as requisições de seu alvo (como fizemos em classe), fica
difícil prever tais valores a fim de mandar respostas constantes
"cegamente" ao alvo do envenenamento, (sem ao menos saber se ou quando
ele fez a solicitação!), esperando que ela vença a corrida UDP.

Nesse cenário (sem monitorar a comunicação), é preciso muito poder de
banda e processamento (sem falar cara-de-pau) para um ataque desse
tipo funcionar, a menos que alguém consiga prever com certa precisão
os valores dos campos ID e SourcePort dos pacotes DNS da vítima. Pois
é.

Em 2007, Amit Klein da Trusteer lançou um artigo que apresenta um
algoritmo capaz de prever o próximo ID e a próxima porta de
requisições feitas por um servidor BIND 9.O artigo pode ser obtido em
http://www.trusteer.com/bind9dns. Há pelo menos um exploit para essa
vulnerabilidade, disponível em http://www.milw0rm.com/exploits/4266

2) A segunda forma é mais elegante, e envolve o envio de RRs (Resource
Records) adicionais à vítima. Ela pergunta: "quem é
www.exemplo.com.br?" e vc responde: "www.exemplo.com.br é 1.2.3.4 e, a
propósito, www.site-legitimo.com.br é 4.3.2.1". Para contornar esse
problema, clientes e servidores DNS costumam fazem verificação de
autoridade para saber se as informações respondidas pelo servidor
deveriam de fato vir do servidor. Isso previne também ataques um pouco
mais elaborados nessa estrutura, como uma resposta do tipo:
"www.exemplo.com.br eu não sei, mas é resolvido por ns.google.com, e
ns.google.com.br é 4.3.2.1). Essa foi a grande onda de '95, mas agora
(felizmente) a grande maioria dos servidores DNS estão protegidos
desse tipo de ataque, certo? Bom... quase :-)

Ataques que misturam as abordagens 1 e 2 podem ser usados de uma forma
mais eficaz do que separadamente. No início deste ano, Dan Kaminski
modelou um ataque extremamente poderoso dessa forma. Tão poderoso que
culminou na criação de um grupo de trabalho envolvendo os principais
desenvolvedores de servidores DNS em um esforço conjunto (sediado na
própria Microsoft) para a resolução do problema e divulgação (dia 8 de
julho agora) de atualizações simultâneas para seus produtos - seguidos
de uma forte orientação para que administradores atualizem seus
sistemas. 13 dias depois (ontem), informações detalhadas sobre o
ataque foram divulgadas e já existem exploits disponíveis. Mas como
funciona esse novo ataque?

Se enviarmos uma resposta maliciosa fingindo ser do dominio
"exemplo.com.br", podemos devolver não apenas o endereço solicitado
(e.g. www.exemplo.com.br) como outros do mesmo dominio (e.g.
intranet.exemplo.com.br) nos RRs adicionais. Esse tipo de resposta
adicional dentro do mesmo domínio é aceita (pois passa no teste de
verificação de autoridade) e costuma visar a otimização dos tempos de
resposta e evitar solicitações futuras previsíveis. Mas ainda temos
que correr contra o servidor DNS verdadeiro e, se perdermos essa
corrida, precisaremos esperar o cache expirar para tentar a sorte
novamente.

Para contornar esse problema e tornar o ataque efetivo, fazemos com
que nossa vítima procure não por "www.exemplo.com.br", mas por um
endereço inválido qualquer, como "aaaaa.exemplo.com.br". Enquanto o
servidor DNS verdadeiro deve responder com a mensagem NXDOMAIN
("domínio não existe"), sua resposta maliciosa deve conter qualquer
coisa para esse endereço específico (qualquer coisa mesmo, não
importa) e adicionar à resposta um RR adicional dizendo que
"www.exemplo.com.br" aponta para o IP malicioso!

Até aí nada de mais, é apenas uma variação do ataque #2 respondendo a
informação adicional para o mesmo domínio em vez de para um dominio
alternativo. Ainda temos que vencer a corrida! A grande sacada está em
forçar a vítima a fazer *diversas* queries DNS para servidores
inexistentes, para que possamos repetir a corrida tantas vezes quanto
necessário. Ou seja: se perdemos com "aaaaa.exemplo.com.br", tentamos
novamente com "aaaab.exemplo.com.br", "aaaac.exemplo.com.br".... até
um improvável "zzzzz.exemplo.com.br". E digo improvável pois, em 26^5
solicitações (11.881.376), não vencer nenhuma corrida é muita falta de
sorte :-)

Estimativas sugerem que ataques bem sucedidos podem ser feitos em
menos de 10 segundos em servidores DNS sem as correções aplicadas. 10
segundos!

Lembrem-se também que ataques a servidores DNS são facilitados quando
tiramos o destino original do ar (assim, corremos apenas contra nós
mesmos). Duas formas eficientes de se retirar servidores DNS do ar
são:

Servidores DNS utilizam o protocolo UDP para responder solicitações, e
TCP para transferência de zona. Como mensagens UDP estão limitadas a
512 bytes (sem contar os cabeçalhos UDP e IP), respostas maiores são
truncadas e possuem o bit TC ativo no header. Algumas implementações,
no entanto, optam por solicitações DNS via TCP para esses casos,
evitando assim que os dados sejam truncados - mas abrindo toda uma
gama de possibilidades de ataques, e por isso é recomendado que
conexões TCP/53 sejam sempre desativadas em ambientes hostis como a
Internet.

Mas, voltando à ataques de negação de serviços a servidores DNS. Se
eles aceitam conexões TCP (quer para transferência de zona ou para
transações DNS via TCP), teremos algumas vantagens em cima de ataques
de flooding tradicionais via TCP. Do RFC 1035 que especifica o DNS,
seção 4.2.2 ("TCP Usage"):

-------------------------8<---------------------------
- The server should assume that the client will initiate connection
closing, and should delay closing its end of the connection until all
outstanding client requests have been satisfied.

- If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle for a
period on the order of two minutes.  In particular, the server should
allow the SOA and AXFR request sequence (which begins a refresh
operation) to be made on a single connection. Since the server would
be unable to answer queries anyway, a unilateral close or reset may be
used instead of a graceful close.
-------------------------8<---------------------------

Então, ataques de SYN flooding contra a porta 53/tcp devem ser
bastante eficazes. Outra possibilidade é fazer diversas solicitações
que obriguem o servidor DNS alvo do DoS a pedir a informação a outros
servidores DNS (em particular, servidores que você controle) e
aumentar o tempo de resposta através do envio de informações
adicionais desnecessárias e demoradas (como registros TXT
grosseiramente exagerados).

Sintam-se como sempre à vontade para usarem a lista a fim de discutir
essas e outras questões!

[]s

breno