O que é envenenamento de cache DNS (DNS spoofing)?
O envenenamento de cache DNS é o ataque que faz um servidor de nomes guardar e distribuir uma resposta falsa, de modo que quem digita o endereço certo é levado ao servidor do criminoso. Não há link suspeito para clicar nem erro de digitação: o nome está correto, quem errou foi a resposta. É o ataque que a assinatura de DNS, o DNSSEC, existe para tornar detectável, e o que explica por que confiar no DNS não é detalhe técnico.
Como um cache de DNS é envenenado
Antes de qualquer conexão, o dispositivo pergunta a um servidor resolvedor qual é o número de um nome. Esse resolvedor guarda a resposta por um tempo para não perguntar de novo. O ataque mira exatamente essa cópia guardada.
O atacante provoca a pergunta
Ele força o resolvedor a consultar um nome sob seu interesse, por exemplo pedindo um subdomínio que ainda não está no cache. Assim controla o momento exato em que a janela abre, e não precisa mais esperar o cache expirar: a própria especificação calcula que, com essa técnica e uma única porta de origem, a chance de acerto chega a 50% em 7 segundos.
Dispara respostas falsas em rajada
Enquanto a resposta legítima viaja, ele envia muitas respostas forjadas, cada uma chutando o identificador da consulta. Basta uma acertar antes da verdadeira chegar.
A resposta falsa é aceita e guardada
O resolvedor não tinha como distinguir: a resposta parecia vir do lugar certo e chegou primeiro. Ele a entrega a quem perguntou e a guarda durante o prazo que a resposta falsa pediu, até o teto que o próprio resolvedor impõe.
Todo mundo atrás daquele resolvedor é afetado
A partir daí não é uma vítima, são todas: cada pessoa e cada sistema que use aquele resolvedor recebe o endereço errado, sem nada de anormal na tela.
Fonte: RFC 5452, a especificação do IETF sobre medidas para tornar o DNS resistente a respostas forjadas, que descreve o ataque, mede a sua viabilidade e define as contramedidas exigidas dos resolvedores.
Por que o DNS aceitou isso por décadas
- A resposta era conferida por um número de 16 bits. Era todo o segredo compartilhado entre pergunta e resposta, e a própria especificação calcula: com esse campo bem sorteado, bastam cerca de 32 mil tentativas em média para acertar.
- Quem chega primeiro ganha. O resolvedor aceita a primeira resposta que pareça válida e descarta as seguintes. O atacante não precisa impedir a resposta verdadeira, precisa apenas correr mais.
- O prazo de validade vem na própria resposta. A resposta falsa carrega o tempo que pede para ficar em cache, e é isso que decide por quanto tempo o envenenamento dura. O limite não é do atacante nem da vítima: é o teto que cada resolvedor impõe, e nas configurações mais comuns esse teto é de 24 horas.
- A vítima não tem sintoma. O endereço na barra está certo, o nome está certo, e nada avisa que a tradução foi adulterada. É por isso que o ataque não aparece em treinamento de conscientização: não há o que a pessoa possa notar.
As formas de entregar a resposta errada
- Envenenamento do cache A forma clássica e a mais valiosa para o atacante, porque contamina de uma vez todos que usam aquele resolvedor. É a que a RFC 5452 mede e a que o DNSSEC torna detectável.
- Resposta forjada na rede local Em rede aberta ou comprometida, o atacante responde à consulta antes do servidor legítimo, sem precisar envenenar cache nenhum. Atinge quem está naquela rede, um de cada vez.
- Resolvedor alterado no dispositivo Em vez de enganar o resolvedor, o ataque troca qual resolvedor o aparelho usa, apontando para um servidor do criminoso. Aqui o problema já está dentro do equipamento.
- Sequestro do registro no registrador Não é falsificação, é tomada de controle: com acesso à conta do domínio, o criminoso muda o registro na origem. A resposta passa a ser oficialmente errada, e o DNSSEC não impede, porque quem controla essa conta controla também o elo que ancora a assinatura no domínio de cima: basta removê-lo ou trocá-lo pelo seu para o domínio deixar de ser assinado.
O que muda quando a tradução não é confiável
O DNS é a camada que ninguém enxerga e da qual tudo depende. Um endereço envenenado não afeta só o acesso a um site: afeta o aplicativo que chama uma interface de programação, o servidor que busca uma atualização, o sistema que se conecta ao banco de dados e, o que mais importa aqui, o servidor que procura para onde entregar o e-mail do seu domínio. É por isso que este ataque aparece como fundação de uma família inteira de defesas: o registro que diz quais servidores podem enviar em seu nome, a chave que confere a assinatura das suas mensagens, a política que exige canal criptografado, todos eles são respostas de DNS. Se a tradução puder ser adulterada, cada uma dessas defesas responde exatamente o que o atacante quiser que ela responda. A correção de 2008, que fez os resolvedores sortearem também a porta de origem, encareceu o ataque em ordens de grandeza, mas encarecer não é impedir: continua sendo uma corrida em que o mais rápido ganha, e não uma verificação de quem está falando: a própria especificação calcula que, mesmo com as 64 mil portas recomendadas, o nível de 50% é alcançado em cerca de 116 horas. Há ainda a consequência que costuma passar despercebida na diretoria: boa parte dos certificados digitais é emitida contra uma prova publicada no DNS. Quem controla a resposta pode obter um certificado válido para o seu nome e exibir o cadeado no site falso, e pode desviar para onde o seu domínio recebe e-mail, que é como um pedido de mudança de conta bancária chega convincente ao seu cliente.
Como reduzir a exposição ao envenenamento
A defesa se divide entre o que você faz como quem consulta e o que faz como dono de um domínio:
- Use resolvedores que validam assinaturaUm resolvedor que confere o DNSSEC recusa a resposta adulterada em vez de repassá-la. É a única defesa que ataca a causa, e não o custo do ataque.
- Assine o seu próprio domínioAssinar permite que quem consulta o seu nome detecte adulteração, incluindo os servidores que entregam o seu e-mail. É a metade do problema que está ao seu alcance resolver sozinho.
- Trate a conta do registrador como conta críticaO sequestro na origem não é falsificação: quem tem a conta pode desligar a própria assinatura. Verificação de dois fatores, trava de transferência e revisão de quem tem acesso valem mais aqui do que qualquer outra medida.
- Mantenha os resolvedores internos atualizadosAs contramedidas da especificação, como o sorteio da porta de origem, só valem se o software estiver em versão que as implemente. Resolvedor antigo em rede interna é a porta que a correção de 2008 nunca alcançou.
- Registre as consultas de DNSO histórico de consultas é o que permite reconstruir um incidente e perceber padrões estranhos. É a mesma matéria-prima que a filtragem de DNS usa para bloquear domínios maliciosos.
Na prática
É como adulterar a lista telefônica em vez de invadir a casa: você procura o nome certo, disca o número que a lista devolveu e quem atende é outra pessoa. Nada no seu lado parece errado, porque nada no seu lado está errado. Por isso este ataque não se resolve com atenção do usuário, e sim com uma resposta de DNS que possa ser conferida.
Como a Zamak trata a confiança no DNS
A Zamak Technologies trata o DNS como camada de confiança, e não como cadastro: resolvedores que validam assinatura, domínio do cliente assinado, conta de registrador com acesso controlado e histórico de consultas guardado para investigação, junto de quem já responde pela rede do cliente. Toda a autenticação de e-mail repousa nessa camada, porque SPF, DKIM e DMARC são todos respostas de DNS. O DNSSEC explica como essa conferência funciona, e a filtragem de DNS trata o outro lado do problema, o domínio que é malicioso desde a origem. Isso faz parte da Cibersegurança gerenciada do Método Zamak.