Проблеми, довеждащи до заобикаляне на аутентификацията на Wi-Fi в IWD и wpa_supplicant

В откритите пакети 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.

Източник: opennet.ru