En esta serie de entradas vamos a hacer una revisión de los tipos de ataque y mecanismos de defensa más habituales para tratar de mantener la seguridad de un servicio tan extendido e importante como es el de resolución de nombres o DNS.
El DNS como sabemos, es empleado principalmente para traducir nombres de domino en direcciones IP. Normalmente un DNS resolver (al que llamaremos cliente por comodidad) envía una pregunta del tipo ¿quién es www.securityartwork.com?, y su servidor DNS le envía una respuesta con la dirección IP correspondiente.
Imagen 1: PCAP de respuesta a una consulta tipo A
En este caso, fijándonos en los flags de la respuesta vemos que hay tres bits a 1: el primero que indica que es una respuesta, el segundo que en la consulta se solicitó recursión al servidor, y el tercero que el servidor puede realizar consultas recursivas.
Esto es porque las consultas se pueden realizar de manera iterativa o recursiva. En una consulta iterativa, el cliente envía la consulta a su servidor DNS y si éste no conoce la respuesta, le responderá con la mejor respuesta que conozca. Esta suele ser la dirección IP del servidor autoritativo (bit de Authoritative a 1) de un dominio de nivel superior.
A continuación el cliente reenvía la consulta al servidor obtenido en la respuesta anterior, repitiendo este proceso hasta que finalmente contesta el servidor autoritativo para la zona del dominio solicitado.
En el caso de las consultas recursivas, si el servidor no conoce la respuesta, realizará una serie de peticiones iterativas a los servidores autoritativos de los dominios de nivel superior (‘.’,’com’,’es’,etc.) hasta que reciba una respuesta autoritativa para el dominio solicitado. Finalmente la reenvía al cliente DNS como respuesta No Autoritativa. Durante este proceso todas las respuestas recibidas quedan convenientemente almacenadas en caché.
Una vez hecha esta introducción vamos a ver el primero de los ataques: DNS caché poisoning.
1. DNS Caché Poisoning
Inicialmente, un cliente DNS tenía tres requisitos para dar por buena una respuesta DNS:
- el dominio de la consulta y de la respuesta coinciden
- el puerto UDP origen de la consulta y destino de la respuesta coinciden
- el valor de Transaction ID (ver imagen 1) o TXID coincide en el origen y en la respuesta
En las primeras versiones todas las consultas usaban el mismo puerto de origen por lo que conocido éste, un atacante podía enviar al servidor DNS víctima, múltiples respuestas fraudulentas para un dominio muy consultado (pongamos example.com) con un TXID diferente en cada una de ellas.
Nombre: example.com
Addresses: <IP ATACANTE>
<IP ATACANTE>
TXID: <0000-FFFF> //65536 combinaciones
La mayoría de las respuestas serían descartadas por el servidor al no tener registrada ninguna consulta pendiente de resolución con ese identificador, pero el escaso tamaño de éste (16 bits) y el gran número de consultas DNS salientes, harían posible que alguna de las respuestas fuese dada por buena y almacenada en la caché del servidor DNS. Así el atacante lograba redirigir el tráfico destinado al dominio afectado, hacia una IP de su elección.
Ahora pongamos que, como example.com es un dominio muy visitado, está cacheado en el DNS víctima. Inicialmente se pensaba que la ventana temporal para el ataque estaba comprendida entre el instante en que expiraba la entrada en la caché y cuando se recibía la respuesta legítima. Cualquier respuesta que llegase después sería descartada ya que la consulta ya se había satisfecho. El atacante debería esperar a que se agotase el TTL del registro de example.com en la caché para probar suerte de nuevo.
Esto fue hasta que el investigador de seguridad Dan Kaminsky ideó un nuevo ataque que permitía evadir por completo esta ventana temporal, logrando llevar a cabo el envenenamiento de la caché en unos cuantos segundos. Si el atacante conseguía que el servidor hiciera consultas de resolución para subdominios inexistentes de example.com, podría bombardearlo de nuevo con respuestas fraudulentas. Así, no tendría que esperar a que se refresque la caché para lograr enviar una respuesta que acabase siendo aceptada por el cliente.
En principio modificar la entrada para un dominio que no existe no tiene gran interés, sin embargo este investigador fue un paso más allá, aprovechando la opción de añadir información adicional para los servidores autoritativos, logrando así tomar control de todas las peticiones de resolución del dominio ‘envenenado’ enviadas al servidor víctima.
Así, supongamos que tenemos en nuestra red un open dns resolver, esto es, tenemos publicado un servidor DNS recursivo que responde las consultas desde cualquier origen. Un atacante puede comenzar enviando peticiones al servidor para que resuelva subdominios inexistentes de example.com y a continuación bombardearlo con respuestas especialmente diseñadas para envenenar el registro de la caché que apunta al servidor autoritativo de example.com.
//Ejemplo de respuesta Nombre: 00001.example.com Addresses: NULL example.com nameserver = ns1.example.com //ó nameserver = sitiomalo.es example.com nameserver = ns2.example.com ns1.example.com internet address = <IP ATACANTE> ns2.example.com internet address = <IP ATACANTE> TXID: <0000-FFFF> //65536 combinaciones
Afortunadamente, la vulnerabilidad no fue publicada hasta que no se hubieron introducido algunas mejoras pero el problema principal, que no se realiza autenticación alguna del servidor autoritativo, persiste.
En el siguiente post veremos algunas de las mejoras introducidas así como algunos mecanismos para tratar de reducir las probabilidades de éxito de este ataque.
