Cómo de crítico era el fallo en los servidores DNS (III)

En la entrada anterior ya vimos los efectos del agujero de seguridad, ahora nos quedan por ver las causas.

Envenenamiento de la caché

Las consultas DNS no requieren conexión porque utilizan el protocolo UDP. Esto significa que se envía un único paquete con la consulta y se espera la respuesta en otro paquete UDP. Entonces, ¿nos fiamos de cualquier paquete de respuesta que llega? Obviamente no. Cada paquete entrante tiene una serie de indicadores que sirven para comprobar su validez: la dirección IP de quien envía el paquete, el puerto utilizado para la comunicación, un identificador (ID) aleatorio de 16 bits y el propio contenido del paquete. El servidor DNS se realiza las siguientes preguntas al recibir un paquete de respuesta:

  • ¿Le acabo de preguntar algo a la IP que me envía este paquete?
  • ¿Es una respuesta a la pregunta que yo he realizado?
  • ¿El ID coincide con el que yo he enviado?
  • ¿El puerto de llegada es el mismo desde el que yo pregunté?

Si las respuestas a todas estas preguntas son afirmativas, el servidor DNS acepta la respuesta como válida y la almacena en la caché. La primera respuesta válida que llega se acepta.

¿Qué tendría que hacer un atacante para explotar el agujero de seguridad? Para empezar, ser más rápido contestando que el servidor al que preguntó el DNS atacado. Esto es fácil: bastaría con realizar un ataque DDoS para inutilizar ese servidor y enviar muchos paquetes iguales al DNS atacado para asegurar el éxito.

¿Qué más? Cambiar la IP del que manda el paquete por otra cualquiera es algo trivial. Los únicos impedimentos que quedan por salvar son el ID y el puerto de destino, y aquí están los fallos graves. Me explico. Resulta que el ID aleatorio es de 16 bits, lo que nos da 65.536 posibilidades (muy pocas, porque 65.536 paquetes distintos se envían muy rápido), y lo que es peor: un servidor DNS utiliza siempre el mismo puerto para las consultas. Por lo tanto, es relativamente sencillo para un atacante averiguar qué puerto utiliza un servidor DNS y predecir el ID que utilizará para las consultas. Es decir, debido a las peculiaridades en la implementación del protocolo DNS, es fácil para un atacante confundir a un servidor y envenenar su caché con datos falsos, lo cual nos deja a los usuarios indefensos.

Los grandes fabricantes solucionan el problema

Desconozco qué medidas se habrán tomado al respecto, pero hago notar que tan sólo con permitir que cada consulta se haga desde un puerto aleatorio, las posibilidades aumentan notablemente –65.536 puertos posibles a los que hay que restar 1.024 puertos restringidos, y 65.536 ID posibles por cada puerto; en total 4.227.858.432 posibilidades–, y por consiguiente la dificultad para el atacante es muchísimo mayor.

En cualquier caso, no hay por qué preocuparse. Los grandes fabricantes –como Debian, Cisco, Infoblox, ISC, Juniper, Microsoft, Red Hat, Sun (Solaris)…– se pusieron manos a la obra y sacaron los parches pertinentes para sus servidores con gran rapidez. A día de hoy, seguro que todos los administradores del mundo han actualizado sus equipos y ya no hay nada que temer.

Más información en esta nota técnica del US CERT que describe la vulnerabilidad o en esta otra nota del SANS Institute.

5 comentarios sobre “Cómo de crítico era el fallo en los servidores DNS (III)

  1. Muy buena explicacion la mejor de la red sobre el funcionamiento de los dns y del agujero.

    ya ves que pasan los años y seguimos leyendo tus ladrillos.

    un saludo.

Comentarios cerrados.