Resumen

  • El envenenamiento de estilo Kaminsky provocaba consultas por nombres nuevos para abrir una y otra vez una carrera fuera de ruta: una respuesta inventada debía adivinar los parámetros de la consulta y adelantarse al servidor auténtico.
  • Los parches coordinados de 2008 no autenticaron el DNS. Añadieron identificadores y puertos de origen impredecibles al filtro local, una defensa que solo existía si cortafuegos y NAT preservaban la entropía observable.

La primera coincidencia se convertía en autoridad

Un resolvedor recursivo preguntaba por UDP y recibía, normalmente, una respuesta sin firma. Para decidir si debía aceptarla no comprobaba quién afirmaba el dato mediante criptografía. Comparaba el paquete con una operación que seguía abierta.

RFC 5452 enumeró después la frontera: la sección de pregunta y el identificador debían coincidir; la respuesta debía aparentar proceder de la dirección consultada y volver a la dirección y puerto usados por el resolvedor. Por regla general, ganaba el primer paquete que cumplía esas condiciones.

Un atacante fuera de ruta no veía la consulta, pero podía falsificar la dirección de un servidor autoritativo y lanzar muchas respuestas candidatas. Si una acertaba la tupla y llegaba antes, el caché la trataba como válida y la ofrecía a sus clientes. El efecto podía desviar web, correo y cualquier servicio que usara esos nombres.

No era un control ilimitado del DNS. Era autoridad efectiva sobre un caché concreto, sobre registros aceptados y durante su vida útil. Por eso no basta con una etiqueta única de “seguridad DNS”. El acceso a recursión, la correspondencia de respuestas, el bailiwick, la aleatoriedad y la validación de firmas protegen superficies distintas.

El fallo transformó la espera en repetición

Los ataques de predicción no nacieron en 2008. RFC 3833 ya describía en 2004 los identificadores de 16 bits, los puertos previsibles y los encadenamientos de nombres. Algunos generadores ofrecían menos incertidumbre de la que sugería el campo; muchos resolvedores reutilizaban un único puerto UDP.

Kaminsky mostró una forma práctica de concatenar esas debilidades. El adversario inducía una consulta por una etiqueta aleatoria bajo el dominio objetivo. Al no estar en caché, el nombre obligaba al resolvedor a preguntar al servidor autoritativo. Entonces llegaba una ráfaga de respuestas falsas. Si ninguna ganaba, una etiqueta distinta abría una consulta nueva.

El nombre aleatorio era el mecanismo de reinicio, no necesariamente el premio. Una respuesta podía intentar introducir una delegación que afectara al dominio padre, dentro de las reglas de pertinencia del resolvedor. Así desaparecía la necesidad de esperar a que caducara un registro atractivo.

RFC 5452 modeló algunas técnicas repetitivas como si el TTL efectivo fuera casi cero. Con 7.000 paquetes falsos por segundo y un único puerto, su ejemplo alcanza un 50 % en unos siete segundos. No es una duración universal. Es una advertencia matemática: repetir una oportunidad barata convierte una probabilidad pequeña en un riesgo operativo.

El puerto añadió una incógnita local

La reparación de emergencia amplió la combinación que debía adivinarse. Los resolvedores corregidos eligieron un puerto de origen impredecible para cada consulta y fortalecieron el identificador de transacción. El puerto pasó a funcionar como otro campo de identidad local.

RFC 5452 calculó que unas 64.000 opciones multiplicaban el espacio por ese factor. En el mismo modelo de 7.000 paquetes por segundo, el punto del 50 % pasaba de siete segundos a unas 116 horas. CERT/CC habló de cerca de 16 bits adicionales en teoría, aunque los puertos reservados y ocupados limitan el conjunto real.

La medida pudo desplegarse sin cambiar el formato del protocolo. Un servidor autoritativo ya sabía contestar al puerto desde el que llegaba la consulta. Cada proveedor modificó su ejecución y cada operador pudo instalarla sin coordinar una fecha universal.

La mejora tenía costes. ISC advirtió que el parche inicial de BIND afectaba de forma perceptible a cargas superiores a unas 10.000 consultas por segundo y ofreció ramas beta optimizadas. Los cortafuegos que solo permitían salir desde el puerto 53 debían cambiar. Los traductores con estado necesitaban más entradas.

El resultado no eliminó el trabajo de ingeniería. Sustituyó una tupla previsible por una administración más compleja de sockets y estado. La decisión podía medirse, revertirse y ajustarse localmente.

La entropía podía morir en el equipo siguiente

Un inventario podía mostrar el parche y, sin embargo, los paquetes exteriores seguir una secuencia estrecha. Los dispositivos NAT/PAT suelen reescribir puertos. CERT/CC señaló que podían reducir o anular la mejora; RFC 5452 destacó los traductores que serializan o limitan el conjunto.

Eso no convierte a todo NAT en enemigo. Algunos conservan la selección del host y otros modifican la variación en sentidos distintos. La pregunta correcta es cuántas opciones ve el atacante al final del camino.

DNS-OARC ofreció una comprobación desde el lado autoritativo. Sus servicios de puertos e identificadores devolvían una descripción de los valores observados. La operación dejaba de confiar en una versión de paquete y podía inspeccionar la conducta efectiva después de sistema operativo, cortafuegos y traducción.

Esta es una prueba directa de la primacía del código en ejecución. El boletín expresa intención; la telemetría de la ruta demuestra si la protección llegó viva al límite donde debía actuar.

La publicación conjunta no instaló nada

DNS-OARC sitúa una cumbre privada en Microsoft el 31 de marzo de 2008. El 8 de julio, CERT/CC publicó VU#800113 y numerosos fabricantes distribuyeron parches. ISC actualizó BIND. Microsoft cambió la aleatoriedad de identificadores, los sockets UDP y la gestión del caché.

La reserva coordinada se quebró antes de la explicación prevista. La cronología registra una filtración efectiva el 21 de julio, código funcional el 23 y más implementaciones el 24. El aviso de Microsoft del 25 de julio dijo que el riesgo había aumentado; también indicó que no conocía entonces ataques activos ni impacto en clientes y que el exploit probado no funcionaba contra MS08-037 instalado.

No conviene convertir esas frases en una certeza mayor. El código público aumentó la capacidad atacante. La falta de incidentes conocidos por Microsoft no descartó un uso mundial. El éxito en una prueba no certificó todas las combinaciones de resolvedor y red.

Kaminsky presentó el mecanismo en Black Hat el 7 de agosto. RFC 5452 se publicó en enero de 2009. La protección llegó primero como código compatible desplegable y después como regla común documentada. El RFC ordenó el aprendizaje; no hizo que los paquetes de julio se instalaran.

Comprar azar no equivale a comprar autenticidad

El puerto aleatorio hizo mucho más cara una falsificación fuera de ruta. No demostró que los datos sin firma procedieran de la autoridad delegada. Un atacante en ruta podía observar la consulta; un NAT podía comprimir el espacio; suficiente estado filtrado o una técnica distinta podía alterar la probabilidad.

ISC llamó a DNSSEC la solución definitiva y, al mismo tiempo, reconoció que desplegarla de inmediato no era realista. DNSSEC aporta una cadena de firmas para comprobar origen e integridad. Esa prueba es diferente de aumentar el coste de acertar una carrera.

Ambas capas siguen siendo útiles. La correspondencia estricta y la entropía descartan falsificaciones baratas antes de validar criptografía. DNSSEC juzga la autoridad del contenido. Ninguno de los dos controles debe atribuirse la función del otro.

La Especificación Inicial Mínima de Heng Lu permite separar responsabilidades. La regla compartida define qué atributos deben coincidir y qué propiedad de imprevisibilidad debe sostenerse. No necesita imponer el generador, el asignador de sockets ni el calendario de un fabricante. Las decisiones futuras permanecen con quienes ejecutan el sistema; la adopción se demuestra por conducta, no por declaración.

Límites de la evidencia

Las fuentes prueban una exposición multivendedor y una técnica mucho más práctica. No prueban que todos los resolvedores tuvieran el mismo defecto, que todos se actualizaran el 8 de julio ni que siete segundos o 116 horas describan cualquier red. La aleatorización no anuló todo envenenamiento y la existencia de DNSSEC no probó su validación desplegada.

La conclusión precisa es suficiente: parte de la confianza dependía de una carrera pequeña cuyo azar muchos sistemas reducían. La respuesta agrandó ese espacio, permitió observarlo y dejó la autenticación como un problema distinto.

Fuentes