Cómo de crítico era el fallo en los servidores DNS (II)

Vamos a continuar con la explicación del protocolo DNS. Nos quedó pendiente en la entrada anterior detallar cómo es una petición DNS, esto es, qué ocurre en la red para que nos den el «teléfono» para «llamar» a Google con nuestro navegador.

Funcionamiento del protocolo DNS

En el siguiente gráfico se detalla el proceso de una resolución de dominio completa, aunque no siempre se requieren todos los pasos, ya veremos por qué:

1. En primer lugar, desde nuestro PC se genera una petición DNS hacia el servidor de nuestro proveedor de conexión. Dicha petición va en un paquete UDP y en él se pide la IP para la dirección «www.google.com» (en nuestro ejemplo).
2. Como nuestro servidor DNS no tiene conexión directa con la página solicitada, en principio, no sabe su dirección, así que tendrá que averiguarla. Para ello, realiza la misma consulta a uno de los Root Servers de los que sí sabe la dirección, puesto que son fijos.
3. El Root Server tampoco conoce la dirección de «www.google.com», pero sí que conoce la dirección del DNS que alberga los dominios «.com», así que se la entrega a nuestro servidor DNS, con lo cual ya está un poquito más cerca de lo que busca.
4. Nuestro DNS de nuevo realiza la misma consulta, pero esta vez al DNS encargado de los dominios «.com». Éste último tampoco conoce la respuesta final, pero sí que conoce la dirección del DNS que alberga los dominios «google.com»…
5. … así que se la entrega.
6. Una vez más, nuestro DNS realiza la misma consulta al DNS ubicado en «google.com». Y, por fin, él sí conoce la respuesta, puesto que se encuentra en su misma red.
7. Se dice que es «autoritativo» para esa dirección. Le entrega la respuesta final a nuestro servidor DNS.
8. Tras estos pasos que, aunque largos, se realizan en un lapso de tiempo pequeño, nuestro servidor ya conoce la respuesta a nuestra pregunta y nos la entrega.
9. Ahora ya podemos comunicarnos directamente con «www.google.es» puesto que conocemos su dirección IP.

Fácil, ¿no? Y diréis, ¿siempre se realizan todos estos pasos? Evidentemente, no es necesario. Una vez que un servidor DNS ha realizado una consulta y conoce una IP más, la guarda en su memoria caché para agilizar futuras peticiones, ya que es esperable que las direcciones IP no estén variando todo el tiempo. Como sí pueden variar, estas entradas de la memoria caché se guardan un tiempo máximo y luego se borran, por lo que habrá que volver a averiguarlas con los pasos anteriores.

Buscando el agujero de seguridad

Ahora bien, cuando recibimos la respuesta de un servidor DNS, nuestro ordenador confía en esos datos ciegamente. ¿Qué ocurriría si un atacante consiguiera hacerle creer al servidor DNS que la dirección IP para «www.google.com» (u otra página) es otra diferente a la real? Pues bien, en ese caso el servidor DNS guardaría en su caché esa asociación falsa para futuras consultas, y cuando nosotros solicitáramos la dirección de Google, nos haría entrega de esa dirección falsa en la cual nuestro ordenador confiaría ciegamente (porque no tiene manera de comprobar su validez).

En consecuencia, un atacante lograría llevarnos a donde él quisiera de manera indetectable mediante este método, denominado cache poisoning o envenenamiento de la caché. Por poner un ejemplo ilustrativo, imaginemos que alguien realiza una réplica de la página web de nuestro banco y la instala en su ordenador. Mediante envenenamiento de la caché del servidor DNS, logra que éste asocie el dominio de nuestro banco con la IP de su ordenador. Al ingresar nosotros en la web de nuestro banco, en realidad estaremos cargando la página alojada en el ordenador del atacante, y al enviar nuestros datos de conexión se los estaremos dando en bandeja de plata. Y lo peor de todo: ¡es imposible enterarse!

En la próxima entrega, profundizaremos en las causas de este agujero de seguridad y qué han podido hacer para solucionarlo.