dougives/wispScript y kit de hardware para desautenticar automáticamente clientes 802.11 en masa. Captura paquetes para futuras fechorías.
Script para desautenticar clientes 802.11 en masa automáticamente. Captura paquetes para fechorías posteriores. Excelente iniciador de conversaciones en tu cafetería local.
Este script fue diseñado para ejecutarse en una Raspberry Pi 3 o superior. También funcionará en hardware similar con las mismas o mayores capacidades, por supuesto.
Se requiere una cantidad considerable de equipo adicional para operar el script de manera efectiva. También necesitarás:
Para máxima efectividad, también deberías tener:
Personalmente uso ConnectBot con Hacker's Keyboard en mi teléfono móvil para controlar equipos como este a través de SSH. Atrae la menor atención y cabe en el bolsillo.
Sugiero que el dispositivo se configure para conectarse automáticamente a una VPN que tú hospedes, para evitar problemas de enrutamiento/NAT. Configurar OpenVPN en un host en la nube es la forma más sencilla de lograrlo. Asegúrate de usar la directiva de configuración del servidor client-to-client de OpenVPN, o de tener el reenvío configurado de otra manera.
Obviamente, necesitarás algún otro método además de wifi para conectar el dispositivo a internet. El acceso celular es el candidato más simple. A menos que desees extraer capturas de paquetes del dispositivo de forma remota, se requiere muy poco ancho de banda (<100Kib/s). Puedes arreglártelas usando un plan de datos "ilimitado" barato que restrinja tu velocidad después de cierta cantidad de datos usados.
He tenido problemas de MTU al ejecutar OpenVPN sobre redes celulares. El remedio más sencillo es establecer tu MTU en 1200 con ip link set dev tunX mtu 1200, donde tunX es tu dispositivo tun. Puede que necesites usar un MTU diferente dependiendo de tu red.
Dependiendo de tu configuración específica, los dispositivos USB conectados pueden consumir más energía de la que la Raspberry Pi puede proporcionar a través de sus medios habituales. Usar un concentrador USB con alimentación como el mencionado anteriormente te permitirá alimentar las radios a través de otro puerto USB de la batería. Algunos concentradores USB baratos realimentarán el concentrador en la Raspberry Pi. Esto es adecuado siempre que uses una batería de buena calidad, e incluso útil.
Otra solución es proporcionar alimentación adicional al concentrador USB usando un divisor como este. Funciona, pero no lo recomiendo. Es una cosa más que podría desconectarse accidentalmente y es difícil de organizar de otra manera.
Si estás proporcionando control remoto a través de un teléfono celular conectado por USB, debes asegurarte de que la batería tenga carga completa al iniciar el equipo, si es posible. Algunos dispositivos baratos pueden no consumir suficiente corriente para mantenerse al día con la energía consumida por una conexión de datos constante.
La combinación de múltiples radios, la Raspberry Pi y el módem celular se calentará mucho. Las Panda PAU06 se calientan especialmente. Si no te importa el calor, terminarás con radios derretidas o algo peor. Haz una prueba con la bolsa o carcasa elegida a temperatura ambiente de antemano para asegurarte de que proporcione una disipación de calor adecuada. Si debes usar el equipo en un ambiente caluroso, como dentro de un vehículo en un día cálido, toma medidas adicionales para evitar el sobrecalentamiento. En el caso de un vehículo, configurar los controles de clima para A/C y arrancar el vehículo de forma remota intermitentemente será suficiente.
Algunos teléfonos celulares baratos son propensos al sobrecalentamiento debido a la combinación del equipo adicional y la necesidad de transmitir datos regularmente. Pueden apagarse bajo estas condiciones, impidiendo el control remoto. Colocar el teléfono en un compartimento separado del resto del equipo ayudará, pero es mejor usar un dispositivo diferente.
Si tienes la intención de operar el equipo de forma encubierta, ten en cuenta que el calor puede llamar la atención de formas inesperadas. Si se deja en el tablero de un vehículo durante un día de nieve, derretirá la nieve y el hielo. Habrá un espacio redondo y limpio en el parabrisas, centrando el equipo a la vista, ¡mientras que todo lo demás está cubierto de nieve!
Las instrucciones de instalación de Wisp se detallan en rpi-install.md. Los pasos deberían ser similares para sistemas no Raspbian. Wisp depende de aireplay-ng de aircrack-ng para transmitir tramas de desautenticación. Notablemente, necesitarás compilar Python-3.7.1 para el dispositivo, lo cual también se describe en el archivo rpi-install.md.
Wisp depende de otro pequeño programa en C llamado dream. El código fuente está incluido como dream.c. Dream depende de libpcap.
Compila dream para tu dispositivo con el comando gcc -O3 dream.c -lpcap.
Dream es una herramienta para monitorear tráfico 802.11 con una salida greppable por líneas. También guarda el tráfico capturado en archivos con el formato pcap estándar. Wisp llama a dream por cada radio de monitoreo y analiza la salida en busca de tráfico de clientes. Aquí están sus argumentos:
--a: Solo reporta tráfico de clientes asociados. (Todos los paquetes aún se registran en disco si --d está habilitado.)--d (archivo): Vuelca paquetes al archivo especificado.-[b][c][d][f][s][t]: Especifica qué campos mostrar por línea, específicamente:
b: BSSc: Número de canal.d: Nombre del dispositivo que recibió el paquete.f: Frecuencia.s: Estación (STA).t: Marca de tiempo de pcap.Estos campos siempre se imprimen en el mismo orden, independientemente del orden especificado. (Es decir, -bcst es equivalente a -sctb.)
Wisp lee un archivo con formato json llamado wisp.json para la configuración. Aquí hay una descripción de las claves:
monitors: Contiene una lista de dispositivos que se configurarán como monitores. Cada dispositivo contiene subclaves que describen su configuración específica:
channel: El canal para que el dispositivo monitoree.injector: El dispositivo que se configurará para inyectar tramas de desautenticación.timing: Lista varios parámetros de temporización, todos dados en milisegundos:
delay: El retardo entre paquetes de desautenticación enviados, por cliente.jitter: Modula el tiempo de retardo por una cantidad aleatoria, en el rango dado.stale: Cantidad de tiempo que un cliente no es visto antes de ser eliminado de la lista de retardo. Tiene poco efecto práctico a menos que esté cerca del período de retardo.Todos los parámetros se cargan desde wisp.json, por lo que wisp se invoca simplemente: python3 ./wisp.py
Wisp configurará automáticamente las radios según lo descrito en wisp.json. También deshabilitará rfkill y matará cualquier proceso interferente, similar al comportamiento de airmon-ng.
Wisp renombra los dispositivos especificados con el formato wispX donde X es el número asociado con el phy. Renombrará los dispositivos de vuelta a sus nombres originales al salir.
Wisp genera un . por cada desautenticación enviada. Esta es una forma simple y efectiva de asegurarse de que está funcionando como se espera.
Wisp (a través de dream) generará archivos pcap con el prefijo del nombre de la radio (phy) que capturó los paquetes, junto con una cadena hexadecimal aleatoria, terminando en .cap. Algo como phy0-8cf9ec5ca146943f.cap, por ejemplo. Luego puedes inspeccionar, analizar y manipularlos con cualquier herramienta habitual para archivos pcap.