El sistema distribuido del DNS, la manera en que puede ser consultado y su forma de gestionar la caché ha dado lugar a que muchas técnicas hacking se apoyen en él. Desde extraer datos por medio de consultas DNS en un ataque SQL Injection, hasta inspeccionar los hábitos y el perfil de los empleados de una empresa haciendo estudios con DNS Cache Snooping, pasando por guardar ficheros como valores de respuesta a peticiones DNS.
En esta ocasión el paper titulado "Ghost Domain Names: Revoked Yet Still Resolvable" ahonda un poco más en el tema del DNS, la gestión de la caché y el mantenimiento de un dominio borrado más allá de sus límites. La idea detrás de la técnica es conseguir que un registro no sea borrado nunca de la memoria caché de un servidor DNS.
Supongamos el dominio test.com que tiene un servidor DNS llamado ns.test.com en el que se crea el registro fantasma.test.com de tipo A que apunta a una dirección IP. Se quiere hacer que ese dominio permanezca resoluble a través de un servidor DNS al que llamaremos ns.vulnerable.com aún cuando este haya sido borrado del servidor ns.test.com
Para conseguir transmitir la información de fantasma.test.com a otro servidor DNS hay que solicitar la resolución de ese nombre de dominio al servidor donde se quiere cachear, en este ejemplo ns.vulnerable.com. Con ello la información del registro fantasma.test.com pasará a la caché de ns.vulnerable.com.
Ese registro se almacena en la caché junto con un TTL (Time To Live) que indica el tiempo que queda hasta que sea borrado de la caché, y que irá decreciendo constantemente hasta llegar a 0, momento en que desaparecerá. Por otro lado hay que tener presente que también se almacena información del registro del servidor DNS que lo atendió, con su correspondiente TTL.
Acto seguido se borra el registro fantasma.test.com del servidor ns.test.com. Sin embargo, todos las peticiones que se realicen a través de ns.vulnerable.com seguirán siendo respondidas, ya que el TTL aún no ha llegado a 0, momento en que desaparecerá ese registro de Internet.
¿Cómo evitar que el valor de TTL llegué a 0?
La respuesta para evitar que el valor TTL del registro fantasma.test.com llegue a 0 implica que el servidor DNS ns.vulnerable.com actualice la información de la caché, para lo que se usa un pequeño truco que consiste en:
1) Se cambia el nombre del servidor ns.test.com a ns2.test.com
2) Se solicita la resolución de ns2.test.com a través del servidor ns.vulnerable.com
Con este proceso, el servidor DNS vulnerable, al actualizar su caché detecta que se ha cambiado el nombre y actualiza la información de su base de datos, pero también actualiza el valor TTL de su registro y de todos los registros vinculados a él en la caché, con lo que el valor TTL de fantasma.test.com vuelve a inicializarse.
La técnica paso a paso ha sido publicada en InfoSecInstitute y en las pruebas realizadas que se pueden leer en el paper hay datos curiosos, como servidores DNS populares que han probado vulnerables a esta técnica o que software es vulnerable.
En el estudio hay más datos curiosos, como que a veces hay procesos de reset que hacen que el TTL baje a 0 como parte de procesos de mantenimiento de la caché, y han hecho un estudio sobre cuánto tiempo se puede tener un dominio falso mantenido resoluble en la caché de los servidores DNS por el mundo, y los clientes de qué partes del mundo seguirían viéndolo vivo.
Saludos Malignos!
No he entendido el procedimiento. ¿Cambiar el nombre del servidor ns.test.com a ns2.test.com? ¿hay que ser el admin del servidor?
ResponderEliminarO hay que cambiar el nombre en la consulta?
Voy a echarle un ojo al paper original a ver si me aclaro.
Chema, aunque no tenga nada que ver en el tema. hay rumores de q vengas a bolivia, si lo haces puedes traerte unos libros de info64 a la venta??
ResponderEliminarChemita, esto que hablas del DNS, esta afectado a los clientes de Telefonica por la vulnerabilidad, el INTECO alerto de ello:
ResponderEliminarhttp://pastebin.com/cu5Tv8gF
http://pastebin.com/zbzNc14g
http://routertelefonica/password.cgi
Entran el router del cliente y les cambian los DNS por unos que contienen troyanos bancarios.
Pero silencio, es mejor no ser alarmista y no comentar nada a los clientes, es mejor que los estafen.
Cabrones.