<div dir="ltr">Alguns canalhas infelizmente liberaram o código, que era private entre algumas pessoas.<br>Já está no Framework3(Metasploit).<br>Agora os Script Kiddies, vão poder se aproveitar falha ARRRGHHH!!!!<br><br><div class="gmail_quote">
2008/8/4 Marco A P D'Andrade <span dir="ltr"><<a href="mailto:mdacwb@gmail.com">mdacwb@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Para encerrar o tema, chegou à meu conhecimento um aviso do CERT,<br>
relativo a problemas de DNS.<br>
<br>
Por sinal eles utilizam um esquema similar ao demonstrado<br>
anteriormente, mas melhor elaborado (visualmente)!<br>
<br>
<a href="http://2642efe12765161057ca96a3.et.dns-oarc.net/" target="_blank">http://2642efe12765161057ca96a3.et.dns-oarc.net/</a><br>
<br>
========== Texto CERT ===========<br>
Gostariamos de solicitar que:<br>
<br>
* Seja efetuado o upgrade do software de DNS deste servidor o mais<br>
rapido possivel.<br>
<br>
Uma descricao do problema e possiveis solucoes sao descritas em:<br>
<br>
<a href="http://www.us-cert.gov/cas/techalerts/TA08-190B.html" target="_blank">http://www.us-cert.gov/cas/techalerts/TA08-190B.html</a><br>
<a href="http://www.kb.cert.org/vuls/id/800113" target="_blank">http://www.kb.cert.org/vuls/id/800113</a><br>
<a href="http://eng.registro.br/pipermail/gter/2008-July/019316.html" target="_blank">http://eng.registro.br/pipermail/gter/2008-July/019316.html</a><br>
<br>
Caso o upgrade ja' tenha sido feito, favor desconsiderar esta<br>
mensagem. Se voce nao for a pessoa correta para corrigir o problema<br>
deste servidor DNS, por favor repasse essa mensagem para alguem de sua<br>
organizacao que possa faze-lo.<br>
<br>
Mais detalhes sobre o porque do envio desta mensagem, quem e' o<br>
CERT.br, como confirmar que o seu servidor e' vulneravel e como<br>
resolver este problema estao listados abaixo.<br>
<br>
Ao final deste email segue o IP do servidor DNS afetado.<br>
<br>
Cordialmente,<br>
<br>
CERT.br<br>
<<a href="mailto:cert@cert.br">cert@cert.br</a>><br>
<a href="http://www.cert.br/" target="_blank">http://www.cert.br/</a><br>
<br>
======================================================================<br>
<br>
* O que e' um ataque de DNS cache poisoning?<br>
<br>
O ataque de DNS cache poisoning (envenamento de cache) e' uma<br>
tecnica que permite a um atacante introduzir informacao DNS forjada<br>
no cache de um servidor DNS.<br>
<br>
* Este servidor DNS nao e' um recursivo aberto e nao aceita consultas<br>
do mundo externo. Ainda assim estou vulneravel?<br>
<br>
Sim, se o servidor e' recursivo e possui uma versao vulneravel do<br>
software de DNS, isto ja' permite que o ataque seja realizado. A<br>
atualiacao do servidor e' a unica maneira de mitigar o ataque.<br>
<br>
* Por que devo me preocupar com isso?<br>
<br>
Ataques de DNS cache poisoning podem trazer riscos aos clientes que<br>
utilizem este servidor, que podem ser direcionados a sites<br>
incorretos, possivelmente maliciosos e sob o controle do atacante.<br>
Programas que exploram esta vulnerabilidade ja' estao publicamente<br>
disponiveis.<br>
<br>
* Onde posso obter informacoes sobre o problema e como soluciona-lo?<br>
<br>
- Multiple DNS implementations vulnerable to cache poisoning<br>
<a href="http://www.kb.cert.org/vuls/id/800113" target="_blank">http://www.kb.cert.org/vuls/id/800113</a><br>
<br>
* Como posso testar se meu servidor e' vulneravel?<br>
<br>
- check your resolver's source port behavior<br>
<a href="https://www.dns-oarc.net/oarc/services/porttest" target="_blank">https://www.dns-oarc.net/oarc/services/porttest</a><br>
<br>
- o mesmo teste, mas usando nslookup de maquinas Windows<br>
nslookup -type=txt -timeout=30 <a href="http://porttest.dns-oarc.net" target="_blank">porttest.dns-oarc.net</a><br>
<br>
- Web-based DNS Randomness Test<br>
<a href="https://www.dns-oarc.net/oarc/services/dnsentropy" target="_blank">https://www.dns-oarc.net/oarc/services/dnsentropy</a><br>
<br>
* Alem de aplicar o patch, tem algo a mais que eu possa fazer?<br>
<br>
Sim, aplicar o patch e' muito importante, mas nao e' a solucao<br>
definitiva para o problema de DNS cache poisoning. Uma solucao mais<br>
permanente e' tambem a adocao de DNSSEC:<br>
<br>
- Info: DNSSEC<br>
<a href="http://registro.br/info/dnssec.html" target="_blank">http://registro.br/info/dnssec.html</a><br>
<br>
* O CERT.br esta' fazendo testes nos meus servidores?<br>
<br>
Nao. O Registro.br, atraves da analise das consultas que recebe,<br>
identificou uma serie de servidores DNS recursivos vulneraveis. O<br>
CERT.br esta' notificando os responsaveis pelos servidores presentes<br>
nesta lista.<br>
<br>
* Por que estou recebendo essa mensagem?<br>
<br>
Voce esta' recebendo esse email por estar listado em<br>
<a href="http://registro.br/" target="_blank">http://registro.br/</a> como contato desta rede ou dominio.<br>
<br>
Se voce for contato de varias redes diferentes e' possivel que voce<br>
receba mais de um email, com conteudos diferentes. Por favor nao<br>
apague outras copias que vier a receber.<br>
<br>
* O que e' o CERT.br?<br>
<br>
O CERT.br -- Centro de Estudos, Resposta e Tratamento de Incidentes<br>
de Seguranca no Brasil -- e' o Grupo de Resposta a Incidentes de<br>
Seguranca para a Internet brasileira, mantido pelo NIC.br do Comite<br>
Gestor da Internet no Brasil. E' o grupo responsavel por tratar<br>
incidentes de seguranca em computadores, envolvendo redes conectadas<br>
`a Internet brasileira.<br>
<br>
* O que e' o Registro.br?<br>
<br>
O Registro.br e' a entidade, no Brasil, responsavel pelas atividades<br>
de registro de nomes de dominio, administracao e publicacao do DNS<br>
para o dominio .br, alem da distribuicao de enderecos Internet.<br>
============================<br>
<br>
<br>
<br>
Sds,<br>
Marco Antonio<br>
<div><div></div><div class="Wj3C7c"><br>
2008/8/1 Marco A P D'Andrade <<a href="mailto:mdacwb@gmail.com">mdacwb@gmail.com</a>>:<br>
> eheheh<br>
><br>
> Breno...<br>
><br>
> <funny><br>
> Vc realmente é válido o argumento de que vc escreve muito :D<br>
><br>
> Eu acho que não fui claro quando pedi um "resumo" :D<br>
><br>
> </funny><br>
><br>
> De qualquer forma, agradeço a atenção !<br>
><br>
> Sds,<br>
> Marco Antonio<br>
><br>
> 2008/8/1 breno <<a href="mailto:breno@rio.pm.org">breno@rio.pm.org</a>><br>
>><br>
>> 2008/8/1 Marco A P D'Andrade <<a href="mailto:mdacwb@gmail.com">mdacwb@gmail.com</a>>:<br>
>> ><br>
>> > Como me foi pedido para não fazer intervenção nos DNS's daqui, já<br>
>> > que já tem gente suficiente trabalhando nisto, não me dei ao trabalho<br>
>> > de estudar a falha (se alguem puder resumir, é bem vindo), mas entendo<br>
>> > que o risco se dê por queries seguidas de um spoof de respostas, que<br>
>> > devem chegar antes, em um momento que aquele servidor não tenha a<br>
>> > informação cacheada...<br>
>> ><br>
>> ><br>
>> > Me parece, em minha vâ filosofia, que se fosse utilizado um forward<br>
>> > para um servidor diferente, o DNS já estaria seguro, pois as respostas<br>
>> > não seriam recebidas pelo servidor consultado, mas por um central,<br>
>> > desconhecido pelo atacante... mas é mera especulação sem conhecimento<br>
>> > completo de causa, que eu precisava compartilhar com alguem ;)<br>
>> ><br>
>><br>
>> Opa, eu não sou muito de contribuir em off-topics, mas o assunto<br>
>> realmente é importante então talvez ajude a mostrar a necessidade de<br>
>> atualizar servidores - ou simplesmente satisfazer um pouco a<br>
>> curiosidade do MDA :-)<br>
>><br>
>> Na ocasião do lançamento do primeiro exploit público da<br>
>> vulnerabilidade, mandei um email para a lista do curso de pentest da<br>
>> Clavis detalhando um pouco mais a questão. O mesmo deverá ser<br>
>> expandido, revisado e estruturado na forma de artigo para o GRIS/UFRJ<br>
>> em um futuro próximo. Aos interessados, segue o forward:<br>
>><br>
>> []s<br>
>><br>
>> -b<br>
>><br>
>> ---------- Forwarded message ----------<br>
>> From: Breno G. de Oliveira <<a href="mailto:breno@clavis.com.br">breno@clavis.com.br</a>><br>
>> Date: 2008/7/23<br>
>> Subject: sobre os novos (e velhos) ataques a servidores DNS<br>
>> To: <a href="mailto:curso_pentest@clavis.com.br">curso_pentest@clavis.com.br</a><br>
>><br>
>><br>
>> Oi Pessoal,<br>
>><br>
>> como vimos durante o curso, há duas formas clássicas de atacarmos<br>
>> servidores DNS (cache poisoning):<br>
>><br>
>> 1) A primeira envolve uma corrida contra o servidor verdadeiro, onde<br>
>> torcemos para nossa resposta maliciosa chegar antes da resposta<br>
>> legítima. Esse método traduz uma vulnerabilidade inerente do protocolo<br>
>> DNS, sem correção evidente. O que se faz na indústria para mitigar o<br>
>> problema é adicionar dificuldade em criar respostas válidas (i.e., que<br>
>> serão aceitas pelo cliente que fez a consulta DNS, seja um host final<br>
>> ou outro servidor DNS) usando valores aleatórios tanto para o campo ID<br>
>> (de 16 bits, responsável por identificar a transação solicitada) do<br>
>> header DNS quanto para a porta de origem da solicitação (a de destino<br>
>> é, naturalmente, 53). Assim, a menos que vc esteja monitorando<br>
>> ativamente as requisições de seu alvo (como fizemos em classe), fica<br>
>> difícil prever tais valores a fim de mandar respostas constantes<br>
>> "cegamente" ao alvo do envenenamento, (sem ao menos saber se ou quando<br>
>> ele fez a solicitação!), esperando que ela vença a corrida UDP.<br>
>><br>
>> Nesse cenário (sem monitorar a comunicação), é preciso muito poder de<br>
>> banda e processamento (sem falar cara-de-pau) para um ataque desse<br>
>> tipo funcionar, a menos que alguém consiga prever com certa precisão<br>
>> os valores dos campos ID e SourcePort dos pacotes DNS da vítima. Pois<br>
>> é.<br>
>><br>
>> Em 2007, Amit Klein da Trusteer lançou um artigo que apresenta um<br>
>> algoritmo capaz de prever o próximo ID e a próxima porta de<br>
>> requisições feitas por um servidor BIND 9.O artigo pode ser obtido em<br>
>> <a href="http://www.trusteer.com/bind9dns" target="_blank">http://www.trusteer.com/bind9dns</a>. Há pelo menos um exploit para essa<br>
>> vulnerabilidade, disponível em <a href="http://www.milw0rm.com/exploits/4266" target="_blank">http://www.milw0rm.com/exploits/4266</a><br>
>><br>
>><br>
>> 2) A segunda forma é mais elegante, e envolve o envio de RRs (Resource<br>
>> Records) adicionais à vítima. Ela pergunta: "quem é<br>
>> <a href="http://www.exemplo.com.br" target="_blank">www.exemplo.com.br</a>?" e vc responde: "<a href="http://www.exemplo.com.br" target="_blank">www.exemplo.com.br</a> é <a href="http://1.2.3.4" target="_blank">1.2.3.4</a> e, a<br>
>> propósito, <a href="http://www.site-legitimo.com.br" target="_blank">www.site-legitimo.com.br</a> é <a href="http://4.3.2.1" target="_blank">4.3.2.1</a>". Para contornar esse<br>
>> problema, clientes e servidores DNS costumam fazem verificação de<br>
>> autoridade para saber se as informações respondidas pelo servidor<br>
>> deveriam de fato vir do servidor. Isso previne também ataques um pouco<br>
>> mais elaborados nessa estrutura, como uma resposta do tipo:<br>
>> "<a href="http://www.exemplo.com.br" target="_blank">www.exemplo.com.br</a> eu não sei, mas é resolvido por <a href="http://ns.google.com" target="_blank">ns.google.com</a>, e<br>
>> <a href="http://ns.google.com.br" target="_blank">ns.google.com.br</a> é <a href="http://4.3.2.1" target="_blank">4.3.2.1</a>). Essa foi a grande onda de '95, mas agora<br>
>> (felizmente) a grande maioria dos servidores DNS estão protegidos<br>
>> desse tipo de ataque, certo? Bom... quase :-)<br>
>><br>
>> Ataques que misturam as abordagens 1 e 2 podem ser usados de uma forma<br>
>> mais eficaz do que separadamente. No início deste ano, Dan Kaminski<br>
>> modelou um ataque extremamente poderoso dessa forma. Tão poderoso que<br>
>> culminou na criação de um grupo de trabalho envolvendo os principais<br>
>> desenvolvedores de servidores DNS em um esforço conjunto (sediado na<br>
>> própria Microsoft) para a resolução do problema e divulgação (dia 8 de<br>
>> julho agora) de atualizações simultâneas para seus produtos - seguidos<br>
>> de uma forte orientação para que administradores atualizem seus<br>
>> sistemas. 13 dias depois (ontem), informações detalhadas sobre o<br>
>> ataque foram divulgadas e já existem exploits disponíveis. Mas como<br>
>> funciona esse novo ataque?<br>
>><br>
>> Se enviarmos uma resposta maliciosa fingindo ser do dominio<br>
>> "<a href="http://exemplo.com.br" target="_blank">exemplo.com.br</a>", podemos devolver não apenas o endereço solicitado<br>
>> (e.g. <a href="http://www.exemplo.com.br" target="_blank">www.exemplo.com.br</a>) como outros do mesmo dominio (e.g.<br>
>> <a href="http://intranet.exemplo.com.br" target="_blank">intranet.exemplo.com.br</a>) nos RRs adicionais. Esse tipo de resposta<br>
>> adicional dentro do mesmo domínio é aceita (pois passa no teste de<br>
>> verificação de autoridade) e costuma visar a otimização dos tempos de<br>
>> resposta e evitar solicitações futuras previsíveis. Mas ainda temos<br>
>> que correr contra o servidor DNS verdadeiro e, se perdermos essa<br>
>> corrida, precisaremos esperar o cache expirar para tentar a sorte<br>
>> novamente.<br>
>><br>
>> Para contornar esse problema e tornar o ataque efetivo, fazemos com<br>
>> que nossa vítima procure não por "<a href="http://www.exemplo.com.br" target="_blank">www.exemplo.com.br</a>", mas por um<br>
>> endereço inválido qualquer, como "<a href="http://aaaaa.exemplo.com.br" target="_blank">aaaaa.exemplo.com.br</a>". Enquanto o<br>
>> servidor DNS verdadeiro deve responder com a mensagem NXDOMAIN<br>
>> ("domínio não existe"), sua resposta maliciosa deve conter qualquer<br>
>> coisa para esse endereço específico (qualquer coisa mesmo, não<br>
>> importa) e adicionar à resposta um RR adicional dizendo que<br>
>> "<a href="http://www.exemplo.com.br" target="_blank">www.exemplo.com.br</a>" aponta para o IP malicioso!<br>
>><br>
>> Até aí nada de mais, é apenas uma variação do ataque #2 respondendo a<br>
>> informação adicional para o mesmo domínio em vez de para um dominio<br>
>> alternativo. Ainda temos que vencer a corrida! A grande sacada está em<br>
>> forçar a vítima a fazer *diversas* queries DNS para servidores<br>
>> inexistentes, para que possamos repetir a corrida tantas vezes quanto<br>
>> necessário. Ou seja: se perdemos com "<a href="http://aaaaa.exemplo.com.br" target="_blank">aaaaa.exemplo.com.br</a>", tentamos<br>
>> novamente com "<a href="http://aaaab.exemplo.com.br" target="_blank">aaaab.exemplo.com.br</a>", "<a href="http://aaaac.exemplo.com.br" target="_blank">aaaac.exemplo.com.br</a>".... até<br>
>> um improvável "<a href="http://zzzzz.exemplo.com.br" target="_blank">zzzzz.exemplo.com.br</a>". E digo improvável pois, em 26^5<br>
>> solicitações (11.881.376), não vencer nenhuma corrida é muita falta de<br>
>> sorte :-)<br>
>><br>
>> Estimativas sugerem que ataques bem sucedidos podem ser feitos em<br>
>> menos de 10 segundos em servidores DNS sem as correções aplicadas. 10<br>
>> segundos!<br>
>><br>
>><br>
>> Lembrem-se também que ataques a servidores DNS são facilitados quando<br>
>> tiramos o destino original do ar (assim, corremos apenas contra nós<br>
>> mesmos). Duas formas eficientes de se retirar servidores DNS do ar<br>
>> são:<br>
>><br>
>> Servidores DNS utilizam o protocolo UDP para responder solicitações, e<br>
>> TCP para transferência de zona. Como mensagens UDP estão limitadas a<br>
>> 512 bytes (sem contar os cabeçalhos UDP e IP), respostas maiores são<br>
>> truncadas e possuem o bit TC ativo no header. Algumas implementações,<br>
>> no entanto, optam por solicitações DNS via TCP para esses casos,<br>
>> evitando assim que os dados sejam truncados - mas abrindo toda uma<br>
>> gama de possibilidades de ataques, e por isso é recomendado que<br>
>> conexões TCP/53 sejam sempre desativadas em ambientes hostis como a<br>
>> Internet.<br>
>><br>
>> Mas, voltando à ataques de negação de serviços a servidores DNS. Se<br>
>> eles aceitam conexões TCP (quer para transferência de zona ou para<br>
>> transações DNS via TCP), teremos algumas vantagens em cima de ataques<br>
>> de flooding tradicionais via TCP. Do RFC 1035 que especifica o DNS,<br>
>> seção 4.2.2 ("TCP Usage"):<br>
>><br>
>> -------------------------8<---------------------------<br>
>> - The server should assume that the client will initiate connection<br>
>> closing, and should delay closing its end of the connection until all<br>
>> outstanding client requests have been satisfied.<br>
>><br>
>> - If the server needs to close a dormant connection to reclaim<br>
>> resources, it should wait until the connection has been idle for a<br>
>> period on the order of two minutes. In particular, the server should<br>
>> allow the SOA and AXFR request sequence (which begins a refresh<br>
>> operation) to be made on a single connection. Since the server would<br>
>> be unable to answer queries anyway, a unilateral close or reset may be<br>
>> used instead of a graceful close.<br>
>> -------------------------8<---------------------------<br>
>><br>
>> Então, ataques de SYN flooding contra a porta 53/tcp devem ser<br>
>> bastante eficazes. Outra possibilidade é fazer diversas solicitações<br>
>> que obriguem o servidor DNS alvo do DoS a pedir a informação a outros<br>
>> servidores DNS (em particular, servidores que você controle) e<br>
>> aumentar o tempo de resposta através do envio de informações<br>
>> adicionais desnecessárias e demoradas (como registros TXT<br>
>> grosseiramente exagerados).<br>
>><br>
>><br>
>> Sintam-se como sempre à vontade para usarem a lista a fim de discutir<br>
>> essas e outras questões!<br>
>><br>
>><br>
>> []s<br>
>><br>
>> breno<br>
>> _______________________________________________<br>
>> Rio-pm mailing list<br>
>> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
><br>
><br>
_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Daniel de Oliveira Mantovani<br>"A sede pelo aprendizado é insaciável"<br><a href="http://mantovanihouse.blogspot.com/">http://mantovanihouse.blogspot.com/</a><br>
------------------------------------------------------------<br>
</div>