Envenenamiento del DNS

Un resolutor no pregunta a los servidores autoritativos cada vez. Guarda cada respuesta durante el tiempo de vida que declara el registro y le sirve esa copia a todos los clientes que tiene detrás. El envenenamiento va contra esa copia: el atacante consigue que el resolutor acepte una respuesta falsificada y la almacene, y desde ese momento todos sus usuarios acaban en la dirección del atacante mientras la entrada siga viva, sin que se haya tocado ni un solo equipo de la víctima.

Que la falsificación cuele es una carrera. Cuando el resolutor pregunta al servidor autoritativo, el atacante intenta entregar una respuesta que llegue antes que la legítima y que parezca válida, lo que exige acertar la pregunta, el identificador de la transacción y el puerto que usó el resolutor. Las defensas que lo hacen difícil son justo las que vuelven impredecibles esos valores, y por encima de ellas la validación con DNSSEC, que permite al resolutor rechazar una respuesta cuya firma no cuadra.

Con una sola entrada envenenada basta para que salga rentable: el dominio donde la gente introduce sus credenciales, el punto desde el que se descargan las actualizaciones de software o el registro de correo. El caso típico es el bancario: el usuario escribe la dirección correcta de su banco, su resolutor le devuelve la IP del servidor del atacante y aterriza en una copia del sitio preparada para recoger credenciales, que es phishing servido sin necesidad de que nadie pulse un enlace de un correo.

El radio de daño es el resolutor, no la víctima. Un resolutor corporativo sirve a una oficina entera y el de un operador a una población grande, así que una sola falsificación aceptada redirige a todo el que va por detrás. La organización cuyo nombre se falsificó no tiene nada que buscar en sus propios registros, porque no se tocó nada suyo, y casi siempre se entera por sus usuarios.

Se confunde con el secuestro de DNS, y los dos piden arreglos distintos. El secuestro toma el control de la resolución (en el registrador, en los registros de la zona o sobre la configuración del resolutor), así que la respuesta mala es la respuesta auténtica y se sirve correctamente. El envenenamiento deja el control donde estaba y corrompe una copia en caché, así que la respuesta mala es una falsificación que el resolutor se creyó. El doble factor en el registrador y la vigilancia de los registros paran lo primero y no hacen nada contra lo segundo; los parámetros de consulta impredecibles y la validación DNSSEC paran lo segundo y no hacen nada contra lo primero.

Y una vez dentro, la entrada falsificada se queda hasta que caduca o hasta que alguien vacía la caché. Cuánto dura lo decide el atacante, porque el tiempo de vida viaja en la propia respuesta que él fabricó.

En el perímetro miramos los resolutores que el cliente usa de verdad y los que expone. Comprobamos si un resolutor responde consultas recursivas a cualquiera desde internet, porque un resolutor abierto es a la vez un objetivo y una herramienta para atacar a otros; si sus parámetros de consulta están bien aleatorizados; y si valida DNSSEC, que es el control que convierte una respuesta falsificada en una respuesta rechazada. Del lado del cliente miramos por dónde viajan las consultas y si hay un transporte cifrado como DNS over HTTPS. Los hallazgos se escriben contra el resolutor y contra el control que faltaba, con la redirección demostrada cuando el alcance lo permite. Esto forma parte de cómo comprobamos la integridad del DNS en el perímetro.