Envenenamiento DNS en Android: puede ser engañado a la hora de resolver dominios

La vulnerabilidad se debe a una implementación débil del sistema generador de números pseudo-aleatorios que se utilizan como identificador único de cada petición DNS. La debilidad de este sistema está ocasionada por el uso del identificador del proceso (PID) y la hora actual como semilla para generar los números aleatorios.

En el protocolo DNS (cuando trabaja sobre UDP) las peticiones DNS para resolver dominios se envían al servidor con un identificador único en los paquetes que conforman la petición. Así, a la hora de que el servidor responda, sabe a quién corresponde cada conversación.

Este identificador debe estar conformado por un valor aleatorio y el puerto UDP de destino. Para que un ataque de envenenamiento de DNS a este nivel funcione, un atacante podría enviar respuestas falsas al que intenta resolver (y hacerlo antes de que llegue la respuesta legítima del servidor real consultado).

En esta inundación de respuestas falsificaría la relación dominio-ip y podría engañar a la víctima. Tratándose de UDP (que no necesita confirmación de las dos partes como TCP) esto es posible. En cierta manera, lo que impide este ataque es precisamente ese código aleatorio que genera el cliente cuando quiere resolver. El atacante debe intentar predecir el próximo número aleatorio e inyectar respuestas que el sistema de resolución DNS no ha solicitado. Así puede engañarlo.

Si el identificador generado para cada consulta no es suficientemente aleatorio y llega a ser predicho de alguna manera, el atacante solo tiene que inundar al resolvedor de paquetes UDP con una pequeña cantidad de respuestas DNS. La que coincida será tomada en serio por el dispositivo que intenta resolver, haciéndole caso a los paquetes del atacante en vez de al servidor DNS legítimo consultado.

Si por el contrario el sistema de resolución realmente elige números aleatorios, las posibilidades del atacante son mínimas y necesitaría años para poder engañar al dispositivo. En el caso de Android, de los 32 bits posibles que pueden componer el identificador, se han visto que hasta 21 no eran realmente aleatorios, lo que facilita enormemente este ataque.

Este fallo podría permitir a un atacante predecir el identificador únicoy llevar a cabo un envenenamiento DNStradicional, enviando paquetes UDP a la víctima. En la demostración del vídeo, el ataque dura solo unos 10 minutos.

Una aplicación interesante que proponen los descubridores es la de incitar a la víctima a visitar una web del atacante. Esta, a través de JavaScript, comienza a «estimular» al sistema de resolución intentando resolver subdominios que no existen. El atacante además comienza a inyectar respuestas desde otro punto. El sistema de resolución se «confunde» y acaba creyendo que el dominio está en la IP que pertenece al atacante. Este configura el servidor web en esa IP para que robe todas las cookies de la víctima. El usuario acaba visitándola y así se podrá suplantar su usuario en cualquier página.

Han publicado un vídeo con una prueba de concepto como demostración de la vulnerabilidad, en la que se obtienen las cookies de un dominio.:

Por supuesto, para consumar totalmente estos ataques sobre páginas autenticadas con SSL, la víctima debería obviar las alertas del navegador.

La vulnerabilidad ha sido reportada y corregida por el del Android Security Team en la versión 4.1.1. En esta versión, para obtener números aleatorios se utiliza /dev/urandom que dispone de una entropía adecuada determinada por la actividad en la red.

Juan José Ruiz

Sergio de los Santos

Twitter: @ssantosv