[Rio-pm] Fwd: [Cascavel-pm] [OT] Vulnerabilidade nos servidores de DNS
Marco A P D'Andrade
mdacwb em gmail.com
Segunda Agosto 4 08:58:15 PDT 2008
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
>
>
Mais detalhes sobre a lista de discussão Rio-pm