Источник https://xss.pro
Автор evdo
Рисунок 1 – Содержимое кадра Probe Response ложной легитимной AP.
Рисунок 2 – Содержимое кадра Probe Response ложной AP.
2. Получив противоречивые ответы, клиентское устройство успешно инициирует процедуру аутентификации с легитимной AP, используя тип аутентификации Open System (см. Рисунок 3).
Рисунок 3 – Начало процедуры аутентификации STA.
3. Легитимная AP принимает аутентификацию (см. Рисунок 4).
Рисунок 4 – Ответное сообщение от легитимной AP.
4. STA отправляет запрос на ассоциацию с легитимной AP (см. Рисунок 5), которая подтверждается ответным кадром (см. Рисунок 6).
Рисунок 5 – Содержимое кадра запроса на ассоциацию.
Рисунок 6 – Ответ Assosiation Response со стороны легитимной AP.
5. Легитимной AP в адрес STA направляется первое сообщение рукопожатия, которое остается без ответа (см. Рисунок 7).
Не получив ответ от STA после трех повторных кадров, легитимная AP направляет в адрес STA пакет деаутентификации с указанием причины Reason code: 4-way handshake timeout (0x000f)(см. Рисунок 8).
Рисунок 7 – Первое сообщение рукопожатия.
Рисунок 8 – Отправка пакета деаутентификации в адрес STA.
Рисунок 9 – Циклическое прерывание подключения HP Spectre X360 (Intel 8275).
Клиентское устройство Honor V8 Pro (Magic OS 8.1):
1. В ответ на запрос Probe Request клиентского устройства со стороны легитимной и ложной AP практически одновременно производится отправка кадров Probe Response.
2. Получив эти противоречивые ответы, клиентское устройство успешно инициирует процедуру аутентификации с легитимной AP, используя тип аутентификации Open System.
3. Легитимная AP принимает аутентификацию.
4. STA отправляет запрос на ассоциацию с легитимной AP, которая подтверждается ответным кадром.
5. Этапы 2-4 повторяются циклически, не позволяя STA подключиться к легитимной AP (см. Рисунок 10).
Рисунок 10 – Циклическое прерывание подключения Honor V8 Pro.
Результаты анализа трафика обобщены в таблице.
Атака приводит к циклическому прерыванию или полной блокировке подключения в зависимости от реализации клиентского стека.
Эти результаты дополняют выводы Vanhoef и Ronen [2], а также последующих исследований [3], которые выявили уязвимости в обработке неаутентифицированных кадров в WPA3, включая DoS через перегрузку SAE и спуфинг RSNE.
Настоящая реализация использует стандартный механизм проверки RSNE, подтверждая его уязвимость для DoS даже после патчей Wi-Fi Alliance.
В адресном варианте атаки ложная AP отвечает только целевым устройствам (из hostapd.accept), блокируя их работу и не затрагивая другие.
4. Заключение
В ходе работы рассмотрена процедура аутентификации в WPA3, включая элемент RSNE и четырехстороннее рукопожатие, а также проведен анализ ее безопасности на основе стандарта IEEE 802.11-2020.
Исследована уязвимость [2, 3], связанная с механизмом проверки RSNE со стороны клиентского устройства, что позволяет проводить атаки типа «DoS» путем имитации ложных кадров Beacon и Probe Response с несогласованными параметрами безопасности, приводя к прерыванию подключения.
Для эксплуатации уязвимости предложен метод реализации ложной точки доступа с использованием модифицированной версии сервиса hostapd в ОС Linux.
Экспериментальная проверка подтвердила возможность проведения атаки на всех устройствах тестового стенда, с вариативностью поведения: на некоторых устройствах атака приводит к циклическому прерыванию на этапе рукопожатия или ассоциации, на других — к блокировке инициации аутентификации без дальнейшего обмена.
Атака «DoS» эффективна в общем и адресном вариантах, что дополняет существующие подходы [3] за счёт модификации hostapd и тестирования на современных устройствах.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1] IEEE Std 802.11-2020. IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems Local and Metropolitan Area Networks—Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. The Institute of Electrical and Electronics Engineers, Inc., 2020.
[2] Vanhoef M., Ronen E. Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd. IEEE Symposium on Security and Privacy (SP), 2020.
[3] Zehl S., Zubow A., Wolisz A. A Wireless Intrusion Detection System for 802.11 WPA3 Networks. 2021.
Автор evdo
WPA3 – используем процедуру защиты в качестве уязвимости.
1. Введение
Процесс подключения к сети Wi-Fi клиентского устройства (STA) начинается с обнаружения доступных сетей. В общем случае точка доступа (AP) периодически транслирует кадры Beacon, содержащие информацию о сети, включая SSID (идентификатор сети), BSSID (идентификатор точки доступа) и элемент RSNE (Robust Security Network Element).
Согласно стандарту IEEE 802.11-2020 (раздел 9.4.2.25), RSNE — это информационный элемент (ID 48), который позволяет STA и AP согласовать наивысший уровень безопасности из поддерживаемых.
Элемент RSNE включается в управляющие кадры, такие как Beacon, Probe Response, Association Request/Response, а также в кадры EAPOL-Key и содержит информацию о поддерживаемых механизмах безопасности сети, включая:
В первом сообщении рукопожатия AP сообщает в адрес STA параметр ANonce и, при необходимости, элемент RSNE для подтверждения параметров безопасности.
В ответ STA должен отправить второе сообщение рукопожатия, содержащее SNonce, MIC (Message Integrity Code) и собственный RSNE.
AP сравнивает полученный RSNE с тем, что STA указала в кадре Association Request и со своими параметрами. В случае несоответствия (например, указывает неподдерживаемый AKMP, такой как PSK вместо SAE), AP прерывает рукопожатие (раздел 12.7.6.4: "The Authenticator verifies that the RSN Information Element (RSNE) received in Message 2 from the Supplicant is valid and consistent with the RSNE advertised by the Authenticator and the RSNE provided by the Supplicant in the Association Request. If there is a mismatch, the Authenticator shall abort the 4-way handshake.")
Особенностью WPA3 является то, что STA также прерывает соединение при обнаружении различий в RSNE от AP ("The Supplicant verifies that the RSN Information Element (RSNE) received in Message 1 or Message 3 from the Authenticator matches the RSNE received in the Beacon or Probe Response frame. If there is a mismatch, the Supplicant shall abort the 4-way handshake.")
Таким образом, механизм защиты стандарта может быть использован в качестве уязвимости: если атакующий обеспечит поступление на STA кадров от имени легитимной AP с различными значениями RSNE, то обмен с такой AP будет принудительно прекращен со стороны клиентского устройства.
Аналогичные уязвимости, связанные с манипуляцией неаутентифицированными кадрами в WPA3, были исследованы Vanhoef и Ronen [2], которые выявили возможность downgrade и DoS-атак через подделку параметров безопасности в фазе SAE, а также в работах по спуфингу кадров Beacon для вызова ситуации несоответствия RSNE [3].
Данная работа дополняет эти выводы, предлагая детальную практическую реализацию вектора атаки типа «отказ в обслуживании», использующего проверку RSNE в четырехстороннем рукопожатии, применимую в WPA3-only сетях, с модификацией сервиса hostapd и экспериментами на современных устройствах.
2. Реализация атаки
На основе механизма проверки RSNE со стороны STA предлагается формировать и излучать ложные пакеты типа Beacon и Probe Response с параметрами безопасности, отличными от легитимных.
Для реализации используем штатный сервис ОС Linux — hostapd (Host Access Point Daemon) — в модифицированном виде.
2.1 Компиляция модифицированной версии hostapd
Чтобы ограничить обмен ложной AP только кадрами Probe Response и предотвратить обработку запросов на аутентификацию, достаточно внести изменения в функцию “handle_auth”, которая реализует обработку входящих кадров аутентификации (подтип WLAN_FC_STYPE_AUTH кадров управления) в файле
Загрузим и распакуем исходный код сервиса hostapd актуальной версии:
Найдем функцию
Добавим
Это предотвратит любую дальнейшую обработку - функция просто выйдет, не отправляя ответ “Authentication response” и не обновляя состояние STA.
Установим зависимости:
Компилируем проект:
2.2 Формирование конфигурационного файла hostapd.
Для запуска сервиса создадим конфигурационный файл
Разберём каждый параметр из конфигурационного файла, объясним его значение и роль в контексте работы ложной точки доступа.
interface=wlxe84e6a0133b0
Указывает сетевой интерфейс, который будет использоваться для создания точки доступа (обычно соответствует физическому Wi-Fi-адаптеру).
ssid=OpenWrt3
Задаёт имя сети (Service Set Identifier, SSID), которое будет отображаться клиентам при сканировании доступных Wi-Fi-сетей.
Для атаки важно, чтобы SSID поддельной точки доступа совпадал с SSID легитимной AP. Это позволяет поддельной AP имитировать легитимную, заставляя STA подключаться к ней и получать поддельные кадры Beacon с RSNE.
beacon_int=10
Опеределяет интервал времени между отправкой кадров Beacon (1 единица = 1.024 мс).
Стандартное значение интервала составляет 100 единиц, для атаки используем минимально возможное (10), существенно увеличив вероятность обработки кадров от поддельной AP со стороны STA.
bssid=82:AF:CA:AD:49:AD
Задаёт MAC-адрес точки доступа (Basic Service Set Identifier, BSSID).
BSSID поддельной AP доджен совпадать с BSSID легитимной AP.
ignore_broadcast_ssid=1
Включает скрытие SSID (значение 0 означает, что SSID транслируется в кадрах Beacon; 1 — SSID не транслируется; 2 — SSID отправляется как пустой).
Делает атаку относительно скрытной.
macaddr_acl=0
Отключает контроль доступа STA по MAC-адресам (0 — доступ открыт для всех; 1 — используется белый список; 2 — используется чёрный список).
Используем это поле в дальнейшем для реализации адресной атаки.
hw_mode=a
Устанавливает режим работы ложной AP в диапазоне 5 ГГц (802.11a).
Если легитимная AP работает в диапазоне 5 ГГц, поддельная AP также должна использовать hw_mode=a, чтобы STA видела её сигнал в том же диапазоне.
channel=149
Определяет частотный канал ложной AP в диапазоне 5 ГГц (канал 149 соответствует частоте 5745 МГц).
Для успешной атаки поддельная AP должна работать на том же канале, что и легитимная AP (в данном случае 149), чтобы STA получала её кадры Beacon и Probe Response.
wpa=1
Включает защиту WPA (значение 1 означает WPA1; 2 — WPA2; 3 — WPA1+WPA2).
В данном случае специально выбран слабый протокол (WPA1), чтобы заставить STA выбрать его вместо WPA3, вызывая несоответствие RSNE в 4-стороннем рукопожатии и прерывание соединения.
wpa_passphrase=testtest
Задаёт пароль (pre-shared key, PSK) для WPA/WPA2. В данном случае пароль — testtest.
В атаке пароль не играет ключевой роли, так как цель — не подключение, а DoS через несоответствие RSNE.
wpa_key_mgmt=WPA-PSK
Указывает метод управления ключами (AKMP). WPA-PSK соответствует использованию pre-shared key (PSK) для WPA/WPA2. Это ключевая настройка для атаки.
rsn_pairwise=CCMP
Задаёт алгоритм шифрования для парного (unicast) трафика. CCMP — это AES-CCMP (Counter Mode with CBC-MAC Protocol), стандарт для WPA2/WPA3.
В атаке акцент на AKMP (WPA-PSK вместо SAE), а не на шифре, поэтому выбор CCMP нейтрален для атаки.
ieee80211w=2
Включает защиту управляющих кадров (Management Frame Protection, MFP). Значение 2 означает, что MFP обязательна (1 — опциональна, 0 — отключена).
Так как кадры Beacon и Probe Response не защищены MFP, настройка не оказывает влияния на атаку. В данном примере значение совпадает с дейтсвующим режимом работы легитимной AP.
2.3 Проверка аппаратных ограничений на запуск сервиса.
Для запуска hostapd на частотном канале легитимной AP необходимо предварительно убедиться, что необходимый функционал поддерживается беспроводным адаптером.
Используем команду
В приведенном примере адаптер поддерживает режим точки доступа (AP), но его вещание на частотных каналах 169, 173 и 177 в диапазоне 5 ГГц запрещено (метка “no IR”).
Такая блокировка определяется версией прошивки устройства и регуляторными ограничениями, которые при необходимости могут быть изменены посредством команды sudo iw reg set {код региона}.
3. Экспериментальная проверка атаки.
Для работы hostapd требуется ОС Linux (протестировано на Linux Mint 22.2) и сетевая Wi-Fi карта с поддержкой режима AP.
Для перехвата и дальнейшего анализа трафика между легитимной, ложной AP и атакуемым устройством дополнительно задействуем сетевую карту с поддержкой режима мониторинга (“monitor mode”).
Используем тестовый стенд, состоящий из следующего оборудования:
На легитимной AP установим режим WPA3, произвольный частотный канал и пароль.
Отредактируем файл конфигурации
Переведем адаптер EDUP AX3000 в режим мониторинга:
Подключим все клиентские устройства к легимной сети, затем выключим беспроводной интерфейс на каждом из них.
Для адресной атаки в файле конфигурации
Запустим атаку:
После этого включим беспроводной интерфейс на каждом клиентском устройстве для запуска процедуры автоматического подключения к легитимной AP.
Фиксируем сетевое состояние клиентских устройств в течение двух минут.
По истечении этого периода, в случае отсутствия подключения к сети, выполним подключение к легитимной AP вручную, выбрав сеть из списка доступных в интерфейсе ОС.
3.2 Результаты эксперимента.
В результате анализа сетевого трафика установлено следующее.
Клиентские устройства Xiaomi Poco X3 Pro (Android 13) и HP Spectre X360 (Linux Mint 22.2, Intel CNVi):
1. В ответ на запрос
При этом ответ от легитимной AP содержит элемент RSNE (см. Рисунок 1), а ответ от ложной AP содержит параметры безопасности в дополнительном IE вендора, что не противоречит стандарту (см. Рисунок 2).
Процесс подключения к сети Wi-Fi клиентского устройства (STA) начинается с обнаружения доступных сетей. В общем случае точка доступа (AP) периодически транслирует кадры Beacon, содержащие информацию о сети, включая SSID (идентификатор сети), BSSID (идентификатор точки доступа) и элемент RSNE (Robust Security Network Element).
Согласно стандарту IEEE 802.11-2020 (раздел 9.4.2.25), RSNE — это информационный элемент (ID 48), который позволяет STA и AP согласовать наивысший уровень безопасности из поддерживаемых.
Элемент RSNE включается в управляющие кадры, такие как Beacon, Probe Response, Association Request/Response, а также в кадры EAPOL-Key и содержит информацию о поддерживаемых механизмах безопасности сети, включая:
- версию RSNA;
- групповой шифр (Group Cipher Suite) для многоадресного трафика (например, CCMP-128);
- список парных шифров (Pairwise Cipher Suite List) для unicast-трафика (например, CCMP-256, GCMP-128);
- список методов аутентификации и управления ключами (AKM Suite List), такие как SAE для WPA3 или PSK для WPA2;
- возможности RSN (RSN Capabilities), включая поддержку защиты управляющих кадров (Management Frame Protection, MFP), счетчики воспроизведения и другие флаги;
- опциональные поля, такие как PMKID (Pairwise Master Key Identifier) для кэширования ключей.
В первом сообщении рукопожатия AP сообщает в адрес STA параметр ANonce и, при необходимости, элемент RSNE для подтверждения параметров безопасности.
В ответ STA должен отправить второе сообщение рукопожатия, содержащее SNonce, MIC (Message Integrity Code) и собственный RSNE.
AP сравнивает полученный RSNE с тем, что STA указала в кадре Association Request и со своими параметрами. В случае несоответствия (например, указывает неподдерживаемый AKMP, такой как PSK вместо SAE), AP прерывает рукопожатие (раздел 12.7.6.4: "The Authenticator verifies that the RSN Information Element (RSNE) received in Message 2 from the Supplicant is valid and consistent with the RSNE advertised by the Authenticator and the RSNE provided by the Supplicant in the Association Request. If there is a mismatch, the Authenticator shall abort the 4-way handshake.")
Особенностью WPA3 является то, что STA также прерывает соединение при обнаружении различий в RSNE от AP ("The Supplicant verifies that the RSN Information Element (RSNE) received in Message 1 or Message 3 from the Authenticator matches the RSNE received in the Beacon or Probe Response frame. If there is a mismatch, the Supplicant shall abort the 4-way handshake.")
Таким образом, механизм защиты стандарта может быть использован в качестве уязвимости: если атакующий обеспечит поступление на STA кадров от имени легитимной AP с различными значениями RSNE, то обмен с такой AP будет принудительно прекращен со стороны клиентского устройства.
Аналогичные уязвимости, связанные с манипуляцией неаутентифицированными кадрами в WPA3, были исследованы Vanhoef и Ronen [2], которые выявили возможность downgrade и DoS-атак через подделку параметров безопасности в фазе SAE, а также в работах по спуфингу кадров Beacon для вызова ситуации несоответствия RSNE [3].
Данная работа дополняет эти выводы, предлагая детальную практическую реализацию вектора атаки типа «отказ в обслуживании», использующего проверку RSNE в четырехстороннем рукопожатии, применимую в WPA3-only сетях, с модификацией сервиса hostapd и экспериментами на современных устройствах.
2. Реализация атаки
На основе механизма проверки RSNE со стороны STA предлагается формировать и излучать ложные пакеты типа Beacon и Probe Response с параметрами безопасности, отличными от легитимных.
Для реализации используем штатный сервис ОС Linux — hostapd (Host Access Point Daemon) — в модифицированном виде.
2.1 Компиляция модифицированной версии hostapd
Чтобы ограничить обмен ложной AP только кадрами Probe Response и предотвратить обработку запросов на аутентификацию, достаточно внести изменения в функцию “handle_auth”, которая реализует обработку входящих кадров аутентификации (подтип WLAN_FC_STYPE_AUTH кадров управления) в файле
/src/ap/ieee802_11.c .Загрузим и распакуем исходный код сервиса hostapd актуальной версии:
wget https://w1.fi/releases/hostapd-2.11.tar.gztar xzvf hostapd-2.11.tar.gzcd hostapd-2.11/hostapdНайдем функцию
handle_auth в коде.
C:
static void handle_auth(struct hostapd_data *hapd,
const struct ieee80211_mgmt *mgmt, size_t len,
int rssi, int from_queue);Добавим
return; в начало тела функции, сразу после открытия фигурных скобок.Это предотвратит любую дальнейшую обработку - функция просто выйдет, не отправляя ответ “Authentication response” и не обновляя состояние STA.
Установим зависимости:
sudo apt install pkg-config libnl-3-dev libssl-dev libnl-genl-3-devКомпилируем проект:
cd hostapd-2.11/hostapdcp defconfig .configmake -j 22.2 Формирование конфигурационного файла hostapd.
Для запуска сервиса создадим конфигурационный файл
“rsne_dos.conf” следующего содержания:
Код:
interface=wlxe84e6a0133b0
ssid=OpenWrt3
beacon_int=10
bssid=82:AF:CA:AD:49:AD
ignore_broadcast_ssid=1
macaddr_acl=0
hw_mode=a
channel=149
wpa=1
wpa_passphrase=testtest
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
ieee80211w=2Разберём каждый параметр из конфигурационного файла, объясним его значение и роль в контексте работы ложной точки доступа.
interface=wlxe84e6a0133b0
Указывает сетевой интерфейс, который будет использоваться для создания точки доступа (обычно соответствует физическому Wi-Fi-адаптеру).
ssid=OpenWrt3
Задаёт имя сети (Service Set Identifier, SSID), которое будет отображаться клиентам при сканировании доступных Wi-Fi-сетей.
Для атаки важно, чтобы SSID поддельной точки доступа совпадал с SSID легитимной AP. Это позволяет поддельной AP имитировать легитимную, заставляя STA подключаться к ней и получать поддельные кадры Beacon с RSNE.
beacon_int=10
Опеределяет интервал времени между отправкой кадров Beacon (1 единица = 1.024 мс).
Стандартное значение интервала составляет 100 единиц, для атаки используем минимально возможное (10), существенно увеличив вероятность обработки кадров от поддельной AP со стороны STA.
bssid=82:AF:CA:AD:49:AD
Задаёт MAC-адрес точки доступа (Basic Service Set Identifier, BSSID).
BSSID поддельной AP доджен совпадать с BSSID легитимной AP.
ignore_broadcast_ssid=1
Включает скрытие SSID (значение 0 означает, что SSID транслируется в кадрах Beacon; 1 — SSID не транслируется; 2 — SSID отправляется как пустой).
Делает атаку относительно скрытной.
macaddr_acl=0
Отключает контроль доступа STA по MAC-адресам (0 — доступ открыт для всех; 1 — используется белый список; 2 — используется чёрный список).
Используем это поле в дальнейшем для реализации адресной атаки.
hw_mode=a
Устанавливает режим работы ложной AP в диапазоне 5 ГГц (802.11a).
Если легитимная AP работает в диапазоне 5 ГГц, поддельная AP также должна использовать hw_mode=a, чтобы STA видела её сигнал в том же диапазоне.
channel=149
Определяет частотный канал ложной AP в диапазоне 5 ГГц (канал 149 соответствует частоте 5745 МГц).
Для успешной атаки поддельная AP должна работать на том же канале, что и легитимная AP (в данном случае 149), чтобы STA получала её кадры Beacon и Probe Response.
wpa=1
Включает защиту WPA (значение 1 означает WPA1; 2 — WPA2; 3 — WPA1+WPA2).
В данном случае специально выбран слабый протокол (WPA1), чтобы заставить STA выбрать его вместо WPA3, вызывая несоответствие RSNE в 4-стороннем рукопожатии и прерывание соединения.
wpa_passphrase=testtest
Задаёт пароль (pre-shared key, PSK) для WPA/WPA2. В данном случае пароль — testtest.
В атаке пароль не играет ключевой роли, так как цель — не подключение, а DoS через несоответствие RSNE.
wpa_key_mgmt=WPA-PSK
Указывает метод управления ключами (AKMP). WPA-PSK соответствует использованию pre-shared key (PSK) для WPA/WPA2. Это ключевая настройка для атаки.
rsn_pairwise=CCMP
Задаёт алгоритм шифрования для парного (unicast) трафика. CCMP — это AES-CCMP (Counter Mode with CBC-MAC Protocol), стандарт для WPA2/WPA3.
В атаке акцент на AKMP (WPA-PSK вместо SAE), а не на шифре, поэтому выбор CCMP нейтрален для атаки.
ieee80211w=2
Включает защиту управляющих кадров (Management Frame Protection, MFP). Значение 2 означает, что MFP обязательна (1 — опциональна, 0 — отключена).
Так как кадры Beacon и Probe Response не защищены MFP, настройка не оказывает влияния на атаку. В данном примере значение совпадает с дейтсвующим режимом работы легитимной AP.
2.3 Проверка аппаратных ограничений на запуск сервиса.
Для запуска hostapd на частотном канале легитимной AP необходимо предварительно убедиться, что необходимый функционал поддерживается беспроводным адаптером.
Используем команду
iw list:
Код:
Supported interface modes:
* managed
* AP
* AP/VLAN
* monitor
* P2P-client
* P2P-GO
* P2P-device
Frequencies:
* 5180.0 MHz [36] (23.0 dBm)
* 5200.0 MHz [40] (23.0 dBm)
* 5220.0 MHz [44] (23.0 dBm)
* 5240.0 MHz [48] (23.0 dBm)
...
* 5845.0 MHz [169] (27.0 dBm) (no IR)
* 5865.0 MHz [173] (27.0 dBm) (no IR)
* 5885.0 MHz [177] (27.0 dBm) (no IR)В приведенном примере адаптер поддерживает режим точки доступа (AP), но его вещание на частотных каналах 169, 173 и 177 в диапазоне 5 ГГц запрещено (метка “no IR”).
Такая блокировка определяется версией прошивки устройства и регуляторными ограничениями, которые при необходимости могут быть изменены посредством команды sudo iw reg set {код региона}.
3. Экспериментальная проверка атаки.
Для работы hostapd требуется ОС Linux (протестировано на Linux Mint 22.2) и сетевая Wi-Fi карта с поддержкой режима AP.
Для перехвата и дальнейшего анализа трафика между легитимной, ложной AP и атакуемым устройством дополнительно задействуем сетевую карту с поддержкой режима мониторинга (“monitor mode”).
Используем тестовый стенд, состоящий из следующего оборудования:
- точка доступа Xiaomi AX3200 (версия прошивки 1.0.8 RB01);
- клиентское устройство Nothing Phone 3A Pro (Android 15);
- клиентское устройство Xiaomi Poco X3 Pro (Android 13);
- клиентское устройство Honor V8 Pro (Magic OS 8.1);
- клиентское устройство HP Spectre X360 (Linux Mint 22.2 со встроенным адаптером Intel CNVi);
- клиентское устройство HP Spectre X360 (Linux Mint 22.2 со встроенным адаптером Intel 8275);
- iPhone 12 (iOS 18.5);
- ложная точка доступа на базе ноутбука HP Spectre X360 и двух Wi-Fi адаптеров EDUP AX3000; один адаптер используем для работы hostapd, другой – для мониторинга сетевого трафика.
На легитимной AP установим режим WPA3, произвольный частотный канал и пароль.
Отредактируем файл конфигурации
"rsne_dos.conf", указав эти параметры. В рамках эксперимента они уже известны; в других условиях параметры определяются посредством применения утилиты airodump-ng.Переведем адаптер EDUP AX3000 в режим мониторинга:
Код:
sudo ifconfig wlxe**********8 down
sudo iwconfig wlxe**********8 mode monitor
sudo ifconfig wlxe**********8 upПодключим все клиентские устройства к легимной сети, затем выключим беспроводной интерфейс на каждом из них.
Для адресной атаки в файле конфигурации
"rsne_dos.conf" укажем macaddr_acl=1 и добавим строку accept_mac_file=/etc/hostapd.accept, где hostapd.accept – файл, содержащий строки с mac-адресами целей.Запустим атаку:
sudo ./hostapd rsne_dos.conf -ddПосле этого включим беспроводной интерфейс на каждом клиентском устройстве для запуска процедуры автоматического подключения к легитимной AP.
Фиксируем сетевое состояние клиентских устройств в течение двух минут.
По истечении этого периода, в случае отсутствия подключения к сети, выполним подключение к легитимной AP вручную, выбрав сеть из списка доступных в интерфейсе ОС.
3.2 Результаты эксперимента.
В результате анализа сетевого трафика установлено следующее.
Клиентские устройства Xiaomi Poco X3 Pro (Android 13) и HP Spectre X360 (Linux Mint 22.2, Intel CNVi):
1. В ответ на запрос
Probe Request STA со стороны легитимной и ложной AP практически одновременно производится отправка кадров Probe Response.При этом ответ от легитимной AP содержит элемент RSNE (см. Рисунок 1), а ответ от ложной AP содержит параметры безопасности в дополнительном IE вендора, что не противоречит стандарту (см. Рисунок 2).
Рисунок 1 – Содержимое кадра Probe Response ложной легитимной AP.
Рисунок 2 – Содержимое кадра Probe Response ложной AP.
2. Получив противоречивые ответы, клиентское устройство успешно инициирует процедуру аутентификации с легитимной AP, используя тип аутентификации Open System (см. Рисунок 3).
Рисунок 3 – Начало процедуры аутентификации STA.
3. Легитимная AP принимает аутентификацию (см. Рисунок 4).
Рисунок 4 – Ответное сообщение от легитимной AP.
4. STA отправляет запрос на ассоциацию с легитимной AP (см. Рисунок 5), которая подтверждается ответным кадром (см. Рисунок 6).
Рисунок 5 – Содержимое кадра запроса на ассоциацию.
Рисунок 6 – Ответ Assosiation Response со стороны легитимной AP.
5. Легитимной AP в адрес STA направляется первое сообщение рукопожатия, которое остается без ответа (см. Рисунок 7).
Не получив ответ от STA после трех повторных кадров, легитимная AP направляет в адрес STA пакет деаутентификации с указанием причины Reason code: 4-way handshake timeout (0x000f)(см. Рисунок 8).
Рисунок 7 – Первое сообщение рукопожатия.
Рисунок 8 – Отправка пакета деаутентификации в адрес STA.
6. Этапы 1-5 повторяются циклически, не позволяя STA подключиться к легитимной AP.
Клиентские устройства Nothing Phone 3A Pro (Android 15), iPhone 12 (iOs 18.5) и HP Spectre X360 (Linux Mint 22.2, Intel 8275):
1. В ответ на запрос Probe Request клиентского устройства со стороны легитимной и ложной AP практически одновременно производится отправка кадров Probe Response.
2. Получив противоречивые ответы, устройство не инициирует процедуру аутентификации, уязвимость которой предполагалось использовать.
3. Этапы 1-2 повторяются циклически, не позволяя STA подключиться к легитимной AP (см. Рисунок 9).
Ручное или автоматическое подключение клиентских устройств к атакуемой сети при этом недоступно.
Клиентские устройства Nothing Phone 3A Pro (Android 15), iPhone 12 (iOs 18.5) и HP Spectre X360 (Linux Mint 22.2, Intel 8275):
1. В ответ на запрос Probe Request клиентского устройства со стороны легитимной и ложной AP практически одновременно производится отправка кадров Probe Response.
2. Получив противоречивые ответы, устройство не инициирует процедуру аутентификации, уязвимость которой предполагалось использовать.
3. Этапы 1-2 повторяются циклически, не позволяя STA подключиться к легитимной AP (см. Рисунок 9).
Ручное или автоматическое подключение клиентских устройств к атакуемой сети при этом недоступно.
Рисунок 9 – Циклическое прерывание подключения HP Spectre X360 (Intel 8275).
Клиентское устройство Honor V8 Pro (Magic OS 8.1):
1. В ответ на запрос Probe Request клиентского устройства со стороны легитимной и ложной AP практически одновременно производится отправка кадров Probe Response.
2. Получив эти противоречивые ответы, клиентское устройство успешно инициирует процедуру аутентификации с легитимной AP, используя тип аутентификации Open System.
3. Легитимная AP принимает аутентификацию.
4. STA отправляет запрос на ассоциацию с легитимной AP, которая подтверждается ответным кадром.
5. Этапы 2-4 повторяются циклически, не позволяя STA подключиться к легитимной AP (см. Рисунок 10).
Рисунок 10 – Циклическое прерывание подключения Honor V8 Pro.
Результаты анализа трафика обобщены в таблице.
Атака приводит к циклическому прерыванию или полной блокировке подключения в зависимости от реализации клиентского стека.
Эти результаты дополняют выводы Vanhoef и Ronen [2], а также последующих исследований [3], которые выявили уязвимости в обработке неаутентифицированных кадров в WPA3, включая DoS через перегрузку SAE и спуфинг RSNE.
Настоящая реализация использует стандартный механизм проверки RSNE, подтверждая его уязвимость для DoS даже после патчей Wi-Fi Alliance.
В адресном варианте атаки ложная AP отвечает только целевым устройствам (из hostapd.accept), блокируя их работу и не затрагивая другие.
| Клиентское устройство | Версия ОС | Поведение при атаке | Циклические этапы | Эффект |
| Xiaomi Poco X3 Pro | Android 13 | Инициирует аутентификацию и ассоциацию, но прерывает обмен на этапе рукопожатия | 1. Probe Response от обеих AP; 2. Аутентификация; 3. Ассоциация; 4. Handshake timeout; 5. Deauth (reason 0x000f) | Циклическое прерывание |
| HP Spectre X360 (Intel CNVi) | Linux Mint 22.2 | Аналогично Poco X3 Pro | То же | Циклическое прерывание |
| Nothing Phone 3A Pro | Android 15 | Не инициирует аутентификацию | 1. Probe Response от обеих AP; 2. Нет аутентификации. | Блокировка подключения |
| iPhone 12 | iOS 18.5 | Аналогично Nothing Phone | То же | Блокировка подключения |
| HP Spectre X360 (Intel 8275) | Linux Mint 22.2 | Аналогично Nothing Phone | То же | Блокировка подключения |
| Honor V8 Pro | Magic OS 8.1 | Инициирует аутентификацию и ассоциацию, но прерывает обмен до рукопожатия | 1. Probe Response от обеих AP; 2. Аутентификация; 3. Ассоциация; 4. Отсутствие handshake. | Циклическое прерывание |
4. Заключение
В ходе работы рассмотрена процедура аутентификации в WPA3, включая элемент RSNE и четырехстороннее рукопожатие, а также проведен анализ ее безопасности на основе стандарта IEEE 802.11-2020.
Исследована уязвимость [2, 3], связанная с механизмом проверки RSNE со стороны клиентского устройства, что позволяет проводить атаки типа «DoS» путем имитации ложных кадров Beacon и Probe Response с несогласованными параметрами безопасности, приводя к прерыванию подключения.
Для эксплуатации уязвимости предложен метод реализации ложной точки доступа с использованием модифицированной версии сервиса hostapd в ОС Linux.
Экспериментальная проверка подтвердила возможность проведения атаки на всех устройствах тестового стенда, с вариативностью поведения: на некоторых устройствах атака приводит к циклическому прерыванию на этапе рукопожатия или ассоциации, на других — к блокировке инициации аутентификации без дальнейшего обмена.
Атака «DoS» эффективна в общем и адресном вариантах, что дополняет существующие подходы [3] за счёт модификации hostapd и тестирования на современных устройствах.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1] IEEE Std 802.11-2020. IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems Local and Metropolitan Area Networks—Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. The Institute of Electrical and Electronics Engineers, Inc., 2020.
[2] Vanhoef M., Ronen E. Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd. IEEE Symposium on Security and Privacy (SP), 2020.
[3] Zehl S., Zubow A., Wolisz A. A Wireless Intrusion Detection System for 802.11 WPA3 Networks. 2021.
Последнее редактирование: