Después de haber asistido a los dos últimos DEFCON, estoy muy emocionado de hablar en DEFCON 18 este año. En anticipación a mi presentación, “Cómo piratear millones de enrutadores”, pensé que aprovecharía esta oportunidad para responder algunas preguntas, ofrecer información de antecedentes y dar un breve avance sobre la charla.
La mayoría de las personas asumen que debido a que no tienen habilitada la administración remota en su enrutador, los atacantes externos no pueden acceder a la interfaz web administrativa de su enrutador. Sin embargo, para muchos enrutadores esto simplemente no es cierto; cualquier persona con un dominio registrado puede, de hecho, obtener acceso interactivo completo a la interfaz web interna del enrutador para explotar vulnerabilidades o iniciar sesión en el dispositivo (ya sea a través de la contraseña predeterminada del enrutador o un ataque de fuerza bruta), en ese momento pueden ver configuraciones, cambiar configuraciones y generalmente hacer lo que quieran con el enrutador *. Sin embargo, este ataque no está restringido a la interfaz web principal; también se puede usar para obtener acceso interactivo a servicios basados en SOAP que se ejecutan en el enrutador, como Universal Plug-n-Play, que no requiere autenticación alguna. Si bien este ataque no funciona contra todos los enrutadores, de treinta enrutadores diferentes probados, el ataque fue exitoso contra más de la mitad de ellos, incluido el venerable WRT54G de Linksys, enrutadores ActionTec utilizados por clientes de Verizon FiOS y DSL, y muchos otros. Dado el número y la popularidad de los enrutadores afectados, esto se traduce en muchos millones de enrutadores vulnerables implementados en todo el mundo, sin mencionar todos los otros enrutadores que aún no se han probado.
El ataque es en realidad una combinación de muchas cosas, desde navegadores y JavaScript hasta firewalls y pilas TCP / IP, pero en última instancia se centra en el enlace DNS *. Aunque el enlace DNS se ha discutido públicamente durante casi 15 años, muchas personas aún no lo entienden completamente. He recibido varias consultas sobre la charla, y generalmente se reducen a dos preguntas básicas:
1) ¿Qué es el enlace DNS?
2) ¿Qué tiene de especial la técnica de reenlace de DNS presentada en esta charla?
Para comprender el enlace DNS, examinemos por qué se necesita el enlace DNS en primer lugar: la misma política de dominio. La misma política de dominio es una política de seguridad que aplica su navegador web. Esa política establece que si navega a https://www.evilhacker.com/, esa página de www.evilhacker.com puede indicarle a su navegador web que cargue contenido de otros sitios web (imágenes, JavaScript, CSS, iframes, etc. ), pero no puede ver las respuestas de esos sitios web ni acceder al contenido que devuelven esos sitios web. En otras palabras, JavaScript de www.evilhacker.com solo puede acceder al contenido de www.evilhacker.com porque ese contenido proviene del mismo dominio. Esto es algo bueno, ya que no querría que JavaScript de www.evilhacker.com realice XmlHttpRequests no autorizadas a sitios web dentro de su red local o en otro lugar.
El problema con esta política es que las computadoras no usan nombres de dominio para comunicarse entre sí; ellos usan direcciones IP. La idea detrás del enlace DNS es:
1) Haga que la víctima cargue JavaScript desde www.evilhacker.com.
2) Convenza al navegador de la víctima de que www.evilhacker.com se ha movido a una dirección IP diferente, por ejemplo, 192.168.1.1.
3) El JavaScript de Evil hacker es libre de interactuar con www.evilhacker.com, que el navegador ahora cree que se encuentra en 192.168.1.1.
La parte difícil en el ataque anterior es convencer al navegador de la víctima para que cambie las direcciones IP. Varios métodos para lograr esto se han presentado en el pasado, entonces, ¿por qué otra charla sobre los ataques de reenlace de DNS? Porque, simplemente, los ataques de enlace de DNS comunes que se han discutido en el pasado no son prácticos o simplemente ya no funcionan:
o Establecer valores bajos de TTL en las respuestas de DNS ya no funciona debido a la fijación de DNS.
o Los ataques de anclaje anti-DNS solo funcionan en navegadores antiguos (IE6 /7, FF2.x), e incluso entonces, el ataque de reconfiguración tarda entre 15 y 120 segundos en tener efecto según el navegador de la víctima.
o La técnica de “registro A múltiple” ya no se puede utilizar para volver a vincular a direcciones IP internas (RFC1918).
o Además de los navegadores, los complementos de terceros como Flash y Java han implementado medidas anti-reenlace.
Gracias a varias características presentes en muchos enrutadores populares y sus sistemas operativos subyacentes *, nada de esto impedirá el ataque discutido en esta charla, que se ha probado contra redes en vivo en escenarios del mundo real (con los permisos adecuados de los propietarios de la red, naturalmente). Las protecciones comunes de reenlazado anti-DNS que ofrecen servicios como dnsmasq, OpenDNS y NoScript no evitarán este ataque ni cambiarán la dirección IP interna del enrutador. La buena noticia es que tanto los proveedores como los usuarios finales pueden hacer arreglos para protegerse contra este ataque *. La mala noticia es que se trata de soluciones que deberían haberse implementado hace años, pero que tanto los proveedores como los usuarios han ignorado.
Por supuesto, ¿qué es una charla sin un lanzamiento de herramienta? Demostraré y lanzaré una herramienta que automatiza todo el ataque y extiende la interfaz web interna del enrutador de destino a un sitio web externo donde el atacante puede acceder y navegar por las páginas web del enrutador en tiempo real, como si estuviera sentado en el LAN mismo. Todo lo que necesita el atacante es un usuario dentro de la red de destino para navegar al sitio web del atacante. ¡Es una herramienta de piratería de apuntar y hacer clic que es divertida para toda la familia!
* Para ser discutido con más detalle en la charla!
Fuente: Def Con
