aleksamcode/preferred-network-list-snifferИнструмент разведки для захвата и отображения SSID из списка предпочтительных сетей устройства.
Предпочтительный сниффер списка сетей (PNLS) — это инструмент для аудита Wi-Fi Red Team с простым веб-интерфейсом, способный перехватывать SSID1 из списка предпочтительных сетей (PNL)2 устройства. Это достигается путём сканирования Probe Request'ов в ближайшей окрестности, которые затем анализируются для получения SSID и другой информации и, наконец, передаются в веб-интерфейс. Основной мотивацией для этого проекта было исследование 802.11 Probe Request'ов и рисков для конфиденциальности, связанных с передаваемыми ими данными.
Рис. 1: Общая схема системы PNLS
[!WARNING] Все материалы в этом проекте предназначены только для целей исследования безопасности.
[!NOTE]
Этот проект является частью моих текущих исследований в области .
Чтобы отслеживать текущую работу над PNLS, смотрите доску проекта.
Вот что вам понадобится для дублирования и развёртывания этого проекта, включая аппаратные и программные компоненты. Когда ваше рабочее окружение будет готово, переходите к разделу настройка.
sudo airmon-ng start wlan0 [2].[!NOTE]
Образ Kali использует ядро Re4son, которое включает драйверы для внешних Wi-Fi-карт и прошивку Nexmon для встроенной беспроводной карты на RPi 3 и 4 [3].
Рис. 2: PNLS, работающий на RPi 4 с внешней антенной и внешним аккумулятором
Рис. 3: PNLS, работающий на RPi 4 в корпусе с антенной AWUS036ACS
Рис. 4: PNLS, работающий на RPi 4 с антенной AWUS036ACM
Если вы не хотите использовать Docker, перейдите к настройке без Docker.
Быстрая настройка экземпляра для разработки:
# Сначала клонируйте этот репозиторий.
git clone https://github.com/AleksaMCode/Preferred-Network-List-Sniffer.git
# Перейдите в корневую папку проекта.
cd Preferred-Network-List-Sniffer
# Соберите образы backend и frontend.
docker compose build
# Запустите серверы backend и frontend.
docker compose up
# Перейдите в папку сниффера.
cd sniffer
# Запустите сервис Sniffer.
sudo python3 sniffer.py
В настоящее время образов для нескольких платформ нет, проект поддерживает только архитектуру ARM64v8. Загрузите последние предварительно собранные образы из реестра контейнеров GitHub и запустите их локально.
# Сначала клонируйте этот репозиторий.
git clone https://github.com/AleksaMCode/Preferred-Network-List-Sniffer.git
# Перейдите в корневую папку проекта.
cd Preferred-Network-List-Sniffer
# Загрузите предварительно собранные образы.
docker pull ghcr.io/aleksamcode/pnls-backend-ghcr:latest
docker pull ghcr.io/aleksamcode/pnls-frontend-ghcr:latest
# Запустите серверы backend и frontend.
docker compose up
# Перейдите в папку сниффера.
cd sniffer
# Запустите сервис Sniffer.
sudo python3 sniffer.py
Backend: для запуска серверов ASGI и Redis и необходимых служб смотрите эти инструкции.
Frontend: для запуска сервера React смотрите эти инструкции.
Вот скриншот, когда всё было запущено «вручную»:
Рис. 5: Скриншот PNLS
Probe Requests — это управляющие кадры 802.11, которые используются для подключения устройств к ранее ассоциированным беспроводным точкам доступа (AP). Когда устройство включает Wi-Fi, но не подключено к сети, оно периодически отправляет пачку Probe Request'ов, содержащих SSID из своего PNL. Эти кадры отправляются незашифрованными, и любой, кто осуществляет радиочастотный (RF) мониторинг, может захватить и прочитать их. Probe отправляются на широковещательный адрес DA (ff:ff:ff:ff:ff:ff). После отправки устройство запускает таймер Probe. По истечении таймера устройство обрабатывает полученный ответ. Если устройство не получило ответа, оно переходит на следующий канал и повторяет процесс. Существует два типа Probe Request'ов:
Направленные Probe Requests: используют конкретный SSID из PNL устройства
Null Probe Requests: используют шаблонный SSID (пустой SSID)
Пустые запросы отправляются, чтобы получить ответ от всех доступных AP в зоне действия.
В дополнение к фильтрации кадров 802.11 Probe Request из всех захваченных пакетов Sniffer также будет отфильтровывать шаблонные SSID.
При захвате Probe Request'ов в местах с крупной локальной сетью и большим количеством Wi-Fi-клиентов PNLS неизбежно будет захватывать много Probe Request'ов, содержащих SSID этой сети. Фильтрация таких SSID может быть полезна, так как они не представляют для нас ценности и могут увеличить нагрузку на сокеты. Отфильтровывание этих SSID не только снизит нагрузку на сокетные соединения, но и предотвратит спам упомянутых SSID в веб-интерфейсе.
При использовании этой функции вам потребуется внести небольшие изменения в исходный код. А именно, необходимо обновить список SSID_FILTER в файле settings.py, добавив значение, которое должен игнорировать Sniffer. После обновления пересоберите проект и запустите PNLS.
Этот проект использует событийно-ориентированную архитектуру (EDA), построенную поверх архитектур, управляемых сообщениями. Хотя в этом проекте используется централизованное решение (всё запускается с RPi), благодаря слабой связанности компонентов в результате использования EDA при необходимости можно создать децентрализованное решение. PNLS состоит из издателя событий (sniffer), потребителя событий (веб-приложение) и канала событий. Здесь канал событий реализован как промежуточное ПО, ориентированное на сообщения (MOM).
Рис. 6: Диаграмма развёртывания системы PNLS
Асинхронный серверный шлюзовой интерфейс (ASGI) предоставляет стандартизированный интерфейс между асинхронными Python-веб-серверами и службами [4]. ASGI был выбран из-за необходимости проекта в долгоживущем WebSocket-соединении для обеспечения асинхронного взаимодействия между разными клиентами. Кроме того, он позволяет использовать фоновые корутины во время вызовов API. PNLS использует реализацию uvicorn для Python для работы с ASGI-веб-сервером.
Благодаря использованию протокола связи WebSocket мы можем обеспечить полнодуплексную двустороннюю связь. Хотя этому проекту не нужна двусторонняя связь, ему требуется взаимодействие в реальном времени между компонентами системы. Таким образом, перехваченные данные будут доступны конечному пользователю сразу после захвата.
MOM проекта реализована через брокер сообщений на основе Redis. В модели «издатель-подписчик» (pub-sub) Sniffer отвечает за создание сообщений, а веб-приложение (подписчик) регистрируется для определённого Topic (канала Redis). Когда Sniffer отправляет сообщение в Topic, оно распространяется всем подписанным потребителям, что обеспечивает асинхронную и масштабируемую связь. PNLS использует легковесный протокол сообщений Redis Pub/Sub для широковещательной рассылки сообщений с целью распространения кратковременных сообщений с низкой задержкой и высокой пропускной способностью [5][6]. Таким образом, удаётся избежать накладных расходов, связанных с кодированием структур данных в форме, пригодной для записи на диск. Благодаря этому такое решение потенциально может обеспечить более высокую производительность [7]. На рисунке ниже показана упрощённая активность системы через событийно-ориентированный рабочий процесс.
Рис. 7: Диаграмма последовательности модели Pub-Sub в PNLS
[!NOTE] Реализованная MOM не предоставляет постоянного хранилища или очереди сообщений для накопления данных, что означает потерю сообщений, если они публикуются в Topic без подписчиков.
Ниже приведён пример веб-интерфейса, отображающего опубликованные тестовые SSID.
Рис. 8: Веб-интерфейс PNLS - пример с тестовыми SSID
| PNL | Список предпочтительных сетей |
| PNLS | Предпочтительный сниффер списка сетей |
| SSID | Идентификатор набора услуг |
| UI | Пользовательский интерфейс |
| RPi | Raspberry Pi |
| OS | Операционная система |
| AP | Точка доступа |
| RF | Радиочастота |
| EDA | Событийно-ориентированная архитектура |
| MOM | Промежуточное ПО, ориентированное на сообщения |
| ASGI | Асинхронный серверный шлюзовой интерфейс |
| pub-sub | издатель-подписчик |
Идентификатор набора услуг (SSID) — это 802.11 ID, используемый для именования сети Wi-Fi, состоящий максимум из 32 символов, которые могут содержать буквы с учётом регистра, цифры и специальные символы, длиной не более 32 символов. ↩
Список предпочтительных сетей — это коллекция сохранённых SSID с дополнительными настройками, созданная при первом подключении устройства к этим сетям. ↩
Broadcom официально никогда не поддерживал режим мониторинга, что ограничивало полезность беспроводных карт в устройствах Raspberry Pi [8]. Проект Nexmon представляет собой патч прошивки для чипов Broadcom, используемых в устройствах RPi [1]. Этот патч позволит вам использовать режим мониторинга на вашем устройстве RPi. ↩
Среда патчинга прошивки на C для чипов Broadcom/Cypress Wi-Fi, которая включает режим мониторинга, инъекцию кадров и многое другое. ↩