Vulnerabilidad DNS de Kaminsky (resumen)

Hace unas semanas tuvimos la noticia de cómo era posible burlar el protocolo DNS para conseguir que usuarios incautos fueran redireccionados a servicios fraudulentos, suplantando los verdaderos. Este artículo trata de explicar, de forma breve, dicha vulnerabilidad.

Sin entrar en detalles de la estructura de una petición DNS, indicaremos el modus-operandi de este protocolo.

Cuando un usuario solicita acceder a un host mediante su nombre (supongamos, para fijar ideas, que se trata de una petición HTTP mediante un navegador web, aunque pudiera ser cualquier tipo de servicio que haga uso de DNS para resolver nombres), esta petición llegará, en primer lugar en caso de existir, a la pequeña caché de su router; en caso de no encontrar la entrada HOSTNAME – IP se reenviará esta petición al servidor DNS de nuestro proveedor de servicios de internet (ISP, Internet Services Provider, véase: ONO, Telefónica, Rediris, etc). Este mensaje tiene un identificador único, que sirve para que quien conozca la respuesta sepa a quién contestar.

Resolución DNS normal

Resolución DNS normal

En estos servidores puede encontrarse la resolución de tal nombre mediante una IP (y es importante reseñar que todo el trabajo del protocolo DNS es con IP’s) la respuesta es enviada al cliente. Pero de no ser así se reenvía la petición a un servidor de mayor nivel en la jerarquía (servidores GTLD). A su vez estos servidores realmente no conocen la respuesta, pero sí saben quién puede responder. Se comportan como un broker de bolsa o un intermediario, para que nos hagamos una idea. Estas respuestas son devueltas al servidor DNS de nuestro ISP.

La manera que tienen los ISP de acceder a estos servidores GTLD es de forma aleatoria, es decir: tienen una lista de GTLD’s y acceden a uno cualquiera de ellos, y así sucesivamente hasta que alguien les devuelve una respuesta válida. Estas peticiones utilizan, por lo general un identificador de mensaje que es el mismo que les llegó del cliente, pero incrementado en una unidad.

Finalmente, cuando se encuentra la respuesta, esta es enviada al servidor DNS de nuestro ISP y cacheada para siguientes peticiones.

El problema viene si un supuesto servidor que es consultado por un GTLD y que trata de suplantar a un servidor fidedigno está esnifando los identificadores de las peticiones DNS de los clientes. Si consigue colar una petición DNS al servidor ISP pidiendo la dirección IP del sitio al que trata de suplantar y a continuación inunda la red hacia el propio servidor ISP con respuestas cuyos identificadores se van incrementando en 1, puede ocurrir que consiga colar la respuesta falsa antes de que llegue la respuesta auténtica de los servidores GTLD, cuya respuesta llegaría más tarde y sería deshechada.

Ataque que aprovecha la vulnerabilidad de Kaminsky

Ataque que aprovecha la vulnerabilidad de Kaminsky

El daño está hecho: hemos colado una entrada fraudulenta en el servidor ISP víctima, y las siguientes peticiones de los clientes serán redireccionadas al servidor fraudulento que trata de suplantar el auténtico. Y nadie podrá darse cuenta del cambiazo, pues a todos los efectos se ha resuelto la petición de forma correcta.

Si alguien desea obtener más información, puede consultar el artículo original (en inglés) en:

http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s