Los
investigadores Jonathan Kalechstein, Gabi Nakibly y Roee Hay han presentado en
la conferencia USENIX WOOT 13 de Washington un nuevo método para forzar en BIND
la elección de servidor de nombres manipulando remotamente los valores de la
caché SRTT. Esto podría acelerar los
ataques de envenenamiento de caché DNS, dirigiendo las consultas a un
servidor o red controlado por el atacante. ISC anuncia que el algoritmo será
reimplementado para subsanar el fallo.
El servidor de nombres BIND es
uno de los más usados en Internet. Creado en 1988, en la universidad de
Berkeley, actualmente es desarrollado por el ISC (Internet System Consortium).
BIND tiene licencia BSD y se encuentra disponible para una amplia gama de
sistemas tanto Unix como Microsoft Windows.
Envenamiento de caché DNS
Los ataques de envenenamiento de
caché DNS tratan de engañar al resolvedor de nombres de dominio para que guarde
un registro de recursos incorrectos o inválidos. De esta forma, cuando al
resolvedor se le pide la IP
de cierto dominio que se ha "envenenado",
consultará al registro malicioso, que lo redirigirá a una IP controlada por el
atacante. Este tipo de ataques pueden
ser usados para pharming, o la instalación de malware si el atacante está
simulando ser, por ejemplo, un servidor de actualizaciones de software.
¿Cómo llega el registro falso a
la cache del DNS? Normalmente, cuando un resolvedor recursivo (típico, por
ejemplo, en los ISP) recibe una consulta de un usuario, este la busca en su
caché. Si no la encuentra, consulta a un servidor de nombres autoritativo del
dominio. Un atacante podría, antes de que el servidor legítimo respondiera,
suplantarlo y enviar un registro malicioso, aprovechando que la primera
respuesta en llegar es la que se considera válida. El registro se almacenaría
en la cache y es servido a los usuarios.
Una de las soluciones a este
problema es acompañar la consulta con ciertos valores, pseudo-aleatorios
conocidos por el resolvedor. Si la respuesta no contiene esos mismos valores,
es descartada. Se utilizan el identificador de la transacción (TXID), el puerto
UDP de origen y la IP
del servidor de nombres al que se va a hacer dicha petición.
El problema de dar con estos
valores pseudo-aleatorios para construir la respuesta falsa da lugar a enfoques
llamados "blind" o ciegos,
por el hecho de que el atacante no los conoce de antemano. Sin embargo, en el pasado han aparecido varias
vulnerabilidades en este sistema.
Aprovechando el diseño del algoritmo SRTT
Uno de los valores necesarios
para que una respuesta DNS sea aceptada es, como hemos dicho, las IP del servidor
de nombres que la envía. Esta debe ser la misma a la que se ha enviado la
petición. De no ser así será rechazada.
Es fácil para un atacante
falsificar la IP
de origen en una respuesta. Por ello, se utilizan soluciones como el SRTT para
no hacerla previsible. El algoritmo Smoothed Round Trip Time (SRTT) elige un
servidor de nombres a consultar entre un conjunto que el resolvedor almacena en
la caché SRTT, compartida por todos los dominios. A cada una de estas IPs se le
asocia un valor (basado en el RTT o Round Trip Time), que cambiará con el
tiempo y el éxito de las consultas. El servidor que tenga un valor SRTT más
bajo será el elegido para hacer la petición.
El ataque aprovecha una debilidad
en el algoritmo SRTT que permite influir en la elección del servidor que será
usado para resolver la consulta. Si el atacante tiene éxito conocerá de
antemano uno de los valores usados para contrastar las respuestas.
Para forzar la elección de un
servidor de nombres víctima, se decrementa artificialmente su puntuación SRTT
hasta un valor arbitrario. De esta forma el resolvedor DNS lo elige para
realizar la próxima petición del dominio del que es autoritativo, lo que permite
al atacante conocer que servidor suplantar. Además, el servidor de nombres
víctima (el que vamos a forzar) no recibe ninguna consulta durante el ataque,
por lo que no puede detectarlo.
Para esto, el método utiliza las
funciones Decay y Update del algoritmo. En la primera, al hacer una consulta a
un servidor de nombres concreto, el valor SRTT del resto de servidores se
reduce en un factor del 2%. Esto se hace para evitar que un servidor acabe
acaparando todas las conexiones. La segunda actualiza el valor conforme a su
historial (valor anterior) y la velocidad de respuesta.
Proceso de ataque
Dado un atacante tras un equipo,
un conjunto de n de servidores de nombres no abiertos (servidores DNS que no
permiten consultas sobre dominios de terceros) cualesquiera, y dos servidores
de nombres autoritativos controlados por el (NS1 y NS2, aunque el segundo es
opcional según el timeout del resolvedor). El primer paso es añadir estos
últimos a la caché.
Para esto, se hace una consulta
al servidor objetivo sobre cualquier dominio del que NS2 sea servidor
autoritativo. Hay que tener en cuenta que NS2 debe tener menor latencia con el
resolvedor que el servidor víctima, ya que queremos que tras la primera
petición tenga menor puntuación que este (parte de la puntuación al actualizar
es dada por el tiempo de espera). Esto nos servirá más adelante para parar la
resolución recursiva antes de que el servidor víctima sea consultado.
Después, se consulta un dominio
sobre el que nuestro servidor de apoyo, NS1, sea autoritativo. Este responderá
delegando (desviando la consulta) sobre los n servidores no abiertos, NS2 y el
propio servidor víctima.
Los n servidores no abiertos
entrarán en la tabla SRTT con la puntuación más baja y se producirán n
iteraciones. En cada iteración, se selecciona uno del conjunto, el de
puntuación más baja, y se le envía la consulta. Al no conocer el dominio,
recibirán una penalización en su valor SRTT.
A su vez, por cada iteración la
función 'Decay' reducirá la
puntuación del resto de servidores en los que hemos delegado, entre ellos
nuestro infiltrado, NS2, y el servidor víctima. Finalmente, se le envía la
consulta a NS2, que responde satisfactoriamente.
El servidor víctima ha bajado su
puntuación en cada iteración, pero no ha recibido penalización ni su valor SRTT
se actualiza, ya que no ha llegado a ser consultado. Por tanto, habremos
logrado reducir el valor SRTT de la victima en un ratio de 0.98^n+1. Con un
conjunto de servidores no abiertos lo suficientemente grande, habremos logrado
que su valor se sitúe por debajo del resto de servidores autoritativos para su
zona Como la tabla SRTT es compartida entre dominios, la siguiente petición
elegirá la victima para la consulta. Ya conocemos la IP y podríamos (en caso de no
existir otras medidas) usarla para construir respuestas falsas.
Impacto
Hay que tener en cuenta que este
enfoque no representa un ataque por si mismo, pero asiste a otros. Como
consecuencia principal, acelera un posible ataque de envenenamiento de la caché
del DNS. Ya que el atacante elimina uno de los valores que se deben averiguar
para que la respuesta falsificada del atacante sea tomada por válida.
Por otro lado, si fuerza el
tráfico por una ruta donde lo esté capturando mediante un ataque hombre en el
medio puede ver las peticiones DNS, y por tanto los valores aleatorios de
estas. Con estos valores, puede construir una respuesta y suplantar al servidor
legítimo. Otra opción es forzar el tráfico DNS no hacia un servidor que
controlemos, si no hacia uno sobre el que queramos realizar una denegación de
servicio.
El fallo, que afecta a las
versión 9 de BIND sea en configuración autoritativa, recursiva o híbrida, ya ha
sido reconocido por ISC. El algoritmo será reimplementado en futuras versiones
de BIND.
Como curiosidad, Roee Hay formó
parte del equipo de IBM que hace un año descubrió que Android era vulnerable al
envenenamiento de DNS.
Más información:
Subverting BIND's SRTT Algorithm
. Derandomizing NS Selection
Subverting BIND’s SRTT Algorithm: Derandomizing
NS Selection [blog]
Francisco López
