Conocido hace 10 años, y de actualidad de un año a esta parte, debido a vulnerabilidades en los
plugins de los navegadores, es el llamado
"DNS rebinding". El ataque, en concepto, es muy sencillo, este post es una sencilla
receta para introducirlo.
Objetivo del ataque: el navegador del usuario, y más exactamente, alguna de sus extensiones (Flash, Java, ...). Se pretende que haga peticiones a un sitio web distinto al que el navegador cree que está llamando realmente, cosa en principio no posible porque tiene su protección para ello.
Esta protección es el llamado
DNS pinning: consiste en que el navegador guarda una base de datos,
caché o como lo quieras llamar, con pares nombre-de-host <--> IP, durante un tiempo determinado fijo o hasta que se cierre el navegador. La idea original era que se llamara siempre al mismo servidor, mientras tuviera su entrada en esta "pin-cache". Esta medida completaba a la política de
"same-origin-policy", cuyo objetivo es evitar que un script cargado al acceder a un dominio, intente acceder a elementos de otro.
Se puede conseguir no sólo acceder a otro sitio web, sino a cualquier otro tipo de aplicación de internet, como puede ser un servidor SMTP, usando como plataforma de lanzamiento el navegador del usuario. Esto es porque un plugin dispone de la capacidad de crear sockets
a pelo.
Ingredientes para ejecutarlo:
- un servidor de web, con alguna aplicación especialmente preparada
- un nombre de dominio que se pueda controlar, en tu propio DNS, o por ejemplo, en dyndns.org
- un medio de conseguir que las víctimas invoquen a la aplicación web, como puede ser un banner en otros sitios web, o un poco de ingeniería social
- algo de información extra, dependiendo de qué se pretenda hacer
Elaboración:
Prepara el servidor de web con la aplicación maliciosa, y sácalo a Internet, o a donde pueda ser alcanzable por quienes quieres (no olvides securizarlo en condiciones, no vaya a ser que alguien más listo que tú y yo haga cosas malas con él ;) ).
Crea el nombre de dominio para la aplicación en el servidor DNS, y asígnale al menos dos direcciones IP: la IP real de tu servidor, y la IP a la que quieres que el cliente llegue. La segunda dirección IP puede depender de esa información que hay que saber antes, por ejemplo, si lo que se pretende es acceder a un servidor web de intranet, de acceso restringido a equipos de la red interna de una organización, pues eso, hay que saber antes su dirección.
Ahora el navegador de la víctima llamará al sitio web malicioso (engañado de alguna manera), y el DNS le devolverá la primera dirección IP, la del servidor con la aplicación víctima. El servidor de web devolverá el código malicioso. Acto seguido, se deberá cerrar el acceso al mismo, por ejemplo, aplicando una regla de denegación de acceso en el firewall.
Este código que descargue deberá esperar algo de tiempo, y luego invocar de nuevo al sitio web del atacante. Al encontrar que no está accesible, usará la segunda dirección IP suministrada por el DNS. ¡Bingo!. Accede al servidor deseado por el atacante.
Por supuesto, la gracia, el truco del almendruco, es tener a mano el script maligno ;)
Este problema, que tuvo sus variantes hace años, ha vuelto a la actualidad debido a la implementación de los plugins que llevan los navegadores. Y es que tienen una caché con pares nombre-de-host <--> IP, distinta a la que tiene el navegador en sí. Además, reimplementan las medidas de seguridad que traían ya los navegadores. Por ejemplo, en la página de Adobe se habla de una
actualización para Flash Player, corrigiendo un problema de este tipo.
Las posibilidades de este tipo de ataque son elevadas: desde acceder a sitios restringidos, al envío de spam, explotación de vulnerabilidades... todo usando el navegador del usuario como plataforma de lanzamiento.
Leo además en OpenDNS que ofrecen una
solución en su servicio. Se habla también de un plugin de Firefox para evitar este problema, llamado
LocalRodeo (no lo he probado).
Algunos enlaces (buscando en Google, salen de los primeros):
SecurityFocusdark readinghackszineinvestigación de la Universidad de Stanford: presentación completa de toda la problemática, objetivos que pretende un atacante (extenso), soluciones (aún más extenso), referencias a otros trabajos...
blog de Christian: explica bastante bien qué es el DNS pinning, por qué apareció, cómo evolucionó, etc. Con gráficos y todo.
