aleksamcode/preferred-network-list-snifferUno strumento di ricognizione per catturare e visualizzare SSID dalla Preferred Network List del dispositivo.
Sniffer della Lista di Reti Preferite (PNLS) è uno strumento di auditing Wi-Fi per Red Team con una semplice interfaccia web, in grado di intercettare gli SSID1 dalla lista delle reti preferite (PNL)2 del dispositivo. Ciò è realizzato sniffando le Probe Request nelle vicinanze, che vengono poi analizzate per estrarre SSID e altre informazioni e infine propagate nell'interfaccia web. La motivazione principale di questo progetto è stata quella di esaminare le Probe Request 802.11 e i rischi per la privacy associati ai dati che trasmettono.
Fig. 1: Panoramica del sistema PNLS
[!WARNING] Tutto il contenuto di questo progetto è destinato esclusivamente a scopi di ricerca sulla sicurezza.
[!NOTE]
Questo progetto fa parte della mia ricerca in corso sulla Protezione della Privacy nelle Reti Wi-Fi.
Per monitorare il lavoro in corso sul PNLS, consulta la bacheca del progetto.
Ecco cosa ti servirà per duplicare e distribuire questo progetto, inclusi sia i componenti hardware che software. Una volta che il tuo ambiente di lavoro è pronto, vai alla sezione di configurazione.
sudo airmon-ng start wlan0 [2].[!NOTE]
L'immagine Kali utilizza il kernel di Re4son, che include i driver per schede Wi-Fi esterne e il firmware Nexmon per la scheda wireless integrata su RPi 3 e 4 [3].
Fig. 2: PNLS in esecuzione su un RPi 4 con antenna esterna e power bank
Fig. 3: PNLS in esecuzione su un RPi 4 con custodia e antenna AWUS036ACS
Fig. 4: PNLS in esecuzione su un RPi 4 con antenna AWUS036ACM
Se non vuoi usare Docker, vai alla configurazione senza Docker.
Configura rapidamente un'istanza di sviluppo:
# First clone this repo.
git clone https://github.com/AleksaMCode/Preferred-Network-List-Sniffer.git
# Move to the project root folder.
cd Preferred-Network-List-Sniffer
# Build backend and frontend image.
docker compose build
# Bring up both the backend and the frontend server.
docker compose up
# Move into the sniffer folder.
cd sniffer
# Run the Sniffer service.
sudo python3 sniffer.py
Attualmente, le immagini multi-piattaforma non sono disponibili e il progetto supporta solo l'architettura ARM64v8. Scarica le ultime immagini precostruite dal GitHub Container Registry ed eseguile localmente.
# First clone this repo.
git clone https://github.com/AleksaMCode/Preferred-Network-List-Sniffer.git
# Move to the project root folder.
cd Preferred-Network-List-Sniffer
# Download the prebuild images.
docker pull ghcr.io/aleksamcode/pnls-backend-ghcr:latest
docker pull ghcr.io/aleksamcode/pnls-frontend-ghcr:latest
# Bring up both the backend and the frontend server.
docker compose up
# Move into the sniffer folder.
cd sniffer
# Run the Sniffer service.
sudo python3 sniffer.py
Backend: per avviare i server ASGI e Redis e per eseguire i servizi necessari, consulta queste istruzioni.
Frontend: per eseguire il server React, consulta queste istruzioni.
Ecco uno screenshot di quando tutto è stato eseguito "manualmente":
Fig. 5: Screenshot di PNLS
Le Probe Request sono frame di gestione 802.11 utilizzati per connettere i dispositivi ai punti di accesso (AP) wireless precedentemente associati. Ogni volta che un dispositivo ha il Wi-Fi attivo ma non è connesso a una rete, invia periodicamente una raffica di Probe Request contenenti gli SSID della sua PNL. Questi frame vengono inviati non crittografati e chiunque stia monitorando le Radio Frequenze (RF) può catturarli e leggerli. Le Probe vengono inviate all'indirizzo DA di broadcast (ff:ff:ff:ff:ff:ff). Una volta inviate, il dispositivo avvia il Probe Timer. Alla fine del timer, il dispositivo elabora la risposta ricevuta. Se il dispositivo non ha ricevuto risposta, passa al canale successivo e ripete il processo. Esistono due tipi di Probe Request:
Probe Request Dirette: utilizzano uno specifico SSID dalla PNL del dispositivo
Probe Request Nulle: utilizzano un SSID Wildcard (SSID vuoto)
Le richieste vuote vengono inviate per ottenere una risposta da tutti gli AP disponibili nel raggio d'azione.
Oltre a filtrare i frame di Probe Request 802.11 da tutti i pacchetti catturati, Sniffer filtrerà anche gli SSID Wildcard.
Durante la cattura delle Probe Request in luoghi dove è presente una grande rete locale con molti client Wi-Fi, PNLS catturerà inevitabilmente molte Probe Request contenenti l'SSID di detta rete. Il filtraggio di tali SSID può essere vantaggioso, poiché non hanno valore per noi e possono causare un aumento del carico sui socket. Filtrare questi SSID non solo ridurrà il carico sulle connessioni socket, ma impedirà anche lo spam degli SSID suddetti nell'interfaccia web.
Quando si utilizza questa funzione, sarà necessario apportare piccole modifiche al codice sorgente. Nello specifico, dovrai aggiornare l'elenco SSID_FILTER nel file settings.py con il valore che vuoi che Sniffer ignori. Una volta aggiornato, ricostruisci il progetto e avvia PNLS.
Questo progetto utilizza l'architettura guidata dagli eventi (EDA), progettata sopra architetture guidate dai messaggi. Sebbene questo progetto utilizzi una soluzione centralizzata (tutto viene eseguito dal RPi), grazie ai componenti debolmente accoppiati come risultato dell'uso di EDA, è possibile creare una soluzione decentralizzata se necessario. PNLS è composto da un editor di eventi (sniffer), un consumatore di eventi (applicazione web) e un canale di eventi. Qui, il canale di eventi è implementato come middleware orientato ai messaggi (MOM).
Fig. 6: Diagramma di deployment del sistema PNLS
L'Asynchronous Server Gateway Interface (ASGI) fornisce un'interfaccia standardizzata tra server web Python capaci di asincronia e servizi [4]. L'ASGI è stato scelto a causa della necessità del progetto di una connessione WebSocket di lunga durata per facilitare comunicazioni asincrone tra diversi client. Inoltre, consente anche l'utilizzo di coroutine in background durante le chiamate API. PNLS utilizza l'implementazione uvicorn per Python per utilizzare il server web ASGI.
Attraverso l'utilizzo del protocollo di comunicazione WebSocket, siamo in grado di facilitare una comunicazione full-duplex bidirezionale. Sebbene questo progetto non abbia la necessità di una comunicazione bidirezionale, ha bisogno di un'interazione in tempo reale tra i componenti del sistema. In questo modo, i dati sniffati saranno disponibili per l'utente finale non appena vengono catturati.
Il MOM del progetto è realizzato tramite Message Broker utilizzando Redis. Nel modello publish-subscribe (pub-sub), lo Sniffer è responsabile della produzione di messaggi, mentre l'applicazione web (subscriber) si registra per un Topic specifico (canale Redis). Quando lo Sniffer invia un messaggio a un Topic, viene distribuito a tutti i consumatori iscritti, consentendo una comunicazione asincrona e scalabile. PNLS utilizza il protocollo di messaggistica leggero Redis Pub/Sub per la diffusione dei messaggi, al fine di propagare messaggi di breve durata con bassa latenza e grande throughput [5][6]. In questo modo, sono stati evitati gli overhead associati alla codifica delle strutture dati in una forma che può essere scritta su disco. Così facendo, questa soluzione avrà potenzialmente prestazioni migliori [7]. La figura seguente mostra l'attività semplificata del sistema attraverso il flusso di lavoro guidato dagli eventi.
Fig. 7: Diagramma di sequenza del modello Pub-Sub di PNLS
[!NOTE] Il MOM implementato non fornisce archiviazione persistente né una coda di messaggi per l'accumulo di dati, il che significa che i messaggi andranno persi se vengono pubblicati su un Topic senza abbonati.
Di seguito è riportato un esempio dell'interfaccia web che mostra gli SSID di test pubblicati.
Fig. 8: PNLS web - esempio con SSID di test
Un Service Set Identifier (SSID) è un ID 802.11 utilizzato per nominare una rete Wi-Fi, composto da un massimo di 32 caratteri che possono includere lettere maiuscole/minuscole, numeri e caratteri speciali, con una lunghezza massima di 32 caratteri. ↩
Una Lista di Reti Preferite è una raccolta di SSID salvati con impostazioni aggiuntive, creata la prima volta che hai connesso il tuo dispositivo a quelle reti. ↩
Broadcom non ha mai supportato ufficialmente la modalità monitor, limitando l'utilità delle schede wireless nei dispositivi Raspberry Pi [8]. Il progetto Nexmon è una patch del firmware per i chip Broadcom in uso nei dispositivi RPi [1]. Questa patch ti permetterà di utilizzare la modalità monitor sul tuo dispositivo RPi. ↩
Il framework di patching del firmware basato su C per chip Wi-Fi Broadcom/Cypress che abilita la modalità monitor, l'iniezione di frame e molto altro. ↩
| PNL | Lista delle Reti Preferite |
| PNLS | Sniffer della Lista delle Reti Preferite |
| SSID | Identificatore del Set di Servizi |
| UI | Interfaccia Utente |
| RPi | Raspberry Pi |
| OS | Sistema Operativo |
| AP | Punti di Accesso |
| RF | Radio Frequenza |
| EDA | Architettura Guidata dagli Eventi |
| MOM | Middleware Orientato ai Messaggi |
| ASGI | Interfaccia Gateway del Server Asincrono |
| pub-sub | publish-subscribe |