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

Marco A P D'Andrade mdacwb em gmail.com
Sexta Agosto 1 14:28:00 PDT 2008


eheheh

Breno...

<funny>
Vc realmente é válido o argumento de que vc escreve muito :D

Eu acho que não fui claro quando pedi um "resumo" :D

</funny>

De qualquer forma, agradeço a atenção !

Sds,
Marco Antonio

2008/8/1 breno <breno em rio.pm.org>

> 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
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20080801/8a186237/attachment.html>


Mais detalhes sobre a lista de discussão Rio-pm