aleksamcode/preferred-network-list-snifferUma ferramenta de reconhecimento para capturar e exibir SSIDs da Lista de Redes Preferidas do dispositivo.
Preferred Network List Sniffer (PNLS) é uma ferramenta de auditoria Wi-Fi da Red Team com uma interface web simples, capaz de interceptar SSIDs1 da lista de redes preferidas (PNL)2 do dispositivo. Isso é feito capturando Probe Requests nas proximidades, que são então analisados para obter SSID e outras informações e, finalmente, propagados para a interface web. A motivação principal deste projeto foi investigar os Probe Requests 802.11 e os riscos de privacidade associados aos dados que eles transmitem.
Fig. 1: Visão geral do sistema PNLS
[!WARNING] Todo o conteúdo deste projeto é destinado apenas para fins de pesquisa em segurança.
[!NOTE]
Este projeto faz parte da minha pesquisa em andamento sobre Proteção de Privacidade em Redes Wi-Fi.
Para acompanhar o trabalho em andamento no PNLS, consulte o quadro do projeto.
Aqui está o que você precisará para duplicar e implantar este projeto, incluindo os componentes de hardware e software. Depois de ter seu ambiente de trabalho pronto, vá para as seções de configuração.
sudo airmon-ng start wlan0 [2].[!NOTE]
A imagem Kali usa o kernel do Re4son, que inclui os drivers para placas Wi-Fi externas e o firmware Nexmon para a placa sem fio integrada no RPi 3 e 4 [3].
Fig. 2: PNLS executando em um RPi 4 com antena externa e banco de bateria
Fig. 3: PNLS executando em um RPi 4 com uma caixa e uma antena AWUS036ACS
Fig. 4: PNLS executando em um RPi 4 com uma antena AWUS036ACM
Se você não quiser usar Docker, vá para configuração sem Docker.
Configure rapidamente uma instância de desenvolvimento:
# 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
Atualmente, imagens multi-plataforma não estão disponíveis, e o projeto suporta apenas a arquitetura ARM64v8. Baixe as imagens pré-construídas mais recentes do GitHub Container Registry e execute-as 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: para iniciar os servidores ASGI e Redis e executar os serviços necessários, veja estas instruções.
Frontend: para executar o servidor React, veja estas instruções.
Aqui está uma captura de tela quando tudo foi executado "manualmente":
Fig. 5: Captura de tela do PNLS
Probe Requests são quadros de gerenciamento 802.11 usados para conectar dispositivos aos Pontos de Acesso (AP) sem fio previamente associados. Sempre que um dispositivo tem o Wi-Fi ativado, mas não está conectado a uma rede, ele envia periodicamente uma rajada de Probe Requests contendo SSIDs de sua PNL. Esses quadros são enviados sem criptografia, e qualquer pessoa que esteja monitorando Radiofrequência (RF) pode capturá-los e lê-los. Os Probes são enviados para o endereço DA de broadcast (ff:ff:ff:ff:ff:ff). Uma vez enviados, o dispositivo inicia o Probe Timer. Ao final do timer, o dispositivo processa a resposta recebida. Se o dispositivo não recebeu uma resposta, ele irá para o próximo canal e repetirá o processo. Existem dois tipos de Probe Requests:
Directed Probe Requests: usando SSID específico da PNL do dispositivo
Null Probe Requests: usando Wildcard SSID (SSID vazio)
Blank Requests são enviados para obter uma resposta de todos os APs disponíveis que estão ao alcance.
Além de filtrar quadros 802.11 Probe Request de todos os pacotes capturados, o Sniffer também filtrará os Wildcard SSIDs.
Ao capturar Probe Requests em locais onde há uma grande rede local com muitos clientes Wi-Fi, o PNLS inevitavelmente capturará muitos Probe Requests que contêm o SSID da referida rede. A filtragem desses SSIDs pode ser vantajosa, pois eles não têm valor para nós e podem causar um aumento na carga dos sockets. Filtrar esses SSIDs não apenas reduzirá a carga nas conexões socket, mas também evitará o spam dos SSIDs mencionados na interface web.
Ao usar este recurso, você precisará fazer pequenos ajustes no código-fonte. Precisamente, você precisará atualizar a lista SSID_FILTER no arquivo settings.py com o valor que deseja que o Sniffer ignore. Depois de atualizado, reconstrua o projeto e inicie o PNLS.
Este projeto usa arquitetura orientada a eventos (EDA), que é projetada sobre arquiteturas orientadas a mensagens. Embora este projeto use uma solução centralizada (tudo é executado a partir do RPi), devido aos componentes fracamente acoplados como resultado do uso de EDA, é possível criar uma solução descentralizada, se necessário. O PNLS consiste em um publicador de eventos (sniffer), um consumidor de eventos (aplicação web) e um canal de eventos. Aqui, o canal de eventos é implementado como Middleware Orientado a Mensagens (MOM).
Fig. 6: Diagrama de implantação do sistema PNLS
A Asynchronous Server Gateway Interface (ASGI) fornece uma interface padronizada entre servidores web Python com capacidade assíncrona e serviços [4]. A ASGI foi escolhida devido à necessidade do projeto de uma conexão WebSocket de longa duração para facilitar comunicações assíncronas entre diferentes clientes. Além disso, também permite a utilização de corrotinas em segundo plano durante chamadas de API. O PNLS usa a implementação uvicorn para Python a fim de usar o servidor web ASGI.
Através da utilização do protocolo de comunicação WebSocket, podemos facilitar a comunicação full-duplex bidirecional. Embora este projeto não tenha a necessidade de comunicação bidirecional, ele tem a necessidade de interação em tempo real entre os componentes do sistema. Desta forma, os dados capturados estarão disponíveis para o usuário final assim que forem capturados.
O MOM do projeto é realizado através do Message Broker usando Redis. No modelo publish-subscribe (pub-sub), o Sniffer é responsável por produzir mensagens, enquanto a aplicação web (subscritor) se registra para o Tópico específico (canal Redis). Quando o Sniffer envia uma mensagem para um Tópico, ela é distribuída a todos os consumidores inscritos, permitindo uma comunicação assíncrona e escalável. O PNLS usa o protocolo de mensagens leve Redis Pub/Sub para transmissão de mensagens, a fim de propagar mensagens de curta duração com baixa latência e grande taxa de transferência [5][6]. Desta forma, as sobrecargas associadas à codificação de estruturas de dados em um formato que possa ser gravado em disco foram evitadas. Ao fazer isso, esta solução terá potencialmente melhor desempenho [7]. A figura abaixo exibe a atividade simplificada do sistema através do fluxo de trabalho orientado a eventos.
Fig. 7: Diagrama de sequência do modelo Pub-Sub do PNLS
[!NOTE] O MOM implementado não fornece armazenamento persistente ou uma fila de mensagens para acumulação de dados, o que significa que as mensagens serão perdidas se forem publicadas em um Tópico sem assinantes.
Abaixo está um exemplo de uma interface web exibindo SSIDs de teste publicados.
Fig. 8: PNLS web - exemplo com SSIDs de teste
Um Service Set Identifier (SSID) é um ID 802.11 usado para nomear uma rede Wi-Fi, consistindo de no máximo 32 caracteres que podem conter letras maiúsculas/minúsculas, números e caracteres especiais, com comprimento não superior a 32 caracteres. ↩
Uma Preferred Network List é uma coleção de SSIDs salvos com configurações adicionais que você criou na primeira vez que conectou seu dispositivo a essas redes. ↩
A Broadcom nunca suportou oficialmente o modo monitor, o que limitou a utilidade das placas sem fio em dispositivos Raspberry Pi [8]. O projeto Nexmon é um patch de firmware para os chips Broadcom em uso nos dispositivos RPi. [1]. Este patch permitirá que você use o modo monitor em seu dispositivo RPi. ↩
O C-based Firmware Patching Framework para Chips Wi-Fi Broadcom/Cypress que permite Modo Monitor, Injeção de Quadros e muito mais. ↩
| PNL | Lista de Redes Preferidas |
| PNLS | Sniffer de Lista de Redes Preferidas |
| SSID | Identificador de Conjunto de Serviço |
| UI | Interface de Usuário |
| RPi | Raspberry Pi |
| OS | Sistema Operacional |
| AP | Pontos de Acesso |
| RF | Radiofrequência |
| EDA | Arquitetura Orientada a Eventos |
| MOM | Middleware Orientado a Mensagens |
| ASGI | Asynchronous Server Gateway Interface |
| pub-sub | publicar-assinar |