Атака на WPA3. Часть 3. Война продолжается

Вот мы и подошли к финишу, друзья. Представляем вам третью часть, которая завершает наше исследование атак на WPA3....

Атака на WPA3. Часть 3. Война продолжается

Вот мы и подошли к финишу, друзья. Представляем вам третью часть, которая завершает наше исследование атак на WPA3. Сегодня мы подведем итоги и сделаем выводы о способности OWE противостоять угрозам.

С точки зрения риска, OWE практически не отличается от открытого протокола.

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

 – Принятие HTTPS широко распространено. В результате, пассивные атаки работают не надежно с 2005 года

   – Атаки HTTP Downgrade стали в значительной степени неактуальными из-за широкого распространения HSTS.

   – Созданиее поддельных AP по-прежнему представляют собой проблему, поскольку их можно использовать для выполнения атак с использованием портала авторизации и атак со статическим контентом (от которых HTTPS не защитит).

В ходе нашего исследования мы идентифицировали две основные проблемы, OWE. Эти проблемы описаны в следующих подразделах.

OWE не предоставляет механизм для проверки подлинности точки доступа

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

Требования RFC не пользователям различать зашифрованные и незашифрованные соединения. Анализ RFC 8110, определяющей технические характеристики OWE, показывает интересное решение. Согласно Разделу 6 RFC 8110:

OWE является заменой для открытой аутентификации 802.11. Следовательно, когда OWE-совместимые точки доступа обнаружены, в отображении названия точки доступа пользователям не должны быть показаны какие либо обозначения того, что точка безопасна, такие символы, как «замка». Для пользователя OWE SSID должна выглядеть также, как такой же, как обычная открытая сеть.

По моему личному мнению, широкое внедрение OWE займет годы, и если попытки отказаться от WEP станут признаком будущего успеха, маловероятно, что открытый WiFi когда-либо будет полностью забыт. Существует причина, по которой веб-браузеры отображают значок “замка” при подключении к серверу по протоколу HTTPS – пользователи должны знать, когда их данные защищены, а когда передаются в чистом виде.

Поскольку RFC 8110 допускает, что OWE ничего не даёт для защиты пользователей от активных атак, отображение значка блокировки может вводить пользователей в заблуждение. Пользователи, которые не знают об ограничениях OWE, могут ошибочно полагать, что OWE предлагает надежную защиту от современных беспроводных угроз.

Похоже, что производители устройств приняли эту проблему во внимание и намеренно игнорировали RFC 8110, отображая отличительный значок (хотя и не обязательно означающий шифрование). Например, Android 9 на Razer 3 позволяет пользователям различать OWE и открытые точки доступа:

Однако, еще неизвестно, будет ли так во всех операционных системах и устройствах.

Методология исследования и результаты

При исследовании этой темы мы старались придерживаться научного метода.

Вопрос: подвержены ли OWE атакам, и если да, то каким?

Гипотеза: OWE подвержен атакам

Эксперимент: мы разбили на несколько этапов, которые описаны ниже

Анализ: мы проанализировали результаты

Вывод: наш вывод заключается в том, что гипотеза верна и OWE не дает существенных преимуществ по сравнению с открытыми беспроводными сетями.

Эксперимент

Эксперимент был разбит на следующие этапы:

 – Попытка создать рабочую точку доступа OWE с помощью hostapd

 –  Попытка подключить станцию ​​(wpa_supplicant) к точке доступа OWE

  Убедившись, что точка доступа и станция правильно внедрили OWE, мы использовали Wireshark для проверки трафика.

  – Попытка выполнить проверку концептуальных атак на точку доступа OWE.

Мы следовали тем же процедурам при оценке OWE.

Из этих четырех этапов, первые три фактически оказались наиболее сложной и трудоемкой частью всего проекта, главным образом из-за отсутствия документации. Напомним, что мы начали наше исследование в апреле 2019 года. Ни один из параметров конфигурации, необходимых для создания или подключения к точке доступа OWE, не был публично задокументирован в то время. На самом деле мы закончили создание рабочих файлов конфигурации для hostapd и wpa_supplicant путем обратного инжиниринга набора тестов hostap, который состоял из более чем 100 000 строк кода Python. Затем мы убедились, что наши конфигурации были правильными, следуя процессу, аналогичному тому, который описан во второй части этой серии.

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

OWE Evil Twin Attack

В этом пошаговом руководстве предполагается, что вы уже выполнили шаги настройки, описанные в части II:

Из вашего каталога owe-lab создайте точку доступа OWE на wlan0, скопировав файл конфигурации, найденный в conf-files / hostapd-owe.conf, в hostapd. Обратите внимание, что это тот же файл конфигурации, который мы использовали во второй части этой серии. Если вам интересно, что делает этот конфигурационный файл, вы можете найти там подробное объяснение.

./hostapd conf-files/hostapd.conf

Затем подтвердите, что hostapd правильно создал точку доступа OWE, как показано на следующем снимке экрана (более подробное объяснение того, что мы ищем в Wireshark, см. В части II).

Затем скопируйте файлы конфигурации из conf-files/wpa_supplicant-owe.conf, в wpa_supplicant, чтобы подключить wlan1 в качестве клиентского устройства к точке доступа, работающей на wlan0.

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

Затем, используя eaphammer, создаем двойника нашей точки доступа OWE, которая работает на wlan0 (обратите внимание, что мы используем wlan2 для создания поддельной точки).

./eaphammer -i wlan2 --captive-portal --auth owe --essid owe

Дальше сложная часть – заставить станцию работать на wlan1 для подключения к нашей фейковой точке доступа, работающей на wlan2. Есть два способа выполнить атаку:

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

Атака на процесс выбора сети: работает, когда станция в настоящее время не подключена ни к одной беспроводной сети. Мы заставляем станцию подключаться к нашей точке доступа, используя ESSID, который находится в списке предпочтительных сетей (PNL) рабочей станции.

Если целевая рабочая станция уже подключена к точке доступа, что означает, что атака на процесс роуминга 802.11 наиболее целесообразно. Однако OWE использует защищенные фреймы управления, что не позволяет нам подделывать пакеты деаутентификации для принудительного роуминга станции [2]. Таким образом, мы вынуждены заманивать станцию ​​к нам, предоставляя наиболее мощный сигнал.

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

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

Когда правильная точка доступа более недоступна, станция, работающая на wlan1, начинает поиск другой точки доступа с тем же ESSID для подключения. Наш Ewil Twin, работающий на wlan2, отвечает на запрос, и станция подключается к нему, как показано на следующих двух скриншотах.

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

./eaphammer -i wlan2 --captive-portal --auth owe --essid owe

Наконец, мы можем проверить с Wireshark:

(wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol) && wlan.bssid == 00:11:22:33:44:00

Вот и все – мы успешно провели атаку на сеть, защищенную OWE.

Подтверждение результатов концепции: OWE Transition Mode

Мы также предприняли аналогичные атаки на режим OWE Transition. Подробное описание этих концептуальных атак не приводится. Тем не менее, наши результаты должны быть достаточными для повторения. Кроме того, EAPHammer Wiki предоставляет инструкции для выполнения AP-атак на OWE Transition Mode:

https://github.com/s0lst1c3/eaphammer/wiki/XV.-Attacking-Opportunistic-Wireless-Encryption

Вывод

Внедрение OWE WiFi Alliance – это верный шаг, поскольку это поможет поддержать шифрования для неаутентифицированных беспроводных сетей. Однако, не предоставляя решения для проверки подлинности точек доступа, OWE WiFi Alliance не в состоянии смягчить угрозу атак злоумышленников на открытые сети. Таким образом, OWE WiFi Alliance не может снизить риск, связанный с неаутентифицированной беспроводной связью. Тот факт, что использование обязательных защищенных фреймов управления (PMF) является обязательным, является положительным фактором, поскольку делает атаки на фейковые точки доступа более трудными.

Все новое – хорошо забытое старое. И с новыми стандартами ничего нового даже и не придумали. OWE уязвима. Что и требовалось доказать.

Очень злой админ
Очень злой админ Автор статьи

Админ сайта. Публикует интересные статьи с других ресурсов, либо их переводы. Если есть настроение, бывает, что пишет и что-то своё.