Suplantación DNS y envenenamiento de caché: guía práctica

El DNS se diseñó originalmente sin ningún medio para verificar que una respuesta procedía realmente del servidor de nombres que decía ser su origen. Esa carencia permite la suplantación: un atacante situado para interceptar una consulta DNS o competir con ella puede devolver una respuesta falsificada que dirija a la víctima a una dirección elegida por él, a menudo para desviar el tráfico hacia un servidor malicioso que se hace pasar por un sitio legítimo.

Envenenamiento de caché: la misma idea, a escala

El envenenamiento de caché toma la misma idea de la respuesta falsificada y la dirige contra un resolvedor compartido en lugar de contra una única víctima. Si un atacante logra colar una respuesta falsa en la caché de un resolvedor recursivo de uso muy extendido, todos los usuarios posteriores de ese resolvedor reciben la respuesta envenenada hasta que caduca, de modo que una sola falsificación exitosa se convierte en un ataque contra todos los que comparten ese resolvedor, sin necesidad de interceptar cada una de sus consultas individuales.

Cómo se defiende el DNS moderno

Ninguna de estas defensas está desplegada de forma universal; en particular, la adopción de DNSSEC sigue siendo parcial entre los dominios que forman internet. Usar un resolvedor público bien gestionado y atento a la seguridad, y tratar un resultado de resolución inesperado o sospechoso como algo que conviene volver a comprobar con un segundo resolvedor independiente, sigue siendo una precaución práctica razonable incluso donde DNSSEC no entra en juego.

El fallo que cambió la seriedad con que se toma este problema

El envenenamiento de caché dejó de ser una preocupación teórica en 2008, cuando el investigador de seguridad Dan Kaminsky reveló un fallo fundamental que afectaba a casi todos los resolvedores DNS en uso en aquel momento: el espacio de posibles ID de transacción y puertos de origen que un atacante tenía que adivinar era lo bastante pequeño como para recorrerlo por fuerza bruta en segundos con una conexión rápida, lo que permitía envenenar la caché de un resolvedor para un dominio entero, y no solo para un registro. La divulgación dio lugar a una publicación de parches inusualmente coordinada y simultánea en todos los grandes proveedores de software DNS (la aleatorización del puerto de origen pasó a ser estándar casi de la noche a la mañana) y es una de las razones principales por las que las defensas enumeradas arriba existen en su forma actual.

Por qué la adopción de DNSSEC sigue rezagada pese a que la solución tiene veinte años

DNSSEC resuelve el problema de confianza de fondo de forma mucho más completa que la aleatorización de puertos por sí sola: es una prueba criptográfica, no solo un juego de adivinanzas más difícil. Su lento despliegue tiene más que ver con la complejidad operativa que con dudas sobre su valor: firmar correctamente una zona, rotar las claves a tiempo sin romper la validación y mantener intacta toda la cadena de confianza desde la raíz hasta un dominio concreto es bastante más difícil de hacer bien que añadir un registro A sin firmar. Un solo error en ese proceso produce exactamente el modo de fallo SERVFAIL tratado en otra parte de esta serie, lo que en sí mismo disuade a los operadores de dominios más pequeños que no cuentan con personal con experiencia en DNS. La brecha entre «resuelto en teoría» y «desplegado en todas partes en la práctica» es común en la infraestructura de seguridad, y DNSSEC es un claro ejemplo.