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

Daniel de Oliveira Mantovani daniel.oliveira.mantovani em gmail.com
Segunda Agosto 4 14:24:17 PDT 2008


Alguns canalhas infelizmente liberaram o código, que era private entre
algumas pessoas.
Já está no Framework3(Metasploit).
Agora os Script Kiddies, vão poder se aproveitar falha ARRRGHHH!!!!

2008/8/4 Marco A P D'Andrade <mdacwb em gmail.com>

> Para encerrar o tema, chegou à meu conhecimento um aviso do CERT,
> relativo a problemas de DNS.
>
> Por sinal eles utilizam um esquema similar ao demonstrado
> anteriormente, mas melhor elaborado (visualmente)!
>
> http://2642efe12765161057ca96a3.et.dns-oarc.net/
>
> ========== Texto CERT ===========
> Gostariamos de solicitar que:
>
>  * Seja efetuado o upgrade do software de DNS deste servidor o mais
>   rapido possivel.
>
>   Uma descricao do problema e possiveis solucoes sao descritas em:
>
>   http://www.us-cert.gov/cas/techalerts/TA08-190B.html
>   http://www.kb.cert.org/vuls/id/800113
>   http://eng.registro.br/pipermail/gter/2008-July/019316.html
>
> Caso o upgrade ja' tenha sido feito, favor desconsiderar esta
> mensagem.  Se voce nao for a pessoa correta para corrigir o problema
> deste servidor DNS, por favor repasse essa mensagem para alguem de sua
> organizacao que possa faze-lo.
>
> Mais detalhes sobre o porque do envio desta mensagem, quem e' o
> CERT.br, como confirmar que o seu servidor e' vulneravel e como
> resolver este problema estao listados abaixo.
>
> Ao final deste email segue o IP do servidor DNS afetado.
>
> Cordialmente,
>
> CERT.br
> <cert em cert.br>
> http://www.cert.br/
>
> ======================================================================
>
> * O que e' um ataque de DNS cache poisoning?
>
>  O ataque de DNS cache poisoning (envenamento de cache) e' uma
>  tecnica que permite a um atacante introduzir informacao DNS forjada
>  no cache de um servidor DNS.
>
> * Este servidor DNS nao e' um recursivo aberto e nao aceita consultas
>  do mundo externo.  Ainda assim estou vulneravel?
>
>  Sim, se o servidor e' recursivo e possui uma versao vulneravel do
>  software de DNS, isto ja' permite que o ataque seja realizado.  A
>  atualiacao do servidor e' a unica maneira de mitigar o ataque.
>
> * Por que devo me preocupar com isso?
>
>  Ataques de DNS cache poisoning podem trazer riscos aos clientes que
>  utilizem este servidor, que podem ser direcionados a sites
>  incorretos, possivelmente maliciosos e sob o controle do atacante.
>  Programas que exploram esta vulnerabilidade ja' estao publicamente
>  disponiveis.
>
> * Onde posso obter informacoes sobre o problema e como soluciona-lo?
>
>  - Multiple DNS implementations vulnerable to cache poisoning
>    http://www.kb.cert.org/vuls/id/800113
>
> * Como posso testar se meu servidor e' vulneravel?
>
>  - check your resolver's source port behavior
>    https://www.dns-oarc.net/oarc/services/porttest
>
>  - o mesmo teste, mas usando nslookup de maquinas Windows
>    nslookup -type=txt -timeout=30 porttest.dns-oarc.net
>
>  - Web-based DNS Randomness Test
>    https://www.dns-oarc.net/oarc/services/dnsentropy
>
> * Alem de aplicar o patch, tem algo a mais que eu possa fazer?
>
>  Sim, aplicar o patch e' muito importante, mas nao e' a solucao
>  definitiva para o problema de DNS cache poisoning.  Uma solucao mais
>  permanente e' tambem a adocao de DNSSEC:
>
>    - Info: DNSSEC
>    http://registro.br/info/dnssec.html
>
> * O CERT.br esta' fazendo testes nos meus servidores?
>
>  Nao.  O Registro.br, atraves da analise das consultas que recebe,
>  identificou uma serie de servidores DNS recursivos vulneraveis.  O
>  CERT.br esta' notificando os responsaveis pelos servidores presentes
>  nesta lista.
>
> * Por que estou recebendo essa mensagem?
>
>  Voce esta' recebendo esse email por estar listado em
>  http://registro.br/ como contato desta rede ou dominio.
>
>  Se voce for contato de varias redes diferentes e' possivel que voce
>  receba mais de um email, com conteudos diferentes.  Por favor nao
>  apague outras copias que vier a receber.
>
> * O que e' o CERT.br?
>
>  O CERT.br -- Centro de Estudos, Resposta e Tratamento de Incidentes
>  de Seguranca no Brasil -- e' o Grupo de Resposta a Incidentes de
>  Seguranca para a Internet brasileira, mantido pelo NIC.br do Comite
>  Gestor da Internet no Brasil.  E' o grupo responsavel por tratar
>  incidentes de seguranca em computadores, envolvendo redes conectadas
>  `a Internet brasileira.
>
> * O que e' o Registro.br?
>
>  O Registro.br e' a entidade, no Brasil, responsavel pelas atividades
>  de registro de nomes de dominio, administracao e publicacao do DNS
>  para o dominio .br, alem da distribuicao de enderecos Internet.
> ============================
>
>
>
> Sds,
> Marco Antonio
>
> 2008/8/1 Marco A P D'Andrade <mdacwb em gmail.com>:
> > 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
> >
> >
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>



-- 
Daniel de Oliveira Mantovani
"A sede pelo aprendizado é insaciável"
http://mantovanihouse.blogspot.com/
------------------------------------------------------------
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20080804/a49fbf8d/attachment-0001.html>


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