HD Moore, do Metasploit, e “I)ruid”, do Computer Academic Underground (CAU), disponibilizaram ontem dois códigos capazes de envenenar um cache DNS usando a técnica desenvolvida por Dan Kaminsky. Os detalhes do problema vazaram na segunda-feira (22), o que significa que os exploits foram desenvolvidos em apenas um dia.
O primeiro código é baseado nas informações já conhecidas sobre a falha. A segunda versão explora a brecha de uma forma diferente e permite que domínios sejam redirecionados de uma forma ainda mais perigosa, por meio da substituição do registro NS1. Esta nova técnica, de acordo com os autores, foi desenvolvida por Cedric Blancher.
Usando estes programas, um invasor pode, por exemplo, redirecionar sites de bancos para servidores maliciosos que hospedam clones das páginas originais, mas que capturam os dados da conta. Como o código já está pronto, não é necessário conhecimento aprofundado para executar o ataque — basta saber utilizar o exploit.
De acordo com os criadores do código, um atacante usando esta ferramenta pode envenenar um cache em poucos minutos. Kaminsky, que descobriu a falha e não está envolvido na criação deste código, disse que poderia fazê-lo em questão de segundos, mas a versão do ataque original por ele desenvolvida só será revelada na conferência de segurança BlackHat, em agosto.
Provedores precisam aplicar o patch o mais rápido possível. Alguns provedores brasileiros ainda não aplicaram a correção e estão permitindo que seus clientes sejam redirecionados a sites falsos. Internautas podem fazer um teste por meio do site DoxPara.com para verificar se o servidor DNS operado pelo provedor já foi corrigido.
Na matéria anterior publicada sobre este assunto na Linha Defensiva, o especialista em segurança Nelson Murilo sugeriu que provedores também realizem mudanças adicionais de configuração no servidor DNS para dificultar a realização de ataques de envenenamento de cache.
SSL
SSL/IE6 | Reprodução
O ataque não permite que a proteção SSL seja inutilizada, o que significa que a página falsa de um banco que utiliza HTTPS em sua página principal (e que portanto faz o “cadeado” aparecer nela) pode ser identificada verificando-se a inexistência do cadeado ou o uso de um certificado falso.
Bancos que usam o certificado apenas para o envio dos dados em formulários não podem ser identificados, pois a verificação da existência do cadeado simplesmente não poderá ser feita — ao clicar-se no formulário, os dados já foram enviados.
fonte: Linha Defensiva
Nenhum comentário:
Postar um comentário