Статья Уязвимость «User interface misrepresentation of critical information in Wi-Fi» CVE-2022-32666

[evdo]

Источник https://xss.pro
Автор evdo

Уязвимость «User interface misrepresentation of critical information in Wi-Fi» CVE-2022-32666
​

28 мая 2023 года Efstratios Chatzoglou в исследовании «Bl0ck: Paralyzing 802.11 connections through Block Ack frames» [1] опубликовал данные об уязвимости CVE-2022-32666.
Две атаки, совместно названные «Bl0ck», позволяют осуществить атаку типа «отказ в обслуживании» (DoS) в современных сетях Wi-Fi стандарта 802.11ac (Wi-Fi 5) и 802.11ax (Wi-Fi 6).

Несмотря на публичный характер работы и признание наличия уязвимости со стороны вендоров оборудования, только вендором MediaTek зарезервирован соответствующий идентификатор CVE.

Уязвимость CVE-2022-32666 состоит в возможности со стороны третьих лиц влиять на обмен кадрами при осуществлении процедуры группового подтверждения данных QoS (ADDBA, описание процедуры – далее) в современном беспроводном оборудовании. Уязвимость устраняется текущим стандартом [2], если участники обмена поддерживают процедуру защищенного группового подтверждения (PBAC). При этом процедура должна быть включена как инициатором, так и получателем данных. На момент проведения исследований [1] информация о реализации процедуры защищенного группового подтверждения (PBAC) в реальных устройствах отсутствует.
​

Предмет атаки - кадры типа BAR и BA
​

Стандартом IEEE 802.11 определено три типа кадров: “управление” (management), “контроль” (control) и “данные” (data). Тип кадра обозначается 2-битным полем в его заголовке и принимает значения 00, 01, 10 для управляющих, контрольных кадров и кадров данных соответственно. Также имеется 4-битное поле подтипа, указывающее конкретный тип управляющего, контрольного кадра или кадра данных (см. Рисунок 1).
​

Рисунок 1 - Типы и подтипы кадров IEEE 802.11
​

Контрольные кадры, которые являются предметом уязвимости CVE-2022-32666, обеспечивают доставку всех остальных типов кадров за счёт реализации функций управления доступом к беспроводной среде и подтверждения приема.
В поправке к стандарту 802.11e-2005 для подтверждения приема блока кадров данных с качеством обслуживания (Quality of Service, QoS) вводятся новые типы кадров: кадры запроса группового подтверждения (Block Ack Request, BAR) и кадры группового подтверждения (Block Ack, BA), имеющие значение типа/подтипа 01/1000 и 01/1001 соответственно (см. Рисунок 2 и 3).
Смысл нововведения - увеличение пропускной способности сети за счёт сокращения объема служебных данных протокола (уменьшения количества одиночных кадров подтверждения, которые необходимо отправить). Кадры группового подтверждения обрабатываются в зависимости от используемой политики: отложенной или немедленной, имеют информационное поле переменной длины.

Информационное поле в кадрах BAR содержит 2-октетное подполе управления начальной последовательностью группового подтверждения (Block Ack Starting Sequence Control), которое состоит из 12-битного номера начальной последовательности (Starting Sequence Number, SSN), содержащего порядковый номер (SN) первой единицы служебных данных MAC (MSDU), для которой отправляется этот кадр BAR, и 4-битного подполя номера фрагмента (Fragment Number, FN), значение которого установлено в 0 (см. Рисунок 2).
​

Рисунок 2 - Содержание кадра BAR
​

Информационное поле в кадрах BA состоит из подполя управления начальной последовательностью группового подтверждения (как и в случае BAR выше) и 8-октетного подполя битовой карты группового подтверждения (Block Ack Bitmap). Как уже указывалось, последнее подполе используется для сигнализации статуса приема не более чем 64 MSDU, агрегированных или нет. Каждый бит, установленный в 1 в битовой карте, подтверждает прием одной MSDU в порядке возрастания SN. Первый бит битовой карты соответствует MSDU с SN, который совпадает со значением подполя SSN в подполе управления начальной последовательностью группового подтверждения.
​

Рисунок 3 - Содержание кадра BA
​

Типовая сеть стандарта 802.11ac или 802.11ax состоит из точки доступа (AP) и ассоциированных с ней станций (STA).

Механизм подтверждения приема блока кадров данных QoS следующий:

• инициатор обмена (STA) передает несколько кадров данных QoS, за которыми следует BAR получателю (AP).

• AP отвечает кадром BA, который включает битовую карту, указывающую, какие кадры были получены.
• кадры, отмеченные в битовой карте нулевым значением, считаются не полученными и подлежат повторной передаче инициатором обмена в следующем блоке данных.

Процедура группового подтверждения инициализируется обменом управляющими кадрами действия (action) типа ADDBA Request/Response. Для установления соглашения о групповом подтверждении инициатор отправляет кадр запроса добавления группового подтверждения (ADDBA) получателю. Получатель отвечает кадром ответа ADDBA. Эти всегда подтверждаемые кадры запроса и ответа содержат информацию о технических возможностях каждого участника обмена, включая размер буфера, поддержку агрегации кадров (A-MSDU) и используемую политику группового подтверждения. Соглашение о групповом подтверждении завершается отправкой инициатором кадра удаления группового подтверждения (DELBA) (см. Рисунок 4).
​

Рисунок 4 - Установление и завершение сессии группового подтверждения ADDBA
​

Согласно § 10.25 стандарта [2], «количество кадров в блоке ограничено, и набор состояний, которое должен фиксировать получатель, ограничен».
В частности, стандарт гласит, что для каждого соглашения о групповом подтверждении должен поддерживаться буфер переупорядочивания приема, содержащий следующие данные:
– любая буферизованная полученная MSDU, агрегированная или нет, которая еще не была передана;
– параметр WinStartB, обозначающий значение подполя SN первой еще не полученной MSDU. Этот параметр инициализируется значением подполя SSN кадра запроса ADDBA, соответствующего кадру ответа ADDBA. SN является частью поля Sequence Control, существующего в любом управляющем кадре или кадре данных.
– параметр WinEndB, обозначающий наибольший SN, ожидаемый к приему в текущем окне приема. Этот параметр инициализируется значением WinStartB + WinSizeB - 1.
– параметр WinSizeB, обозначающий размер окна приема. Он устанавливается равным меньшему из двух значений - “64” или значению поля Buffer Size кадра ответа ADDBA, установившего соглашение о групповом подтверждении. Поле Buffer Size включено в поле Block Ack Parameter Set кадра ответа ADDBA.
Помимо указанного буфера, со стороны получателя фиксируется временная запись группового подтверждения, известная как Scoreboard Context Control, которая включает битовую карту, индексируемую подполем SN.
Самые низкие и высокие SN, обозначенные в битовой карте, называются WinStartR и WinEndR соответственно. Параметр WinSizeR обозначает максимальный размер окна передачи, который устанавливается аналогично WinSizeB.

Со стороны инициатора в свою очередь формируется буфер передачи с параметрами WinStartO и WinSizeO. Первый параметр обозначает SSN окна передачи, а второй — количество буферов, согласованных в соглашении о групповом подтверждении. Буфер передачи освобождается после получения кадра BA от получателя.

Учитывая изложенное и принимая во внимание, что ни кадр BAR, ни кадр BA не являются защищенными [2], любое устройство может быть подвержено атакам, при которых атакующий передает поддельные кадры BAR или BA со случайным SSN или битовой картой группового подтверждения в адрес получателя.

Например, произвольный SSN, переносимый таким поддельным кадром BAR, может запутать буфер или нарушить контекст Scoreboard у получателя.

Уязвимость устраняется текущим стандартом [2], если участники обмена поддерживают процедуру защищенного группового подтверждения. В этом случае получатель не должен обновлять параметр WinStartB на основе информации SSN, передаваемой кадром BAR, в частности, в подполе Starting Sequence Control, включенном в поле информации BAR. Вместо этого инициатор должен отправить надежный (защищенный) кадр запроса ADDBA.
Процедура защищенного группового подтверждения определяется одновременным наличием установленных флагов Management Frame Protection Capable (MFPC), Management Frame Protection Required (MFPR) и Protected Block ack Agreement Capable (PBAC) в поле Robust Security Network (RSN) (см. Рисунок 5).
​

Рисунок 5 – Флаги защищенного группового подтверждения PBAC
(отмечены красным)

Атака I: Блокирование работы любой выбранной STA​

При атаке используется поддельный кадр BAR, в котором MAC-адрес отправителя подменяется на MAC-адрес легитимной STA, а MAC-адрес получателя - на MAC-адрес точки доступа AP (см. рисунок 6).​

Как видно из рисунка, подполе Block Ack Starting Sequence Control поддельного кадра имеет значение FN, равное 4 (согласно стандарту [2] для кадров BAR и BA значение FN должно быть равно 0), и произвольный SSN меньше 2^12, учитывая, что подполе SN 12-битное.

Рисунок 6 - Реализация атаки первого типа
​

Случайный SSN, содержащийся в подполе Block Ack Starting Sequence Control кадра BAR, не имеет отношения к SN кадров данных QoS, ранее переданных от AP к легитимной STA.​

Например, SN отправленных кадров данных QoS от AP к STA находятся в диапазоне от 100 до 120, в то время как подполе Block Ack Starting Sequence Control в поддельном кадре BAR имеет SSN, равный 1175. В любом случае, атака работает с незапрошенными кадрами BAR, то есть не требуется, чтобы легитимная STA и AP ранее использовали обмен данными QoS.

Как показано на рисунке 6, AP всегда отвечает на такие кадры BAR кадром BA, несущим подполе Block Ack Bitmap, состоящее из одних нулей. Тем не менее, такое поведение не соответствует текущему контексту, учитывая, что буфер AP не содержит соответствующей информации.

Возможен второй вариант атаки, при котором атакующий сначала перехватывает кадры данных QoS, которыми обмениваются AP и STA, чтобы узнать SN переданных кадров. После этого один из этих (действительных) SN используется в качестве SSN в поле Information поддельного кадре BAR.​

Атака II: Блокирование всех STA одновременно ​

Результатом этой атаки является то, что прекращается предоставление сервиса QoS всем ассоциированным с целевой точкой доступа (AP) станциям (STA).​

Как видно на рисунке 7, в этом случае атакующим используется фальшивый кадр BA, передаваемый от имени STA точке доступа AP.
Важно отметить, что эта атака эффективна, даже если MAC-адрес отправителя установлен в случайное, но корректно сформированное значение и атакующему не нужно выдавать себя за уже ассоциированную с AP станцию.

Рисунок 7 - Реализация атаки второго типа

Эксплойт Bl0ck​

Bl0ck представляет собой эксплойт для эксплуатации уязвимости CVE-2022-32666 в условиях, приближенных к реальным [3].
Для работы скрипта со стороны атакующего требуется ОС Linux (протестировано на Kali Linux 2025.1) и сетевая Wi-Fi карта с поддержкой стандартов 802.11 ac/ax в режиме мониторинга («monitor mode»).

Для простоты установки зависимостей создадим файл 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==2.5.0

Затем выполним команды установки зависимостей:
sudo apt-get update
sudo apt-get install virtualenv
sudo ./pysetup.sh

Активируем режим мониторинга сетевой карты:
sudo airmon-ng check kill
sudo airmon-ng start wlan1
sudo airodump-ng wlan1

Запустим виртуальное окружение и сам скрипт:
sudo su
source venv/bin/activate
sudo python3 Bl0ck.py -h

Для экспериментальной проверки эксплойта используем тестовый стенд, состоящий из следующего оборудования:
– точка доступа Keenetic Ultra KN-1810 (версия прошивки 4.2.6);
– точка доступа Huawei WS7100 (версия прошивки 2.0.15);
– точка доступа TP-Link AX73 (версия прошивки 1.0.1);
– точка доступа Huawei WS7200 (версия прошивки 10.0.5.15).
– клиентские устройства iPhone 11, OnePlus 11, Samsung Galaxy S20;
– Wi-Fi адаптер для инъекции пакетов EDUP AX1672 на базе чипсета MTK7921AU.

Для работы используем доработанную версию эксплойта (см. вложение).
Инициируем обмен данными QoS на всех клиентских устройствах, например, посредством запуска стриминговых сервисов потокового видео, зафиксируем MAC-адреса устройств.

Команда запуска атаки первого типа (BAR) для блокирования работы выбранной STA:
sudo python3 Bl0ck.py -c {MAC-адрес STA} -b {MAC-адрес AP} -i wlan1 -a BAR -n 300 -r 0 -v 1​

​

Рисунок 8 – Ход выполнения атаки первого типа
на роутер Keenetic Ultra KN-1810
​

На сетевом интерфейсе wlan1 фиксируем излучение поддельных пакетов (BAR) с SSN=1175 (см. Рисунок 9) и появление ответных пакетов от AP (BA) с заполненным нулями полем bitmap (см. Рисунок 10).
​

Рисунок 9 – Поддельный пакет BAR

Рисунок 10 – Ответный кадр BA от уязвимой AP
​

Таким образом установлен факт реакции со стороны AP на кадр BAR, который имеет поле FN с нестандартным значением (“4” вместо “0”) и направлен в адрес AP вне контекста передачи кадра данных QoS.
Такой пакет должен быть отброшен AP, иначе она уязвима к атаке Bl0ck.

После отправки нескольких сотен кадров BAR целевая STA становится неспособной общаться с AP, то есть не может отправлять или получать кадры данных QoS, хотя остается ассоциированной с AP.
Атака повторялась несколько раз, после ее прекращения STA возвращалась в свое нормальное состояние.
В отношении точек доступа Huawei атака успешно проведена с использованием незапрошенных кадров BA вместо кадров BAR.

Для запуска варианта атаки первого типа на основе действительных данных SN используется следующая команда:
sudo python3 Bl0ck.py -c {MAC-адрес STA} -b {MAC-адрес AP} -i wlan1 -a BARS -n 300 -r 0 -v 1

Поскольку все точки доступа оказались уязвимыми к обычной атаке первого типа, этот вариант атаки оказался не менее эффективен.

Команда запуска атаки второго типа (BA) для блокирования работы всех STA:
sudo python3 Bl0ck.py -c {MAC-адрес STA} -b {MAC-адрес AP} -i wlan1 -a BA -n 300 -r 1 -v 1

Как и в случае предыдущей атаки, нескольких сотен атакующих кадров достаточно, чтобы вывести из строя целевую AP, сделав ее неспособной обслуживать все ассоциированные STA; однако STA остаются подключенными к неотвечающей AP.
После прекращения атаки нормальная работа AP восстанавливается без вмешательства пользователя.

Подробные результаты выполнения атак первого и второго типа указаны в таблице 1.

Таблица 1 – Результаты проведения атак первого и второго типа
​

AP	Атака I (BAR)​	Атака I (BA)​	Атака I (вариант)​	Атака II (BA)​
Keenetic Ultra	+​	–​	+​	–​
Huawei WS7100	+​	+​	+​	+​
TP-Link AX73	+​	–​	+​	–​
Huawei WS7200	+​	+​	+​	+​

ЗАКЛЮЧЕНИЕ​

В статье рассмотрена уязвимость беспроводных сетей стандарта Wi-Fi CVE-2022-32666, проведена практическая проверка возможности атак двух разных типов посредством доработанного эксплойта Bl0ck.

В результате установлено, что эксплойт Bl0ck:
– вызывает отказ в обслуживании всех или выбранных STA уязвимых AP;
– имеет высокую скрытность работы (несколько сотен кадров BA или BAR в общем потоке данных, в зависимости от атаки, могут исходить от случайного MAC-адреса отправителя).

Несмотря на то, что защита от уязвимости предусмотрена в актуальной версии стандарта [2], поддержка режима защищенного блочного подтверждения PBAC в исследуемых устройствах Wi-Fi не обнаружена.
Уязвимость CVE-2022-32666 остается актуальной из-за ошибок в драйверах и отсутствия защиты кадров BAR и BA от вмешательства со стороны третьих лиц в современных устройствах.
​

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
​

[1] E. Chatzoglou, V. Kampourakis, G. Kambourakis. Bl0ck: Paralyzing 802.11 connections through Block Ack frames.​

URL: https://arxiv.org/abs/2302.05899

[2] 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.​

IEEE Std 802.11- 2020 (Revision of IEEE Std 802.11-2016) (2021).

[3] Bl0ck attack exploits. URL: https://github.com/efchatz/Bl0ck​