aleksamcode/preferred-network-list-snifferUna herramienta de reconocimiento para capturar y mostrar SSIDs de la Lista de Redes Preferidas del dispositivo.
Sniffer de Lista de Redes Preferidas (PNLS) es una herramienta de auditoría Wi-Fi para Red Team con una interfaz web simple, capaz de interceptar SSID1 de la lista de redes preferidas (PNL)2 del dispositivo. Esto se logra mediante la captura de Solicitudes de Sonda en las cercanías, que luego se analizan para obtener el SSID y otra información, y finalmente se propagan a la interfaz web. La motivación principal de este proyecto fue investigar las Solicitudes de Sonda 802.11 y los riesgos de privacidad asociados con los datos que transmiten.
Fig. 1: Vista general del sistema PNLS
[!WARNING] Todo el contenido de este proyecto está destinado únicamente a fines de investigación en seguridad.
[!NOTE]
Este proyecto es parte de mi investigación en curso sobre Protección de la Privacidad en Redes Wi-Fi.
Para monitorear el trabajo en curso en PNLS, consulte el tablero del proyecto.
Esto es lo que necesitará para duplicar e implementar este proyecto, incluidos los componentes de hardware y software. Una vez que tenga su entorno de trabajo listo, diríjase a las secciones de configuración.
sudo airmon-ng start wlan0 [2].[!NOTE]
La imagen de Kali utiliza el kernel de Re4son, que incluye los controladores para tarjetas Wi-Fi externas y el firmware Nexmon para la tarjeta inalámbrica incorporada en RPi 3 y 4 [3].
Fig. 2: PNLS ejecutándose en una RPi 4 con una antena externa y un banco de baterías
Fig. 3: PNLS ejecutándose en una RPi 4 con una carcasa y una antena AWUS036ACS
Fig. 4: PNLS ejecutándose en una RPi 4 con una antena AWUS036ACM
Si no desea usar Docker, diríjase a la configuración sin Docker.
Configure rápidamente una instancia de desarrollo:
# Primero clone este repositorio.
git clone https://github.com/AleksaMCode/Preferred-Network-List-Sniffer.git
# Muévase a la carpeta raíz del proyecto.
cd Preferred-Network-List-Sniffer
# Construya la imagen del backend y del frontend.
docker compose build
# Inicie tanto el backend como el frontend.
docker compose up
# Muévase a la carpeta del sniffer.
cd sniffer
# Ejecute el servicio Sniffer.
sudo python3 sniffer.py
Actualmente, no hay imágenes multi-plataforma disponibles, y el proyecto solo soporta la arquitectura ARM64v8. Descargue las últimas imágenes preconstruidas desde el Registro de Contenedores de GitHub y ejecútelas localmente.
# Primero clone este repositorio.
git clone https://github.com/AleksaMCode/Preferred-Network-List-Sniffer.git
# Muévase a la carpeta raíz del proyecto.
cd Preferred-Network-List-Sniffer
# Descargue las imágenes preconstruidas.
docker pull ghcr.io/aleksamcode/pnls-backend-ghcr:latest
docker pull ghcr.io/aleksamcode/pnls-frontend-ghcr:latest
# Inicie tanto el backend como el frontend.
docker compose up
# Muévase a la carpeta del sniffer.
cd sniffer
# Ejecute el servicio Sniffer.
sudo python3 sniffer.py
Backend: para iniciar los servidores ASGI y Redis y ejecutar los servicios necesarios, consulte estas instrucciones.
Frontend: para ejecutar el servidor React, consulte estas instrucciones.
Aquí hay una captura de pantalla cuando todo se ejecutó "manualmente":
Fig. 5: Captura de pantalla de PNLS
Las Solicitudes de Sonda son tramas de gestión 802.11 que se utilizan para conectar dispositivos a Puntos de Acceso (AP) inalámbricos previamente asociados. Cada vez que un dispositivo tiene el Wi-Fi habilitado pero no está conectado a una red, envía periódicamente una ráfaga de Solicitudes de Sonda que contienen SSID de su PNL. Estas tramas se envían sin cifrar, y cualquier persona que esté monitoreando Radio Frecuencia (RF) puede capturarlas y leerlas. Las sondas se envían a la dirección de difusión DA (ff:ff:ff:ff:ff:ff). Una vez enviadas, el dispositivo inicia el Temporizador de Sonda. Al finalizar el temporizador, el dispositivo procesa la respuesta recibida. Si el dispositivo no ha recibido respuesta, pasará al siguiente canal y repetirá el proceso. Hay dos tipos de Solicitudes de Sonda:
Solicitudes de Sonda Dirigidas: utilizando un SSID específico de la PNL del dispositivo
Solicitudes de Sonda Nulas: utilizando un SSID Comodín (SSID vacío)
Las Solicitudes en Blanco se envían para obtener una respuesta de todos los AP disponibles que estén al alcance.
Además de filtrar las tramas de Solicitud de Sonda 802.11 de todos los paquetes capturados, el Sniffer también filtrará los SSID comodín.
Al capturar Solicitudes de Sonda en lugares donde hay una gran red local con muchos clientes Wi-Fi, PNLS inevitablemente capturará muchas Solicitudes de Sonda que contienen el SSID de dicha red. El filtrado de tales SSID puede ser ventajoso, ya que no tienen valor para nosotros y pueden provocar un aumento en la carga del socket. Filtrar estos SSID no solo reducirá la carga en las conexiones de socket, sino que también evitará el spam de los SSID mencionados en la interfaz web.
Al usar esta función, deberá realizar pequeños ajustes en el código fuente. Concretamente, deberá actualizar la lista SSID_FILTER en el archivo settings.py con el valor que desea que el Sniffer ignore. Una vez actualizado, reconstruya el proyecto e inicie PNLS.
Este proyecto utiliza una arquitectura basada en eventos (EDA), diseñada sobre arquitecturas basadas en mensajes. Si bien este proyecto utiliza una solución centralizada (todo se ejecuta desde la RPi), debido a componentes débilmente acoplados como resultado del uso de EDA, es posible crear una solución descentralizada si es necesario. PNLS consta de un publicador de eventos (sniffer), un consumidor de eventos (aplicación web) y un canal de eventos. Aquí, el canal de eventos se implementa como Middleware Orientado a Mensajes (MOM).
Fig. 6: Diagrama de despliegue del sistema PNLS
La Interfaz de Puerta de Enlace de Servidor Asíncrono (ASGI) proporciona una interfaz estandarizada entre servidores web Python con capacidad asíncrona y servicios [4]. Se eligió ASGI debido a la necesidad del proyecto de una conexión WebSocket de larga duración para facilitar las comunicaciones asíncronas entre diferentes clientes. Además, también permite la utilización de corrutinas en segundo plano durante las llamadas API. PNLS utiliza la implementación uvicorn para Python con el fin de usar el servidor web ASGI.
Mediante el uso del protocolo de comunicación WebSocket, podemos facilitar la comunicación bidireccional full-duplex. Si bien este proyecto no necesita comunicación bidireccional, sí necesita interacción en tiempo real entre los componentes del sistema. De esta manera, los datos olfateados estarán disponibles para el usuario final tan pronto como sean capturados.
El MOM del proyecto se realiza a través del Message Broker usando Redis. En el modelo de publicación-suscripción (pub-sub), el Sniffer es responsable de producir mensajes, mientras que la aplicación web (suscriptor) se registra para el Tópico específico (canal de Redis). Cuando el Sniffer envía un mensaje a un Tópico, se distribuye a todos los consumidores suscritos, permitiendo una comunicación asíncrona y escalable. PNLS utiliza el protocolo de mensajería ligero Redis Pub/Sub para la difusión de mensajes con el fin de propagar mensajes de corta duración con baja latencia y alto rendimiento [5][6]. De esta manera, se han evitado las sobrecargas asociadas con la codificación de estructuras de datos en una forma que pueda escribirse en un disco. Al hacerlo, esta solución tendrá potencialmente un mejor rendimiento [7]. La siguiente figura muestra la actividad simplificada del sistema a través del flujo de trabajo basado en eventos.
Fig. 7: Diagrama de secuencia del modelo Pub-Sub de PNLS
[!NOTE] El MOM implementado no proporciona almacenamiento persistente ni una cola de mensajes para la acumulación de datos, lo que significa que los mensajes se perderán si se publican en un Tópico sin suscriptores.
A continuación se muestra un ejemplo de una interfaz web que muestra SSID de prueba publicados.
Fig. 8: Web PNLS - ejemplo con SSID de prueba
Un Identificador de Conjunto de Servicios (SSID) es un ID 802.11 utilizado para nombrar una red Wi-Fi que consta de un máximo de 32 caracteres que pueden contener letras, números y caracteres especiales sensibles a mayúsculas y minúsculas, sin exceder los 32 caracteres. ↩
Una Lista de Redes Preferidas es una colección de SSID guardados con configuraciones adicionales que creó la primera vez que conectó su dispositivo a esas redes. ↩
Broadcom nunca admitió oficialmente el modo monitor, lo que limitó la utilidad de las tarjetas inalámbricas en los dispositivos Raspberry Pi [8]. El proyecto Nexmon es un parche de firmware para los chips Broadcom utilizados en dispositivos RPi [1]. Este parche le permitirá usar el modo monitor en su dispositivo RPi. ↩
El Framework de Parcheo de Firmware basado en C para Chips Wi-Fi Broadcom/Cypress que permite el Modo Monitor, la Inyección de Tramas y mucho más. ↩
| PNL | Lista de Redes Preferidas |
| PNLS | Sniffer de Lista de Redes Preferidas |
| SSID | Identificador de Conjunto de Servicios |
| UI | Interfaz de Usuario |
| RPi | Raspberry Pi |
| OS | Sistema Operativo |
| AP | Puntos de Acceso |
| RF | Radio Frecuencia |
| EDA | Arquitectura Basada en Eventos |
| MOM | Middleware Orientado a Mensajes |
| ASGI | Interfaz de Puerta de Enlace de Servidor Asíncrono |
| pub-sub | publicación-suscripción |