Deficiencia en el algoritmo SRTT acelera el envenenamiento de caché DNS en BIND 9
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.
Fuente: Hispasec
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.
Fuente: Hispasec
Comentarios
Publicar un comentario