Desde hace un mes aproximadamente, se ha venido hablando en los foros y blog sobre la falla encontrada por Dan Kaminsky en el protocolo DNS, una falla que según los medios ha sido parchada con gran celeridad debido a la acción oportuna de Kaminsky de informar primero a todos los ISPs y entidades pertinentes para que el sistema sea parchado, antes de hacer público su descubrimiento; es más algunos lo pintan hasta comu un gran logro, lean la columna que escribió sobre el tema Dennis Fisher. Sin embargo el viernes pasado (8 de agosto), el investigador ruso Evgeniy Polyakov posteo en su blog, que había podido vulnerar exitosamente un servidor DNS que había sido parchado, la noticia fue recogida por el New York Times.
Entonces, ¿fue la falla fue más grave de lo que se pensaba?, ¿cuál es en realidad la falla?, ¿qué tan vulnerables son nuestros PCs a ésta falla?, y ¿cómo podrían usar dicha vulnerabilidad los cyberdelincuentes para sacar partido de ella?, son los puntos que trataremos de aclarar en el presente post.
En primer lugar debemos entender qué es y como funciona el servicio DNS en Internet, la mayoría creo que ya tiene claro que los servidores DNS son aquellos que transforman los nombres que usamos comunmente como www.google.com en un número IP, que es finalmente como la conexión es establecida, sin embargo lo que la mayoría no parece tener claro es que hay dos tipos de servidores DNS, uno es aquel que es dueño de una "zona" y otro es el servidor DNS de cacheo, son éstos últimos los que se ven afectados por éste tipo de ataques.
¿Qué es y para que sirve un servidor DNS de cacheo?, para poner las cosas claras, lo que la mayoría de nosotros usamos ya sea a través de nuestro ISP o uno configurado por nosotros mismos en nuestra LAN, es un servidor DNS de cacheo, es decir un servidor de nombres de dominio que pregunta a los servidores DNS dueños de una zona, por el IP de un nombre que estamos buscando, una vez obtiene ese valor, lo almacena en una memoria cache, por un tiempo estipulado por el servidor DNS dueño del dominio en un parámetro llamado TTL (Time To Live), usualmente horas (hay casos en que pueden ser días), antes de intentar volver a pedir el IP de un nombre de dominio nuevamente.
El mecanismo de ataque es el siguiente:
- Se envía una solicitud de un nombre específico al servidor que sera víctima del ataque.
- Inmediatamente después se envían una serie de tramas UDP fraguadas, con la intención de hacerse pasar por la respuesta del verdadero servidor dueño del dominio.
- Verifica que la respuesta falsa ha sido aceptada por el servidor.
- El servidor atacado devolverá la IP inyectada por el atacante cada vez que se le pregunte por el nombre.
El ataque es posible porque el intercambio DNS es hecho usando el protocolo UDP, que no verifica el establecimiento de una sesión. Para complicar aún más las cosas no se puede tomar ninguna contra medida porque los paquetes UDP se hacen pasar como enviados por el verdadero servidor, sólo analizando la trama no hay forma de saber si viene del servidor legítimo.
Por otro lado no es práctico pasar las solicitudes DNS del protocolo UDP a TCP, porque sobrecargarían a los servidores raíz, así que la solución que se ha intentando es randomizar el puerto con el cuál se hace la solicitud al servidor dueño del dominio, aunque según ha demostrado Evgeniy Polyakov, con suficiente tiempo y ancho de banda, igual es posible corromper los registros de cualquier servidor DNS, incluso si esta parchado.
¿Cuál sería la solución entonces?, puesto que para lanzar un ataque exitoso se requiere que el equipo desde donde lancemos el ataque tenga una latencia menor a la que tendrían los paquetes enviados desde el servidor dueño del dominio, se necitan entonces dos cosas, primero bastante ancho de banda, y una cantidad de saltos menor al servidor que se trata de suplantar. Entonces la mejor forma de estar a salvo de éste tipo de ataques es implementar un servidor DNS dentro de nuestra LAN, de esa forma un ataque sólo sería posible si se realiza desde dentro de nuestra LAN, además de que le haríamos las cosas mucho más difíciles a los hackers porque en vez de infectar un sólo servidor DNS de cacheo en un ISP y afectar a miles o millones de usuarios, deberían de infectar miles de servidores, lo cuál consumiría su ancho de banda. Aunque no he visto que nadie formule ese tipo de soluciones.
¿Cómo un hacker aprovecharía esta vulnerabilidad para atacar a sus víctimas?, de por sí la única forma posible de capitalizar éstos ataques sería a través del fishing, por ejemplo inyectando resgistros como update.tubanco.com, y solicitando a la víctima que actualice su información, desde la perspectiva de los usuarios, incluso si hicieran un ping a update.tubanco.com, obtendrian el IP del servidor impostor, así que un cliente promedio podría caer fácilmente en el engaño.
Los que deseen saber si los servidores de nombres de dominio que estan usando son vulnerables a éste tipo de ataques (es decir no esta parchados), pueden saberlo usando el test que provee Kaminsky en su blog.
Aquellos que ésten interesados en probar un exploit de prueba de concepto, lo pueden hacer descargandolo desde milw0rm, hay versiones en C, Python y para el toolkit metasploit. Aunque les recomendaría que instalen un DNS de cacheo en su LAN para que el experimiento sea exitoso, porque usar líneas con 128 o 256 Kbps de subida como es el caso de la mayoría de líneas ADSL, no garantiza el éxito de la experiencia.
Espero que toda ésta información les haya resultado de utilidad, y despejado sus dudas sobre el "apocalipsis" que podría resultar de la corrupción de los DNS, como veran corromper un sólo registro de un servidor DNS de un ISP principal consume tantos recursos y ancho de banda, que éste tipo de ataques es poco práctico, a menos que se encuentre una forma de llevarlo acabo coordinadamente por redes zombie, pero eso no es para nada una tarea fácil, hay formas más rentables de crackear una red.
