Leí muchos artículos al respecto y no entiendo cómo es posible el envenenamiento del caché si:
- la consulta se cancela y se marca como fallida si el ID de transacción de la respuesta no coincide (es decir, los atacantes no pueden forzar el ID de transacción por fuerza bruta ya que solo se aceptará la primera respuesta).
- El solucionador recursivo envía solo 1 solicitud para el mismo dominio/tipo/clase a la vez, lo que significa que los atacantes no pueden activar muchas solicitudes para el mismo dominio para forzar de forma bruta el ID de la transacción.
En esa configuración que parece básica, ¿cómo es posible el envenenamiento de la caché si los atacantes necesitan adivinar el ID de la transacción? ¿Los atacantes obligarán al solucionador recursivo a resolver el mismo dominio una y otra vez para realizar más intentos? En ese caso eso podría llevar horas...
Respuesta1
Es principalmente su primer punto el que es inexacto:
- la consulta se cancela y se marca como fallida si el ID de transacción de la respuesta no coincide (es decir, los atacantes no pueden forzar el ID de transacción por fuerza bruta ya que solo se aceptará la primera respuesta).
Cuando se recibe una identificación de transacción desconocida, esa respuesta se descarta. Pero su suposición de que la consulta pendiente de alguna manera se considera fallida no es cierta.
Efectivamente, este escenario de ataque se convierte en una carrera para que el atacante obtenga una respuesta válida antes de que llegue la respuesta del servidor de nombres real.
El problema con su suposición es que el objetivo de la identificación de la transacción (+ puerto de origen UDP) es hacer coincidir la respuesta a una consulta pendiente, pero cuando hay una respuesta donde estos valores son incorrectos (no coincide con ninguna consulta), ¿Cómo puedes saber qué consulta deberías considerar fallida?
Y si permitiera algún tipo de coincidencia parcial, ¿cómo implementaría eso de una manera que no reemplace una carrera algo onerosa para el atacante con un ataque DoS trivialmente explotable?
Opciones para una protección "real":
- DNSSEC permite al autor de la consulta validar la autenticidad de los registros en la respuesta, lo que garantiza que no se acepte una respuesta generada por un atacante para nombres en zonas firmadas.
- Para consultas de algún tipo de cliente/reenviador a un servidor de resolución específicamente, DoT y DoH también evitan el problema de envenenamiento de caché.para este "salto" en particular(DoT/DoH sólo protege un canal de comunicaciones entre dos hosts, las resoluciones DNS tienden a tener múltiples "saltos").
(Incluso una simple consulta a través de TCP mejora el escenario particular de la pregunta, pero las soluciones basadas en criptografía son obviamente mucho más amplias en términos de los ataques a los que se enfrentan).