<div dir="ltr">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><div class="gmail_quote">2008/8/1 breno <span dir="ltr"><<a href="mailto:breno@rio.pm.org">breno@rio.pm.org</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;">
2008/8/1 Marco A P D'Andrade <<a href="mailto:mdacwb@gmail.com">mdacwb@gmail.com</a>>:<br>
<div class="Ih2E3d">><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>
</div>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>
<font color="#888888"><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>
</font></blockquote></div><br></div>