Estos tipos de ataques se pueden lograr a través de múltiples CSRF contra las direcciones IP descubiertas a través de la herramienta de reconocimiento de JavaScript.

Diga que su dirección IP local es 192.168.1.100 . Usted visita el sitio web malicioso, se ejecuta JavaScript y encuentra el dispositivo 192.168.1.254 en su red. Ahora, dependiendo de lo complejo que sea JavaScript, identificará la marca y el modelo del enrutador, o simplemente intentará un ataque de fuerza bruta para explotar el enrutador. Es decir, enviará cada exploit en su base de datos en el dispositivo para intentar comprometerlo.

Digamos que el enrutador BOB 2000 tiene una vulnerabilidad en que su URL /config/remoteConfigSettings no implementa ningún tipo de verificación de autenticación. Como esta página solo es accesible desde su red local, normalmente no es vulnerable a los ataques basados en Internet.

Sin embargo, después de que alguien en su red haya visitado el sitio malicioso, esto podría intentar cada ataque en su base de datos para intentar explotar el enrutador en 192.168.1.254 , incluido el envío de una solicitud POST desde el navegador con el cuerpo del mensaje:

AllowInternetAccess=true&RequirePassword=false

a http://192.168.1.254/config/remoteConfigSettings .

Como esta página es vulnerable, la solicitud hace que el lado WAN del enrutador esté disponible para la administración remota y desactiva la autenticación de la contraseña. El sitio web malintencionado puede informar que se encontró un dispositivo para el atacante junto con la IP de Internet para que el atacante inicie sesión más tarde de forma manual o que sea más probable que se agregue a una lista de IP para la explotación automatizada ahora que se otorga el acceso remoto. La explotación remota podría incluir cualquier cosa, desde alterar la configuración de DNS a un servidor controlado por un atacante para un futuro ataque MITM, hasta actualizaciones de firmware maliciosas en el enrutador.

Además de verificar las vulnerabilidades conocidas, el script malicioso también podría probar las solicitudes de enrutadores regulares pero autenticarse con las credenciales predeterminadas o de uso común.

Actualizar

Con respecto a @ Ajedi32's comentar sobre la Política del mismo origen: el escáner no necesita que el enrutador esté en el mismo origen para poder tomar huellas dactilares. Utiliza una combinación de IFrames y etiquetas de imagen para determinar si algo y qué se cargó y luego las compara con las IP predeterminadas conocidas. Desde el sitio del autor :

  

El escáner accede a un IFrame para realizar un escaneo genérico de la red   para las IP de enrutador predeterminadas conocidas, una vez que se haya realizado la conexión, se   pasa la dirección IP y realiza una búsqueda de enrutadores / dispositivos basados en   en esa direccion La razón por la que he decidido hacer esto es porque   quería que el escáner tomara tantos dispositivos como fuera posible porque lo haría   será imposible hacer una huella digital de todo.

     

Una vez que se ha encontrado una dirección IP, pasa esto a la impresión digital.   Función que utiliza un objeto de imagen para establecer una conexión con el dispositivo.   para ver si el gráfico de huellas dactilares está allí.

A través de DNS Rebinding

Otra posibilidad no discutida en el artículo vinculado es un Ataque de reencuadernación de DNS . Supongamos que el truco de IFrame detecta que algo se está ejecutando en 192.168.1.254 una vez que la víctima ha visitado evil.example.com . El script de detección del atacante luego ejecuta un script del lado del servidor para volver a enlazar el DNS de evil.example.com a 192.168.1.254 . Como la entrada de DNS tiene un TTL muy corto, el navegador requiere la búsqueda del nombre y obtiene la dirección del enrutador. Como el enrutador tiene una configuración de credenciales predeterminada, la página maliciosa puede enviar solicitudes AJAX para leer y modificar cualquier contenido en la página de configuración del enrutador. Esto "pasa por alto" la misma política de origen que el enrutador ahora tiene el mismo origen que el sitio malicioso ( http://evil.example.com:80 ).

Este ataque contaría con que el navegador vuelva a verificar el DNS. La mayoría de los navegadores tienen su propio caché de DNS fuera del sistema operativo, y pueden almacenarse en caché durante más tiempo de lo que dictan los TTL, lo que dificulta este tipo de ataque.

Muchos enrutadores tienen una consola de administración basada en web, y parece que eso es lo que explota este ataque. Con frecuencia, solo se puede acceder a la consola de administración en la LAN, en lugar de permitir conexiones externas, y este JavaScript malintencionado es lo que se usa para pasar de la máquina del atacante a la LAN.

Una posible forma en que este ataque podría desarrollarse:

1. El JavaScript malicioso se carga en el navegador de la víctima. Esto no es necesario para salir de la zona de pruebas del navegador, o de lo contrario atacar la PC del usuario, solo tiene que funcionar el tiempo suficiente para atacar el enrutador.
2. El JS busca dispositivos de red locales y determina dónde está ubicado el enrutador (192.168.1.1 y 10.1.1.1 son direcciones IP bastante comunes para un enrutador, por ejemplo).
3. El JS intenta acceder al panel de administración web del enrutador. Recuerde, usted está dentro de la LAN en este punto, por lo que en lo que respecta al enrutador, esta es una conexión interna.
4. El panel de administración del enrutador le solicita un nombre de usuario / contraseña. Existe una buena posibilidad de que este sea el valor predeterminado para ese tipo de enrutador en particular. A menudo será algo como "admin: admin".
5. Si el atacante puede adivinar el nombre de usuario y la contraseña correctos, tendrá acceso al panel de administración. Si existe alguna posibilidad de actualizar el firmware desde el panel de administración de la web (el artículo dice que a veces es así), eso es todo: el juego ha terminado, el atacante puede instalar lo que quiera.