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