─ Un sistema de PHIshing inalámbrico totalmente automático integrado de IoT de Şefik Efe Altınoluk ─
No pruebe este software en usuarios/sistemas para los que no tenga permiso legal. El uso de Wi-Phi
para atacar objetivos sin consentimiento mutuo previo es ilegal. Es responsabilidad del usuario final obedecer todas las leyes locales, estatales y federales aplicables. No asumo ninguna responsabilidad y no soy responsable de ningún mal uso o daño causado por este software, documentación y cualquier elemento de este repositorio.
(VER #4) Debido a que Wi-Phi
puede usarse de manera maliciosa, no comparto la mayor parte del código fuente. Contáctame desde LinkedIn para cualquier caso empresarial/académico/educativo en el que necesites el código de trabajo completo.
Este proyecto tiene la licencia Gnu General Public License Versión 3.0
Consulte LICENCIA para obtener más detalles.
Wi-Phi
es un system
phishing
automático totalmente integrado en placas inalámbricas de IoT
(Internet de las cosas).
Se puede considerar como una Wifi Pineapple
avanzada y rica en funciones.
Wi-Phi
puede realizar phishing a usuarios que ejecutan al menos uno de los siguientes software:
Los componentes principales de Wi-Phi
son:
MicroPython
. Yo uso Deneyap Kart
basado en ESP32
.esp32-20220117-v1.18.bin
Obtenga un dispositivo ESP32 IoT.
Conecte ESP32 a su computadora y obtenga el puerto serie al que está conectado el ESP32.
COMx
/dev/ttyUSBx
o /dev/tty/USBx
Luego ejecute los siguientes comandos para GNU/Linux.
[efe@lhost ~] $ git clone https://github.com/f4T1H21/Wi-Phi.git && cd Wi-Phi
[efe@lhost Wi-Phi] $ pip3 install -r requirements.txt
[efe@lhost Wi-Phi] $ sudo ./setup.sh < serial_port >
Ahora, el software debería estar funcionando, verifique si ve una red Wi-Fi llamada Google Free Wi-Fi
.
Siempre que conecta ESP32 a una fuente de alimentación, el proyecto se ejecuta automáticamente después de la etapa de arranque.
Nada más importa.
Todo el software está implementado en MicroPython y se ejecuta en ESP32.
ESP32 se convierte en un AP (Punto de Acceso) Inalámbrico; y ejecuta tres (3) sockets independientes (en OSI Layer 4):
53/UDP
para servidor DNS
80/TCP
para servidor HTTP
2121/TCP
para servidor Credential Store
Todo el enlace se realiza en la dirección IP de la puerta de enlace (AP), que es 210.210.210.1
La razón por la que elegí esta clase de IP es porque, por alguna razón, los dispositivos Samsung no consideran las direcciones IP cortas como portales cautivos. Lo cual fue un problema para mí.
La idea principal es servir un sitio web de phishing estático en un servidor HTTP y convertirlo en un captive portal
para dispositivos (estaciones) de cualquier proveedor que estén conectados a través de Wi-Fi.
Static site
servido por un servidor HTTPDNS
, HTTP
y CS
TCP
y UDP
para protocolos de alto nivelGateway
LAN
Wireless AP
, Wi-Fi
A continuación se muestra el escenario bien diseñado en el que funciona Wi-Phi
.
Este también es un estudio de caso que me asigné. Así que profundicemos en el caso...
La mayoría de los proveedores de dispositivos envían solicitudes HTTP a ciertos puntos finales de los servidores de detección de portales cautivos específicos de sus proveedores y esperan respuestas HTTP particulares para comprender si la red Wi-Fi tiene un portal cautivo o no.
La siguiente tabla muestra qué responder para varios proveedores de dispositivos, para que el dispositivo suponga que existe un portal cautivo en la red Wi-Fi.
Nota : Mozilla es una excepción a los "proveedores de dispositivos". Firefox (como navegador) puede tomar esta decisión por sí mismo según su propio servidor de detección de portal cautivo.
Las respuestas con código de estado 302 Found
también deben tener un encabezado Location:
para redirigir el navegador (cliente) correctamente.
Proveedor de dispositivos | Puntos finales | Código de estado | Cuerpo de respuesta |
---|---|---|---|
Microsoft (Windows) | www.msftconnecttest.com/ncsi.txt | 200 OK | Microsoft NCSI |
Microsoft (Windows) | www.msftconnecttest.com/connecttest.txt | 200 OK | Microsoft Connect Test |
Microsoft (Windows) | www.msftconnecttest.com/redirect | 302 Found | |
Google (Androide) | connectivitycheck.gstatic.com/gen_204 | 302 Found | |
Google (Androide) | connectivitycheck.gstatic.com/generate_204 | 302 Found | |
Google (Androide) | clients3.google.com/generate_204 | 302 Found | |
Xiaomi | connect.rom.miui.com/gen_204 | 302 Found | |
Xiaomi | connect.rom.miui.com/generate_204 | 302 Found | |
Apple (IOS/MacOS) | captive.apple.com/hotspot-detect.html | 302 Found | |
Mozilla (Firefox) | detectportal.firefox.com/canonical.html | 302 Found | |
Mozilla (Firefox) | detectportal.firefox.com/success.txt | 302 Found |
Para poder responder las solicitudes http que se realizan a los puntos finales anteriores, estas solicitudes deben enviarse al servidor HTTP de ESP32. Para lograr esto, ESP32 debe responder búsquedas de dominios particulares a su propia dirección IP.
google.com
debería ser 210.210.210.1
Por lo tanto, es necesario que haya un servidor de sistema de nombres de dominio ejecutándose en ESP32. Desde este punto de vista, el escenario parece similar a los ataques de secuestro de DNS.
Creo que Google es la empresa de tecnología más popular y confiable del mundo. Así que preparé una página de phishing estática, que se parece casi a la antigua página de inicio de sesión de Gmail. Y también denominada red Wi-Fi como Google Free Wi-Fi
.
A medida que continúa el escenario, después de redirigir el navegador (cliente) a la página de inicio de sesión estática, el usuario debe ingresar sus credenciales y presionar el botón Siguiente. Y las credenciales se almacenan en un archivo local. Luego, el usuario obtiene una IP prohibida hasta el próximo reinicio de ESP32. De lo contrario, la base de datos local puede verse dañada por credenciales ficticias o incorrectas. Después de todo esto, el cliente es redirigido al directorio /
del sitio estático.
Cada vez que un cliente con IP prohibida intenta acceder a cualquier recurso en el servidor HTTP, se sirve el mismo archivo html hacklendin.html
independientemente del método, encabezado, cuerpo, etc. de la solicitud HTTP.
Por otro lado, el almacén de credenciales local se puede ver de forma remota conectándose a 2121/tcp
y autenticándose con la contraseña codificada mientras está conectado a Wi-Fi.
Wi-Phi
es un sistema rico en funciones. Los registros detallados creados por los servicios Wi-Fi
, HTTP
y DNS
se pueden ver en tiempo real. Estos registros no se almacenan localmente para ahorrar almacenamiento.
Para poder ver registros detallados,
boot.py
a un archivo local llamado main.py
boot.py
del dispositivo ESP32.main.py
en ESP32. Puede utilizar la herramienta ampy
para operaciones de archivos y ejecutar software en ESP32.
Echemos un vistazo a un caso en el que tenemos varios dispositivos independientes de varios proveedores conectados a nuestro Google Free Wi-Fi
al mismo tiempo.
Cuando los dispositivos IOS encuentran un portal cautivo, abren automáticamente la página del portal cautivo, sin avisar al usuario: ¡Bien!
Los dispositivos Samsung solo muestran una notificación. Entonces, aquí el usuario debe hacer clic en Sign in to the network
o en la notificación en la parte superior de la pantalla.
Los dispositivos Xiaomi también muestran una notificación. ¡A veces también abren la página del portal cautivo automáticamente, sin avisar al usuario nuevamente!
En Firefox, aparece un mensaje en la parte superior de la ventana de la aplicación. Después de hacer clic en Open network login page
, se abre la página del portal cautivo en una nueva pestaña.
Y el otro que ni siquiera deja decidir a los usuarios (como IOS). Siempre abre la página del portal cautivo automáticamente.
Como expliqué antes,
¡Todo el período de aprendizaje, implementando lo que aprendí en la vida real, corrigiendo errores y escribiendo esta documentación fue muy divertido para mí! ¡Espero que utilices estos conocimientos para lo ético! Contácteme para preguntas adicionales y casos comerciales/académicos/educativos.
Gorjeo
LinkedIn
hackeruno
Hackear la caja
─ Escrito por Şefik Efe Altınoluk ─