vanhoefm/fragattacksАвтоматизированный инструмент проверки уязвимостей для Wi-Fi-клиентов и точек доступа, обнаруживающий уязвимости фрагментации/агрегации FragAttacks с помощью инъекции кадров, тестирования в смешанном режиме и анализа перехваченных пакетов.
Этот репозиторий содержит инструмент FragAttacks. С его помощью можно проверять Wi-Fi-клиенты и точки доступа на наличие frагментационных и agрегационных атак. Эти уязвимости затрагивают все защищённые Wi-Fi-сети. Дополнительную информацию об этих уязвимостях можно найти на сайте fragattacks.com.
Также доступны следующие дополнительные материалы:
Подробный обзор обновлений инструмента, сделанных после 11 августа 2020 года, приведён в журнале изменений. В этом журнале изменений также указано, на какой версии hostap основан инструмент FragAttacks.
Обратите внимание, что атаки идентичны для WPA2 и WPA3, поскольку их шифры CCMP и GCMP идентичны. Для старых сетей WPA по умолчанию используется TKIP для шифрования, а применимость атак против TKIP обсуждается в статье и на сайте. Чтобы показать, что Wi-Fi уязвим с момента его создания, в статье и на сайте также кратко обсуждается применимость атак против WEP.
Поддерживаются только определённые беспроводные сетевые карты. Это связано с тем, что некоторые сетевые карты могут перезаписывать номер последовательности или фрагмента внедряемых кадров либо изменять порядок кадров разного приоритета, что мешает работе тестового инструмента (т.е. инструмент может сообщить, что устройство защищено, хотя это не так). Я подтвердил, что следующие сетевые карты работают корректно:
Последние два столбца означают:
Смешанный режим: можно ли использовать сетевую карту в рекомендуемом смешанном режиме.
Режим внедрения: можно ли использовать сетевую карту в качестве второго интерфейса для внедрения кадров в режиме внедрения.
Да означает, что карта работает без дополнительной настройки в указанном режиме. Патченный драйвер/прошивка означает, что карта совместима при использовании с патченными драйверами и/или прошивкой. Нет означает, что этот режим не поддерживается сетевой картой. Я рекомендую использовать тестовый инструмент в смешанном режиме.
Обратите внимание, что USB-устройства можно использовать внутри виртуальной машины, а модифицированные драйверы и/или прошивку можно установить в этой виртуальной машине. Однако я обнаружил, что использование виртуальных машин может снижать надёжность сетевых карт, и вместо этого рекомендую использовать живой USB-образ, если вы не можете установить модифицированные драйверы/прошивку в основной системе.
Мой опыт работы с указанными выше сетевыми картами описан здесь. Если кратко:
AWUS036ACM в смешанном режиме выглядит надёжной с нашими последними драйверами, и именно её я рекомендую. Более дешёвое, но почти идентичное устройство — карта на чипсете MT7612U. Подробнее см. здесь.
Ранее я рекомендовал Technoethical N150 HGA в смешанном режиме. Этот адаптер идентичен TP-Link TL-WN722N v1.x и требует использования патченных драйверов и прошивки. Это один из наиболее хорошо протестированных адаптеров, но его трудно достать. Именно поэтому теперь я рекомендую AWUS036ACM.
Intel 3160 и 8265 поддерживаются и extensively протестированы. Иногда их прошивка падала, но перезагрузка делает сетевую карту снова работоспособной. Intel AX200 не совместим с тестовым инструментом.
WN111v2, похоже, работает хорошо, хотя я не тестировал его extensively.
Драйвер для AWUS036ACH не входит в состав ядра Linux и требует установки отдельного драйвера. В Kali этот драйвер можно установить через менеджер пакетов. Эта карта не была extensively протестирована.
Если вы не можете найти одну из указанных выше сетевых карт, можно поискать альтернативные сетевые карты, которые с высокой вероятностью тоже будут работать. При использовании сетевой карты, которая явно не поддерживается, я настоятельно рекомендую сначала запустить тесты внедрения перед использованием, а также применить инструмент к заведомо уязвимой реализации, чтобы убедиться, что инструмент работает корректно.
Тестовый инструмент проверялся на Ubuntu 20.04 с ядром 5.8. Если вы используете другой дистрибутив Linux, учтите, что поддерживаются только версии ядра не выше 5.12.
При использовании Ubuntu 20.04 сначала необходимо установить ядро 5.8 следующим образом. Обратите внимание, что ваше существующее ядро останется установленным и по-прежнему будет использоваться по умолчанию:
sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic
Теперь перезагрузите Ubuntu, во время загрузки удерживайте клавишу Shift, выберите «Advanced options for Ubuntu» и запустите ядро 5.8, выбрав «Ubuntu, with Linux 5.8.0-63-generic». Вы можете изменить конфигурацию GRUB, чтобы Ubuntu использовала эту версию ядра по умолчанию. Продолжите следующие инструкции уже под этим запущенным ядром.
Установите необходимые зависимости:
sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
aircrack-ng rfkill firmware-ath9k-htc
# Примечание: в Kali Linux используйте пакет firmware-atheros вместо firmware-ath9k-htc
Теперь склонируйте этот репозиторий, соберите инструменты и настройте виртуальное окружение python3:
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh
Приведённые выше инструкции нужно выполнить только один раз. После получения нового кода через git необходимо
снова выполнить ./build.sh и ./pysetup.sh.
Установите патченные драйверы с помощью:
sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install
Эта команда компилирует драйверы для большинства сетевых карт, поддерживаемых Linux. Если вы хотите скомпилировать
только драйверы для сетевых карт, которые я явно тестировал, используйте вместо этого make defconfig-experiments.
Вы можете получить следующие предупреждения:
make defconfig-wifi могут появляться предупреждения, связанные с -Wyacc и -Wformat-overflow.
Их можно игнорировать, если драйверы успешно компилируются... needs unknown symbol ... Их можно игнорировать, если
они не содержат каталог /lib/modules/*/updates/ и скомпилированные драйверы работают.SSL error и команду sign-file. Это означает, что цифровая
подпись модулей ядра не удалась. Обычно это можно игнорировать.cat /sys/module/mac80211/parameters/fragattack_version
после перезагрузки. Если этот файл существует, модифицированные драйверы установлены успешно.Теперь установите патченную прошивку ath9k_htc:
cd research/ath9k-firmware/
./install.sh
# Теперь перезагрузитесь
Скрипт ./install.sh предполагает, что образы прошивки ath9k_htc находятся в
каталоге /lib/firmware/ath9k_htc. Если в вашей системе это не так, вам
придётся вручную скопировать htc_7010.fw и htc_9271.fw в соответствующий каталог.
После установки патченных драйверов и прошивки необходимо отключить Wi-Fi-адаптеры и перезагрузить систему. Приведённые выше инструкции нужно выполнить снова, если ваше ядро Linux будет обновлено или если будут обновлены патченные драйверы.
Обратите внимание, что даже если ваше устройство работает без дополнительной настройки, я всё равно рекомендую установить модифицированные драйверы, поскольку это гарантирует отсутствие непредвиденных регрессий в коде ядра и драйверов.
Если вы не можете установить модифицированные драйверы/прошивку в основной системе, можно загрузить живой USB-образ, содержащий модифицированные драйверы/прошивку вместе с нашим тестовым инструментом. В качестве альтернативы можно использовать виртуальную машину с USB-сетевыми картами, хотя я обнаружил, что использование виртуальной машины на практике менее надёжно.
Каждый раз, когда вы хотите использовать тестовый инструмент, сначала нужно загрузить виртуальное окружение python от имени root. Это можно сделать с помощью:
cd research
sudo su
source venv/bin/activate
Теперь следует отключить Wi-Fi в вашем менеджере сети,
чтобы он не мешал работе тестового инструмента. Также убедитесь, что другие сетевые службы не вызывают
исходящий трафик. Это можно гарантировать, заблокировав трафик с помощью iptables, выполнив ./droptraffic.sh
(отменить это можно перезагрузкой). При желании выполните sudo airmon-ng check, чтобы увидеть, какие ещё
процессы могут использовать беспроводную сетевую карту и мешать работе нашего инструмента.
Тестовый инструмент может проверять как клиентов, так и точки доступа:
Проверка точек доступа: настройте точку доступа, которую хотите протестировать, отредактировав research/client.conf. Это
стандартный файл конфигурации wpa_supplicant; см. документацию hostap
для обзора всех поддерживаемых параметров.
Проверка клиентов: необходимо запустить тестовый инструмент с параметром --ap (см. ниже). Это
заставит инструмент создать точку доступа с именем testnetwork и паролем abcdefgh. Подключитесь
к этой сети с помощью клиента, который хотите проверить. По умолчанию клиент должен запросить IP-адрес
через DHCP. Чтобы изменить свойства создаваемой точки доступа, например канал, на котором она создаётся,
можно отредактировать research/hostapd.conf.
Этот режим требует только одну беспроводную сетевую карту, но обычно требует патченный драйвер и/или прошивку. См. раздел Патченные драйверы о том, как установить патченные драйверы/прошивку, и Поддерживаемые сетевые карты для списка совместимых сетевых карт. Запустите тестовый инструмент в этом режиме с помощью:
./fragattack.py wlan0 [--ap] $COMMAND
Возможные значения $COMMAND перечислены в разделах проверка на уязвимости
и расширенные тесты уязвимостей.
Одно из преимуществ этого режима — он довольно хорошо работает при тестировании клиентов, которые могут переходить в спящий режим. Тем не менее, если возможно, я рекомендую отключить функцию сна у тестируемого клиента, см. Обработка спящего режима.
Этот режим требует две беспроводные сетевые карты: одна будет действовать как точка доступа или клиент, а другая будет использоваться для внедрения кадров. Преимущество в том, что этот режим может работать без патченных драйверов. Запустите тестовый инструмент в этом режиме с помощью:
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
Здесь интерфейс wlan0 будет действовать как легитимный клиент или точка доступа, а wlan1 будет использоваться для внедрения кадров. Для wlan0 подойдёт любая карта, поддерживающая обычный режим клиента или точки доступа в Linux. Для wlan1 необходимо использовать карту, поддерживающую режим внедрения согласно Поддерживаемым сетевым картам.
При тестировании клиентов в этом режиме внедряемые кадры могут отправляться, когда клиент находится в спящем состоянии. Это приводит к сбою атак, поэтому необходимо убедиться, что клиент не перейдёт в спящее состояние.
Этот режим является экспериментальным и предназначен только для исследовательских целей. См. подробности о режиме hwsim для получения дополнительной информации.
Вы можете проверить устройства, запустив тестовый инструмент, как описано в разделе режимы интерфейса,
и заменив $COMMAND одной из команд в таблице ниже. Мы предполагаем, что клиенты будут
запрашивать IP-адрес через DHCP (если это не так, см. статическая настройка IP).
Все команды работают как с клиентами, так и с точками доступа, если не указано иное.
Инструмент выводит TEST COMPLETED SUCCESSFULLY, если устройство уязвимо к атаке, соответствующей
заданной $COMMAND, и выводит Test timed out! Retry to be sure, or manually check result, если
устройство не уязвимо. После завершения теста можно закрыть инструмент с помощью CTRL+C.
У большинства атак есть несколько небольших вариантов, представленных разными значениями $COMMAND.
Проверка результата некоторых тестов требует запуска tcpdump или wireshark на тестируемом устройстве (в таблице ниже указано, нужно ли использовать tcpdump). Этот захват пакетов tcpdump должен включать только пакеты, которые прошли обработку на PHY и MAC уровнях. Например, в Linux такой захват следует выполнять, пока беспроводной интерфейс находится в режиме «managed» или «ap», а не в режиме монитора; это означает, что захват будет содержать только пакеты, прошедшие обработку на уровне Wi-Fi. См. избегание tcpdump на точках доступа для обсуждения того, как некоторые тесты можно выполнить без запуска tcpdump на точках доступа.
Чтобы проверить вашу тестовую конфигурацию, первая команда в таблице ниже выполняет обычный пинг, который должен пройти успешно. Вторая команда отправляет пинг в виде двух фрагментированных Wi-Fi-кадров и должна завершиться ошибкой лишь в редком случае, когда тестируемое устройство не поддерживает фрагментацию. Если один из этих тестов не работает, следуйте инструкциям в разделе тест внедрения сетевой карты, чтобы убедиться, что ваша сетевая карта корректно внедряет кадры. Если тестируемый клиент может перейти в спящий режим, см. Обработка спящего режима.
Третья, четвёртая и пятая команды не являются атаками, а проверяют базовое поведение дефрагментации устройства и дополнительно обсуждаются ниже таблицы.
Соответствие команд CVE перечислено ниже. Обратите внимание, что для ошибок реализации мы приводим эталонный идентификатор CVE; однако поставщики могут использовать другие CVE, поскольку уязвимость реализации обычно получает уникальный CVE для каждой затронутой кодовой базы. Тем не менее мы рекомендуем всегда ссылаться на эти эталонные CVE как на простой способ указать на каждый тип обнаруженной ошибки реализации.
ping: Этот тест всегда должен проходить успешно. Если он не проходит, что-то не так с тестовой конфигурацией.- ping I,E,E: Этот тест должен успешно выполняться на всех современных ноутбуках, смартфонах и точках доступа. Если он завершается неудачей, скорее всего, что-то не так с настройкой теста. Попробуйте добавить параметр --icmp-size 100 в качестве исправления. Если тест работает с этим дополнительным параметром, вам придётся выполнять все остальные тесты также с этим дополнительным параметром. Единственный случай, когда я сталкивался с обоснованным провалом этого теста, — когда тестируемое устройство не поддерживает приём фрагментированных кадров; такое возможно на лёгких IoT-устройствах и, например, на OpenBSD.ping I,E,E --delay 5: Этот тест используется для проверки максимально допустимой задержки между двумя фрагментами.
Если этот тест не работает, попробуйте ещё раз с --delay 1.5 или меньше. Например, Linux удаляет фрагменты
из памяти через 2 секунды, то есть задержка 1.8 будет работать, а 2.2 приведёт к отсутствию ответа. Если максимально
допустимая задержка мала, все фрагменты, отправляемые в других тестах, должны отправляться в пределах этой максимально
допустимой задержки. В противном случае тесты будут тривиально завершаться неудачей, и вы можете сделать вывод,
что устройство не уязвимо к атаке, хотя на самом деле оно уязвимо.
ping-frag-sep: Этот тест отправляет фрагментированный Wi-Fi кадр, разделённый посторонним кадром.
То есть он отправляет первый фрагмент, затем (обычный) посторонний Wi-Fi кадр и, наконец, второй фрагмент.
Если этот тест завершается неудачей, (стандартная) атака со смешанным ключом и атака на кэш, скорее всего, также
завершатся неудачей (поскольку они требуют отправки других кадров между двумя фрагментами). Этот тест также завершится
неудачей, если приёмник проверяет, имеют ли фрагменты последовательные номера пакетов (см. следующий тест
ping-frag-sep --pn-per-qos).
ping-frag-sep --pn-per-qos: То же, что и выше, но добавление параметра --pn-per-qos гарантирует, что оба фрагмента
ping-запроса имеют последовательные номера пакетов (PN). Это то, что приёмник должен проверять для обеспечения
безопасности. К сожалению, до публикации наших результатов многие реализации не проверяли, являются ли PN
последовательными. Этот тест может завершиться неудачей, если приёмник не отслеживает последний полученный счётчик
пакетов для каждого QoS TID; в этом случае вы можете игнорировать другие тесты, содержащие параметр --pn-per-qos.
Тест ping I,E --amsdu проверяет, поддерживает ли реализация не-SPP A-MSDU (он не проверяет, уязвимо ли устройство
к CVE-2020-24588). Для предотвращения атак в идеале сеть должна требовать использования SPP A-MSDU и отбрасывать все
не-SPP A-MSDU. Однако большинство производителей в настоящее время реализуют вместо этого ad-hoc меры защиты
(см. раздел 7.2 статьи). В связи с этим для проверки того, уязвимо ли устройство к атакам агрегации (A-MSDU)
(CVE-2020-24588), необходимо использовать следующие два теста:
amsdu-inject: Этот тест моделирует атаку внедрения A-MSDU, описанную в разделе 3.2 статьи. В частности,
он отправляет A-MSDU кадр, начало которого также является корректным заголовком LLC/SNAP (поскольку именно это
происходит и в нашей эталонной атаке). Если этот тест завершится успешно, устройство уязвимо к CVE-2020-24588.
amsdu-inject-bad: Некоторые устройства некорректно разбирают A-MSDU кадры, начинающиеся с корректного заголовка
LLC/SNAP, из-за чего описанный выше тест завершается неудачей. В этом случае попробуйте вместо него тест
amsdu-inject-bad (см. раздел 3.6 статьи). Обратите внимание: если этот тест завершится успешно, последствия атаки
фактически идентичны случаю реализаций, которые корректно разбирают такие кадры, то есть устройство уязвимо
к CVE-2020-24588.
При запуске теста со смешанным ключом против точки доступа точка доступа должна быть настроена на регулярное
(например, каждую минуту) обновление сеансового ключа (PTK) путём выполнения нового 4-стороннего рукопожатия.
Инструмент выведет Client cannot force rekey. Waiting on AP to start PTK rekey при ожидании этого рукопожатия
обновления PTK. Против небольшого числа точек доступа инструмент также может запросить обновление PTK, добавив
параметр --rekey-req, то есть нет необходимости настраивать точку доступа на периодическое обновление ключа.
Некоторые точки доступа нельзя настроить на регулярное обновление сеансового ключа (PTK). Против таких точек доступа можно вместо этого попробовать тест атаки на кэш. Если точка доступа уязвима к атакам на кэш, то она, вероятно, также уязвима к атакам со смешанным ключом (если только нет убедительных доказательств обратного, например, аудит кода показывает, что атаки со смешанным ключом предотвращены). Если точка доступа не уязвима к атакам на кэш, то мы не можем сказать ничего о её подверженности атакам со смешанным ключом, и в этом случае я рекомендую вместо этого провести аудит кода.
ping I,F,BE,AE --pn-per-qos: Дополнительный параметр --pn-per-qos гарантирует, что оба внедрённых фрагмента имеют
последовательные номера пакетов, что необходимо для успешной атаки со смешанным ключом против некоторых устройств
(например, против Linux).
Некоторые устройства реализуют 4-стороннее рукопожатие по-разному, и это повлияет на успех или неудачу этих тестов. В случае неудачи тестов рекомендуется также выполнить тесты атаки со смешанным ключом, перечисленные в разделе Расширенные тесты уязвимости.
При тестировании точки доступа инструмент отправляет первый фрагмент, затем пытается повторно ассоциироваться
с точкой доступа и, наконец, отправляет второй фрагмент. Однако не все точки доступа корректно поддерживают процесс
повторной ассоциации. В этом случае добавьте опцию --full-reconnect, как показано в таблице, которая заставляет
инструмент выполнить деаутентификацию после отправки первого фрагмента.
При тестировании клиента инструмент отправляет первый фрагмент, деассоциирует клиента и, как только клиент
переподключится, отправляет второй фрагмент. В идеале клиент должен немедленно переподключиться после отправки кадра
деассоциации. Для этого может потребоваться отключить все остальные сети на тестируемом клиенте. Я также обнаружил,
что некоторые клиенты, похоже, некорректно обрабатывают деассоциацию; в этом случае вы можете добавить опцию
--full-reconnect, как показано в таблице, чтобы вместо этого отправить кадр деаутентификации.
Я обнаружил, что лучше всего выполнять каждый тест атаки на кэш несколько раз. Иногда тест атаки на кэш может завершиться неудачей, хотя реализация действительно уязвима. Это может быть связано с фоновым шумом, другими устройствами, отправляющими кадры на тестируемое устройство, и т.д.
ping I,E,R,AE [--full-recon]: Здесь второй фрагмент отправляется сразу после переподключения к тестируемому
устройству, что важно в случае, если устройство очищает фрагменты из памяти через короткое время. Обратите внимание,
что full-recon — это сокращение от full-reconnect.
ping I,E,R,E [--full-recon]: Здесь второй фрагмент отправляется через 1 секунду после переподключения
к тестируемому устройству, что может быть полезно, если между завершением рукопожатия и установкой согласованного
ключа есть небольшая задержка.
В наших экспериментах этот тест завершался неудачей только против Linux и устройств, не поддерживающих фрагментацию.
ping I,E,P и linux-plain: если этот тест завершится успешно, результирующие атаки описаны в разделе 6.3 статьи.
Если кратко, в сочетании с уязвимостью A-MSDU или кэша её можно использовать для внедрения пакетов. Без сочетания
с другими уязвимостями последствия зависят от конкретной реализации (CVE-2020-26147).
ping I,P,E: если этот тест завершится успешно, тривиально внедрять кадры в открытом виде в направлении устройства,
если в сети используется фрагментация (CVE-2020-26147).
ping I,P: если этот тест завершится успешно, реализация принимает кадры в открытом виде в защищённой Wi-Fi сети,
что позволяет тривиально внедрять пакеты (CVE-2020-26140).
ping I,P,P: если этот тест завершится успешно, реализация принимает фрагментированные кадры в открытом виде
в защищённой Wi-Fi сети, что позволяет тривиально внедрять пакеты (CVE-2020-26143).
Следующие два теста отправляют широковещательные кадры, которые не ретранслируются автоматически, поэтому рекомендуется выполнять их несколько раз. Это связано с тем, что фоновый шум может помешать тестируемым устройствам получить внедрённый широковещательный кадр. В моих экспериментах были затронуты в основном клиенты (из протестированных точек доступа были затронуты только Free/NetBSD).
ping I,D,P --bcast-ra: Отправляет одноадресный ping во втором широковещательном фрагменте в открытом виде после
подключения. Результат этого варианта атаки проверяется инструментом автоматически.
ping D,BP --bcast-ra: Здесь указанный выше кадр отправляется во время подключения к сети (т.е. во время 4-стороннего
рукопожатия). Это важно, поскольку некоторые клиенты и точки доступа уязвимы только до завершения 4-стороннего
рукопожатия. Для подтверждения результата этого теста необходимо запустить wireshark или tcpdump на жертве
и отслеживать, получает ли жертва внедрённый ping-запрос. В tcpdump можно использовать фильтр icmp, а в wireshark —
фильтр frame contains "test_ping_icmp", чтобы проще обнаружить этот ping-запрос. В моих экспериментах были затронуты
в основном клиенты.
eapol-amsdu I,P: Это стандартный тест для уязвимости, зависящей от конкретной реализации, описанной в разделе 6.5
статьи. Уязвимыми могут быть как клиенты, так и точки доступа. Его результат проверяется инструментом автоматически.
Тесты, оканчивающиеся на BP (eapol-amsdu BP и eapol-amsdu-bad BP): эти тесты внедряют вредоносный кадр во время
выполнения 4-стороннего рукопожатия. Для подтверждения результата этого теста необходимо запустить wireshark или
tcpdump на жертве и отслеживать, получает ли жертва внедрённый ping-запрос. В tcpdump можно использовать фильтр icmp,
а в wireshark — фильтр frame contains "test_ping_icmp", чтобы проще обнаружить этот ping-запрос.
Тесты, начинающиеся с eapol-amsdu-bad (eapol-amsdu-bad BP и eapol-amsdu-bad I,P): некоторые реализации
некорректно обрабатывают A-MSDU кадры, первые 6 байт которых также совпадают с корректным заголовком RFC1042
для EAPOL. Для тестирования таких реализаций необходимо использовать вариант теста eapol-amsdu-bad. Обратите
внимание: если этот тест завершится успешно, последствия атаки идентичны случаю реализаций, которые корректно
разбирают такие кадры (подробнее см. разделы 3.6 и 6.6 статьи).
Если инструмент, похоже, не работает, проверьте следующее:
Проверьте, что никакой другой процесс не использует сетевую карту (например, завершите ваш сетевой менеджер).
Если раньше всё работало, попробуйте отключить ваш Wi-Fi адаптер, перезагрузить компьютер или виртуальную машину
и попробуйте снова. Также попробуйте отключить аппаратное шифрование с помощью скрипта disable-hwcrypto.sh
(перезагрузите компьютер после выполнения этого скрипта).
Убедитесь, что тестируемое устройство не переходит в спящий режим (из-за чего оно пропускает внедрённые кадры). Я рекомендую запускать инструмент в смешанном режиме, поскольку он лучше обрабатывает клиенты, которые могут переходить в спящий режим.
Запустите тесты внедрения, чтобы убедиться, что внедрение работает правильно. Также убедитесь, что используется канал 20 МГц; внедрение на других каналах не тестировалось.
Проверьте, что ваша машина не генерирует фоновый трафик, который мешает тестам. В частности, отключите сеть в вашей ОС, вручную завершите ваш DHCP-клиент/сервер и т.д. См. также Перед каждым использованием.
Убедитесь, что вы подключаетесь к правильной сети. Перепроверьте client.conf.
Убедитесь, что тестируемая точка доступа использует (AES-)CCMP в качестве алгоритма шифрования. Другие алгоритмы шифрования, такие как TKIP или GCMP, не поддерживаются.
Если вы обновили код с помощью git, выполните ./build.sh и ./pysetup.sh снова (см. Предварительные требования).
Если исправленные драйверы были обновлены, не забудьте также перекомпилировать их.
Если вы используете виртуальную машину, попробуйте вместо этого запустить инструмент с загрузочного USB-образа.
Проверьте, что тестируемое устройство не блокирует ICMP ping-запросы. Если оно не отвечает на ping-запросы, вы можете запустить tcpdump или wireshark на устройстве или попробовать любой другой метод из списка в разделе Отсутствие поддержки ICMP.
Из-за различий в реализациях может быть трудно подтвердить/эксплуатировать определённые уязвимости; в частности, атаку со смешанным ключом и атаку на кэш может быть нетривиально подтвердить на практике. Поэтому я рекомендую считать устройство безопасным только в том случае, если в коде есть явные проверки, предотвращающие эти атаки. Кроме того, если позволяет время, я также рекомендую следующие более продвинутые тесты. У них меньше шансов обнаружить новые уязвимости, но они могут выявить варианты атак или особенности поведения устройств, которые обычные тесты не могут обнаружить.
Если обычные тесты из раздела Тестирование на уязвимости уже подтвердили наличие определённого класса уязвимостей, то нет особой необходимости тестировать другие варианты атак для этой уязвимости. Все команды работают как против клиентов, так и против точек доступа, если не указано иное.
Выполнять эти два теста имеет смысл только в том случае, если основной тест ping I,E --amsdu завершается неудачей
и вы хотите лучше понять, как тестируемое устройство обрабатывает A-MSDU кадры:
ping I,E --amsdu-fake: Если этот тест завершится успешно, приёмник обрабатывает все кадры как обычные кадры (то есть
не поддерживает A-MSDU кадры). Такое поведение не идеально, хотя маловероятно, что злоумышленник сможет использовать
это на практике (см. раздел 3.5 статьи).
ping I,E --amsdu-fake --amsdu-spp: Если этот тест завершится успешно, приёмник аутентифицирует флаг QoS A-MSDU
каждого полученного кадра (т.е. не будет маскировать его нулём при приёме), но затем обрабатывает все полученные кадры
как обычные кадры (то есть не поддерживает приём настоящих A-MSDU кадров). Такое поведение не идеально, хотя
маловероятно, что злоумышленник сможет использовать это на практике (см. раздел 3.5 статьи).
Большинство протестированных мной устройств уязвимы к атакам со смешанным ключом. Если обычные тесты атаки со смешанным
ключом показывают, что устройство не уязвимо, но тест ping-frag-sep завершается успешно, настоятельно рекомендуется
попробовать эти альтернативные тесты атаки со смешанным ключом.В качестве общего замечания: при тестировании точки доступа вы можете добавить параметр --rekey-req к любому тесту атаки со смешиванием ключей, чтобы активно запросить повторное рукопожатие. Небольшое число точек доступа затем выполнит повторное рукопожатие. Однако большинство точек доступа проигнорируют этот запрос, и их необходимо явно настроить на регулярное обновление сеансового ключа (PTK).
Некоторые примечания относительно тестов:
ping I,F,BE,E и ping I,E,F,AE: это довольно простые тесты атаки со смешиванием ключей, в которых оба фрагмента внедряются в разное время.
ping I,E,F,AE --rekey-plain: некоторые драйверы (например, MediaTek) выполняют повторное рукопожатие в открытом виде. Чтобы протестировать устройства, использующие такой драйвер, необходимо добавить параметр --rekey-plain.
ping I,E,F,AE --rekey-plain --rekey-req: эта конкретная комбинация полезна для тестирования маршрутизаторов, использующих драйвер MediaTek. Эти маршрутизаторы выполняют повторное рукопожатие в открытом виде, и клиент может активно запросить повторное рукопожатие.
ping I,E,F,AE --rekey-early-install: небольшое число клиентов (ошибочно) устанавливают ключ слишком рано во время повторного согласования парного сеансового ключа. Чтобы надёжно протестировать таких клиентов, добавьте параметр --rekey-early-install. Этот тест не имеет смысла против точек доступа.
ping I,E,F,E [--rekey-pl] [--rekey-req]: этот вариант теста аналогичен предыдущим тестам ping I,E,F,AE *, за исключением того, что второй фрагмент отправляется через 1 секунду после 4-стороннего рукопожатия. Это может быть важно, поскольку на небольшом числе устройств наблюдается небольшая задержка перед установкой нового ключа. Обратите внимание, что является сокращением от .
Наконец, если тест ping-frag-sep не завершается успешно, следует попробовать следующий тест атаки со смешиванием ключей:
ping I,F,BE,AE --freebsd: по сути, выполняет повторное рукопожатие против реализации FreeBSD или драйвера, заимствующего код из FreeBSD, не влияя на процесс дефрагментации кадров данных. Подробности см. в Приложении E к статье.ping I,E,R,AE --freebsd --full-reconnect: этот тест можно использовать для проверки, уязвима ли точка доступа FreeBSD или драйвер, заимствующий код из FreeBSD, к атаке на кэш. Подробности о том, как работает этот тест, см. в Приложении E к статье. Также следует попробовать этот тест без параметра --full-reconnect. Тест также работает против клиентов, но они вряд ли будут затронуты.
ping I,E,R,AP --freebsd --full-reconnect: этот тест является вариантом против точек доступа FreeBSD или драйвера, заимствующего код из FreeBSD, в котором второй фрагмент отправляется в открытом виде после повторного подключения к точке доступа. На некоторых донглах FreeBSD этот тест был более надёжным и по-прежнему доказывает, что старые фрагменты остаются в памяти точки доступа после повторного подключения. Также следует попробовать этот тест без параметра --full-reconnect. Тест также работает против клиентов, но они вряд ли будут затронуты.
ping I,E,R,AP [--full-reconnect]: в этом тесте второй фрагмент отправляется в открытом виде. Это может быть полезно, если тестируемое устройство не устанавливает ключ сразу после 4-стороннего рукопожатия. Если этот тест завершается успешно, это показывает, что устройство сохраняет фрагменты в памяти после (повторного) подключения к сети, то есть оно уязвимо к атакам на кэш. В отличие от двух приведённых выше команд, эту также полезно выполнять против клиентов (а также точек доступа).
ping I,E,E --amsdu: этот тест отправляет фрагментированный кадр A-MSDU, который не все устройства могут корректно принимать. Он не проверяет наличие уязвимости. Вместо этого этот тест полезен для определения практической эксплуатируемости «смешанной атаки открытого/зашифрованного текста». А именно, если этот тест завершается успешно, то атаковать устройство проще, если второй фрагмент можно отправить в открытом виде (тест ping I,E,P). Подробности см. в разделе 6.3 статьи.
ping I,E,P,E и linux-plain 3: если все остальные тесты смешанной атаки открытого/зашифрованного текста не завершились успешно, можно попробовать также эти два дополнительных теста. Я думаю, маловероятно, что это выявит новую уязвимость.
Большинство следующих тестов отправляют широковещательные кадры, которые не ретранслируются автоматически, поэтому рекомендуется выполнять их несколько раз. Это связано с тем, что фоновый шум может помешать тестируемым устройствам получить внедрённый широковещательный кадр. В моих экспериментах затронуты были в основном клиенты. Большинство клиентов уязвимы только во время подключения к сети (т.е. во время выполнения 4-стороннего рукопожатия).
ping I,P --bcast-ra: отправляет одноадресный ICMP ping-запрос внутри широковещательного Wi-Fi кадра в открытом виде (CVE-2020-26145). Этот тест можно выполнять как против клиентов, так и против точек доступа.
ping BP --bcast-ra: аналогичен приведённому выше тесту ping I,P --bcast-ra, но ping отправляется до того, как клиент аутентифицировался в сети, т.е. во время выполнения 4-стороннего рукопожатия (CVE-2020-26145). Необходимо запустить tcpdump или wireshark, чтобы проверить, принимает ли клиент кадр. В tcpdump можно использовать фильтр icmp, а в wireshark также можно использовать фильтр frame contains "test_ping_icmp", чтобы легче обнаружить этот ping-запрос.
ping BP --bcast-ra --bcast-dst: этот тест аналогичен предыдущему, но полезен, если вы не можете запустить tcpdump на целевой точке доступа. Обратите внимание, что этот тест имеет смысл только против точек доступа. Дополнительный параметр --bcast-dst в этом тесте заставляет уязвимую точку доступа транслировать внедрённый ping-запрос всем подключённым клиентам. Другими словами, чтобы проверить, уязвима ли точка доступа, выполните эту команду и слушайте широковещательные Wi-Fi кадры на втором устройстве, подключённом к точке доступа, используя фильтр icmp или frame contains "test_ping_icmp".
ping BP [--bcast-dst]: вариант двух приведённых выше тестов ping BP --bcast-ra [--bcast-dst], за исключением того, что ping-запрос теперь отправляется в одноадресном кадре в открытом виде, а не в широковещательном (CVE пока не назначен — он связан с CVE-2020-26145). Этот тест необходимо выполнять как против клиентов, так и против точек доступа. Ping отправляется до того, как клиент аутентифицировался в сети (т.е. во время выполнения 4-стороннего рукопожатия), поэтому для проверки того, принимает ли устройство этот кадр, необходимо запустить tcpdump или wireshark. Кроме того, при тестировании точек доступа можно добавить параметр --bcast-dst, аналогично приведённому выше тесту, а затем использовать tcpdump или wireshark на втором устройстве, подключённом к точке доступа, с фильтром icmp или frame contains "test_ping_icmp".
eapfrag BP,BP: специализация приведённых выше тестов с широковещательными фрагментами, выполняемая до аутентификации клиента. Это очень экспериментальная атака, основанная на анализе утёкшего кода. Сначала она отправляет фрагмент в открытом виде, начинающийся с заголовка EAPOL, который принимается, поскольку 4-стороннее рукопожатие всё ещё выполняется. Затем отправляется второй широковещательный фрагмент с тем же порядковым номером. Согласно анализу утёкшего кода, некоторые устройства могут принять этот фрагмент (поскольку предыдущий фрагмент был разрешён), но последующий код обработает его как обычный кадр (поскольку фрагмент является широковещательным). Чтобы определить, был ли кадр корректно получен, необходимо использовать tcpdump или wireshark на жертве, например с фильтром icmp или frame contains "test_ping_icmp". Альтернативным вариантом является , если обычный вариант не работает.
Этот тест можно использовать, если вы хотите выполнить тесты eapol-amsdu[-bad] BP, но не можете запустить tcpdump или wireshark на точке доступа. Этот тест имеет смысл только против точек доступа: команда eapol-amsdu[-bad] BP --bcast-dst заставляет уязвимую точку доступа транслировать внедрённый ping-запрос всем подключённым клиентам. Другими словами, чтобы проверить, уязвима ли точка доступа, выполните эту команду и слушайте широковещательные Wi-Fi кадры на втором устройстве, подключённом к точке доступа, с помощью фильтра icmp или frame contains "test_ping_icmp".
eapol-inject 00:11:22:33:44:55: этот тест имеет смысл только против точек доступа. Для выполнения этого теста необходимо подключиться к сети с помощью второго устройства и заменить MAC-адрес 00:11:22:33:44:55 на MAC-адрес этого второго устройства. До аутентификации инструмент отправит точке доступа EAPOL-кадр с этим вторым устройством в качестве конечного получателя. Если точка доступа пересылает EAPOL-кадр второму устройству, она считается уязвимой. Чтобы подтвердить, пересылает ли точка доступа EAPOL-кадр, необходимо запустить tcpdump или wireshark на втором устройстве. Можно использовать фильтр wireshark frame contains "forwarded_data" при мониторинге расшифрованного трафика на беспроводном интерфейсе второго устройства (или фильтр tcpdump ether proto 0x888e для мониторинга всех EAPOL-кадров). Подробности и влияние этого описаны в разделе 6.6 статьи.
eapol-inject-lage 00:11:22:33:44:55: если приведённый выше тест eapol-inject завершается успешно, можно также попробовать eapol-inject-large, чтобы проверить, можно ли использовать эту уязвимость для принудительной передачи зашифрованных фрагментов. Для проверки снова необходимо использовать tcpdump или wireshark. Используйте фильтр wireshark или tshark (wlan.fc.frag == 1) || (wlan.frag > 0) для обнаружения фрагментированных кадров. Я обнаружил, что эта атака срабатывает очень редко.
ping I,D,E: если этот тест завершается успешно, клиент или точка доступа не поддерживают (де)фрагментацию, но при этом всё равно уязвимы к атакам. Проблема в том, что получатель обрабатывает последний фрагмент как полный кадр. Подробности и способы использования этой уязвимости см. в разделе 6.8 статьи.
ping I,E,D: если этот тест завершается успешно, клиент или точка доступа обрабатывает первый фрагмент как полный кадр. Хотя такое поведение не является идеальным, в настоящее время неизвестно, можно ли использовать его по отдельности на практике.
Скрипт test-injection.py можно использовать для проверки того, правильно ли внедряются кадры при использовании режима внедрения:
./test-injection.py wlan0 wlan1
Здесь мы проверяем, правильно ли сетевая карта wlan0 внедряет кадры, а сетевую карту wlan1 используем для наблюдения за тем, правильно ли внедряются кадры. Обратите внимание, что оба интерфейса должны поддерживать режим монитора, чтобы этот тестовый скрипт работал.
Если у вас нет второй сетевой карты, можно выполнить частичный тест внедрения с помощью:
./test-injection.py wlan0
К сожалению, приведённый выше тест может проверить только то, перезаписывает ли ядро поля внедряемых кадров; он не может проверить, перезаписывает ли поля сама прошивка или беспроводной чип.
Чтобы проверить, правильно ли сетевая карта внедряет кадры в смешанном режиме, который я рекомендую использовать, можно выполнить следующие две команды:
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
Здесь мы проверяем, правильно ли wlan0 внедряет кадры, наблюдая за внедрёнными кадрами с помощью второй сетевой карты wlan1. Первая команда проверяет, правильно ли внедряются кадры при использовании смешанного режима в роли клиента, а вторая — при использовании смешанного режима в роли точки доступа. Для запуска теста клиент должен иметь возможность подключиться к сети, а точка доступа ожидает подключения клиента перед началом тестов внедрения (см. Перед каждым использованием для настройки параметров подключения клиента и точки доступа).
Если вы также хотите проверить поведение wlan0 при ретрансляции в смешанном режиме, можно выполнить:
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
Если у вас нет второй сетевой карты, можно выполнить частичный тест внедрения в смешанном режиме с помощью:
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
К сожалению, приведённые выше тесты могут проверить только то, перезаписывает ли ядро поля внедряемых кадров; они не могут проверить, перезаписывает ли поля сама прошивка или беспроводной чип.
Тестовый скрипт выведет подробную информацию о том, какие тесты завершились успешно или неудачно, и в конце выведет либо ==> The most important tests have been passed successfully, либо сообщение о том, что важные тесты не прошли или что не удалось захватить определённые внедрённые кадры.
Обратите внимание, что скрипты внедрения проверяют только наиболее важное поведение. Лучший способ убедиться, что внедрение работает правильно, — выполнить тесты на уязвимость против устройств, которые заведомо уязвимы, и убедиться, что инструмент корректно идентифицирует устройство(а) как уязвимые.
Если некоторые внедрённые кадры не удалось захватить, это может быть связано с фоновым шумом или с тем, что тестируемая сетевая карта не может корректно внедрять определённые кадры (например, прошивка Intel AX200 падает при внедрении фрагментированных кадров). Также возможно, что кадры на самом деле внедряются правильно, но сетевая карта, используемая для наблюдения за корректностью внедрения (wlan1 в приведённых выше примерах), ненадёжна и, например, пропускает большинство кадров из-за фонового шума. Попробуйте также запустить тесты на другом канале.
Если тесты внедрения работают, но у вас возникают проблемы с надёжным выполнением тестов на атаку, это может быть связано с тем, что тестируемые устройства переходят в спящий режим. См. Обработка спящего режима для дополнительных замечаний по этой проблеме.
При использовании wireshark для проверки поведения устройства при внедрении рекомендуется использовать второе устройство в режиме монитора, чтобы видеть, как внедряются кадры.
Если вы откроете интерфейс, используемый для внедрения кадров, вы должны увидеть внедрённые кадры дважды: (1) сначала вы видите кадр таким, каким его внедряет отправляющий инструмент, а затем (2) второй раз — таким, каким кадр был внедрён драйвером. Эти два кадра могут незначительно отличаться, если ядро перезаписало определённые поля. Если вы видите внедрённый кадр только один раз, возможно, он был отброшен ядром.
Если тестируемое устройство не поддерживает DHCP, вы можете вручную указать IP-адреса, которые должен использовать инструмент тестирования. Например:
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
Здесь инструмент тестирования будет использовать IP-адрес 192.168.100.10 и внедрит ping-запрос к IP-адресу пира 192.168.100.1.
Когда тест отправляет IP-пакеты до получения IP-адресов с помощью DHCP, он использует IP-адрес по умолчанию 127.0.0.1. Чтобы использовать другие (стандартные) IP-адреса, вы также можете использовать параметры --ip и -peerip.
Большинство тестов на атаку работают путём отправки ICMP ping-запросов особым образом и проверки того, получаем ли мы ICMP ping-ответ. Если тестируемое устройство не поддерживает ICMP-пинги, вы можете вместо этого использовать ARP-запросы, добавив параметр --arp ко всем тестам. Если тест не поддерживает отправку ARP-запросов, инструмент выведет ошибку Cannot override request type of the selected test, и в этом случае конкретный тест можно выполнить только с использованием ICMP ping-запросов.
TODO: В режиме клиента мы также можем внедрять DHCP-запросы.
Если у вас нет доступа к одной из рекомендуемых беспроводных сетевых карт, вторым вариантом является приобретение сетевой карты, использующей те же драйверы в Linux. В частности, можно попробовать:
Я рекомендую карты на основе ath9k_htc. Не все карты, использующие iwlmvm, будут совместимы. При использовании альтернативной сетевой карты я настоятельно рекомендую сначала запустить тесты внедрения, чтобы убедиться в совместимости сетевой карты.
Чтобы использовать инструмент тестирования на каналах 5 ГГц, используемая сетевая карта должна разрешать внедрение кадров в диапазоне 5 ГГц. К сожалению, это не всегда возможно из-за нормативных ограничений. Чтобы узнать, на каких каналах можно внедрять кадры, выполните iw list и посмотрите в разделе Frequencies каналы, которые не помечены как disabled, no IR или radar detection. Обратите внимание, что эти условия могут зависеть от вашей сетевой карты, текущей настроенной страны и точки доступа, к которой вы подключены. Дополнительную информацию см., например, в документации Arch Linux.
Обратите внимание, что устройство может использовать разные драйверы для работы в диапазонах 2,4 и 5 ГГц. В результате важно тестировать устройства в обоих этих диапазонах, поскольку устройство может вести себя по-разному в зависимости от используемого частотного диапазона.
Обратите внимание, что в смешанном режиме ядро Linux может не разрешать внедрение кадров, даже если отправка обычных кадров разрешена. Это связано с тем, что в функции ieee80211_monitor_start_xmit ядро отказывается внедрять кадры, когда cfg80211_reg_can_beacon возвращает false. В результате Linux может отказываться внедрять кадры, даже если это на самом деле разрешено. Заставить cfg80211_reg_can_beacon возвращать true при правильных условиях позволяет избежать этой ошибки.
На практике некоторые люди обнаружили, что сначала необходимо вручную переключить беспроводную сетевую карту на канал 5 ГГц, на котором работает точка доступа. Подробности см. в этой проблеме GitHub.
Такие устройства, как мобильные телефоны или IoT-устройства, могут переводить свой Wi-Fi-радиомодуль в спящий режим для снижения энергопотребления. В спящем режиме эти устройства не могут принимать Wi-Fi-кадры, что может мешать нашим тестам. Есть несколько вариантов, которые можно попробовать для смягчения этой проблемы:
Попробуйте отключить спящий режим на тестируемом устройстве. Это самое надёжное решение, но, к сожалению, оно не всегда возможно.
Запустите инструмент тестирования в смешанном режиме. Большинство сетевых карт при этом будут ставить внедрённые кадры в очередь, пока тестируемое устройство снова не проснётся.
Попробуйте другую сетевую карту для выполнения тестов. Я обнаружил, что разные сетевые карты внедряют кадры в (несколько) разное время, и это может быть решающим фактором между корректным прибытием внедрённого кадра и его потерей. Например, против Pixel 4 XL инструмент тестирования был ненадёжным при использовании TL-WN722N, но работал надёжно с Intel 8265.
Назначьте статические IP-адреса тестируемому устройству и позвольте инструменту тестирования использовать статические IP-адреса (см. Статическая конфигурация IP). Для многих тестов это может быть надёжнее, поскольку инструмент тестирования сможет немедленно отправить тестовый кадр, вместо того чтобы сначала использовать/ждать DHCP.
т.е. при выполнении 4-стороннего рукопожатия. Это делает их более сложными для автоматического тестирования и обычно означает, что на тестируемом устройстве должен использоваться tcpdump или аналогичный инструмент. Однако точки доступа можно тестировать без запуска tcpdump на ней. В частности, тесты атаки на широковещательные фрагменты (CVE-2020-26145) и атаки A-MSDU EAPOL (CVE-2020-26144) могут выполняться без запуска tcpdump на тестируемом устройстве. Вместо этого tcpdump должен работать на другом клиенте, подключённом к точке доступа. А именно, можно использовать следующие команды:
ping I,P --bcast-ra --bcast-dst и ping BP --bcast-ra --bcast-dst
eapol-amsdu BP --bcast-dst и eapol-amsdu-bad BP --bcast-dst
С помощью этих команд можно отслеживать ping-запрос на другом клиенте, подключённом к точке доступа. В случае получения ping-запроса на этом независимом клиенте тестируемая точка доступа уязвима. К сожалению, в настоящее время тестирование клиентов на эти варианты атак без запуска tcpdump на клиенте представляется сложным.
Если по какой-то причине Linux не распознаёт этот адаптер автоматически, выполните sudo modprobe mt76x2u
для ручной загрузки драйвера. Этот адаптер кажется надёжным с нашими последними драйверами. Если адаптер работает нестабильно,
создайте файл /etc/modprobe.d/mt76.conf со следующим содержимым:```
options mt76_usb disable_usb_sg=1
Затем перезагрузите вашу машину. Также обязательно используйте качественный USB-кабель с этим донглом! Ранее я сталкивался
с нестабильным поведением этого донгла, вызванным плохим кабелем USB 3.0. Поэтому, если у вас возникают проблемы,
может помочь прямое подключение донгла без использования кабеля.
При использовании VirtualBox убедитесь, что включен USB3.0, чтобы донгл был распознан. См.
[эту проблему](https://github.com/vanhoefm/fragattacks/issues/22) для подробностей.
Донгл AWUS036ACM внутри использует чипсет MT7612U. Теперь также существуют донглы с чипсетом MT7612UN, которые
также надежно работают с нашим инструментом тестирования. Пример: [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).
### ath9k_htc
Technoethical N150 HGA, TP-Link TL-WN722N v1.x и Alfa AWUS036NHA используют драйвер `ath9k_htc`.
У меня эти устройства работали довольно хорошо в виртуальной машине, хотя, как и все устройства, они более надежны
при использовании в нативном режиме. При использовании ВМ рекомендую настроить ВМ на использование контроллера USB2.0,
поскольку это казалось более стабильным (по крайней мере, с VirtualBox).
В последних ядрах была регрессия с драйвером `ath9k_htc` ([теперь исправлено](https://www.spinics.net/lists/linux-wireless/msg200825.html)),
из-за которой он не работал. Просто используйте актуальное ядро или наши пропатченные драйверы, чтобы избежать этой проблемы.
#### AWUS036ACH
Это устройство обычно не поддерживается по умолчанию в большинстве дистрибутивов Linux и требует ручной установки
драйверов. В Kali Linux вы можете установить драйвер с помощью `sudo apt install realtek-rtl88xxau-dkms`.
Для установки драйвера в других дистрибутивах проверьте ваш пакетный менеджер или следуйте инструкциям
по установке на [GitHub](https://github.com/aircrack-ng/rtl8812au). Перед подключением устройства
рекомендуется выполнить `modprobe 88XXau rtw_monitor_retransmit=1`.
К сожалению, это устройство не работает в смешанном режиме, который является рекомендуемым, и его сложно
использовать вместе с нашими модифицированными драйверами. На практике вам придется удалить модифицированные
драйверы, а затем запустить инструмент тестирования с параметрами `--no-drivercheck` и `--inject wlan0`,
где wlan0 относится к карте AWUS036ACH. Из-за этих ограничений данное устройство не рекомендуется.
### Intel AX200
Я протестировал Intel AX200 и обнаружил, что он _не_ совместим с инструментом тестирования: его прошивка падает
после инжекции кадра с установленным флагом More Fragments. Если это читает разработчик Intel, пожалуйста,
обновите прошивку и сделайте возможной инжекцию фрагментированных кадров.
### Чипы на базе RT5572
Я тестировал этот чипсет с помощью обычного [CSL USB 2.0 WLAN Adapter 300Mbit adapter](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20).
После отключения аппаратного дешифрования с помощью скрипта `disable-hwcrypto.sh` я смог выполнить
базовый ping-тест (`ping`). Фрагментированный ping-тест (`ping I,E,E`) был очень нестабильным, но иногда работал.
Текущий вывод заключается в том, что чипы RT5572 _могут_ работать с инструментом тестирования после отключения
аппаратного шифрования. Но для подтверждения этого необходимы дополнительные эксперименты (обратная связь приветствуется).
<a id="id-hwsim-details"></a>
## 9.9. Подробности режима Hwsim
**Предупреждение**: *в настоящее время это экспериментальный режим, используйте его только в исследовательских целях.*
Этот режим требует только одну сетевую карту, поддерживающую режим монитора, и, в отличие от смешанного режима,
сетевая карта не обязана поддерживать виртуальные интерфейсы. Недостатком является то, что в этом режиме кадры
обрабатываются немного медленнее, и он ненадежен, когда сетевая карта не подтверждает кадры:
- Из-за коммита 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") аутентификация
в качестве клиента будет немедленно истекать по таймауту, что означает, что мы currently не можем использовать режим hwsim в качестве клиента.
_TODO: Нам нужно пропатчить ядро, чтобы избежать этого таймаута._
- Если мы тестируем клиента, который использует коммит 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status"),
мы (как AP) должны подтверждать кадры, отправленные в нашу сторону. В противном случае тестируемый клиент будет
не в состоянии подключиться.
_TODO: Проверить, какие устройства подтверждают кадры в режиме монитора, и протестировать `iw set wlanX monitor active`._
- Некоторые AP также потребуют, чтобы кадры аутентификации и ассоциации подтверждались клиентом.
Это означает, что мы (как клиент) снова должны подтверждать кадры, отправленные в нашу сторону.
_TODO: Проверить, какие устройства подтверждают кадры в режиме монитора, и протестировать `iw set wlanX monitor active`._
- По какой-то странной причине Intel/mvm не может получать кадры данных от Android/iPhone/iPad
после 4-way HS? Это очень странный баг. _TODO: Исследовать это далее._
Перед использованием этого режима создайте две виртуальные сетевые карты:
./hwsim.sh
Это выведет два созданных виртуальных интерфейса "hwsim", например wlan1 и wlan2. При тестировании
AP в этом режиме вы должны сначала найти канал AP и перевести реальную сетевую карту на этот канал:
./scan.sh wlan0
ifconfig wlan0 down
iw wlan0 set type monitor
ifconfig wlan0 up
# Pick the channel that the AP is on (in this example 11)
iw wlan0 set channel 11
Здесь wlan0 относится к _реальной_ сетевой карте (не к интерфейсу, созданному `hwsim.sh`). При тестировании
клиента сначала не нужно настраивать канал (он берется из `hostapd.conf`). Теперь вы можете запустить
инструмент тестирования следующим образом:
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
После выполнения инструмента вы можете сразу запустить его снова с новой `$COMMAND`.
<a id="id-wpa3-sae"></a>
## 9.10. Тестирование устройств WPA3 и SAE
Вы можете протестировать AP WPA3/SAE, добавив следующие две строки в `client.conf`:
key_mgmt=SAE
ieee80211w=1
Для тестирования клиентов WPA3/SAE вы можете изменить `hostapd.conf` и установить параметры:
wpa_key_mgmt=SAE
ieee80211w=2
Мы протестировали вышеуказанное с Intel 8265, Intel 3160, Netgear WN111v2 (`carl9170`),
TP-Link TL-WN722N (`ath9k_htc`) и WNDA3200 (`ath9k_htc`). С этими устройствами я смог подключиться к AP
и запустить некоторые тесты. Так что, похоже, это должно работать со всеми уже поддерживаемыми донглами.
Обратите внимание, что я не тестировал это детально: моим предположением было, что работа устройства
в режиме WPA2 или WPA3 не повлияет на результаты тестов.
Предоставленный `client.conf` по умолчанию включает как метод hunting-and-pecking, так и
метод hash-to-element. Чтобы настроить AP, поддерживающую hash-to-element (и тем самым протестировать
новейшие клиенты WPA3/SAE), вы можете изменить `hostapd.conf` и установить параметр:
sae_pwe=2
Установив это значение, AP будет принимать и метод hunting-and-pecking, и метод hash-to-element.
<a id="id-live-image"></a>
## 9.11. Live USB образ
Скачайте [live USB образ](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso)
и запишите его на USB с помощью:
# Unmount in case there's an old partition on the USB
sudo umount /dev/sdb*
# Copy the image
sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress
Контрольная сумма sha256sum образа — `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. Замените `/dev/sdb`
на вашу USB-флешку. Если вы не используете Linux, поищите в интернете, как записать ISO-образ на USB-флешку.
При запуске live-образа нажмите "Try Ubuntu" во время загрузки. Откройте терминал, щелкнув правой кнопкой мыши
по рабочему столу и выбрав "Open in Terminal", и выполните:
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
Теперь вы можете запустить `./fragattacks.py` и следовать обычным инструкциям из этого README.
Не забудьте отключить Wi-Fi с помощью `nmcli radio wifi off`, как показано выше, в противном случае
сетевой менеджер Ubuntu будет мешать работе инструмента тестирования. Этот README также присутствует
на live-образе по пути `~/fragattacks/README.md`.
Обратите внимание, что airmon-ng может быть ненадежным на live-образе, и лучше использовать [iw](https://github.com/vanhoefm/fragattacks/issues/36).
<a id="id-design-notes"></a>
# 10. Примечания по проектированию
Аргументы, передаваемые команде ping, определяют, какие действия выполнит инструмент тестирования
и когда эти действия будут выполнены. Каждое действие отделяется запятой (`,`). По умолчанию
действие выполняется после подключения клиента, и в этом случае одна буква обозначает,
какое действие выполняется. Обратите внимание, что это реализовано в
функции [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23).
Возможные действия:
- `I`: получить IP-адрес. По умолчанию это делается с помощью DHCP, если только IP-адрес не указан явно
с помощью аргументов `--ip` и `--peerip`, в этом случае ничего не делается.
- `E`: инжектировать зашифрованный пакет/фрагмент ping-запроса.
- `P`: инжектировать открытый пакет/фрагмент ping-запроса.
- `F`: обновить сеансовый ключ, инициировав 4-стороннее рукопожатие (в роли AP) или ожидая
4-стороннее рукопожатие (в роли клиента).
- `R`: позволить клиенту переподключиться к сети.
- `D`: это специальное "мета-действие". Относитесь к нему как к пустому фрагменту ping-запроса,
который на самом деле не отправляется.
Если есть только одно действие `E` или `P`, то ping-запрос инжектируется как один кадр.
Если есть несколько действий `E`, `P`, то ping-запрос фрагментируется, и количество фрагментов
равно количеству действий `E` или `P`. Если присутствует специальное действие `D`, то
ping-запрос фрагментируется по оставшимся действиям `E` или `P` (см. примеры в таблице).
Это поведение фрагментации реализовано в классе [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47).
Перед вышеуказанными действиями можно поставить букву, чтобы изменить момент выполнения действия:
- `S`: действие выполняется на 1-м или 2-м сообщении 4-стороннего рукопожатия.
- `B`: действие выполняется на 3-м или 4-м сообщении 4-стороннего рукопожатия.
- `A`: действие выполняется сразу после завершения 4-стороннего рукопожатия.
- `C`: действие выполняется через 1 секунду после завершения 4-стороннего рукопожатия. Количество секунд
ожидания можно изменить с помощью параметра `--connected-delay`.
Например, см. две приведенные выше таблицы с командами.
<a id="id-change-log"></a>
# 11. Журнал изменений
**Версия 1.3.4 (в разработке):**:
- Всегда шифровать кадры EAPOL (Rekey) Request, даже при использовании --rekey-plaintext.
- Клиент теперь принимает повторные EAPOL-кадры. Это гарантирует, что переустановка ключей работает,
даже если тестируемая AP реализует переустановку ключей неправильно.
- Обновлен wpa_supplicant для повторного включения подключения к корпоративным сетям, использующим MS-CHAPv2.
Ранее, когда ОС использует OpenSSL 3.0 или выше, MD4 был отключен по умолчанию, что означало невозможность
использования MS-CHAPv2.
- Добавлен параметр `--pre-test-delay`. Он добавляет задержку между получением IP-адреса и передачей
первых фрагментов/кадров. См. [pull request](https://github.com/vanhoefm/fragattacks/pull/44) от
Michael Trimarchi и Angelo Compagnucci.
- Обновлены модифицированные драйверы, чтобы они также компилировались на ядре Linux 5.13. Это экспериментально.
- Сделан тест инжекции более надежным за счет более длительного ожидания кадров в тесте переупорядочивания.
- Внесены небольшие изменения, чтобы упростить компиляцию кода на старых платформах (с более старыми версиями
Python и библиотек OpenSSL).
- Обновлен README примером установки старого поддерживаемого ядра на Ubuntu 20.04. Добавлены
примечания по проектированию. Теперь рекомендуется AWUS036ACM.
**Версия 1.3.3 (11 мая 2021)**:
- Обновлены модифицированные драйверы для компиляции на ядрах Linux 5.10, 5.11 и 5.12.
- Обновлена прошивка для устройств `ath9k_htc` (не должно повлиять на тесты).
- Произведена реструктуризация репозитория для публичного релиза. Удалены внутренние документы и слайды,
вместо них даны ссылки на публичные версии этих документов.
- Базовая поддержка каналов 40 МГц при использовании параметра `--inject-test[-postauth]` для тестирования инжекции.
В реальных тестах на уязвимости использование каналов 40 МГц не тестировалось (при необходимости используйте
`disable_ht40` в `client.conf`).
**Версия 1.3.2 (8 марта 2021)**:
- Добавлены презентационные [раздаточные материалы](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) и
[краткое описание](https://papers.mathyvanhoef.com/fragattacks-overview.pdf)
корневой причины и влияния каждой уязвимости.
- Обновлен этот README, чтобы [объяснить](#id-test-sanity), что параметр `--icmp-size 100` или аналогичный можно
добавлять ко всем тестам, отправляющим фрагментированные кадры, если тестируемое устройство принимает только
фрагменты определенного минимального размера.
- Исправлены небольшие опечатки в этом README.
**Версия 1.3.1 (1 марта 2021)**:
- Добавлен тест [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) в этот README. Он инжектирует открытый ping
во время подключения (т.е. во время 4-стороннего рукопожатия). Как клиенты, так и AP могут быть уязвимы
к этой атаке.
- Обновлен [обзор атак](#id-paper-clarifications) новыми примерами того, как уязвимости инжекции пакетов
могут быть использованы на практике. Это включает методы обмана клиентов, работающих только с IPv4,
с целью использования вредоносного DNS-сервера, а также методы прямой связи с устройствами за NAT/межсетевым
экраном (например, для эксплуатации локальных сервисов).
- Уточнено, что [тесты с широковещательными фрагментами](#id-extended-bcast-check) могут выполняться как против клиентов,
так и против AP.
- Инструмент тестирования теперь проверяет, загружена ли ожидаемая версия библиотеки Python Scapy.
- Исправлены некоторые ссылки на статью в этом README (теперь корректно ссылается на разделы 6.4, 6.6 и 6.8).
- Обновлено до черновой версии 3 статьи. По сравнению с черновой версией 2 нет серьезных изменений, только
незначительные текстовые и структурные правки. По содержанию это теперь финальная версия статьи.
**Версия 1.3 (20 января 2021)**:
- Эта версия основана на коммите hostap `a337c1d7c` ("New TWT operations and attributes to TWT Setup and Nudge").
- Добавлен [обзор](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) атак и их предварительных условий, а также созданы [эти слайды](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf),
чтобы лучше проиллюстрировать, как атака агрегации (CVE-2020-24588) работает на практике.
- Добавлены <a href="#id-wpa3-sae">инструкции</a> по тестированию устройств WPA3/SAE с использованием либо метода
| Сетевая карта | USB | 5GHz | смешанный режим | режим внедрения |
|---|
| Technoethical N150 HGA | Да | Нет | патченный драйвер/прошивка | патченный драйвер/прошивка |
| TP-Link TL-WN722N v1.x | Да | Нет | патченный драйвер/прошивка | патченный драйвер/прошивка |
| Alfa AWUS036NHA | Да | Нет | патченный драйвер/прошивка | патченный драйвер/прошивка |
| Intel Wireless-AC 8265 | Нет | Да | патченный драйвер | да |
| Intel Wireless-AC 3160 | Нет | Да | патченный драйвер | да |
| Alfa AWUS036ACM | Да | Да | патченный драйвер | да |
| Netgear WN111v2 | Да | Нет | патченный драйвер | да |
| Alfa AWUS036ACH | Да | Да | нет | да |
| Команда | Краткое описание |
|---|
ping | Отправить обычный пинг. |
ping I,E,E | Отправить обычный фрагментированный пинг. |
ping I,E,E --delay 5 | Отправить обычный фрагментированный пинг с задержкой 5 секунд между фрагментами. |
ping-frag-sep | Отправить обычный фрагментированный пинг с фрагментами, разделёнными другим кадром. |
ping-frag-sep --pn-per-qos | То же, что и выше, но работает также, если цель принимает только последовательные PN. |
ping I,E --amsdu | Отправить пинг, инкапсулированный в обычный (не защищённый SPP) кадр A-MSDU. |
amsdu-inject | Имитировать атаку: отправить кадр A-MSDU, начало которого также является корректным заголовком rfc1042. |
amsdu-inject-bad | То же, что и выше, но для целей, которые некорректно разбирают кадр. |
ping I,F,BE,AE | Внедрить два фрагмента, зашифрованных разными ключами. |
ping I,F,BE,AE --pn-per-qos | То же, что и выше, но работает также, если цель принимает только последовательные PN. |
ping I,E,R,AE | Внедрить фрагмент, попытаться вызвать реассоциацию и внедрить второй фрагмент. |
ping I,E,R,E | То же, что и выше, но с большей задержкой перед отправкой второго фрагмента. |
ping I,E,R,AE --full-recon | Внедрить фрагмент, деаутентифицировать и переподключиться, затем внедрить второй фрагмент. |
ping I,E,R,E --full-recon | То же, что и выше, но с большей задержкой перед отправкой второго фрагмента. |
ping I,E,E --inc-pn 2 | Отправить фрагментированный пинг с непоследовательными номерами пакетов. |
ping I,E,P | Отправить фрагментированный пинг: первый фрагмент зашифрован, второй фрагмент открытым текстом. |
ping I,P,E | Отправить фрагментированный пинг: первый фрагмент открытым текстом, второй фрагмент зашифрован. |
ping I,P | Отправить пинг открытым текстом. |
ping I,P,P | Отправить фрагментированный пинг: оба фрагмента отправлены открытым текстом. |
linux-plain | Атака фрагментации со смешанным открытым/шифрованным трафиком, специфичная для Linux. |
ping I,D,P --bcast-ra | Отправить одноадресный пинг в открытом широковещательном 2-м фрагменте после подключения. |
ping D,BP --bcast-ra | То же, что и выше, но кадр отправляется во время 4-стороннего рукопожатия (проверить с помощью tcpdump). |
eapol-amsdu I,P | Отправить открытый A-MSDU, содержащий пинг-запрос, замаскированный под кадр EAPOL. |
eapol-amsdu BP | То же, что и выше, но кадр отправляется во время рукопожатия (проверить с помощью tcpdump). |
eapol-amsdu-bad I,P | Отправить некорректный открытый A-MSDU, содержащий пинг-запрос, замаскированный под кадр EAPOL. |
eapol-amsdu-bad BP | То же, что и выше, но кадр отправляется во время подключения (проверить с помощью tcpdump). |
В целом проверка того, уязвимо ли устройство к атакам на кэш, может быть утомительной. Поэтому я также рекомендую провести аудит кода, чтобы проверить, остаются ли фрагменты в памяти после деассоциации или деаутентификации от сети или после повторной ассоциации (это также можно динамически проверять с помощью отладочных выводов). Если фрагменты остаются в памяти, это следует рассматривать как риск, даже если неизвестно, можно ли это эксплуатировать. Это похоже на ситуацию, когда известно, что в реализации есть переполнение буфера, но (пока) неизвестно, как его эксплуатировать.
Запустите инструмент с дополнительным параметром --debug 2, чтобы получить дополнительные отладочные выводы
от wpa_supplicant или hostapd, а также от самого инструмента.
С помощью второго интерфейса в режиме монитора убедитесь, что между фрагментами не отправляются другие кадры. Например, я обнаружил, что моё устройство Intel иногда отправляет кадры Block Ack Response Action между фрагментами, и это мешало процессу дефрагментации тестируемого устройства.
Перепроверьте, что вы используете модифицированную прошивку, если она требуется для вашей беспроводной сетевой карты.
Инструмент уже проверяет это автоматически для устройств ath9k_htc. Инструмент также автоматически проверяет,
используете ли вы модифицированные драйверы, хотя может быть полезно вручную перепроверить это в вашем конкретном
дистрибутиве Linux.
Может помочь добавить задержку между получением IP-адреса и передачей первого фрагмента/кадра. Сделайте это
с помощью параметра --pre-test-delay.
| Команда | Краткое описание |
|---|
ping I,E --amsdu-fake | Если этот тест завершится успешно, флаг A-MSDU игнорируется (§3.5). |
ping I,E --amsdu-fake --amsdu-spp | Проверяет, аутентифицируется ли флаг A-MSDU, но затем игнорируется (§3.5). |
ping I,F,BE,E | На случай, если новый ключ устанавливается относительно поздно. |
ping I,E,F,AE | Вариант для случая, когда во время рукопожатия обновления ключа не принимаются кадры данных. |
ping I,E,F,AE --rekey-plain | Если устройство выполняет рукопожатие обновления ключа в открытом виде. |
ping I,E,F,AE --rekey-plain --rekey-req | То же, что и выше, и активно запрашивает обновление ключа в роли клиента. |
ping I,E,F,AE --rekey-early-install | Устанавливает новый ключ после отправки сообщения 3 4-стороннего рукопожатия. |
ping I,E,F,E [--rekey-pl] [--rekey-req] | То же, что и 4 теста выше, но с большей задержкой перед вторым фрагментом. |
ping I,F,BE,AE --freebsd | Атака со смешанным ключом против FreeBSD или аналогичных реализаций. |
ping I,E,R,AE --freebsd [--full-reconnect] | Атака на кэш, специфичная для реализаций FreeBSD. |
ping I,E,R,AP --freebsd [--full-reconnect] | Атака на кэш, специфичная для реализаций FreeBSD. |
ping I,E,R,AP [--full-reconnect] | Тест атаки на кэш, в котором второй фрагмент отправляется в открытом виде. |
ping I,E,E --amsdu | Отправляет обычный ping в виде фрагментированного A-MSDU кадра. |
ping I,E,P,E | Ping: первый фрагмент зашифрован, второй — в открытом виде, третий — зашифрован. |
linux-plain 3 | То же, что и linux-plain, но фрагмент-приманка отправляется с приоритетом QoS 3. |
ping I,P --bcast-ra | Ping в широковещательном кадре в открытом виде после 4-стороннего рукопожатия. |
ping BP --bcast-ra [--bcast-dst] | Ping в широковещательном кадре в открытом виде во время 4-стороннего рукопожатия (используйте tcpdump). |
ping BP [--bcast-dst] | Ping в кадре в открытом виде во время 4-стороннего рукопожатия (используйте tcpdump). |
eapfrag BP,BP | Экспериментальная атака с широковещательным фрагментом (используйте tcpdump). |
eapol-amsdu[-bad] BP --bcast-dst | То же, что и eapol-amsdu BP, но проще проверяется против точек доступа (используйте tcpdump). |
eapol-inject 00:11:22:33:44:55 | Проверяет, пересылает ли точка доступа кадры EAPOL до аутентификации (используйте tcpdump). |
eapol-inject-large 00:11:22:33:44:55 | Заставляет точку доступа отправлять фрагментированные кадры с помощью внедрения EAPOL (используйте tcpdump). |
ping I,D,E | Отправляет ping внутри зашифрованного второго фрагмента (без первого фрагмента). |
ping I,E,D | Отправляет ping внутри зашифрованного первого фрагмента (без второго фрагмента). |
--rekey-pl--rekey-plaineapfrag BP,AE