Война продолжается: атаки на расширенный открытый WPA3/ Часть 2. Привет, OWE!

В эфире вторая часть нашего большого исследования атак на WPA3 и сегодня мы расскажем, как работает OWE.

OWE — это средство шифрования открытых сетей. И это то, чего не было в стандарте 802.11 за последние 20 лет. Предполагается, что OWE неотличим от открытого Wi-Fi с точки зрения пользователя – пользователь просто подключается к защищенной сети OWE, и после короткого обмена ключами вся последующая связь шифруется.

На первый взгляд, это звучит замечательно – пока вы не обнаружите, что OWE защищает только от пассивных атак.

OWE следует пятиэтапному процессу, который начинается с обнаружения сети и завершается передачей зашифрованных данных между клиентом и точкой доступа. Мы рассмотрим каждый из этих этапов в следующих разделах, а также обсудим важную дополнительную информацию. 

Песочница

Итак, я подготовил набор сценариев установки для создания тестового окружения.

Обратите внимание, что эти сценарии установки предназначены для Kali 5.3.7, и я не планирую поддерживать их или предоставлять поддержку для любой другой операционной системы. Программное обеспечение не является статичным, это на случай, если вы читаете статью в 2025 году, а сценарий установки не работает, ну … вы сами понимаете …

Чтобы создать тестовое окружение, сначала используйте git clone для получения сценариев от Github:

git clone https://github.com/s0lst1c3/owe-lab

Затем запустите скрипт установки:

cd owe-lab
./lab-setup

Если скрипт установки успешно завершен, у вас должна появиться директория, которая выглядит следующим образом:

Как вы можете видеть на скриншоте выше, скрипт установки создаст тестовое окружение с каждым из следующих компонентов:

– Виртуальная точка доступа и базовая станция

– Wireshark Dev Branch

– EAPHammer

– AP и файлы конфигурации станции

– Скрипты управления аппаратным симулятором

 Я кратко опишу каждый из этих компонентов в следующих разделах.

Виртуальная точка доступа и базовая станция

Это только последние версии wpa_supplicant и hostapd с зависимостями, разрешенными и скомпилированными с поддержкой OWE и одновременной проверки подлинности на равных (SAE).

Wireshark Dev Branch

 Мы будем использовать Wireshark как для анализа, так и для проверки того, что все в лаборатории работает так, как нужно. Для поддержки OWE и SAE нам нужна последняя версия Wireshark, которую можно скомпилировать только из исходного кода. К счастью, скрипт позаботится об этом.

EAPHammer

 Комплект беспроводных атак с поддержкой OWE для проверок концепции (побочный продукт этого исследования).

 AP и файлы конфигурации станции

Тестовое окружение включает каталог conf-files, содержащий набор файлов конфигурации wpa_supplicant и hostapd для открытых сетей, режимов OWE и OWE Transition. На момент нашего исследования реализация OWE в hostapd еще находилась в стадии разработки. Следовательно, ни один из параметров конфигурации, необходимых для создания или подключения к точке доступа OWE, не был задокументирован. Не имея общедоступной документации, мы закончили тем, что обратились к обзору кода пакета whitebox модульного тестирования hostap (более 100,00 строк кода) для создания этого относительно простого набора рабочих файлов конфигурации.

Скрипты управления аппаратным симулятором

 Стек Wi-Fi mac80211 (подсистема ядра, которая работает с Wi-Fi) поставляется с модулем ядра с именем mac80211_hwsim, который можно использовать для моделирования произвольного числа виртуальных беспроводных интерфейсов и передачи виртуального трафика WiFi между ними. Мы используем исключительно mac80211_hwsim.

Чтобы включить модуль ядра mac80211_hwsim, используйте modprobe, как показано в примере ниже. Переменная radios используется для указания количества создаваемых виртуальных интерфейсов.

modprobe mac80211_hwsim radios=3

В качестве альтернативы вы можете просто запустить скрипт enable-hwsim:

./enable-hwsim

После включения mac80211_hwsim вы можете просматривать созданные вами интерфейсы с помощью команды iwconfig. В Kali (и любом другом дистрибутиве на основе Debian в этом отношении) вновь созданные интерфейсы будут создаваться по модели wlanX, где X – положительное целое число. Вы также заметите новый интерфейс с именем hwsim0. На самом деле это тап-интерфейс, который можно использовать для захвата трафика, передаваемого между интерфейсами wlanX.

Чтобы разрушить виртуальную среду, используйте команду rmmod, как показано в следующем примере:

rmmod mac80211_hwsim

Справочная информация

Прежде чем мы продолжим, нам нужно просмотреть некоторую справочную информацию. Если вы не знакомы с тем, как работает 802.11, я рекомендую просмотреть следующую запись блога:

https://posts.specterops.io/modern-wireless-attacks-pt-i-basic-rogue-ap-theory-evil-twin-and-karma-attacks-35a8571550ee

В дополнение вам необходимо кратко охватить следующие понятия:

   Кодирование длины типа (TLV)

   Информационные элементы

   Элементы надежной сети безопасности (RSN)

   Селекторы пакета управления ключами аутентификации (AKM)

Кодирование элементов и типа-длины-значения (TLV)

 Тип-длина-значение (TLV) – это схема кодирования, которая используется в протоколах связи для добавления информации к отдельным сообщениям (в данном случае к пакетам). TLV опирается на структуры данных, называемые элементами.

Информационные элементы (IE) – это элементы, используемые для добавления метаданных в кадры управления (MF). Фреймы beacon-a, тестовые запросы, тестовые ответы и фреймы связи создаются путем добавления IE друг к другу.

Давайте сосредоточимся на фреймах beacon-a. Как вы, возможно, помните, фреймы периодически передаются точками доступа (AP), чтобы сообщить о своем присутствии и возможностях соседним станциям. IE – это структура данных, которая делает это возможным. Чтобы проиллюстрировать это, давайте откроем фрейм beacon-a в Wireshark и посмотрим, как он устроен. Здесь я использую следующий пример захвата из вики:

https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=Network_Join_Nokia_Mobile.pcap

Самый первый пакет в захвате – это фрейм beacon-a. Выбор этого фрейма в Wireshark открывает три раскрывающихся меню (в зависимости от конфигурации Wireshark они могут быть уже расширены):

Развертывание самого нижнего меню на снимке экрана выше открывает два новых меню:

Нас интересует выпадающий список с пометкой «Параметры с тегами». Развернув меню «Параметры с тегами», вы увидите список IE, который в Wireshark известен как «теги»:

Чтобы увидеть, как 802.11 использует кодировку TLV в действии, щелкните IE «Набор параметров SSID», чтобы развернуть его, как показано на следующем снимке экрана:

Первое поле IE (номер тега) указывает его тип данных, который в этом случае является «набором параметров SSID». Следующее поле IE – это поле длины его значения, которое в данном случае равно 9. Последнее поле IE – это его значение, которое, как мы знаем, представляет собой 9-байтовый SSID из-за полей типа и длины в IE.

Большая часть метаданных фрейма beacon-a хранится в IE, которые следуют этому формату Type-Length-Value. Другие фреймы управления построены аналогично.

Фаза 1 OWE: обнаружение сети

 Зачем мы так много времени говорили о кодировании Type-Length-Value (TLV) и информационных элементах (IE)? Они очень важны для понимания того, как OWE работает на уровне пакетов. Чтобы увидеть это, давайте рассмотрим процесс аутентификации OWE в Wireshark.

 Начните с включения имитируемых интерфейсов WiFi с помощью сценария enable-hwsim, поставляемого в тестовом окружении:

./enable-hwsim

Затем задайте Network Manager отказ от контроля над вашими интерфейсами hwsim0, wlan0 и wlan1 и перевод интерфейсы hwsim0, wlan0 и wlan1 в режим онлайн:

nmcli device set wlan0 managed off
nmcli device set wlan1 managed off
nmcli device set hwsim0 managed off
ifconfig wlan0 up
ifconfig wlan1 up
ifconfig hwsim0 up

Затем откройте Wireshark из каталога вашего окружения и установите его на прослушку интерфейса hwsim0, как показано на следующем снимке экрана:

Затем создайте экземпляр точки доступа OWE с помощью hostapd. Мы сделаем это, предоставив hostapd следующий файл конфигурации, который можно найти в каталоге conf-files:

# use interface wlan0
interface=wlan0# set ssid to "owe"
ssid=owe# manually set BSSID
bssid=a6:44:ce:d8:61:6f# set channel to 1
channel=1 # require Protected Management Frames (PMF)
ieee80211w=2# enable full IEEE 802.11i/RSN
wpa=2# set key management element to OWE
wpa_key_mgmt=OWE # set RSN pairwise cipher to CCMP
rsn_pairwise=CCMP

Чтобы запустить точку доступа, просто передайте hostapd соответствующий файл конфигурации, как показано в следующей команде:

./hostapd conf-files/hostapd-owe.conf

Вернувшись в окно Wireshark, отфильтруйте фреймы beacon-a с вашей точки доступа, используя следующий фильтр:

wlan.fc.subtype == 0x8 && wlan.bssid == a6:44:ce:d8:61:6f

После применения фильтра выберите один из пакетов и разверните меню «Параметры с тегами», как показано на следующем снимке экрана:

Затем разверните тег «Информация RSN», как показано на следующем снимке экрана:

Затем разверните теги «Список управления ключами аутентификации> Пакет управления ключами аутентификации (AKM)», как показано на следующем снимке экрана:

Вот важная часть: обратите внимание на значение элемента «Тип управления ключами (AKM)». Точки доступа (AP), которые поддерживают OWE, объявляют о своей поддержке протокола с помощью селектора Suite проверки подлинности и управления ключами (AKM), который добавляется к элементу RSN всех beacon-a и тестовых фреймов ответа, которые выдает AP. Базовые станции, которые поддерживают OWE, распознают наличие этого элемента и используют его для идентификации соседних точек доступа, которые поддерживают OWE.

Теперь давайте рассмотрим, что происходит, когда мы подключаем базовую станцию ​​к точке доступа. Для этого мы будем использовать бинарный файл wpa_supplicant нашего окружения со следующим файлом конфигурации:

# OWE network
network={
 ssid="owe" # connect to SSID "owe"
 frequency=2412 # connect to channel 1 (center freq 2412)
 key_mgmt=OWE # use OWE
 proto=RSN # use RSN
 ieee80211w=2 # use Protected Management Frames (PMF)
 pairwise=CCMP # set pairwise cipher suite to CCMP
}

Чтобы подключиться к точке доступа OWE, передайте wpa_supplicant соответствующий файл конфигурации, как показано в следующей команде:

./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-owe.conf

Базовая станция распознает точку доступа как OWE-совместимую и с ее помощью инициирует аутентификацию в открытой системе (аутентификация в открытой системе – просто причудливый способ сказать, что «аутентификация на самом деле не происходит»). Вы можете увидеть процесс аутентификации в Wireshark, используя следующий фильтр:

wlan.fc.type_subtype == 0xb

OWE Фаза 2: Ассоциация

 Как только клиентское устройство выполнило аутентификацию открытой системы с точкой доступа (AP), клиент и AP переходят к процессу ассоциации 802.11. Во время ассоциации происходит обмен ключами Диффи-Хеллмана (DH) OWE и четырехстороннее рукопожатие.

Помните, что OWE является формой криптографии с открытым ключом – и клиент, и AP должны иметь возможность обмениваться ключами DH друг с другом, чтобы обеспечить безопасную связь. Как и на этапе обнаружения сети, этот обмен ключами облегчается с помощью информационных элементов (IE), которые добавляются к кадрам запроса и ответа на ассоциацию. Когда базовая станция отправляет запрос на ассоциацию к точке доступа, элемент DH-параметра добавляется к кадру зондирующего запроса. Этот элемент параметра DH содержит открытый ключ базовой станции. Затем точка доступа отвечает фреймом ответа ассоциации, к которому ее открытый ключ добавляется в свой собственный элемент параметра DH.

Давайте рассмотрим этот процесс, изолировав процесс ассоциации, используя следующий фильтр (который фильтрует для запроса ассоциации и фреймов ответа):

wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1

Если мы выберем первый отображаемый пакет (который является запросом на ассоциацию), мы заметим, что он содержит расширенный тег с именем «Параметр Диффи-Хеллмана OWE», как показано на следующем снимке экрана.

Расширение тега «OWE Diffie-Hellman Paramater» раскрывает открытый ключ базовой станции:

Точно так же выбор соответствующего кадра ответа ассоциации также показывает наличие расширенного тега с именем «Параметр Диффи-Хеллмана OWE», который содержит открытый ключ точки доступа.

Процесс обмена открытыми ключами таким способом известен как обмен ключами Диффи-Хеллмана (DH).

OWE Фаза 3: Постассоциация

 Как только клиент и AP завершили процесс связывания, а также обмен ключами DH, создается парный главный ключ (PMK). PMK присваивается уникальный идентификатор, известный как идентификатор парного главного ключа (PMKID). Затем AP инициирует четырехстороннее рукопожатие с клиентом, в котором PMK используется для создания ключей шифрования.

 Вы можете видеть, как это рукопожатие происходит в Wireshark, изолируя пакеты EAPOL с помощью следующего фильтра:

EAPOL

OWE, фаза 4: передача данных

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

Обратите внимание, что во всем этом процессе однозначно отсутствует одна вещь: сертификаты.

OWE переходный режим

 Режим OWE Transition был разработан для обеспечения открытого доступа к сети как для новых устройств с поддержкой OWE, так и для устаревших устройств, которые не поддерживают OWE.

 Вот как это работает. Точки доступа, настроенные для использования режима перехода OWE, фактически обслуживают два базовых набора услуг (BSS) одновременно. Первый BSS – это открытая точка доступа с видимым ESSID. Второй BSS сконфигурирован для использования OWE, и ему присваивается случайно сгенерированный ESSID, который отличается от ESSID открытой точки доступа. Это второе OWE также скрыто, что означает, что его можно обнаружить только с помощью направленных тестовых запросов.

Чтобы создать точку доступа, которая соответствует этой конфигурации, мы используем файл конфигурации, подобный показанному ниже. Обратите внимание, что этот файл конфигурации устанавливает две BSS одинакового беспроводного интерфейса – один открытый и один с поддержкой OWE. Параметры конфигурации owe_transition_ssid и owe_transition_bssid используются для связывания двух BSS. Если этот файл конфигурации кажется запутанным, не бойтесь двигаться дальше. Это будет иметь больше смысла после изучения того, что AP и станция делают в Wireshark.

# general ---interface=wlan0 
ssid=owe-hidden 
bssid=a6:44:ce:d8:61:6f 
channel=1
ignore_broadcast_ssid=1 
ieee80211w=1 # owe_transition ---wpa=2 
wpa_key_mgmt=OWE 
rsn_pairwise=CCMP 
owe_transition_ssid="transition"
owe_transition_bssid=fe:e1:de:ce:a5:ed# populate_owe_transition_open_bss ---bss=wlan0_0
ssid=transition
bssid=fe:e1:de:ce:a5:ed
owe_transition_ssid="owe-hidden"
owe_transition_bssid=a6:44:ce:d8:61:6fwpa=2 
wpa_key_mgmt=OWE 
rsn_pairwise=CCMP 

Давайте посмотрим, что на самом деле делает этот файл конфигурации, используя его для создания точки доступа в режиме OWE Transition, а затем проанализировав его в Wireshark. Начните с запуска hostapd с файлом конфигурации, показанным в следующей команде:

./hostapd conf-files/hostapd-owe-transition.conf

Затем выполните фильтрацию фреймов beacon-a в Wireshark, используя следующий фильтр:

wlan.fc.type_subtype == 0x8

Вы должны увидеть серию фреймов beacon-a, передаваемых двумя разными точками доступа, как показано на следующем снимке экрана.

Обратите внимание, что примерно половина этих фреймов beacon-a поступает с BSS с SSID, установленным на «переход», тогда как остальные поступают с BSS, SSID которого скрыт. Давайте сосредоточимся на видимой сети, отфильтровывая ее BSSID:

wlan.ssid == transition

Если мы выберем один из фреймов beacon-a и развернем его отмеченные параметры, как показано на следующем снимке экрана, мы увидим специфический для поставщика элемент типа «Режим перехода OWE».

Эта часть очень важна: расширение этого специфичного для поставщика элемента показывает BSSID точки доступа вместе с ее SSID («owe-hidden»).

Этот специфический для поставщика элемент является одним из ключей к функционированию OWE Transition Mode – для подключения к AP переходного режима базовые станции сначала отправляют пробный запрос на открытый ESSID точки доступа. Базовые станции, которые поддерживают OWE, будут проверять наличие элемента режима перехода OWE в ответе пробы AP, а также любых последующих кадров радиомаяка, передаваемых AP. Если элемент присутствует, станция затем сделает пробный запрос на скрытый ESSID BSS, чтобы инициировать соединение с ним. Клиентские устройства, которые не поддерживают OWE, будут игнорировать элемент режима OWE Transition и просто подключатся к открытой BSS.

Давайте рассмотрим этот процесс с точки зрения станции. Мы начнем с того, что расскажем wpa_supplicant, что наша точка доступа в переходном режиме рассматривается как открытая ESS, передав ей следующий файл конфигурации:

# OWE network
network={
 ssid="transition"
 frequency=2412
 key_mgmt=NONE
}

Инициализируйте wpa_supplicant, используя следующую команду, и наблюдайте, как он подключается к точке доступа в переходном режиме:

./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-transition-open.conf

Мы также можем видеть станцию, соединяющуюся с AP с точки зрения AP:

Мы можем использовать следующий фильтр, чтобы изолировать процесс соединения в Wireshark (замените аппаратный адрес вашей станции 02: 00: 00: 00: 01: 00).

wlan.addr == 02:00:00:00:01:00 && wlan.addr == fe:e1:de:ce:a5:ed && wlan.fc.type == 0x0

Как видно на скриншоте, показанном выше, процесс идентичен тому, что происходит с открытой сетью.

Теперь давайте выполним тот же анализ, на этот раз передавая wpa_supplicant файл конфигурации, который говорит ему обрабатывать нашу точку доступа в переходном режиме как OWE ESS:

# OWE network
network={
 ssid="transition"
 frequency=2412
 key_mgmt=OWE
 proto=RSN
 ieee80211w=2
 pairwise=CCMP
}

Вы можете увидеть этот процесс в действии (с точки зрения клиента) на следующем снимке экрана, который показывает выходные данные отладки, сгенерированные wpa_supplicant, когда он подключается к горячей точке OWE Transition Mode.

./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-transition-open.conf

На скриншоте, показанном выше, wpa_supplicant сначала пытается подключиться к открытой точке доступа. Затем он узнает, что открытая горячая точка на самом деле является сетью режима перехода OWE, и анализирует ESSID его скрытой OWE BSS из конкретного тега поставщика. Наконец, wpa_supplicant перемещается к скрытому OWE BSS.

Вывод

 Следующий и последний пост в этой серии будет посвящен ограничениям OWE. До встречи на канале!

Вас ебали, ебут и будут ебать. Государство, хакеры, чиновники.
Остановить эту свингер-пати невозможно. Но мы научим предохраняться.
Следите за новостями на нашем канале @cybersecs или на сайте
cybersec.org