Источник https://xss.pro
Автор evdo
1.1 Постановка задачи исследования
Рисунок 1 - Структура запроса BSS Transition Management Request.
Рисунок 2 – Структура кадра BTM Query.
Рисунок 3 – Структура элемента Neighbor Report.
Рисунок 4 – Структура поля BSSID Information.
Рисунок 5 – Структура кадра BTM Request.
Рисунок 6 – Структура кадра BTM Response.
«pos»: указатель на данные кадра BTM Request (payload после action field). Необходим для обработки полей запроса;
«end»: указатель на конец буфера. Необходим для проверки границ и предотвращения его переполнения;
«reply»: флаг, указывающий, нужно ли отправить ответ (1 для unicast, 0 для multicast). Ответ должен быть отправлен только для unicast-запросов (как требует IEEE 802.11v).
Алгоритм работы функции:
1. Проверка длины кадра.
Функция проверяет, соответствует ли длина кадра минимальному набору обязательных полей («Dialog Token», «Request Mode», «Disassociation Timer», «Validity Interval»). Если длина кадра меньше 5 байт, кадр считается некорректным, и функция завершает выполнение. Это необходимо для предотвращения обработки поврежденных или неполных кадров, что могло бы привести к ошибкам или уязвимостям.
2. Обработка заголовка запроса.
Извлекаются обязательные поля кадра: «Dialog Token» (1 байт) для идентификации сессии, «Request Mode» (1 байт) для определения типа запроса (например, наличие флагов «disassoc_imminent» или «pref_cand_list»), «Disassociation Timer» (2 байта) для указания времени до отключения, «Validity Interval» (1 байт) для определения срока действия списка кандидатов.
3. Сохранение параметров в контексте.
Параметры запроса сохраняются в структуре «wpa_s» для последующей обработки (например, в ответах или событиях). Это необходимо для хранения состояния запроса на протяжении обработки, чтобы избежать повторного парсинга.
4. Проверка поддержки BSS Transition со стороны STA.
Проверяется, отключена ли поддержка MBO/OCE или BTM в конфигурации (wpa_s->disable_mbo_oce || wpa_s->conf->disable_btm). Если отключена, функция завершает выполнение без ответа. Это необходимо для обеспечения конфигурации устройства, где BTM может быть запрещен по причинам совместимости или политики.
5. Обработка элементов поля Neighbor Report.
Если в поле «Request Mode» установлен флаг «WNM_BSS_TM_REQ_PREF_CAND_LIST_INCLUDED», список кандидатов (Neighbor Report elements) подлежит обработке.
Функция «wnm_parse_neighbor_report» извлекает данные о каждом кандидате (BSSID, канал и прочие), элементы с tag != «WLAN_EID_NEIGHBOR_REPORT» или длиной менее 13 байт игнорируются. Длина списка ограничена десятью кандидатами (определяется константой «WNM_MAX_NEIGHBOR_REPORT»).
6. Сохранение списка кандидатов.
Список кандидатов сохраняется в wpa_s->wnm_neighbor_report_elements. Это необходимо для дальнейшего анализа и выбора лучшего кандидата.
7. Проверка флага «disassoc_imminent».
Если в поле «Request Mode» установлен флаг «WNM_BSS_TM_REQ_DISASSOC_IMMINENT», клиент учитывает, что текущая точка доступа может отключить его через период времени «disassoc_timer».
Также обрабатывается поле «Session Information URL» (опциональное поле после флага, с длиной «url_len»), которое затем логируется. Если «url_len» превышает доступную длину буфера (end - pos), весь кадр игнорируется для предотвращения переполнения, что обеспечивает безопасность. Переменная «beacon_int» (интервал кадров типа Beacon текущего BSS) используется для преобразования значения «disassoc_timer» в миллисекунды.
8. Определение целесообразности перехода
В случае отсутствия кандидатов отправляется ответ WNM_BSS_TM_REJECT_NO_SUITABLE_CANDIDATES.
Если активен флаг «disassoc_imminent» и список кандидатов непустой, то производится его сортировка («wnm_sort_cand_list»), которая учитывает приоритет кандидатов, требующих немедленного перехода (значение «preference» из Neighbor Report).
Запускается сканирование эфира (функции «wnm_fetch_scan_results» или «wpa_supplicant_req_scan») для проверки актуальности списка кандидатов.
При активированном режиме «btm_offload» решение о переходе принимается внешней системой, а не модулем «wpa_supplicant».
Функция «ieee802_11_rx_bss_trans_mgmt_req» для своей работы использует следующие дополнительные функции:
- «wnm_parse_neighbor_report»: обработка списка кандидатов; - «get_ie»: получение IE для Session Information URL (необходим для поиска конкретного элемента в буфере, хотя для URL используется прямой парсинг);
5.2 Результаты второго этапа.
При помощи генератора кадров обеспечивается манипуляция роумингом устройств — они могут быть переведены на обслуживание AP в произвольном порядке, в том числе повторно. Причиной этого является уязвимость клиентских устройств, которые обрабатывают кадры BTM Request несмотря на отсутствие поддержки стандарта IEEE 802.11v со стороны легитимной AP.
5.3 Выводы по экспериментам.
1. Все клиентские устройства реагируют на кадры BTM Request независимо от поддержки легитимной AP стандарта IEEE 802.11v, что формирует уязвимость.
2. STA по-разному реагируют на ограничение выбора возможных кандидатов пустым или некорректным списком, но в любом случае не теряют соединения с легитимной AP. Таким образом, атака типа «Denial of Service» (вариант №1) на практике оказалась несостоятельной.
3. Атака «Evil Twin» может быть эффективно проведена в части принуждения STA к взаимодействию с поддельной AP. Эксплуатация URL для дальнейших вредоносных действий по причине отсутствия автоматизированной обработки поля «Session Information URL» программным обеспечением STA не представляется возможной.
3. Атака типа «Denial of Service» (вариант №2) обеспечивает принуждение произвольных STA к подключению на выбранные легитимные AP с целью их перегрузки и снижения качества услуг.
Гипотеза о потенциальном векторе атаки через поле «Session Information URL» подтверждена частично: подделка значения поля возможна, но в проверенных операционных системах его обработка не приводит к автоматической сетевой активности (HTTP-запросам), запуску браузера или отображению уведомлений.
Рисунок 7 – Содержимое кадра BTM Request для атаки «Evil Twin».
Рисунок 8 – Содержимое ответного кадра BTM Response (status_code=0).
Рисунок 9 – Содержимое кадра BTM Request с полем «Session Information URL» для атаки «Evil Twin».
Рисунок 10 – Содержимое кадра BTM Response с результатом самостоятельного поиска кандидатов клиентским устройством.
ЗАКЛЮЧЕНИЕ
В ходе работы рассмотрена процедура BSS Transition Management стандарта IEEE 802.11v, а также проведен анализ ее безопасности и обработки в операционных системах.
Выявлены уязвимости, связанные с отсутствием встроенных механизмов аутентификации и шифрования кадров BTM, что позволяет проводить атаки типа «DoS» и «Evil Twin», включая подделку поля «Session Information URL» для потенциального перенаправления на вредоносные ресурсы.
Для эксплуатации уязвимости предложен метод подделки кадров BTM Request, реализованный на языке Python.
Разработан алгоритм атаки и описаны основные этапы его реализации, включая требования к формированию кадров для прохождения проверок в wpa_supplicant.
Экспериментальная проверка подтвердила возможность проведения атаки на всех устройствах тестового стенда, за исключением случаев с некорректным списком кандидатов, где устройства игнорируют кадр или отклоняют запрос без потери соединения.
Атака «DoS» (вариант №1) оказалась несостоятельной, атака «Evil Twin» эффективна в части принуждения к роумингу, но не приводит к автоматической обработке URL.
Атака «DoS» (вариант №2) позволяет перегрузить легитимные AP.
Гипотеза о векторе атаки через поле «Session Information URL» подтверждена частично, поскольку подделка возможна, но в проверенных ОС не вызывает сетевой активности или UI-взаимодействия.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1] IEEE Std 802.11v-2011. Amendment 8: IEEE 802.11 Wireless Network Management. The Institute of Electrical and Electronics Engineers, Inc., 2011.
[2] IEEE Std 802.11r-2008. Amendment 2: Fast Basic Service Set (BSS) Transition. The Institute of Electrical and Electronics Engineers, Inc., 2008.
[3] IEEE Std 802.11ax-2021. Amendment: Enhancements for High Efficiency WLAN. The Institute of Electrical and Electronics Engineers, Inc., 2021.
[4] 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.
[5] Wi-Fi Alliance. Voice-Enterprise Certification. URL: https://www.wi-fi.org/certification/voice-enterprise.
[6] wpa_supplicant source code (version 2.11 for Linux). Hostap project. URL: https://w1.fi/wpa_supplicant/.
[7] Android Open Source Project (AOSP). wpa_supplicant_8 source code (Android 15). Files: wnm_sta.c, ieee802_11_common.c.
URL: https://android.googlesource.com/platform/external/wpa_supplicant_8/
[8] MediaTek proprietary materials (slides on BSS Transition Management Request structure). Proprietary and Confidential.
[9] Cisco Systems. Wireless Network Management with IEEE 802.11k, 802.11v, and 802.11r. Technical documentation.
URL: https://www.cisco.com/c/en/us/td/do...ement_with_ieee_80211k_80211v_and_80211r.html
[10] Aruba Networks. IEEE 802.11k/v/r Configuration Guide. URL: https://www.arubanetworks.com/techd...arubaos-solutions/802-11k-v-r/802-11k-v-r.htm
Автор evdo
Исследование уязвимостей процедуры BSS Transition Management стандарта IEEE 802.11v.
1. ВведениеСтандарты IEEE 802.11k (управление радиоресурсами), 802.11r (быстрый роуминг) и 802.11v (управление беспроводными сетями) разработаны для оптимизации работы Wi-Fi-сетей в сценариях с высокой плотностью устройств или мобильностью, таких как корпоративные сети, общественные места (аэропорты, торговые центры) и сети операторов связи. Эти стандарты обеспечивают улучшенное управление радиоресурсами, ускоренный роуминг и эффективное переключение между точками доступа (BSS Transition Management), что особенно важно для технологий, таких как Voice over Wi-Fi (VoWiFi) и сертификации Wi-Fi Alliance Voice-Enterprise.
В бытовых сетях, где обычно используется одна точка доступа, преимущества IEEE 802.11k/r/v, такие как ускорение роуминга или балансировка нагрузки, менее заметны. Например, переключение между точками доступа в домашней сети занимает около 5 секунд без применения стандарта IEEE 802.11r, тогда как с его использованием время сокращается до 100 миллисекунд (IEEE 802.11r-2008). Для повседневных задач, таких как просмотр веб-страниц или потоковое видео, эта разница незначительна, что снижает интерес к детальному изучению этих стандартов в бытовом контексте.
Академическая литература часто сосредотачивается на новейших стандартах, таких как 802.11ax (Wi-Fi 6) и 802.11be (Wi-Fi 7), или на фундаментальных аспектах беспроводных сетей, таких как пропускная способность, задержки и энергоэффективность (IEEE 802.11ax-2021). Стандарты IEEE 802.11k/r/v, принятые в 2008–2011 годах, считаются зрелыми и широко внедрены в устройства, включая смартфоны Apple (начиная с iOS 6/7), устройства на базе Windows 10, а также чипы Qualcomm, Broadcom и MediaTek (Wi-Fi Alliance Voice-Enterprise). Основная информация о развертывании и настройке этих стандартов содержится в технических блогах и документации вендоров, таких как Cisco и Aruba Networks, поскольку их настройка в корпоративных сценариях требует специализированных знаний.
Несмотря на нишевость применения в бытовых условиях, стандарты IEEE 802.11k/r/v реализованы практически во всех современных устройствах, включая смартфоны, ноутбуки и роутеры. Это обеспечивает совместимость с корпоративными сетями, повышает качество обслуживания VoWiFi и поддерживает сценарии с высокой плотностью устройств.
В бытовых сетях, где обычно используется одна точка доступа, преимущества IEEE 802.11k/r/v, такие как ускорение роуминга или балансировка нагрузки, менее заметны. Например, переключение между точками доступа в домашней сети занимает около 5 секунд без применения стандарта IEEE 802.11r, тогда как с его использованием время сокращается до 100 миллисекунд (IEEE 802.11r-2008). Для повседневных задач, таких как просмотр веб-страниц или потоковое видео, эта разница незначительна, что снижает интерес к детальному изучению этих стандартов в бытовом контексте.
Академическая литература часто сосредотачивается на новейших стандартах, таких как 802.11ax (Wi-Fi 6) и 802.11be (Wi-Fi 7), или на фундаментальных аспектах беспроводных сетей, таких как пропускная способность, задержки и энергоэффективность (IEEE 802.11ax-2021). Стандарты IEEE 802.11k/r/v, принятые в 2008–2011 годах, считаются зрелыми и широко внедрены в устройства, включая смартфоны Apple (начиная с iOS 6/7), устройства на базе Windows 10, а также чипы Qualcomm, Broadcom и MediaTek (Wi-Fi Alliance Voice-Enterprise). Основная информация о развертывании и настройке этих стандартов содержится в технических блогах и документации вендоров, таких как Cisco и Aruba Networks, поскольку их настройка в корпоративных сценариях требует специализированных знаний.
Несмотря на нишевость применения в бытовых условиях, стандарты IEEE 802.11k/r/v реализованы практически во всех современных устройствах, включая смартфоны, ноутбуки и роутеры. Это обеспечивает совместимость с корпоративными сетями, повышает качество обслуживания VoWiFi и поддерживает сценарии с высокой плотностью устройств.
1.1 Постановка задачи исследования
В ходе анализа материалов компании MediaTek, помеченных как “Proprietary and Confidential”, обнаружен слайд, содержащий подробную информацию о структуре запроса BSS Transition Management Request стандарта IEEE 802.11v (IEEE 802.11v-2011). Особое внимание привлекло поле Session Information URL, выделенное зеленым цветом, которое содержит HTTP-ссылку на сетевой ресурс производителя (см. Рисунок 1).
Предполагается, что обработка этого поля клиентским устройством может инициировать сетевую активность, например, автоматический HTTP-запрос к указанному ресурсу, запуск браузера или отображение уведомления пользователю.
Предполагается, что обработка этого поля клиентским устройством может инициировать сетевую активность, например, автоматический HTTP-запрос к указанному ресурсу, запуск браузера или отображение уведомления пользователю.
Рисунок 1 - Структура запроса BSS Transition Management Request.
Такая функциональность потенциально может быть использована как вектор атаки, включая, но не ограничиваясь:
– перенаправление на поддельный сайт для кражи учетных данных;
– выполнение вредоносного кода: запуск JavaScript или другого кода через браузер;
– DoS-атаки: перегрузка устройства или сети за счет многократных запросов к ресурсу.
Для проверки этой гипотезы предлагается исследовать следующие вопросы:
1. Возможность вмешательства в процедуру BSS Transition Management.
Может ли атакующий инициировать или сбросить процедуру BSS Transition Management на клиентском устройстве, используя поддельные кадры или манипуляции с точкой доступа?
2. Подделка значения поля Session Information URL.
Возможно ли внедрение вредоносной ссылки в поле Session Information URL кадра BSS Transition Management Request? Какие механизмы аутентификации или проверки применяются для предотвращения подделки?
3. Анализ обработки поля Session Information URL в операционных системах Android и Linux.
Как программный модуль wpa_supplicant обрабатывает поле Session Information URL? Анализ будет проведен на основе открытого исходного кода wpa_supplicant. Как формировать кадры для атаки?
4. Разработка инструмента для атаки – генератора кадров нужного формата.
5. Экспериментальная проверка на Android, iOS, Windows и Linux.
Как операционные системы iOS и Windows обрабатывают поле Session Information URL? Поскольку их Wi-Fi-стеки являются закрытыми, проверка будет выполнена только экспериментально. Проверка атаки на реальных устройствах Android и Linux с учетом полученной по п.3 информации с использованием анализа сетевого трафика (например, с помощью инструмента Wireshark).
2. Исследование возможности вмешательства в процедуру BSS Transition Management со стороны третьих лиц.– перенаправление на поддельный сайт для кражи учетных данных;
– выполнение вредоносного кода: запуск JavaScript или другого кода через браузер;
– DoS-атаки: перегрузка устройства или сети за счет многократных запросов к ресурсу.
Для проверки этой гипотезы предлагается исследовать следующие вопросы:
1. Возможность вмешательства в процедуру BSS Transition Management.
Может ли атакующий инициировать или сбросить процедуру BSS Transition Management на клиентском устройстве, используя поддельные кадры или манипуляции с точкой доступа?
2. Подделка значения поля Session Information URL.
Возможно ли внедрение вредоносной ссылки в поле Session Information URL кадра BSS Transition Management Request? Какие механизмы аутентификации или проверки применяются для предотвращения подделки?
3. Анализ обработки поля Session Information URL в операционных системах Android и Linux.
Как программный модуль wpa_supplicant обрабатывает поле Session Information URL? Анализ будет проведен на основе открытого исходного кода wpa_supplicant. Как формировать кадры для атаки?
4. Разработка инструмента для атаки – генератора кадров нужного формата.
5. Экспериментальная проверка на Android, iOS, Windows и Linux.
Как операционные системы iOS и Windows обрабатывают поле Session Information URL? Поскольку их Wi-Fi-стеки являются закрытыми, проверка будет выполнена только экспериментально. Проверка атаки на реальных устройствах Android и Linux с учетом полученной по п.3 информации с использованием анализа сетевого трафика (например, с помощью инструмента Wireshark).
Может ли атакующий инициировать или сбросить процедуру на клиентском устройстве, используя поддельные кадры или манипуляции с точкой доступа?
BSS Transition Management (далее - BTM) – это механизм, определённый в стандарте IEEE 802.11v, который используется в беспроводных сетях Wi-Fi для оптимизации процесса роуминга (переключения устройства между точками доступа, AP) и управления нагрузкой в сети.
Цель процедуры – обеспечить быстрый и плавный переход между наборами BSS в пределах одной сервисной зоны ESS.
Аббревиатура BSS в стандарте IEEE 802.11 расшифровывается как «Basic Service Set» базовый набор услуг). BSS представляет собой совокупность устройств (станций - STA), которые взаимодействуют друг с другом через точку доступа (Access Point, далее - AP) или напрямую (в случае ad-hoc сетей). BSS является основой для построения более сложных сетей, таких как ESS (Extended Service Set), когда несколько BSS объединяются через общую сетевую инфраструктуру.
2.1 Алгоритм работы процедуры и используемые кадрыBSS Transition Management (далее - BTM) – это механизм, определённый в стандарте IEEE 802.11v, который используется в беспроводных сетях Wi-Fi для оптимизации процесса роуминга (переключения устройства между точками доступа, AP) и управления нагрузкой в сети.
Цель процедуры – обеспечить быстрый и плавный переход между наборами BSS в пределах одной сервисной зоны ESS.
Аббревиатура BSS в стандарте IEEE 802.11 расшифровывается как «Basic Service Set» базовый набор услуг). BSS представляет собой совокупность устройств (станций - STA), которые взаимодействуют друг с другом через точку доступа (Access Point, далее - AP) или напрямую (в случае ad-hoc сетей). BSS является основой для построения более сложных сетей, таких как ESS (Extended Service Set), когда несколько BSS объединяются через общую сетевую инфраструктуру.
Процедура BTM предусматривает три типа кадров для обмена информацией между точкой доступа (AP) и клиентским устройством (STA): BTM Query, BTM Request и BTM Response. Они используются в зависимости от сценария (инициатива клиента или сети) и этапа процедуры.
1. Инициация процедуры (тип «Solicited» или «Unsolicited»).
Процедура BTM может быть инициирована либо клиентом (тип «Solicited»), либо сетью (тип «Unsolicited»). На этом этапе используются следующие кадры:
а) BTM Query («Solicited»).
Клиент (STA) инициирует процедуру при ухудшении качества соединения и отправляет в адрес запрос AP на предоставление списка AP, доступных для перехода.
б) BTM Request.
Если процедура инициирована сетью («Unsolicited») для балансировки нагрузки или в случае, если планируется отключение BSS, то AP направляет запрос в адрес STA без предварительного кадра BTM Query. В противном случае – в ответ на указанный кадр.
2. Ответ клиента.
Клиентское устройство анализирует полученный кадр BTM Request и принимает решение о переходе. На этом этапе используется кадр BTM Response, которым клиент подтверждает или отклоняет предложение о переходе.
3. Выполнение перехода.
После получения AP кадра BTM Response (или без него, если STA решает перейти на AP самостоятельно), клиент выполняет реассоциацию с новой AP.
На этом этапе используется стандартные кадры IEEE 802.11:
а) Reassociation Request.
Запрос STA на реассоциацию, содержит информацию об аутентификации и текущем соединении.
б) Reassociation Response.
Целевая AP подтверждает или отклоняет реассоциацию.
4. Завершение перехода или отказ.
Если STA принято решение о переходе, то никаких дополнительных кадров не требуется. В противном случае AP может повторить отправку кадра BTM Request с обновленными параметрами или принудительно отключить клиента при помощи кадра Disassociation Frame.
2.2 Описание полей кадра BTM Query.1. Инициация процедуры (тип «Solicited» или «Unsolicited»).
Процедура BTM может быть инициирована либо клиентом (тип «Solicited»), либо сетью (тип «Unsolicited»). На этом этапе используются следующие кадры:
а) BTM Query («Solicited»).
Клиент (STA) инициирует процедуру при ухудшении качества соединения и отправляет в адрес запрос AP на предоставление списка AP, доступных для перехода.
б) BTM Request.
Если процедура инициирована сетью («Unsolicited») для балансировки нагрузки или в случае, если планируется отключение BSS, то AP направляет запрос в адрес STA без предварительного кадра BTM Query. В противном случае – в ответ на указанный кадр.
2. Ответ клиента.
Клиентское устройство анализирует полученный кадр BTM Request и принимает решение о переходе. На этом этапе используется кадр BTM Response, которым клиент подтверждает или отклоняет предложение о переходе.
3. Выполнение перехода.
После получения AP кадра BTM Response (или без него, если STA решает перейти на AP самостоятельно), клиент выполняет реассоциацию с новой AP.
На этом этапе используется стандартные кадры IEEE 802.11:
а) Reassociation Request.
Запрос STA на реассоциацию, содержит информацию об аутентификации и текущем соединении.
б) Reassociation Response.
Целевая AP подтверждает или отклоняет реассоциацию.
4. Завершение перехода или отказ.
Если STA принято решение о переходе, то никаких дополнительных кадров не требуется. В противном случае AP может повторить отправку кадра BTM Request с обновленными параметрами или принудительно отключить клиента при помощи кадра Disassociation Frame.
Структура кадра состоит из фиксированных полей и информационных элементов (IE, Information Elements), представленных на Рисунке 2.
Рисунок 2 – Структура кадра BTM Query.
1. Category (1 байт)
Определяет категорию кадра Action. Для WNM это значение всегда 10 (0x0a).
2. Action (1 байт)
Определяет тип действия в категории WNM. Для кадра BTM Query значение равно 6 (0x06).
3. Dialog Token (1 байт)
Уникальный идентификатор, который позволяет STA сопоставить ответ AP с конкретным запросом.
4. BSS Transition Query Reason (1 байт)
Определяет причину запроса.
Возможные значения следующие:
"0" – причина неопределена;
"1" – существенная потеря кадров и/или плохие радиоусловия;
"2" – существенная задержка для текущих потоков трафика;
"3" – неудовлетворительная емкость QoS для текущих потоков трафика;
"4" – первичная ассоциация с ESS;
"5" – балансировка нагрузки;
"6" – обнаружена AP лучше текущей;
"7" – деаутентифицирован или деассоциирован предыдущей AP;
"8" – аутентификация IEEE 802.1X EAP отклонена AP;
"9" – четырехстороннее рукопожатие отклонено AP;
"10" – получено слишком много отказов для replay counter;
"11" – получено слишком много отказов для MIC;
"12" – превышено максимальное количество попыток повторных передач;
"13" – получено слишком много широковещательных деассоциаций;
"14" – получено слишком много широковещательных деаутентификаций;
"15" – предыдущий переход окончился неудачно;
"16" – низкий уровень сигнала RSSI;
"17" – роуминг из системы IEEE 802.11;
"18" – переход по причине получения кадра BSS Transition Request от AP;
"19" – перечень кандидатов BSS transition прилагается;
"20" – STA покидает ESS;
"21 - 255" – зарезервированы для дальнейшего использования.
5. BSS Transition Candidate List Entries (0 байт или переменной длины)
Опциональный список, содержащий информацию в отношении AP, выявленных STA по результатам сканирования и предлагаемых в качестве кандидатов для перехода.
Каждый элемент списка представляет собой информационный элемент Neighbor Report, содержащий (см. Рисунок 3):
Element ID (1 байт) – идентификатор элемента (значение 52).
Length (1 байт) – длина массива данных элемента.
BSSID (6 байт) – адрес AP BSS, на которую рекомендуется перейти.
BSSID Information (4 байта) - дополнительная информация о целевой AP BSS, включая её возможности, достижимость, безопасность и другие характеристики. Это помогает AP оценить, насколько подходящей является рекомендуемая BSS для перехода.
Определяет категорию кадра Action. Для WNM это значение всегда 10 (0x0a).
2. Action (1 байт)
Определяет тип действия в категории WNM. Для кадра BTM Query значение равно 6 (0x06).
3. Dialog Token (1 байт)
Уникальный идентификатор, который позволяет STA сопоставить ответ AP с конкретным запросом.
4. BSS Transition Query Reason (1 байт)
Определяет причину запроса.
Возможные значения следующие:
"0" – причина неопределена;
"1" – существенная потеря кадров и/или плохие радиоусловия;
"2" – существенная задержка для текущих потоков трафика;
"3" – неудовлетворительная емкость QoS для текущих потоков трафика;
"4" – первичная ассоциация с ESS;
"5" – балансировка нагрузки;
"6" – обнаружена AP лучше текущей;
"7" – деаутентифицирован или деассоциирован предыдущей AP;
"8" – аутентификация IEEE 802.1X EAP отклонена AP;
"9" – четырехстороннее рукопожатие отклонено AP;
"10" – получено слишком много отказов для replay counter;
"11" – получено слишком много отказов для MIC;
"12" – превышено максимальное количество попыток повторных передач;
"13" – получено слишком много широковещательных деассоциаций;
"14" – получено слишком много широковещательных деаутентификаций;
"15" – предыдущий переход окончился неудачно;
"16" – низкий уровень сигнала RSSI;
"17" – роуминг из системы IEEE 802.11;
"18" – переход по причине получения кадра BSS Transition Request от AP;
"19" – перечень кандидатов BSS transition прилагается;
"20" – STA покидает ESS;
"21 - 255" – зарезервированы для дальнейшего использования.
5. BSS Transition Candidate List Entries (0 байт или переменной длины)
Опциональный список, содержащий информацию в отношении AP, выявленных STA по результатам сканирования и предлагаемых в качестве кандидатов для перехода.
Каждый элемент списка представляет собой информационный элемент Neighbor Report, содержащий (см. Рисунок 3):
Element ID (1 байт) – идентификатор элемента (значение 52).
Length (1 байт) – длина массива данных элемента.
BSSID (6 байт) – адрес AP BSS, на которую рекомендуется перейти.
BSSID Information (4 байта) - дополнительная информация о целевой AP BSS, включая её возможности, достижимость, безопасность и другие характеристики. Это помогает AP оценить, насколько подходящей является рекомендуемая BSS для перехода.
Рисунок 3 – Структура элемента Neighbor Report.
Поле BSSID Information (см. Рисунок 4) разделено на несколько субполей, каждое из которых описывает определённые характеристики BSS:
Рисунок 4 – Структура поля BSSID Information.
AP Reachability (Биты 0 - 1)
Определяет доступность подключения к AP:
"0" – значение зарезервировано (не используется);
"1" – AP недоступна;
"2" – доступность AP неизвестна;
"3" – AP доступна для подключения через текущий BSS.
Security (Бит 2):
"0" – политика безопасности отличается от текущей AP.
"1" – политика безопасности совпадает.
Key Scope (Бит 3):
"1" – AP, представленный текущим BSSID, имеет идентичный аутентификатор, что и кандидат для перехода.
"0" – не имеет.
Capabilities (Бит 4):
"0" – дополнительные возможности не поддерживаются (например, QoS, Spectrum Management).
"1" – поддерживаются дополнительные возможности, указанные в других полях Neighbor Report.
Mobility Domain (Бит 5):
"0" – целевой BSS не принадлежит тому же домену мобильности (Mobility Domain), что текущий BSS.
"1" – BSS принадлежит тому же домену мобильности, что упрощает быстрый роуминг (например, с использованием IEEE 802.11r).
High Throughput (Бит 6):
"0" – BSS не поддерживает IEEE 802.11n (HT).
"1" – BSS поддерживает IEEE 802.11n.
Very High Throughput (Бит 7):
"0" – BSS не поддерживает IEEE 802.11ac (VHT).
"1" – BSS поддерживает IEEE 802.11ac.
FTM (Бит 8):
"0" – BSS не поддерживает Fine Timing Measurement (IEEE 802.11mc).
"1" – BSS поддерживает FTM, что позволяет проводить точные измерения расстояния.
High Efficiency (Бит 9):
"0" – BSS не поддерживает IEEE 802.11ax (HE).
"1" – BSS поддерживает IEEE 802.11ax.
Зарезервировано (Биты 10 - 31).
Биты зарезервированы для будущих расширений и должны быть установлены в "0".
2.3 Описание полей кадра BTM Request.Определяет доступность подключения к AP:
"0" – значение зарезервировано (не используется);
"1" – AP недоступна;
"2" – доступность AP неизвестна;
"3" – AP доступна для подключения через текущий BSS.
Security (Бит 2):
"0" – политика безопасности отличается от текущей AP.
"1" – политика безопасности совпадает.
Key Scope (Бит 3):
"1" – AP, представленный текущим BSSID, имеет идентичный аутентификатор, что и кандидат для перехода.
"0" – не имеет.
Capabilities (Бит 4):
"0" – дополнительные возможности не поддерживаются (например, QoS, Spectrum Management).
"1" – поддерживаются дополнительные возможности, указанные в других полях Neighbor Report.
Mobility Domain (Бит 5):
"0" – целевой BSS не принадлежит тому же домену мобильности (Mobility Domain), что текущий BSS.
"1" – BSS принадлежит тому же домену мобильности, что упрощает быстрый роуминг (например, с использованием IEEE 802.11r).
High Throughput (Бит 6):
"0" – BSS не поддерживает IEEE 802.11n (HT).
"1" – BSS поддерживает IEEE 802.11n.
Very High Throughput (Бит 7):
"0" – BSS не поддерживает IEEE 802.11ac (VHT).
"1" – BSS поддерживает IEEE 802.11ac.
FTM (Бит 8):
"0" – BSS не поддерживает Fine Timing Measurement (IEEE 802.11mc).
"1" – BSS поддерживает FTM, что позволяет проводить точные измерения расстояния.
High Efficiency (Бит 9):
"0" – BSS не поддерживает IEEE 802.11ax (HE).
"1" – BSS поддерживает IEEE 802.11ax.
Зарезервировано (Биты 10 - 31).
Биты зарезервированы для будущих расширений и должны быть установлены в "0".
Структура кадра состоит из фиксированных полей и информационных элементов (IE, Information Elements), представленных на Рисунке 5.
Рисунок 5 – Структура кадра BTM Request.
1. Category (1 байт)
Определяет категорию кадра Action. Для WNM это значение всегда 10 (0x0a).
2. Action (1 байт)
Определяет тип действия в категории WNM. Для кадра BTM Request значение равно 7 (0x07).
3. Dialog Token (1 байт)
Уникальный идентификатор, который позволяет AP сопоставить ответ STA с конкретным запросом.
4. Request Mode (1 байт)
Определяет параметры запроса.
Биты поля имеют следующее значение.
Preferred Candidate List Included (Бит 0):
"1" – в кадре присутствует список кандидатов BSS;
"0" – отсутствует.
Abridged (Бит 1):
"1" – предпочтение отдаётся сокращённому списку кандидатов;
"0" – полный список.
Disassociation Imminent (Бит 2):
"1" – станция будет принудительно отключена через время, указанное в поле Disassociation Timer;
"0" – отключение не планируется.
BSS Termination Included (Бит 3):
"1" – в кадре присутствует поле BSS Termination Duration;
"0" – отсутствует.
ESS Disassociation Imminent (Бит 4):
"1" – вся сеть ESS будет отключена;
"0" – нет.
Зарезервированы (Биты 5–7: должны иметь значение «0»).
5. Disassociation Timer (2 байта)
Определяет время в единицах TU (1 TU = 1024 мкс), через которое станция будет отключена от текущего BSS, если переход обязателен (установлен бит Disassociation Imminent).
6. Validity Interval (1 байт)
Определяет период, в течение которого список кандидатов BSS считается актуальным. Значение "0" означает, что актуальность списка кандидатов не имеет ограничения по времени.
7. BSS Termination Duration (0 или 12 байт)
Опциональное поле.
Присутствует, если установлен бит BSS Termination Included = 1.
Определяет, когда работа BSS будет прекращена (например, точка доступа будет выключена).
Биты поля имеют следующее значение.
Element ID (1 байт) – идентификатор элемента (значение 66 для BSS Termination Duration).
Length (1 байт) – длина поля (10 байт).
BSS Termination TSF (8 байт) – время прекращения работы в формате TSF (Timestamp Synchronization Function).
Duration (2 байта) – длительность указанного процесса (в минутах).
8. Session Information URL (0 байт или переменной длины)
Опциональное поле.
Содержит ссылку URL для получения дополнительной информации о сессии.
Формат:
Element ID (1 байт) – идентификатор элемента (значение 68);
Length (1 байт) – длина ссылки URL;
URL (переменная длина) – ASCII-строка с ссылкой URL.
9. BSS Transition Candidate List Entries (0 байт или переменной длины)
Опциональный список, содержащий информацию о рекомендуемых AP BSS для перехода.
Формат списка аналогичен полю BSS Transition Candidate List Entries кадра BTM Query.
10. Operating Class (1 байт).
Поле Operating Class используется в элементе Neighbor Report для указания частотного диапазона и ширины канала BSS. STA использует это значение вместе с полем Channel Number (см. далее), чтобы точно определить рабочий канал целевой AP BSS. Значения Operating Class указаны в Приложении E стандарта IEEE 802.11-2016 и последующих версиях.
Примеры значений поля Operating Class:
"81" – диапазон 2.4 ГГц, каналы 1 - 13, ширина канала 20 МГц, глобальный класс.
"121"– диапазон 5 ГГц, каналы 36 - 144, ширина канала 80 МГц, глобальный класс.
11. Channel Number (1 байт) - номер частотного канала AP BSS.
12. PHY Type (1 байт) - тип физического уровня (IEEE 802.11a/b/g/n/ac/ax).
Поле определяет тип физического уровня (Physical Layer), используемого AP BSS.
Это позволяет станции определить, какой именно тип физического уровня используется в целевой AP BSS, чтобы проверить совместимость.
Возможные значения:
"0" – FHSS (Frequency Hopping Spread Spectrum, устаревший, 802.11 legacy);
"1" – DSSS (Direct Sequence Spread Spectrum, IEEE 802.11b);
"2" – IR (Infrared, устаревший);
"3" – OFDM (Orthogonal Frequency Division Multiplexing, IEEE 802.11a/g);
"4" – HT (High Throughput, IEEE 802.11n);
"5" – DMG (Directional Multi-Gigabit, IEEE 802.11ad, 60 ГГц);
"6" – VHT (Very High Throughput, IEEE 802.11ac);
"7" – TVHT (TV White Space High Throughput, IEEE 802.11af);
"8" – HE (High Efficiency, IEEE 802.11ax);
"9" – "255" - зарезервированы для будущего применения.
Устаревшие типы (например, FHSS или IR) практически не используются в современных сетях, но предусмотрены стандартом для обратной совместимости.
13. BSS Transition Candidate Preference (1 байт) – приоритет целевой AP.
Возможные значения:
"0" – AP исключена из рассмотрения;
"1" - "255" – относительный приоритет AP в списке кандидатов, где значение "255" соответствует наиболее приоритетному. Равные значения поля для разных BSSID означают равный приоритет. Значение поля актуально в течение периода времени, установленного значением поля Validity Interval.
2.4 Описание полей кадра BTM Response.Определяет категорию кадра Action. Для WNM это значение всегда 10 (0x0a).
2. Action (1 байт)
Определяет тип действия в категории WNM. Для кадра BTM Request значение равно 7 (0x07).
3. Dialog Token (1 байт)
Уникальный идентификатор, который позволяет AP сопоставить ответ STA с конкретным запросом.
4. Request Mode (1 байт)
Определяет параметры запроса.
Биты поля имеют следующее значение.
Preferred Candidate List Included (Бит 0):
"1" – в кадре присутствует список кандидатов BSS;
"0" – отсутствует.
Abridged (Бит 1):
"1" – предпочтение отдаётся сокращённому списку кандидатов;
"0" – полный список.
Disassociation Imminent (Бит 2):
"1" – станция будет принудительно отключена через время, указанное в поле Disassociation Timer;
"0" – отключение не планируется.
BSS Termination Included (Бит 3):
"1" – в кадре присутствует поле BSS Termination Duration;
"0" – отсутствует.
ESS Disassociation Imminent (Бит 4):
"1" – вся сеть ESS будет отключена;
"0" – нет.
Зарезервированы (Биты 5–7: должны иметь значение «0»).
5. Disassociation Timer (2 байта)
Определяет время в единицах TU (1 TU = 1024 мкс), через которое станция будет отключена от текущего BSS, если переход обязателен (установлен бит Disassociation Imminent).
6. Validity Interval (1 байт)
Определяет период, в течение которого список кандидатов BSS считается актуальным. Значение "0" означает, что актуальность списка кандидатов не имеет ограничения по времени.
7. BSS Termination Duration (0 или 12 байт)
Опциональное поле.
Присутствует, если установлен бит BSS Termination Included = 1.
Определяет, когда работа BSS будет прекращена (например, точка доступа будет выключена).
Биты поля имеют следующее значение.
Element ID (1 байт) – идентификатор элемента (значение 66 для BSS Termination Duration).
Length (1 байт) – длина поля (10 байт).
BSS Termination TSF (8 байт) – время прекращения работы в формате TSF (Timestamp Synchronization Function).
Duration (2 байта) – длительность указанного процесса (в минутах).
8. Session Information URL (0 байт или переменной длины)
Опциональное поле.
Содержит ссылку URL для получения дополнительной информации о сессии.
Формат:
Element ID (1 байт) – идентификатор элемента (значение 68);
Length (1 байт) – длина ссылки URL;
URL (переменная длина) – ASCII-строка с ссылкой URL.
9. BSS Transition Candidate List Entries (0 байт или переменной длины)
Опциональный список, содержащий информацию о рекомендуемых AP BSS для перехода.
Формат списка аналогичен полю BSS Transition Candidate List Entries кадра BTM Query.
10. Operating Class (1 байт).
Поле Operating Class используется в элементе Neighbor Report для указания частотного диапазона и ширины канала BSS. STA использует это значение вместе с полем Channel Number (см. далее), чтобы точно определить рабочий канал целевой AP BSS. Значения Operating Class указаны в Приложении E стандарта IEEE 802.11-2016 и последующих версиях.
Примеры значений поля Operating Class:
"81" – диапазон 2.4 ГГц, каналы 1 - 13, ширина канала 20 МГц, глобальный класс.
"121"– диапазон 5 ГГц, каналы 36 - 144, ширина канала 80 МГц, глобальный класс.
11. Channel Number (1 байт) - номер частотного канала AP BSS.
12. PHY Type (1 байт) - тип физического уровня (IEEE 802.11a/b/g/n/ac/ax).
Поле определяет тип физического уровня (Physical Layer), используемого AP BSS.
Это позволяет станции определить, какой именно тип физического уровня используется в целевой AP BSS, чтобы проверить совместимость.
Возможные значения:
"0" – FHSS (Frequency Hopping Spread Spectrum, устаревший, 802.11 legacy);
"1" – DSSS (Direct Sequence Spread Spectrum, IEEE 802.11b);
"2" – IR (Infrared, устаревший);
"3" – OFDM (Orthogonal Frequency Division Multiplexing, IEEE 802.11a/g);
"4" – HT (High Throughput, IEEE 802.11n);
"5" – DMG (Directional Multi-Gigabit, IEEE 802.11ad, 60 ГГц);
"6" – VHT (Very High Throughput, IEEE 802.11ac);
"7" – TVHT (TV White Space High Throughput, IEEE 802.11af);
"8" – HE (High Efficiency, IEEE 802.11ax);
"9" – "255" - зарезервированы для будущего применения.
Устаревшие типы (например, FHSS или IR) практически не используются в современных сетях, но предусмотрены стандартом для обратной совместимости.
13. BSS Transition Candidate Preference (1 байт) – приоритет целевой AP.
Возможные значения:
"0" – AP исключена из рассмотрения;
"1" - "255" – относительный приоритет AP в списке кандидатов, где значение "255" соответствует наиболее приоритетному. Равные значения поля для разных BSSID означают равный приоритет. Значение поля актуально в течение периода времени, установленного значением поля Validity Interval.
Структура кадра состоит из фиксированных полей и IE, представленных на Рисунке 6.
Рисунок 6 – Структура кадра BTM Response.
1. Category (1 байт)
Как и в кадре BTM Request, значение поля равно 10 (WNM, 0x0a).
2. Action (1 байт)
Указывает тип действия. Для кадра BTM Response значение поля равно 8 (0x08).
3. Dialog Token (1 байт)
Значение копируется из аналогичного поля кадра BTM Request для сопоставления с ним ответа BTM Response.
4. Status Code (1 байт)
Результат обработки запроса.
Возможные значения следующие:
"0" – Accept (Принят);
"1" – Reject (Unspecified reject reason);
"2" – Reject (Insufficient Beacon or Probe Response frames received from all candidates);
"3" – Reject (Insufficient available capacity from all candidates);
"4" – Reject (BSS Termination undesired);
"5" – Reject (BSS Termination delay requested);
"6" – Reject (STA BSS Transition Candidate List provided);
"7" – Reject (No suitable BSS transition candidates);
"8" – Reject (Leaving ESS);
"9" – "255" - зарезервированы для будущего применения.
5. BSS Termination Delay (1 байт)
Определяет, через сколько минут работа текущего BSS будет прекращена (если применимо). Значение "0" означает, что работа BSS не будет прекращена.
6. Target BSSID (0 или 6 байт)
Если STA принимает запрос (поле Status Code = 0), то это поле содержит BSSID выбранной AP BSS, на которую переходит STA. Если запрос отклонён, поле отсутствует.
7. BSS Transition Candidate List Entries (0 или переменная длина)
Опциональный список, возвращаемый станцией, если она предлагает альтернативные AP BSS. Формат списка аналогичен полю BSS Transition Candidate List Entries кадра BTM Query.
2.5 Возможные варианты вмешательства в процедуру BTM со стороны третьих лиц.Как и в кадре BTM Request, значение поля равно 10 (WNM, 0x0a).
2. Action (1 байт)
Указывает тип действия. Для кадра BTM Response значение поля равно 8 (0x08).
3. Dialog Token (1 байт)
Значение копируется из аналогичного поля кадра BTM Request для сопоставления с ним ответа BTM Response.
4. Status Code (1 байт)
Результат обработки запроса.
Возможные значения следующие:
"0" – Accept (Принят);
"1" – Reject (Unspecified reject reason);
"2" – Reject (Insufficient Beacon or Probe Response frames received from all candidates);
"3" – Reject (Insufficient available capacity from all candidates);
"4" – Reject (BSS Termination undesired);
"5" – Reject (BSS Termination delay requested);
"6" – Reject (STA BSS Transition Candidate List provided);
"7" – Reject (No suitable BSS transition candidates);
"8" – Reject (Leaving ESS);
"9" – "255" - зарезервированы для будущего применения.
5. BSS Termination Delay (1 байт)
Определяет, через сколько минут работа текущего BSS будет прекращена (если применимо). Значение "0" означает, что работа BSS не будет прекращена.
6. Target BSSID (0 или 6 байт)
Если STA принимает запрос (поле Status Code = 0), то это поле содержит BSSID выбранной AP BSS, на которую переходит STA. Если запрос отклонён, поле отсутствует.
7. BSS Transition Candidate List Entries (0 или переменная длина)
Опциональный список, возвращаемый станцией, если она предлагает альтернативные AP BSS. Формат списка аналогичен полю BSS Transition Candidate List Entries кадра BTM Query.
Рассмотрим возможные сценарии атак на клиентские устройства.
2.5.1 Атака типа «Denial of Service».Вариант №1.
Цель атаки - вызвать отказ в обслуживании, заставляя STA многократно пытаться подключиться к несуществующим или неподходящим AP.
Алгоритм атаки:
1. Атакующий отправляет в адрес STA поддельный кадр BTM Request с пустым или некорректным полем Neighbor List и значением поля «Disassociation Timer», равным «0».
2. STA отключается от текущей AP, но не может подключиться к новой, что приводит к временной потере соединения.
Вариант №2.
Цель атакии – нарушение процесса роуминга: принуждение произвольных STA к подключению на выбранные легитимные AP с целью их перегрузки и снижения качества услуг.
Алгоритм атаки:
1. Атакующий отправляет в адрес всех окружающих STA поддельные кадры BTM Request с корректным списком Neighbor List, но манипулируя приоритетами легитимных AP в своих целях.
2. STA отключаются от текущих AP и подключаются к AP, рекомендованным атакующим, вызывая их перегрузку.
3. Попытки со стороны сети балансировать нагрузку нивелируются повторным (непрерывным) излучением кадров по п.1.
Условия для успешной реализации вышеуказанных вариантов атак:
1. Поддержка со стороны STA стандарта IEEE 802.11v. Для первого варианта – также со стороны AP.
2. Отсутствие проверки подлинности кадров (IEEE 802.11w не используется).
3. Автоматическое следование STA рекомендациям кадра BTM Request.
2.5.2 Атака типа «Evil Twin».Цель атаки - вызвать отказ в обслуживании, заставляя STA многократно пытаться подключиться к несуществующим или неподходящим AP.
Алгоритм атаки:
1. Атакующий отправляет в адрес STA поддельный кадр BTM Request с пустым или некорректным полем Neighbor List и значением поля «Disassociation Timer», равным «0».
2. STA отключается от текущей AP, но не может подключиться к новой, что приводит к временной потере соединения.
Вариант №2.
Цель атакии – нарушение процесса роуминга: принуждение произвольных STA к подключению на выбранные легитимные AP с целью их перегрузки и снижения качества услуг.
Алгоритм атаки:
1. Атакующий отправляет в адрес всех окружающих STA поддельные кадры BTM Request с корректным списком Neighbor List, но манипулируя приоритетами легитимных AP в своих целях.
2. STA отключаются от текущих AP и подключаются к AP, рекомендованным атакующим, вызывая их перегрузку.
3. Попытки со стороны сети балансировать нагрузку нивелируются повторным (непрерывным) излучением кадров по п.1.
Условия для успешной реализации вышеуказанных вариантов атак:
1. Поддержка со стороны STA стандарта IEEE 802.11v. Для первого варианта – также со стороны AP.
2. Отсутствие проверки подлинности кадров (IEEE 802.11w не используется).
3. Автоматическое следование STA рекомендациям кадра BTM Request.
Цели атаки:
а) заставить STA подключиться к поддельной точке доступа («Evil Twin»);
б) перенаправить STA на вредоносный URL для запуска эксплойта или кражи учетных данных.
Алгоритм атаки:
1. Атакующий направляет в адрес STA поддельный кадр BTM Request, указывает свою точку доступа в поле Neighbor List и устанавливает для нее максимальный приоритет (значение поля «Preference» равным «255»).
В поле «Disassociation Timer» кадра указывается значение «0» или близкое к нему. Для битовых флагов «Preferred Candidate List Included», «Abridged», «Disassociation Imminent» и «ESS Disassociation Imminent» устанавливается значение «1».
2. В поле «Session Information URL» указывается ссылка на сервер, контролируемый атакующим, который может:
Возможен также вариант атаки типа «отказ в обслуживании» на указанный в поле «Session Information URL» легитимный сервер за счет организации массовых запросов на подключение со стороны атакуемых STA, поскольку поддельные пакеты можно излучать циклически.
Условия для успешной атаки:
1. Поддержка со стороны STA стандарта IEEE 802.11v.
2. Отсутствие проверки подлинности кадров (IEEE 802.11w не используется).
3. Поддержка со стороны STA автоматической обработки URL (например, автоматический запуск браузера).
4. Отсутствие проверки сертификатов или слабая защита соединения с URL (HTTP вместо HTTPS).
2.6 Подделка значения поля Session Information URL в кадрах BTM Request.а) заставить STA подключиться к поддельной точке доступа («Evil Twin»);
б) перенаправить STA на вредоносный URL для запуска эксплойта или кражи учетных данных.
Алгоритм атаки:
1. Атакующий направляет в адрес STA поддельный кадр BTM Request, указывает свою точку доступа в поле Neighbor List и устанавливает для нее максимальный приоритет (значение поля «Preference» равным «255»).
В поле «Disassociation Timer» кадра указывается значение «0» или близкое к нему. Для битовых флагов «Preferred Candidate List Included», «Abridged», «Disassociation Imminent» и «ESS Disassociation Imminent» устанавливается значение «1».
2. В поле «Session Information URL» указывается ссылка на сервер, контролируемый атакующим, который может:
- предложить пользователю ввести учетные данные под видом легитимного ресурса;
- внедрить пользователю вредоносное ПО через загрузку файлов или эксплойты.
Возможен также вариант атаки типа «отказ в обслуживании» на указанный в поле «Session Information URL» легитимный сервер за счет организации массовых запросов на подключение со стороны атакуемых STA, поскольку поддельные пакеты можно излучать циклически.
Условия для успешной атаки:
1. Поддержка со стороны STA стандарта IEEE 802.11v.
2. Отсутствие проверки подлинности кадров (IEEE 802.11w не используется).
3. Поддержка со стороны STA автоматической обработки URL (например, автоматический запуск браузера).
4. Отсутствие проверки сертификатов или слабая защита соединения с URL (HTTP вместо HTTPS).
В рамках исследования возможности вмешательства в процедуру BTM особое внимание уделяется полю «Session Information URL», которое может быть использовано для передачи дополнительной информации клиентскому устройству.
На основе анализа стандарта IEEE 802.11v и описанных сценариев атак (в частности, атаки типа «Evil Twin»), подделка значения этого поля представляется возможной.
Поле «Session Information URL» является опциональным и содержит ASCII-строку с URL, которая может быть произвольно задана в поддельном кадре BTM Request.
Атакующий может внедрить вредоносную ссылку (например, ведущую на фишинговый сайт), поскольку стандарт IEEE 802.11v не предусматривает встроенных механизмов аутентификации или шифрования для кадров типа Action, включая BTM.
Это позволяет генерировать поддельные кадры с помощью инструментов типа Scapy без необходимости аутентификации источника.
Механизмы предотвращения подделки в базовом стандарте IEEE 802.11v отсутствуют: кадры BTM не требуют обязательной проверки подлинности, и клиентское устройство (STA) может принять их как легитимные, если не реализованы дополнительные меры защиты, такие как использование стандарта IEEE 802.11w (Protected Management Frames). В отсутствие данных мер подделка является простым вектором атаки, как показано в сценариях DoS и Evil Twin, где вредоносный URL может привести к фишингу, XSS или внедрению вредоносного кода при автоматической обработке ссылки клиентом.
Таким образом фактическая уязвимость зависит от того, как клиентское устройство обрабатывает эту информацию. В следующем разделе мы перейдем к анализу реализации обработки этого поля в популярных операционных системах.
3. Анализ обработки поля Session Information URL в операционных системах Android и Linux.На основе анализа стандарта IEEE 802.11v и описанных сценариев атак (в частности, атаки типа «Evil Twin»), подделка значения этого поля представляется возможной.
Поле «Session Information URL» является опциональным и содержит ASCII-строку с URL, которая может быть произвольно задана в поддельном кадре BTM Request.
Атакующий может внедрить вредоносную ссылку (например, ведущую на фишинговый сайт), поскольку стандарт IEEE 802.11v не предусматривает встроенных механизмов аутентификации или шифрования для кадров типа Action, включая BTM.
Это позволяет генерировать поддельные кадры с помощью инструментов типа Scapy без необходимости аутентификации источника.
Механизмы предотвращения подделки в базовом стандарте IEEE 802.11v отсутствуют: кадры BTM не требуют обязательной проверки подлинности, и клиентское устройство (STA) может принять их как легитимные, если не реализованы дополнительные меры защиты, такие как использование стандарта IEEE 802.11w (Protected Management Frames). В отсутствие данных мер подделка является простым вектором атаки, как показано в сценариях DoS и Evil Twin, где вредоносный URL может привести к фишингу, XSS или внедрению вредоносного кода при автоматической обработке ссылки клиентом.
Таким образом фактическая уязвимость зависит от того, как клиентское устройство обрабатывает эту информацию. В следующем разделе мы перейдем к анализу реализации обработки этого поля в популярных операционных системах.
Основным компонентом, отвечающим за управление подключением к Wi-Fi сетям в устройствах под управлением ОС Android и Linux, является программный модуль «wpa_supplicant».
3.1 Анализ исходного кода ОС Android на предмет обработки запросов типа BTM Request.
Осуществим анализ алгоритма обработки запроса BTM Request на основе исходного кода AOSP («wpa_supplicant_8», версия Android 15, файлы «wnm_sta.c» и «ieee802_11_common.c»). На основе анализа кода и дополнительных источников, таких как конфигурационные файлы «wpa_supplicant.conf» в AOSP, подтверждается, что режим BTM может быть отключен опцией disable_btm=1, что предотвращает обработку запросов, включая URL. Однако по умолчанию BTM включен, и обработка URL происходит на уровне «wpa_supplicant» с последующей передачей событий в верхние слои Android.
3.1.1 Функция «ieee802_11_rx_bss_trans_mgmt_req».
Функция реализует обработку кадра BTM Request, проверку данных, принятие решения о переходе и формирование ответа. Она определена в файле wnm_sta.c и вызывается из функции «ieee802_11_rx_wnm_action», которая реализует обработку поступающих кадров типа WNM Action. Это обеспечивает централизованную обработку всех WNM-сообщений, включая BTM, с предварительной проверкой состояния соединения (wpa_s->wpa_state >= WPA_ASSOCIATED) и источника.
Параметры:
«wpa_s»: указатель на структуру «wpa_supplicant», содержащую контекст клиента (конфигурация, текущее соединение, драйвер). Необходим для доступа к текущему BSS, конфигурации и отправки событий/ответов;[I]void ieee802_11_rx_bss_trans_mgmt_req(struct wpa_supplicant *wpa_s, const u8 *pos, const u8 *end, int reply)[/I]Параметры:
«pos»: указатель на данные кадра BTM Request (payload после action field). Необходим для обработки полей запроса;
«end»: указатель на конец буфера. Необходим для проверки границ и предотвращения его переполнения;
«reply»: флаг, указывающий, нужно ли отправить ответ (1 для unicast, 0 для multicast). Ответ должен быть отправлен только для unicast-запросов (как требует IEEE 802.11v).
Алгоритм работы функции:
1. Проверка длины кадра.
Функция проверяет, соответствует ли длина кадра минимальному набору обязательных полей («Dialog Token», «Request Mode», «Disassociation Timer», «Validity Interval»). Если длина кадра меньше 5 байт, кадр считается некорректным, и функция завершает выполнение. Это необходимо для предотвращения обработки поврежденных или неполных кадров, что могло бы привести к ошибкам или уязвимостям.
2. Обработка заголовка запроса.
Извлекаются обязательные поля кадра: «Dialog Token» (1 байт) для идентификации сессии, «Request Mode» (1 байт) для определения типа запроса (например, наличие флагов «disassoc_imminent» или «pref_cand_list»), «Disassociation Timer» (2 байта) для указания времени до отключения, «Validity Interval» (1 байт) для определения срока действия списка кандидатов.
Код:
wpa_s->wnm_dialog_token = pos[0];
wpa_s->wnm_mode = pos[1];
wpa_s->wnm_dissoc_timer = WPA_GET_LE16(pos + 2);
valid_int = pos[4];
pos += 5;3. Сохранение параметров в контексте.
Параметры запроса сохраняются в структуре «wpa_s» для последующей обработки (например, в ответах или событиях). Это необходимо для хранения состояния запроса на протяжении обработки, чтобы избежать повторного парсинга.
Код:
wpa_s->wnm_dialog_token = dialog_token;[/JUSTIFY]
wpa_s->wnm_mode = req_mode;
wpa_s->wnm_dissoc_timer = disassoc_timer;
wpa_s->wnm_reply = reply;4. Проверка поддержки BSS Transition со стороны STA.
Проверяется, отключена ли поддержка MBO/OCE или BTM в конфигурации (wpa_s->disable_mbo_oce || wpa_s->conf->disable_btm). Если отключена, функция завершает выполнение без ответа. Это необходимо для обеспечения конфигурации устройства, где BTM может быть запрещен по причинам совместимости или политики.
Код:
if (wpa_s->disable_mbo_oce || wpa_s->conf->disable_btm)
return;5. Обработка элементов поля Neighbor Report.
Если в поле «Request Mode» установлен флаг «WNM_BSS_TM_REQ_PREF_CAND_LIST_INCLUDED», список кандидатов (Neighbor Report elements) подлежит обработке.
Функция «wnm_parse_neighbor_report» извлекает данные о каждом кандидате (BSSID, канал и прочие), элементы с tag != «WLAN_EID_NEIGHBOR_REPORT» или длиной менее 13 байт игнорируются. Длина списка ограничена десятью кандидатами (определяется константой «WNM_MAX_NEIGHBOR_REPORT»).
Код:
wnm_deallocate_memory(wpa_s);
wpa_s->wnm_neighbor_report_elements = os_calloc(WNM_MAX_NEIGHBOR_REPORT, sizeof(struct neighbor_report));
while (end - pos >= 2 && wpa_s->wnm_num_neighbor_report < WNM_MAX_NEIGHBOR_REPORT) {
u8 tag = *pos++;
u8 len = *pos++;
if (tag == WLAN_EID_NEIGHBOR_REPORT) {
struct neighbor_report *rep = &wpa_s->wnm_neighbor_report_elements[wpa_s->wnm_num_neighbor_report];
wnm_parse_neighbor_report(wpa_s, pos, len, rep);
wpa_s->wnm_num_neighbor_report++;
}
pos += len;
}6. Сохранение списка кандидатов.
Список кандидатов сохраняется в wpa_s->wnm_neighbor_report_elements. Это необходимо для дальнейшего анализа и выбора лучшего кандидата.
7. Проверка флага «disassoc_imminent».
Если в поле «Request Mode» установлен флаг «WNM_BSS_TM_REQ_DISASSOC_IMMINENT», клиент учитывает, что текущая точка доступа может отключить его через период времени «disassoc_timer».
Также обрабатывается поле «Session Information URL» (опциональное поле после флага, с длиной «url_len»), которое затем логируется. Если «url_len» превышает доступную длину буфера (end - pos), весь кадр игнорируется для предотвращения переполнения, что обеспечивает безопасность. Переменная «beacon_int» (интервал кадров типа Beacon текущего BSS) используется для преобразования значения «disassoc_timer» в миллисекунды.
Код:
if (wpa_s->wnm_mode & WNM_BSS_TM_REQ_ESS_DISASSOC_IMMINENT) {
char url[256];
u8 url_len;
if (end - pos < 1) return;
url_len = *pos++;
if (url_len > end - pos) return;
os_memcpy(url, pos, url_len);
url[url_len] = '\0';
pos += url_len;
wpa_msg(wpa_s, MSG_INFO, ESS_DISASSOC_IMMINENT "%d %u %s",
wpa_sm_pmf_enabled(wpa_s->wpa), wpa_s->wnm_dissoc_timer * beacon_int * 128 / 125, url);
}8. Определение целесообразности перехода
В случае отсутствия кандидатов отправляется ответ WNM_BSS_TM_REJECT_NO_SUITABLE_CANDIDATES.
Если активен флаг «disassoc_imminent» и список кандидатов непустой, то производится его сортировка («wnm_sort_cand_list»), которая учитывает приоритет кандидатов, требующих немедленного перехода (значение «preference» из Neighbor Report).
Запускается сканирование эфира (функции «wnm_fetch_scan_results» или «wpa_supplicant_req_scan») для проверки актуальности списка кандидатов.
При активированном режиме «btm_offload» решение о переходе принимается внешней системой, а не модулем «wpa_supplicant».
Код:
if (!wpa_s->wnm_num_neighbor_report) {
wnm_send_bss_transition_mgmt_resp(wpa_s, wpa_s->wnm_dialog_token, WNM_BSS_TM_REJECT_NO_SUITABLE_CANDIDATES, MBO_TRANSITION_REJECT_REASON_UNSPECIFIED, 0, NULL);
} else {
wnm_sort_cand_list(wpa_s);
if (wnm_fetch_scan_results(wpa_s) > 0) return;
wpa_supplicant_req_scan(wpa_s, 0, 0);
}Функция «ieee802_11_rx_bss_trans_mgmt_req» для своей работы использует следующие дополнительные функции:
- «wnm_parse_neighbor_report»: обработка списка кандидатов;
- «wnm_send_bss_transition_mgmt_resp»: отправка ответа в адрес AP;
- «wpa_supplicant_event»: уведомление верхних слоев Android о переходе.
3.1.2 Функция «wnm_parse_neighbor_report».
Функция обрабатывает один элемент Neighbor Report из списка кандидатов и извлекает его характеристики. Определена в «wnm_sta.c».
Алгоритм работы:
1. Проверка длины элемента.
Проверяется минимальная длина элемента (13 байт: BSSID + BSSID Info + Op Class + Channel + PHY Type) для фильтрации некорректных данных от AP.
2. Парсинг основных полей.
Извлекаются значения BSSID (6 байт), BSSID Info (4 байта), Regulatory Class (1 байт), Channel Number (1 байт), PHY Type (1 байт).
3. Парсинг субэлементов.
Перебираются и при помощи функции «wnm_parse_neighbor_report_elem» извлекаются значения субэлементов анализируемой позиции в Neighbor Report. Это необходимо для получения дополнительных метрик (например, preference для приоритизации).
4. Вычисление частоты канала AP.
Вычисляется частота канала AP через функцию «wnm_nei_get_chan» (использует параметры «regulatory_class» и «channel_number»).
5. Учет режима MBO (если включено).
Если включено CONFIG_MBO, учитывается «mbo_transition_reason» для приоритизации (первый кандидат помечается как «is_first»). Это необходимо для поддержки MBO, где причина перехода влияет на выбор кандидата.
3.1.3 Функция «get_ie».
Функция ищет конкретный Information Element (IE) в буфере по его идентификатору (ID). Определена в «ieee802_11_common.c» (как часть «__ieee802_11_parse_elems», но «get_ie» - это простая утилита).
Решает задачу извлечения конкретных элементов (например, субэлементов Neighbor Report) из потока IE без полного парсинга.
Алгоритм работы:
1. Инициализация переменных.
Устанавливаются указатели на начало и конец буфера.
2. Перебор элементов.
Перебираются IE, проверяя ID и длину. Если найден нужный IE, возвращается указатель на него.
3. Завершение поиска.
Если IE не найден, возвращается значение NULL. Это необходимо для обработки случаев отсутствия опциональных элементов.
3.1.4 Обработка параметра «Session Information URL» в верхних слоях ОС Android.
После обработки в модуле «wpa_supplicant» URL логируется через функцию «wpa_msg» (уровень MSG_INFO), что видно в logcat как событие ESS_DISASSOC_IMMINENT.
Это событие передается в верхние слои через «wpa_supplicant_event» (EVENT_ESS_DISASSOC_IMMINENT), которое обрабатывается в модулях «WifiMonitor» (frameworks/opt/net/wifi/service/java/com/android/server/wifi/WifiMonitor.java) и затем в «WifiStateMachine» (WifiServiceImpl).
Однако URL не обрабатывается автоматически: он не открывается в браузере и не вызывает UI-взаимодействие.
В случае включенного режима PMF (802.11w) кадр проверяется на наличие подписи MIC, но в коде это влияет только на лог («wpa_sm_pmf_enabled»), не блокируя обработку.
Режим OCV (CONFIG_OCV) применяется косвенно через сканирование («wnm_fetch_scan_results»), где проверяются каналы кандидатов, но не напрямую к URL.
3.2 Анализ исходного кода ОС Linux на предмет обработки запросов типа BTM Request в сравнении с ОС Android.
В результате сравнительного анализа алгоритмов обработки кадра BTM Request на основе ранее рассмотренного кода для Android 15 и последней стабильной версии исходного кода модуля «wpa_supplicant» для Linux (версия 2.11) установлена их идентичность.
3.3 Требования по формированию кадра BTM Request для достижения целей атак.
На основе анализа кода «wpa_supplicant» (функции «ieee802_11_rx_bss_trans_mgmt_req» и «wnm_parse_neighbor_report»), требования по формированию поддельного кадра BTM Request ориентированы на прохождение минимальных проверок парсинга.
Это позволит эксплуатировать отсутствие встроенной аутентификации (без режима PMF) и автоматическую обработку (если флаг «disable_btm» отключен).
Поля кадра описаны в разделе 2.3; здесь указаны только специфичные для атаки адаптации, с учетом логики кода: проверки на длину полей, флагов, отсутствие фильтрации URL.
Для успеха любой атаки необходимо подделать поле «Source Address» кадра («mgmt->sa» должно равняться «wpa_s->bssid», иначе в функции «ieee802_11_rx_wnm_action» кадр будет проигнорирован).
3.3.1 Общие принципы формирования кадра BTM Request.
Перед детальным разбором сценариев отметим ключевые аспекты, применимые ко всем атакам. Эти принципы обеспечивают, чтобы кадр прошел парсинг без ошибок и вызвал желаемое поведение STA.
1. Минимальный формат кадра: обязательные поля: Dialog Token (1 байт, любое ненулевое значение для сессии), Request Mode (1 байт, с нужными флагами), Disassociation Timer (2 байта, LE), Validity Interval (1 байт). Длина больше, либо равна 5 байт (для прохождения if (end - pos < «5») return
.
2. Request Mode: биты флагов (PREF_CAND_LIST_INCLUDED, DISASSOC_IMMINENT) устанавливаем для активации сканирования/отключения (см. раздел 2.3).
3. Neighbor Report: каждый элемент с ID = 52 (WLAN_EID_NEIGHBOR_REPORT) формируем длиной больше, либо равной 13 байт (BSSID (6 байт) + BSSID Info (4 байта) + Op Class (1 байт) + Channel (1 байт) + PHY Type (1 байт)), всего до десяти элементов в списке (ограничение WNM_MAX_NEIGHBOR_REPORT). Обработка в функции «wnm_parse_neighbor_report» требует валидных значений Operating Class/Channel для вычисления частоты «freq» посредством функции «wnm_nei_get_chan» (используем реальные значения для прохождения проверки). Указываем Preference = «255» в субэлементе IE 63 для приоритета нужной AP в функции «wnm_sort_cand_list».
4. Session Information URL: Код игнорирует, если значение «url_len» первышает доступную длину, копирует в буфер 256 байт содержимого с добавлением завершающей последовательности '\0' — используем вредоносный URL (например, "http://evil.com/exploit"), или вставляем спецсимволы для инъекции нужной информации в лог.
5. Безопасность: атакуем при отсутствии режима PMF в сети (иначе потребуется MIC).
Режим OCV косвенно проверяет каналы в сканировании — используем реальные каналы для прохождения проверки.
На основе этих принципов рассмотрим адаптации для атак.
3.3.2 Формирование кадра BTM Request для атак типа «Denial of Service».
Вариант №1 (отключение STA с невозможностью подключения).
Принуждение к отключению в отсутствие валидных альтернатив AP.
Request Mode: установить флаг DISASSOC_IMMINENT = «1» для активации таймера и флаг PREF_CAND_LIST_INCLUDED = «1» для списка кандидатов (даже пустого - код отправит константу «REJECT_NO_SUITABLE», но с флагом «DISASSOC_IMMINENT» STA отключится через таймер);
Disassociation Timer: «0» (немедленное отключение; код обработает флаг DISASSOC_IMMINENT, запустит сканирование, но без кандидатов – потеря связи);
Validity Interval: «0» (немедленное устаревание в коде — список игнорируется, форсируя отключение без альтернатив).
Neighbor List: Пустой («0» элементов — код отправит константу «REJECT_NO_SUITABLE», но с флагом «DISASSOC_IMMINENT» STA отключится через таймер) или некорректный (указать Operating Class = «0» и Channel = «0», чтобы вызвать ошибку в функции «wnm_nei_get_chan», блокируя сканирование).
Session Information URL: для DoS — пустой.
Ожидаемый эффект: принудительное отключение STA (wpa_msg ESS_DISASSOC_IMMINENT) и ограничение возможности сканирования радиоэфира пустым или некорректным списком кандидатов, что приведёт к потере соединения.
Вариант №2 (перегрузка легитимных AP).
Атака направлена на массовый переход устройств к выбранным AP, вызывая их перегрузку.
Request Mode: установить флаг PREF_CAND_LIST_INCLUDED = «1» для активации списка; опционально флаг DISASSOC_IMMINENT = «1» для добавления срочности;
Disassociation Timer: «1» (малый, для быстрого перехода без полного отключения);
Validity Interval: «255» (максимально возможная актуальность для долгосрочного перехода; код вычислит valid_ms = 255*beacon_int*128/125, сохраняя список в структуре «wnm_neighbor_report_elements»).
Neighbor List: «1–10» элементов с BSSID целевых AP (легитимных), Preference = 255 (максимальный приоритет для сортировки в функции «wnm_sort_cand_list»), реальные значения Operating Class/Channel для прохождения проверки вычисления «freq» и успешного сканирования;
Session Information URL: пустой.
Ожидаемый эффект: множественные STA следуют фальшивому списку кандидатов (код сохранит его в «wnm_neighbor_report_elements», запустит процедуру роуминга через «wnm_fetch_scan_results»), вызывая перегрузку целевых AP.
3.3.3 Формирование кадра BTM Request для атаки Evil Twin.
Эта атака сочетает принуждение к подключению к поддельной AP с эксплуатацией URL для дальнейших вредоносных действий.
Request Mode: установить флаг PREF_CAND_LIST_INCLUDED = «1» для активации обработки списка кандидиатов, флаг ABRIDGED = «1» для сокращенного формата и флаг DISASSOC_IMMINENT = «1» для срочности (как в описании атаки), «ESS Disassociation Imminent» для активации обработки Session Information URL .
Disassociation Timer: «0» (немедленный переход; код обработает флаг DISASSOC_IMMINENT).
Validity Interval: «0» (немедленное устаревание — STA быстро отключится и подключится к поддельной AP через сканирование).
Neighbor List: 1 элемент с BSSID поддельной AP, Preference = 255 (приоритет в функции «wnm_sort_cand_list»), реальные значения Operating Class/Channel поддельной AP (например, Operating Class=115 для 5GHz, Channel=36, PHY Type=9).
Session Information URL: url_len=<=255, строка с вредоносным URL (например, "http://evil.com/phish?session=exploit").
Ожидаемый эффект: STA отключится от текущей AP и подключится к поддельной AP (через сканирование), URL откроется в браузере или всплывающем уведомлении (если это автоматизировано в верхних слоях операционной системы).
4. Разработка инструмента для атаки.
Инжекцию кадров BTM Request реализуем на языке Python согласно следующему алгоритму:
1. Подготовительный этап.
Валидация входных параметров (MAC-адресов, каналов); настройка сетевого интерфейса в режим мониторинга с использованием команд ip и iw.
Функции:
validate_mac(mac);
validate_channel(channel);
configure_interface(interface).
2. Формирование кадра.
Объединение RadioTap-заголовка, Dot11FCS-фрейма, элемента Neighbor Report и BTM-запроса с учетом текущего/целевого каналов, флагов безопасности, флагов VHT/HE; определение частоты, PHY-типа и операционного класса.
Функция: construct_btm_frame(real_bssid, fake_bssid, current_channel, target_channel, client_mac, security=False, vht=False, he_ap=False)
3. Выполнение атаки.
Передача собранного кадра на указанный интерфейс в цикле (с паузой 0.5 секунды) с использованием scapy.sendp.
Функция: execute_attack(args)
Исходный код проекта прилагается в файле btm.py.
5. Экспериментальная проверка атаки.
Для работы инструмента для атаки требуется ОС Linux (протестирован на Linux Mint 22.1) и сетевая Wi-Fi карта с поддержкой режима мониторинга («monitor mode»).
Для экспериментальной проверки используем тестовый стенд, состоящий из следующего оборудования:
– точка доступа Xiaomi AX3200 (версия прошивки 1.0.5 RB01);
– точка доступа Cudy TR3000 (версия прошивки OpenWrt 25.120.73261);
– точка доступа Cudy WR6500 (версия прошивки 2.3.0);
– клиентские устройства iPhone 12 (iOs 18.5), Samsung Galaxy S22 (Android 15), Xiaomi Poco X3 Pro (Android 13), Honor V8 Pro (Magic OS 8.1), HP Spectre X360 (Windows 11), HP Spectre X360 (Tails 6.19, wpa_supplicant v.2.10).
– Wi-Fi адаптер для инъекции пакетов EDUP AX3000.
Для простоты установки зависимостей создадим файл pysetup.sh следующего содержания:
В файле requirements.txt укажем строку:
Затем выполним команды установки зависимостей:
Переведем адаптер EDUP AX3000 в режим мониторинга:
Запустим виртуальное окружение и сам скрипт:
В качестве аргументов запуска определены следующие:
{interface} — имя сетевого интерфейса в режиме мониторинга;
{mac1} — mac-адрес легитимной AP;
{mac2} — mac-адрес поддельной AP;
{channel_1} — номер частотного канала легитимной AP;
{channel_2} — номер частотного канала поддельной точки доступа;
{mac2} — mac-адрес клиентского устройства;
--vht (опциональный) – установка флага Very High Throughput (VHT) для поддельной AP;
--he-ap (опциональный) – установка флага High Efficiency (HE AP) для поддельной AP;
--security (опциональный) – установка флага Security в элементе Neighbor report.
Проверка реакции клиентских устройств на кадры BTM Request, сформированные согласно требованиям пп. 3.3.2 и 3.3.3 для реализации атак, проводилась в два этапа.
На первом этапе оценивалась эффективность атаки типа «Denial of Service» (вариант №1) и атаки «Evil Twin». Для этого использовалась одна точка доступа в роли легитимной AP (как с поддержкой стандарта IEEE 802.11v, так и без неё), другая — в роли поддельной AP; все клиентские устройства подключались к легитимной. При помощи разработанного генератора кадров BTM в адрес клиентских устройств последовательно излучались кадры с заданным содержимым, анализировалось содержимое ответных кадров, логов ОС (при наличии) и состояние устройств в сети Wi-Fi.
На втором этапе оценивалась эффективность атаки типа «Denial of Service» (вариант №2). Для этого все имеющиеся точки доступа настраивались в качестве элементов ESS, между которыми случайным образом распределялись подключения устройств, имеющих уязвимости по результатам первого этапа. Затем при помощи генератора кадров в адрес клиентских устройств излучались кадры с заданным содержимым, вынуждая их одновременно переходить на AP в произвольном порядке.
5.1 Результаты первого этапа.
Все клиентские устройства тестового стенда реагируют на кадры BTM Request независимо от поддержки легитимной AP стандарта IEEE 802.11v, что формирует уязвимость. Реакция на различные комбинации флагов и полей (Neighbor List, Session Information URL) варьируется, но в целом не приводит к автоматической обработке URL (открытию браузера, уведомлениям или иной UI-реакции). В системных логах ОС содержимое поля «Session Information URL» не отображается, за исключением случаев, где это может быть доступно через специализированные инструменты (например, logcat в Android). Изменение параметров роуминга в настройках драйверов (где применимо) на обработку кадров не влияет.
Для наглядности, реакции устройств на ключевые сценарии представлены в таблице ниже. В ней учтены: отключение от текущей AP, подключение к поддельной или иной доступной AP, отправка ответа BTM Response (с указанием status_code), самостоятельный поиск кандидата AP при некорректных данных, а также изменения при добавлении в кадр флага ESS_DISASSOC_IMMINENT и поля URL.
Функция обрабатывает один элемент Neighbor Report из списка кандидатов и извлекает его характеристики. Определена в «wnm_sta.c».
[I]static void wnm_parse_neighbor_report(struct wpa_supplicant *wpa_s, const u8 *pos, u8 len, struct neighbor_report *rep)[/I]Алгоритм работы:
1. Проверка длины элемента.
Проверяется минимальная длина элемента (13 байт: BSSID + BSSID Info + Op Class + Channel + PHY Type) для фильтрации некорректных данных от AP.
Код:
if (left < 13) {
wpa_printf(MSG_DEBUG, "WNM: Too short neighbor report");
return;
}2. Парсинг основных полей.
Извлекаются значения BSSID (6 байт), BSSID Info (4 байта), Regulatory Class (1 байт), Channel Number (1 байт), PHY Type (1 байт).
Код:
os_memcpy(rep->bssid, pos, ETH_ALEN);
rep->bssid_info = WPA_GET_LE32(pos + ETH_ALEN);
rep->regulatory_class = *(pos + 10);
rep->channel_number = *(pos + 11);
rep->phy_type = *(pos + 12);
pos += 13;
left -= 13;3. Парсинг субэлементов.
Перебираются и при помощи функции «wnm_parse_neighbor_report_elem» извлекаются значения субэлементов анализируемой позиции в Neighbor Report. Это необходимо для получения дополнительных метрик (например, preference для приоритизации).
Код:
while (left >= 2) {
u8 id = *pos++;
u8 elen = *pos++;
left -= 2;
if (elen > left) break;
wnm_parse_neighbor_report_elem(rep, id, elen, pos);
left -= elen;
pos += elen;
}4. Вычисление частоты канала AP.
Вычисляется частота канала AP через функцию «wnm_nei_get_chan» (использует параметры «regulatory_class» и «channel_number»).
[I] rep->freq = wnm_nei_get_chan(wpa_s, rep->regulatory_class, rep->channel_number);[/I]5. Учет режима MBO (если включено).
Если включено CONFIG_MBO, учитывается «mbo_transition_reason» для приоритизации (первый кандидат помечается как «is_first»). Это необходимо для поддержки MBO, где причина перехода влияет на выбор кандидата.
Код:
#ifdef CONFIG_MBO
if (wpa_s->wnm_mbo_trans_reason_present && wpa_s->wnm_num_neighbor_report == 1) {
rep->is_first = 1;
}
#endif /* CONFIG_MBO */3.1.3 Функция «get_ie».
Функция ищет конкретный Information Element (IE) в буфере по его идентификатору (ID). Определена в «ieee802_11_common.c» (как часть «__ieee802_11_parse_elems», но «get_ie» - это простая утилита).
Решает задачу извлечения конкретных элементов (например, субэлементов Neighbor Report) из потока IE без полного парсинга.
[I]const u8 * get_ie(const u8 *ies, size_t len, u8 ie)[/I]Алгоритм работы:
1. Инициализация переменных.
Устанавливаются указатели на начало и конец буфера.
[I]const u8 *end = ies + len;[/I]2. Перебор элементов.
Перебираются IE, проверяя ID и длину. Если найден нужный IE, возвращается указатель на него.
Код:
while (ies && ies + 1 < end) {
if (ies + 2 + ies[1] > end) break;
if (ies[0] == ie) return ies;
ies += 2 + ies[1];
}3. Завершение поиска.
Если IE не найден, возвращается значение NULL. Это необходимо для обработки случаев отсутствия опциональных элементов.
3.1.4 Обработка параметра «Session Information URL» в верхних слоях ОС Android.
После обработки в модуле «wpa_supplicant» URL логируется через функцию «wpa_msg» (уровень MSG_INFO), что видно в logcat как событие ESS_DISASSOC_IMMINENT.
Это событие передается в верхние слои через «wpa_supplicant_event» (EVENT_ESS_DISASSOC_IMMINENT), которое обрабатывается в модулях «WifiMonitor» (frameworks/opt/net/wifi/service/java/com/android/server/wifi/WifiMonitor.java) и затем в «WifiStateMachine» (WifiServiceImpl).
Однако URL не обрабатывается автоматически: он не открывается в браузере и не вызывает UI-взаимодействие.
В случае включенного режима PMF (802.11w) кадр проверяется на наличие подписи MIC, но в коде это влияет только на лог («wpa_sm_pmf_enabled»), не блокируя обработку.
Режим OCV (CONFIG_OCV) применяется косвенно через сканирование («wnm_fetch_scan_results»), где проверяются каналы кандидатов, но не напрямую к URL.
3.2 Анализ исходного кода ОС Linux на предмет обработки запросов типа BTM Request в сравнении с ОС Android.
В результате сравнительного анализа алгоритмов обработки кадра BTM Request на основе ранее рассмотренного кода для Android 15 и последней стабильной версии исходного кода модуля «wpa_supplicant» для Linux (версия 2.11) установлена их идентичность.
3.3 Требования по формированию кадра BTM Request для достижения целей атак.
На основе анализа кода «wpa_supplicant» (функции «ieee802_11_rx_bss_trans_mgmt_req» и «wnm_parse_neighbor_report»), требования по формированию поддельного кадра BTM Request ориентированы на прохождение минимальных проверок парсинга.
Это позволит эксплуатировать отсутствие встроенной аутентификации (без режима PMF) и автоматическую обработку (если флаг «disable_btm» отключен).
Поля кадра описаны в разделе 2.3; здесь указаны только специфичные для атаки адаптации, с учетом логики кода: проверки на длину полей, флагов, отсутствие фильтрации URL.
Для успеха любой атаки необходимо подделать поле «Source Address» кадра («mgmt->sa» должно равняться «wpa_s->bssid», иначе в функции «ieee802_11_rx_wnm_action» кадр будет проигнорирован).
3.3.1 Общие принципы формирования кадра BTM Request.
Перед детальным разбором сценариев отметим ключевые аспекты, применимые ко всем атакам. Эти принципы обеспечивают, чтобы кадр прошел парсинг без ошибок и вызвал желаемое поведение STA.
1. Минимальный формат кадра: обязательные поля: Dialog Token (1 байт, любое ненулевое значение для сессии), Request Mode (1 байт, с нужными флагами), Disassociation Timer (2 байта, LE), Validity Interval (1 байт). Длина больше, либо равна 5 байт (для прохождения if (end - pos < «5») return
.2. Request Mode: биты флагов (PREF_CAND_LIST_INCLUDED, DISASSOC_IMMINENT) устанавливаем для активации сканирования/отключения (см. раздел 2.3).
3. Neighbor Report: каждый элемент с ID = 52 (WLAN_EID_NEIGHBOR_REPORT) формируем длиной больше, либо равной 13 байт (BSSID (6 байт) + BSSID Info (4 байта) + Op Class (1 байт) + Channel (1 байт) + PHY Type (1 байт)), всего до десяти элементов в списке (ограничение WNM_MAX_NEIGHBOR_REPORT). Обработка в функции «wnm_parse_neighbor_report» требует валидных значений Operating Class/Channel для вычисления частоты «freq» посредством функции «wnm_nei_get_chan» (используем реальные значения для прохождения проверки). Указываем Preference = «255» в субэлементе IE 63 для приоритета нужной AP в функции «wnm_sort_cand_list».
4. Session Information URL: Код игнорирует, если значение «url_len» первышает доступную длину, копирует в буфер 256 байт содержимого с добавлением завершающей последовательности '\0' — используем вредоносный URL (например, "http://evil.com/exploit"), или вставляем спецсимволы для инъекции нужной информации в лог.
5. Безопасность: атакуем при отсутствии режима PMF в сети (иначе потребуется MIC).
Режим OCV косвенно проверяет каналы в сканировании — используем реальные каналы для прохождения проверки.
На основе этих принципов рассмотрим адаптации для атак.
3.3.2 Формирование кадра BTM Request для атак типа «Denial of Service».
Вариант №1 (отключение STA с невозможностью подключения).
Принуждение к отключению в отсутствие валидных альтернатив AP.
Request Mode: установить флаг DISASSOC_IMMINENT = «1» для активации таймера и флаг PREF_CAND_LIST_INCLUDED = «1» для списка кандидатов (даже пустого - код отправит константу «REJECT_NO_SUITABLE», но с флагом «DISASSOC_IMMINENT» STA отключится через таймер);
Disassociation Timer: «0» (немедленное отключение; код обработает флаг DISASSOC_IMMINENT, запустит сканирование, но без кандидатов – потеря связи);
Validity Interval: «0» (немедленное устаревание в коде — список игнорируется, форсируя отключение без альтернатив).
Neighbor List: Пустой («0» элементов — код отправит константу «REJECT_NO_SUITABLE», но с флагом «DISASSOC_IMMINENT» STA отключится через таймер) или некорректный (указать Operating Class = «0» и Channel = «0», чтобы вызвать ошибку в функции «wnm_nei_get_chan», блокируя сканирование).
Session Information URL: для DoS — пустой.
Ожидаемый эффект: принудительное отключение STA (wpa_msg ESS_DISASSOC_IMMINENT) и ограничение возможности сканирования радиоэфира пустым или некорректным списком кандидатов, что приведёт к потере соединения.
Вариант №2 (перегрузка легитимных AP).
Атака направлена на массовый переход устройств к выбранным AP, вызывая их перегрузку.
Request Mode: установить флаг PREF_CAND_LIST_INCLUDED = «1» для активации списка; опционально флаг DISASSOC_IMMINENT = «1» для добавления срочности;
Disassociation Timer: «1» (малый, для быстрого перехода без полного отключения);
Validity Interval: «255» (максимально возможная актуальность для долгосрочного перехода; код вычислит valid_ms = 255*beacon_int*128/125, сохраняя список в структуре «wnm_neighbor_report_elements»).
Neighbor List: «1–10» элементов с BSSID целевых AP (легитимных), Preference = 255 (максимальный приоритет для сортировки в функции «wnm_sort_cand_list»), реальные значения Operating Class/Channel для прохождения проверки вычисления «freq» и успешного сканирования;
Session Information URL: пустой.
Ожидаемый эффект: множественные STA следуют фальшивому списку кандидатов (код сохранит его в «wnm_neighbor_report_elements», запустит процедуру роуминга через «wnm_fetch_scan_results»), вызывая перегрузку целевых AP.
3.3.3 Формирование кадра BTM Request для атаки Evil Twin.
Эта атака сочетает принуждение к подключению к поддельной AP с эксплуатацией URL для дальнейших вредоносных действий.
Request Mode: установить флаг PREF_CAND_LIST_INCLUDED = «1» для активации обработки списка кандидиатов, флаг ABRIDGED = «1» для сокращенного формата и флаг DISASSOC_IMMINENT = «1» для срочности (как в описании атаки), «ESS Disassociation Imminent» для активации обработки Session Information URL .
Disassociation Timer: «0» (немедленный переход; код обработает флаг DISASSOC_IMMINENT).
Validity Interval: «0» (немедленное устаревание — STA быстро отключится и подключится к поддельной AP через сканирование).
Neighbor List: 1 элемент с BSSID поддельной AP, Preference = 255 (приоритет в функции «wnm_sort_cand_list»), реальные значения Operating Class/Channel поддельной AP (например, Operating Class=115 для 5GHz, Channel=36, PHY Type=9).
Session Information URL: url_len=<=255, строка с вредоносным URL (например, "http://evil.com/phish?session=exploit").
Ожидаемый эффект: STA отключится от текущей AP и подключится к поддельной AP (через сканирование), URL откроется в браузере или всплывающем уведомлении (если это автоматизировано в верхних слоях операционной системы).
4. Разработка инструмента для атаки.
Инжекцию кадров BTM Request реализуем на языке Python согласно следующему алгоритму:
1. Подготовительный этап.
Валидация входных параметров (MAC-адресов, каналов); настройка сетевого интерфейса в режим мониторинга с использованием команд ip и iw.
Функции:
validate_mac(mac);
validate_channel(channel);
configure_interface(interface).
2. Формирование кадра.
Объединение RadioTap-заголовка, Dot11FCS-фрейма, элемента Neighbor Report и BTM-запроса с учетом текущего/целевого каналов, флагов безопасности, флагов VHT/HE; определение частоты, PHY-типа и операционного класса.
Функция: construct_btm_frame(real_bssid, fake_bssid, current_channel, target_channel, client_mac, security=False, vht=False, he_ap=False)
3. Выполнение атаки.
Передача собранного кадра на указанный интерфейс в цикле (с паузой 0.5 секунды) с использованием scapy.sendp.
Функция: execute_attack(args)
Исходный код проекта прилагается в файле btm.py.
5. Экспериментальная проверка атаки.
Для работы инструмента для атаки требуется ОС Linux (протестирован на Linux Mint 22.1) и сетевая Wi-Fi карта с поддержкой режима мониторинга («monitor mode»).
Для экспериментальной проверки используем тестовый стенд, состоящий из следующего оборудования:
– точка доступа Xiaomi AX3200 (версия прошивки 1.0.5 RB01);
– точка доступа Cudy TR3000 (версия прошивки OpenWrt 25.120.73261);
– точка доступа Cudy WR6500 (версия прошивки 2.3.0);
– клиентские устройства iPhone 12 (iOs 18.5), Samsung Galaxy S22 (Android 15), Xiaomi Poco X3 Pro (Android 13), Honor V8 Pro (Magic OS 8.1), HP Spectre X360 (Windows 11), HP Spectre X360 (Tails 6.19, wpa_supplicant v.2.10).
– Wi-Fi адаптер для инъекции пакетов EDUP AX3000.
Для простоты установки зависимостей создадим файл pysetup.sh следующего содержания:
Код:
#!/bin/bash
set -e
# Start from a clean environment
rm -rf venv/
# Basic python3 virtual environment
python3 -m venv venv
source venv/bin/activate
pip install wheel
pip install -r requirements.txtВ файле requirements.txt укажем строку:
scapyЗатем выполним команды установки зависимостей:
Код:
sudo apt-get update
sudo apt-get install virtualenv
sudo ./pysetup.shПереведем адаптер EDUP AX3000 в режим мониторинга:
Код:
sudo ifconfig wlxe**********d down
sudo iwconfig wlxe**********d mode monitor
sudo ifconfig wlxe**********d upЗапустим виртуальное окружение и сам скрипт:
Код:
sudo su
source venv/bin/activate
(venv) root@test:/home/test# python3 btm.py -i {interface} -r {mac_1} -f {mac_2} -c {channel_1} -t {channel_2} -m {mac_3} --he-ap --securityВ качестве аргументов запуска определены следующие:
{interface} — имя сетевого интерфейса в режиме мониторинга;
{mac1} — mac-адрес легитимной AP;
{mac2} — mac-адрес поддельной AP;
{channel_1} — номер частотного канала легитимной AP;
{channel_2} — номер частотного канала поддельной точки доступа;
{mac2} — mac-адрес клиентского устройства;
--vht (опциональный) – установка флага Very High Throughput (VHT) для поддельной AP;
--he-ap (опциональный) – установка флага High Efficiency (HE AP) для поддельной AP;
--security (опциональный) – установка флага Security в элементе Neighbor report.
Проверка реакции клиентских устройств на кадры BTM Request, сформированные согласно требованиям пп. 3.3.2 и 3.3.3 для реализации атак, проводилась в два этапа.
На первом этапе оценивалась эффективность атаки типа «Denial of Service» (вариант №1) и атаки «Evil Twin». Для этого использовалась одна точка доступа в роли легитимной AP (как с поддержкой стандарта IEEE 802.11v, так и без неё), другая — в роли поддельной AP; все клиентские устройства подключались к легитимной. При помощи разработанного генератора кадров BTM в адрес клиентских устройств последовательно излучались кадры с заданным содержимым, анализировалось содержимое ответных кадров, логов ОС (при наличии) и состояние устройств в сети Wi-Fi.
На втором этапе оценивалась эффективность атаки типа «Denial of Service» (вариант №2). Для этого все имеющиеся точки доступа настраивались в качестве элементов ESS, между которыми случайным образом распределялись подключения устройств, имеющих уязвимости по результатам первого этапа. Затем при помощи генератора кадров в адрес клиентских устройств излучались кадры с заданным содержимым, вынуждая их одновременно переходить на AP в произвольном порядке.
5.1 Результаты первого этапа.
Все клиентские устройства тестового стенда реагируют на кадры BTM Request независимо от поддержки легитимной AP стандарта IEEE 802.11v, что формирует уязвимость. Реакция на различные комбинации флагов и полей (Neighbor List, Session Information URL) варьируется, но в целом не приводит к автоматической обработке URL (открытию браузера, уведомлениям или иной UI-реакции). В системных логах ОС содержимое поля «Session Information URL» не отображается, за исключением случаев, где это может быть доступно через специализированные инструменты (например, logcat в Android). Изменение параметров роуминга в настройках драйверов (где применимо) на обработку кадров не влияет.
Для наглядности, реакции устройств на ключевые сценарии представлены в таблице ниже. В ней учтены: отключение от текущей AP, подключение к поддельной или иной доступной AP, отправка ответа BTM Response (с указанием status_code), самостоятельный поиск кандидата AP при некорректных данных, а также изменения при добавлении в кадр флага ESS_DISASSOC_IMMINENT и поля URL.
Клиентское устройство | DISASSOC_IMMINENT + PREF_CAND_LIST_INCLUDED + некорректный Neighbor List (Operating Class=0, Channel=0 или 236) | DISASSOC_IMMINENT + PREF_CAND_LIST_INCLUDED + пустой Neighbor List | PREF_CAND_LIST_INCLUDED + ABRIDGED + DISASSOC_IMMINENT | Добавление ESS_DISASSOC_IMMINENT и поля URL: изменения в реакции |
HP Spectre x360 (Windows 11) | Отключение от текущей AP, подключение к поддельной; BTM Response (status_code=0). Игнорирует валидность параметров. | Отключение от текущей AP, подключение к любой доступной в ESS; BTM Response (status_code=0). Самостоятельный выбор кандидата. Если кандидатов нет — отклонение (status_code=7), без отключения. | Немедленное отключение от текущей AP и подключение к поддельной; BTM Response (status_code=0). | Нет изменений в ответе; отключение от текущей AP и подключение к поддельной. |
iPhone 12 (iOS 18.5) | Нет реакции: соединение сохраняется, ответов нет. Проверяет валидность параметров. | Нет реакции: соединение сохраняется, ответов нет. | Немедленное отключение от текущей AP и подключение к поддельной; BTM Response (status_code=0). | Нет изменений в ответе; отключение от текущей AP и подключение к поддельной. |
HP Spectre x360 (Tails 6.19) | Отключение от текущей AP, подключение к поддельной; BTM Response (status_code=0) с собственным Neighbor List (данные измерений STA). Проверяет валидность, инициирует самостоятельный поиск в ESS. | Отклонение (status_code=7), без отключения. | Немедленное отключение от текущей AP и подключение к поддельной; BTM Response (status_code=0). | Нет изменений в ответе; отключение от текущей AP и подключение к поддельной. |
Honor V8 Pro (Magic OS 8.1) | Отключение от текущей AP, подключение к поддельной; BTM Response (status_code=0) с собственным Neighbor List (данные измерений STA). Проверяет валидность, инициирует самостоятельный поиск в ESS. | Отклонение (status_code=7), без отключения. | Немедленное отключение от текущей AP и подключение к поддельной; BTM Response (status_code=0). | Нет изменений в ответе; отключение от текущей AP и подключение к поддельной. |
Xiaomi Poco X3 Pro (Android 13) | Нет реакции: соединение сохраняется, ответов нет. Проверяет валидность параметров. | Нет реакции: соединение сохраняется, ответов нет. | Немедленное отключение от текущей AP и подключение к поддельной; BTM Response (status_code=0). | Игнорирование кадра; нет реакции. |
Samsung Galaxy S22 (Android 15) | Нет реакции: соединение сохраняется, ответов нет. Проверяет валидность параметров. | Нет реакции: соединение сохраняется, ответов нет. | Немедленное отключение от текущей AP и подключение к поддельной; BTM Response (status_code=0). | Нет изменений в ответе; отключение от текущей AP и подключение к поддельной. |
5.2 Результаты второго этапа.
При помощи генератора кадров обеспечивается манипуляция роумингом устройств — они могут быть переведены на обслуживание AP в произвольном порядке, в том числе повторно. Причиной этого является уязвимость клиентских устройств, которые обрабатывают кадры BTM Request несмотря на отсутствие поддержки стандарта IEEE 802.11v со стороны легитимной AP.
5.3 Выводы по экспериментам.
1. Все клиентские устройства реагируют на кадры BTM Request независимо от поддержки легитимной AP стандарта IEEE 802.11v, что формирует уязвимость.
2. STA по-разному реагируют на ограничение выбора возможных кандидатов пустым или некорректным списком, но в любом случае не теряют соединения с легитимной AP. Таким образом, атака типа «Denial of Service» (вариант №1) на практике оказалась несостоятельной.
3. Атака «Evil Twin» может быть эффективно проведена в части принуждения STA к взаимодействию с поддельной AP. Эксплуатация URL для дальнейших вредоносных действий по причине отсутствия автоматизированной обработки поля «Session Information URL» программным обеспечением STA не представляется возможной.
3. Атака типа «Denial of Service» (вариант №2) обеспечивает принуждение произвольных STA к подключению на выбранные легитимные AP с целью их перегрузки и снижения качества услуг.
Гипотеза о потенциальном векторе атаки через поле «Session Information URL» подтверждена частично: подделка значения поля возможна, но в проверенных операционных системах его обработка не приводит к автоматической сетевой активности (HTTP-запросам), запуску браузера или отображению уведомлений.
Рисунок 7 – Содержимое кадра BTM Request для атаки «Evil Twin».
Рисунок 8 – Содержимое ответного кадра BTM Response (status_code=0).
Рисунок 9 – Содержимое кадра BTM Request с полем «Session Information URL» для атаки «Evil Twin».
Рисунок 10 – Содержимое кадра BTM Response с результатом самостоятельного поиска кандидатов клиентским устройством.
ЗАКЛЮЧЕНИЕ
В ходе работы рассмотрена процедура BSS Transition Management стандарта IEEE 802.11v, а также проведен анализ ее безопасности и обработки в операционных системах.
Выявлены уязвимости, связанные с отсутствием встроенных механизмов аутентификации и шифрования кадров BTM, что позволяет проводить атаки типа «DoS» и «Evil Twin», включая подделку поля «Session Information URL» для потенциального перенаправления на вредоносные ресурсы.
Для эксплуатации уязвимости предложен метод подделки кадров BTM Request, реализованный на языке Python.
Разработан алгоритм атаки и описаны основные этапы его реализации, включая требования к формированию кадров для прохождения проверок в wpa_supplicant.
Экспериментальная проверка подтвердила возможность проведения атаки на всех устройствах тестового стенда, за исключением случаев с некорректным списком кандидатов, где устройства игнорируют кадр или отклоняют запрос без потери соединения.
Атака «DoS» (вариант №1) оказалась несостоятельной, атака «Evil Twin» эффективна в части принуждения к роумингу, но не приводит к автоматической обработке URL.
Атака «DoS» (вариант №2) позволяет перегрузить легитимные AP.
Гипотеза о векторе атаки через поле «Session Information URL» подтверждена частично, поскольку подделка возможна, но в проверенных ОС не вызывает сетевой активности или UI-взаимодействия.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
[1] IEEE Std 802.11v-2011. Amendment 8: IEEE 802.11 Wireless Network Management. The Institute of Electrical and Electronics Engineers, Inc., 2011.
[2] IEEE Std 802.11r-2008. Amendment 2: Fast Basic Service Set (BSS) Transition. The Institute of Electrical and Electronics Engineers, Inc., 2008.
[3] IEEE Std 802.11ax-2021. Amendment: Enhancements for High Efficiency WLAN. The Institute of Electrical and Electronics Engineers, Inc., 2021.
[4] 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.
[5] Wi-Fi Alliance. Voice-Enterprise Certification. URL: https://www.wi-fi.org/certification/voice-enterprise.
[6] wpa_supplicant source code (version 2.11 for Linux). Hostap project. URL: https://w1.fi/wpa_supplicant/.
[7] Android Open Source Project (AOSP). wpa_supplicant_8 source code (Android 15). Files: wnm_sta.c, ieee802_11_common.c.
URL: https://android.googlesource.com/platform/external/wpa_supplicant_8/
[8] MediaTek proprietary materials (slides on BSS Transition Management Request structure). Proprietary and Confidential.
[9] Cisco Systems. Wireless Network Management with IEEE 802.11k, 802.11v, and 802.11r. Technical documentation.
URL: https://www.cisco.com/c/en/us/td/do...ement_with_ieee_80211k_80211v_and_80211r.html
[10] Aruba Networks. IEEE 802.11k/v/r Configuration Guide. URL: https://www.arubanetworks.com/techd...arubaos-solutions/802-11k-v-r/802-11k-v-r.htm
Последнее редактирование: