В открытых пакетах IWD (Intel inet Wireless Daemon) и wpa_supplicant, используемых для организации подключения клиентских Linux-систем к беспроводной сети, выявлены уязвимости, приводящие к обходу механизмов аутентификации:

• В IWD уязвимость (CVE-2023-52161) проявляется только при включении работы в режиме точки доступа, что нетипично для IWD, который обычно применяется для организации подключения к беспроводным сетям. Уязвимость позволяет подключиться к созданной точке доступа без знания пароля, например, когда пользователь явно предоставляет возможность выхода в сеть через своё устройство (Hotspot). Проблема устранена в версии IWD 2.14.

  Уязвимость вызвана отсутствием должной проверки порядка прохождения всех шагов при 4-этапном согласовании канала связи, применяемом при первом подключении к защищённой беспроводной сети. Из-за того, что IWD принимает сообщения для любых этапов согласования подключения, не проверяя факт прохождения предыдущего этапа, атакующий может, минуя отправку сообщения второго этапа, сразу отправить сообщение четвёртого этапа и получить доступ к сети, пропустив этап, на котором выполняется проверка аутентификации.

  При этом IWD пытается верифицировать код MIC (Message Integrity Code) для полученного сообщения четвёртого этапа. Так как сообщение второго этапа с параметрами аутентификации не получено, при обработке сообщения четвёртого этапа ключ PTK (Pairwise Transient Key) выставляется в нулевое значение. Соответственно, атакующий может вычислить MIC, используя нулевой PTK, и этот проверочный код будет принят IWD как корректный. После завершения подобного неполного согласования подключения атакующий получит полный доступ к беспроводной сети, так как точка доступа будет принимать отправляемые им кадры, зашифрованные нулевым ключом PTK.
  
  
  

• Выявленная в wpa_supplicant проблема (CVE-2023-52160) позволяет злоумышленнику заманить пользователя в фиктивную беспроводную сеть, выступающую клоном сети, к которой намерен подключиться пользователь. В случае подключения пользователя к подставной сети, атакующий может организовать перехват незашифрованного транзитного трафика пользователя (например, обращения к сайтам без HTTPS).

  Из-за недоработки в реализации протокола PEAP (Protected Extensible Authentication Protocol) атакующий может добиться пропуска второй стадии аутентификации при подключении некорректно настроенного устройства пользователя. Пропуск второй стадии аутентификации позволяет атакующему создать подставной клон заслуживающей доверия Wi-Fi сети и обеспечить подключение пользователя к фиктивной сети без проверки пароля.

  Для успешного проведения атаки в wpa_supplicant на стороне пользователя должна быть отключена проверка TLS-сертификата сервера, а атакующий должен знать идентификатор беспроводной сети (SSID, Service Set Identifier). При этом атакующий должен быть в зоне досягаемости беспроводного адаптера жертвы, но вне зоны досягаемости точки доступа клонируемой беспроводной сети. Атака возможна на сети с WPA2-Enterprise или WPA3-Enterprise, в которых применяется протокол PEAP.

  Разработчики wpa_supplicant заявили, что не считают проблему уязвимостью, так как она проявляется только в некорректно настроенных беспроводных сетях, в которых аутентификация EAP используется вместе с протоколом PEAP (EAP-TTLS) без проверки TLS-сертификата сервера. Конфигурации без проверки сертификата не имеют защиты от активных атак. Выявившие уязвимость утверждают, что подобные некорректные конфигурации типичны и широко распространены, что ставит под угрозу многие потребительские устройства на базе Linux, Android и Chrome OS, на которых применяется wpa_supplicant.

  Для блокирования проблемы в wpa_supplicant выпущен патч, добавляющий режим обязательного прохождения второй фазы аутентификации, помимо проверки TLS-сертификата. По словам разработчиков предложенное изменение лишь обходной путь, усложняющий проведение атак при использовании ручной аутентификации и бесполезный при применении таких опций, как EAP-GTC. Для реального решения проблемы администраторам сетей следует привести их конфигурацию к должному виду, т.е. настроить цепочку доверия для проверки сертификата сервера при помощи параметра ca_cert.