aleksamcode/preferred-network-list-snifferEin Reconnaissance-Tool zum Erfassen und Anzeigen von SSIDs aus der Liste der bevorzugten Netzwerke eines Geräts.
Sniffer für bevorzugte Netzwerklisten (PNLS) ist ein Red-Team-Wi-Fi-Auditing-Tool mit einer einfachen Web-Oberfläche, das in der Lage ist, SSIDs1 aus der bevorzugten Netzwerkliste (PNL)2 des Geräts abzufangen. Dies wird erreicht, indem Probe Requests in der nahen Umgebung gesnifft werden, die dann nach SSID und anderen Informationen durchsucht und schließlich an die Web-UI weitergegeben werden. Die Hauptmotivation für dieses Projekt war die Untersuchung von 802.11-Probe-Requests und der Datenschutzrisiken, die mit den von ihnen übertragenen Daten verbunden sind.
Abb. 1: PNLS-Systemüberblick
[!WARNING] Alle Inhalte dieses Projekts dienen ausschließlich Sicherheitsforschungszwecken.
[!NOTE]
Dieses Projekt ist Teil meiner laufenden Forschung zu Datenschutz in Wi-Fi-Netzwerken.
Um die laufenden Arbeiten am PNLS zu verfolgen, siehe das Projekt-Board.
Hier ist, was Sie benötigen, um dieses Projekt zu duplizieren und bereitzustellen, einschließlich der Hardware- und Softwarekomponenten. Sobald Ihre Arbeitsumgebung bereit ist, gehen Sie zu den Einrichtungsabschnitten.
sudo airmon-ng start wlan0 [2].[!NOTE]
Das Kali-Image verwendet den Kernel von Re4son, der die Treiber für externe Wi-Fi-Karten und die Nexmon-Firmware für die eingebaute WLAN-Karte auf dem RPi 3 und 4 enthält [3].
Abb. 2: PNLS läuft auf einem RPi 4 mit einer externen Antenne und einer Powerbank
Abb. 3: PNLS läuft auf einem RPi 4 mit einem Gehäuse und einer AWUS036ACS-Antenne
Abb. 4: PNLS läuft auf einem RPi 4 mit einer AWUS036ACM-Antenne
Wenn Sie Docker nicht verwenden möchten, gehen Sie zu Einrichtung ohne Docker.
Schnell eine Entwicklungsumgebung einrichten:
# 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
Derzeit sind keine Multi-Plattform-Images verfügbar, und das Projekt unterstützt nur die ARM64v8-Architektur. Laden Sie die neuesten vorgebauten Images aus der GitHub Container Registry herunter und führen Sie sie lokal aus.
# 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: Um den ASGI- und Redis-Server zu starten und die benötigten Dienste auszuführen, siehe diese Anleitung.
Frontend: Um den React-Server auszuführen, siehe diese Anleitung.
Hier ist ein Screenshot, als alles "manuell" ausgeführt wurde:
Abb. 5: PNLS-Screenshot
Probe Requests sind Management-802.11-Frames, die verwendet werden, um Geräte mit zuvor assoziierten drahtlosen Access Points (AP) zu verbinden. Wenn ein Gerät Wi-Fi aktiviert, aber nicht mit einem Netzwerk verbunden ist, sendet es periodisch einen Burst von Probe Requests, die SSIDs aus seiner PNL enthalten. Diese Frames werden unverschlüsselt gesendet, und jeder, der Funkfrequenz (RF) überwacht, kann sie erfassen und lesen. Probes werden an die Broadcast-DA-Adresse (ff:ff:ff:ff:ff:ff) gesendet. Nach dem Senden startet das Gerät den Probe Timer. Am Ende des Timers verarbeitet das Gerät die empfangene Antwort. Wenn das Gerät keine Antwort erhalten hat, wechselt es zum nächsten Kanal und wiederholt den Vorgang. Es gibt zwei Arten von Probe Requests:
Gezielte Probe Requests: Verwendung einer bestimmten SSID aus der PNL des Geräts
Null Probe Requests: Verwendung der Wildcard-SSID (leere SSID)
Leere Requests werden gesendet, um eine Antwort von allen verfügbaren APs in Reichweite zu erhalten.
Zusätzlich zum Filtern von 802.11-Probe-Request-Frames aus allen erfassten Paketen filtert Sniffer auch die Wildcard-SSIDs heraus.
Beim Erfassen von Probe Requests an Orten mit einem großen lokalen Netzwerk und vielen Wi-Fi-Clients wird PNLS unweigerlich viele Probe Requests erfassen, die die SSID dieses Netzwerks enthalten. Das Filtern solcher SSIDs kann vorteilhaft sein, da sie für uns wertlos sind und eine Erhöhung der Socket-Last verursachen können. Das Herausfiltern dieser SSIDs reduziert nicht nur die Last auf Socket-Verbindungen, sondern verhindert auch das Spammen der genannten SSIDs in der Web-UI.
Wenn Sie diese Funktion nutzen, müssen Sie geringfügige Anpassungen am Quellcode vornehmen. Genauer gesagt müssen Sie die Liste SSID_FILTER in der Datei settings.py mit dem Wert aktualisieren, den der Sniffer ignorieren soll. Nach der Aktualisierung bauen Sie das Projekt neu und starten den PNLS.
Dieses Projekt verwendet eine ereignisgesteuerte Architektur (Event-Driven Architecture, EDA), die auf Basis nachrichtengesteuerter Architekturen aufgebaut ist. Obwohl dieses Projekt eine zentralisierte Lösung verwendet (alles wird vom RPi ausgeführt), ist es aufgrund der lose gekoppelten Komponenten durch die Verwendung von EDA möglich, bei Bedarf eine dezentrale Lösung zu erstellen. PNLS besteht aus einem Ereignis-Herausgeber (Sniffer), einem Ereignis-Verbraucher (Webanwendung) und einem Ereignis-Kanal. Hier wird der Ereignis-Kanal als nachrichtenorientierte Middleware (Message-Oriented Middleware, MOM) implementiert.
Abb. 6: PNLS-Systembereitstellungsdiagramm
Das Asynchronous Server Gateway Interface (ASGI) bietet eine standardisierte Schnittstelle zwischen asynchron-fähigen Python-Webservern und -Diensten [4]. Das ASGI wurde gewählt, da das Projekt eine langlebige WebSocket-Verbindung benötigt, um asynchrone Kommunikation zwischen verschiedenen Clients zu ermöglichen. Darüber hinaus erlaubt es die Nutzung von Hintergrund-Coroutinen während API-Aufrufen. Der PNLS verwendet die uvicorn-Implementierung für Python, um den ASGI-Webserver zu nutzen.
Durch die Nutzung des WebSocket-Kommunikationsprotokolls können wir eine Vollduplex-Zweiwegkommunikation ermöglichen. Obwohl dieses Projekt keine Zweiwegkommunikation benötigt, besteht ein Bedarf an Echtzeit-Interaktion zwischen den Systemkomponenten. Auf diese Weise stehen die gesnifften Daten dem Endbenutzer sofort nach der Erfassung zur Verfügung.
Die MOM des Projekts wird durch den Message Broker mittels Redis realisiert. Im Publish-Subscribe-Modell (Pub-Sub) ist der Sniffer für die Erzeugung von Nachrichten verantwortlich, während die Webanwendung (Abonnent) sich für das spezifische Thema (Redis-Kanal) registriert. Wenn der Sniffer eine Nachricht an ein Thema sendet, wird sie an alle abonnierten Verbraucher verteilt, was eine asynchrone und skalierbare Kommunikation ermöglicht. PNLS verwendet das leichte Messaging-Protokoll Redis Pub/Sub für die Nachrichtenverteilung, um kurzlebige Nachrichten mit geringer Latenz und hohem Durchsatz zu verbreiten [5][6]. Auf diese Weise wurde der Overhead vermieden, der mit der Codierung von Datenstrukturen in eine Form verbunden ist, die auf eine Festplatte geschrieben werden kann. Dadurch hat diese Lösung potenziell eine bessere Leistung [7]. Die folgende Abbildung zeigt die vereinfachte Systemaktivität durch den ereignisgesteuerten Workflow.
Abb. 7: Sequenzdiagramm des PNLS Pub-Sub-Modells
[!NOTE] Die implementierte MOM bietet keine dauerhafte Speicherung oder eine Nachrichtenwarteschlange für die Datenakkumulation, was bedeutet, dass Nachrichten verloren gehen, wenn sie ohne Abonnenten an ein Thema veröffentlicht werden.
Nachfolgend ein Beispiel einer Web-UI, die veröffentlichte Test-SSIDs anzeigt.
Abb. 8: PNLS-Web – Beispiel mit Test-SSIDs
Ein Service Set Identifier (SSID) ist eine 802.11-Kennung, die zur Benennung eines Wi-Fi-Netzwerks verwendet wird; sie besteht aus maximal 32 Zeichen, die Groß- und Kleinschreibung, Zahlen und Sonderzeichen enthalten können, und ist nicht länger als 32 Zeichen. ↩
Eine bevorzugte Netzwerkliste (Preferred Network List) ist eine Sammlung gespeicherter SSIDs mit zusätzlichen Einstellungen, die Sie beim ersten Verbinden Ihres Geräts mit diesen Netzwerken erstellt haben. ↩
Das C-basierte Firmware-Patching-Framework für Broadcom/Cypress-Wi-Fi-Chips, das den Überwachungsmodus, Frame-Injection und vieles mehr ermöglicht. ↩
Broadcom hat den Überwachungsmodus nie offiziell unterstützt, was den Nutzen der WLAN-Karten in Raspberry Pi-Geräten einschränkte [8]. Das Nexmon-Projekt ist ein Firmware-Patch für die in RPi-Geräten verwendeten Broadcom-Chips [1]. Dieser Patch erlaubt die Nutzung des Überwachungsmodus auf Ihrem RPi-Gerät. ↩
| PNL | Bevorzugte Netzwerkliste |
| PNLS | Sniffer für bevorzugte Netzwerklisten |
| SSID | Service Set Identifier |
| UI | Benutzeroberfläche |
| RPi | Raspberry Pi |
| OS | Betriebssystem |
| AP | Access Points |
| RF | Funkfrequenz |
| EDA | Ereignisgesteuerte Architektur |
| MOM | Nachrichtenorientierte Middleware |
| ASGI | Asynchronous Server Gateway Interface |
| pub-sub | Publish-Subscribe |