Li muitos artigos sobre isso e não entendo como o envenenamento de cache é possível se:
- a consulta é cancelada e marcada como falha se o ID da transação da resposta não corresponder (ou seja, os invasores não podem usar força bruta no ID da transação, pois apenas a primeira resposta será aceita)
- o resolvedor recursivo envia apenas 1 solicitação para o mesmo domínio/tipo/classe por vez, o que significa que os invasores não podem acionar muitas solicitações para o mesmo domínio para forçar o ID da transação
Nessa configuração que parece básica, como é possível o envenenamento de cache se os invasores precisarem adivinhar o ID da transação? Os invasores forçarão o resolvedor recursivo a resolver o mesmo domínio repetidamente para ter mais tentativas? Nesse caso, isso pode levar horas...
Responder1
É principalmente o seu primeiro marcador que é impreciso:
- a consulta é cancelada e marcada como falha se o ID da transação da resposta não corresponder (ou seja, os invasores não podem usar força bruta no ID da transação, pois apenas a primeira resposta será aceita)
Quando um ID de transação desconhecido é recebido, essa resposta é descartada. Mas sua suposição de que a consulta pendente é de alguma forma considerada falhada não é verdadeira.
Efetivamente, esse cenário de ataque se torna uma corrida para o invasor obter uma resposta válida antes que a resposta do servidor de nomes real chegue.
O problema com sua suposição é que o objetivo do ID da transação (+ porta de origem UDP) é corresponder à resposta a uma consulta pendente, mas quando há uma resposta em que esses valores estão errados (não corresponde a nenhuma consulta), como você pode saber qual consulta você deve considerar que falhou?
E se você permitisse alguma forma de correspondência parcial, como implementaria isso de uma forma que não substituísse uma corrida um tanto onerosa para o invasor por um ataque DoS trivialmente explorável?
Opções para proteção "real":
- O DNSSEC permite que o originador da consulta valide a autenticidade dos registros na resposta, o que garante que uma resposta gerada pelo invasor não seja aceita para nomes em zonas assinadas.
- Para consultas de alguma forma de cliente/encaminhador para um servidor resolvedor especificamente, DoT e DoH também evitam o problema de envenenamento de cachepara este "salto" específico(DoT/DoH protege apenas um canal de comunicação entre dois hosts; as resoluções DNS tendem a ter vários desses "saltos").
(Até mesmo a consulta sobre TCP melhora o cenário específico da questão, mas as soluções baseadas em criptografia são obviamente muito mais amplas em termos de quais ataques elas lidam.)