- Регистрация
- 23 Август 2023
- Сообщения
- 3 600
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 243
Offline
Статьи У вас WPA Enterprise PEAP/TTLS? Тогда мы уже у вас и Пентест WPA-Enterprise: от теории к практике наглядно показывают наличие проблем с безопасностью WPA-Enterprise и рисуют неприглядную картину окружающей нас реальности. Но о том, как настроить Wi-Fi в организации, чтобы избежать описанных ужасов авторы упоминают кратко и без подробностей.
Я буду рассматривать подключение компьютеров домена Active Directory (AD) к Wi-Fi сети при помощи Network Policy Server (NPS). Статья разбита на две части. Теоретическая: общие вопросы, протоколы и их уязвимости, сценарии атак, настройки и особенности их применения. Практическая: производится пошаговая настройка Wi-Fi на базе Active Directory и Network Policy Server.
TL;DR: WPA-Enterprise требует обязательного применения и проверки сертификата сервера. Безальтернативно. Без сертификата WPA‑Enterprise становится просто красивой декорацией в театре безопасности. Статья написана для того, чтобы все и всегда проверяли сертификат сервера.
Определения
Определения
Суппликант — конечное устройство (телефон, ноутбук, компьютер), которое аутентифицируется в системе.
Аутентификатор / RADIUS-клиент / NAS — устройство, которое аутентифицирует подключающееся устройство и, в случае успеха, разрешает доступ к сети. Для Wi-Fi формирует ключи шифрования и организует защищенный канал связи. Аутентификатором может быть сама точка доступа или контроллер, управляющий точками. В рамках этой статьи тот факт, что NAS и точки доступа могут быть разными устройствами, не играет роли, поэтому мы не будем их различать.
Сервер аутентификации / RADIUS-сервер — принимает и обрабатывает запросы аутентификации в соответствии с установленными политиками. В нашем случае это Network Policy Server (NPS). Часто будет упоминаться как просто «сервер».
Каталог — база аутентификационных данных. В нашем случае в качестве каталога выступает Active Directory. В рамках этой статьи практически не рассматривается, поэтому на дальнейших схемах присутствовать не будет.
Процесс аутентификации и его проблемы
Обмен пакетами при EAP аутентификации
В свою очередь, EAP — это фреймворк, а не конкретный протокол аутентификации. В качестве протокола аутентификации NPS предлагает аутентификацию по сертификату EAP-TLS, и аутентификацию по паролю EAP-MSCHAPv2.
Аутентификация по сертификату надежна, но требует развертывания полноценной инфраструктуры открытых ключей (Public Key Infrastructure, PKI) и выпуска сертификатов для всех компьютеров / пользователей, которые будут подключаться.
Единственным вариантом парольной аутентификации для схемы Active Directory c NPS до сих пор остается EAP-MSCHAPv2. Но он уязвим к перехвату. Атакующий может поднять поддельную точку доступа (Evil twin) и перехватить обмен:
Evil Twin MITM
В результате атакующий может:
Знания NT-хэша (даже без пароля) достаточно для подключения к сети, а при помощи техники pass-the-hash он может использоваться вместо пароля уже внутри сети.
Для атаки на MSCHAPv2 настоящий сервер аутентификации вообще не нужен, т.е. возможна следующая модель:
Evil Twin
В этой модели атакующий может просто пройти мимо уязвимого устройства в любом месте. Устройство, увидев знакомую сеть, попытается к ней подключиться и, начав обмен, сообщит атакующему достаточно информации для проведения атаки. После этого атакующий вычисляет пароль и/или хэш и подключается к сети организации.
При использовании EAP у суппликанта нет механизмов проверки NAS. Конечными точками протокола выступают суппликант и сервер аутентификации, только они могут провести взаимную аутентификацию непосредственно. Легитимность NAS и других промежуточных устройств в рамках протокола EAP не проверяется, на что прямо указывается в разделе 4.3.9 RFC 3579.
Цитата
In the case where the authenticator and authentication server reside on different machines, there are several implications for security. First, mutual authentication will occur between the peer and the authentication server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone.
Поэтому для WPA-Enterprise проблема MITM актуальна и сложна. И в этом смысле WPA-PSK действительно выглядит выигрышно по части безопасности.
В целом, для противодействия перехвату достаточно выполнения двух условий:
PEAP vs Evil Twin
Шифрование обеспечивается EAP-PEAP — это EAP-метод, организующий TLS-туннель. Сначала между суппликантом и сервером создается туннель и дальнейшая аутентификация производится внутри, где могут использоваться те же методы: EAP-TLS и EAP-MSCHAPv2.
Есть еще EAP-TTLS — это тоже реализация идеи аутентификации внутри TLS-туннеля с применением разных внутренних методов. Но NPS его не реализует, поэтому подробно останавливаться на нем не будем.
На финальной стадии аутентификации RADIUS-сервер в сообщении Access-Accept передает NAS ключ MSK, который потом преобразуется в PMK и используется для хэндшейка Wi-Fi. Ключ MSK формируются, в частности, на основе ключей TLS-туннеля. Так как атакующий не знает ключей туннеля, то сформировать PMK и установить соединение он не может.
Но без аутентификации сервера шифрование бесполезно, атакующий может действовать по следующей схеме:
Evil Twin как PEAP-прокси
Увы, единственный надежный метод аутентификации сервера — это сертификат. Поэтому совсем без сертификатов никак нельзя.
Атака типа PEAP-MSCHAPv2 прокси подробно рассмотрена в статье: SIMULATION OF MITM IN PEAP WITH HOSTAP. Автор очень точно выразил свою главную мысль, постановка задачи начинается со слов: «So if I am the very user who skips certificate verification» («Допустим, что я тот самый пользователь, который не проверяет сертификат»).
MSCHAPv2 сломан
Он сломан уже очень давно. Еще в далеком 2012 году Moxie Marlinspike запустил сервис www.cloudcracker.com (уже не работает, но есть продолжатели его дела), который предлагал взлом MSCHAPv2 и получение NT-хэша полным перебором всего за сутки.
Суть проблемы описана тут: Weaknesses in MS-CHAPv2 authentication.
Пароль хэшируется как H=MD4(Unicode(Password)) (NT-хэш). Затем этот хэш длиной 128 бит разделяется на три части: K1,K2 по 56 бит и K3 длиной 16 бит, т.е. K1|K2|K3=H. (Здесь: | — конкатенация). Ключи служат ключами DES-шифрования сообщения C, формируя ответ R=R1|R2|R3=DES(K1, C)|DES(K2, C)|DES(K3, C).
Так как хэширование пароля происходит без соли, то NT-хэш функционально эквивалентен паролю и взломщику для прохождения аутентификации достаточно восстановить хэш. Чтобы это сделать, надо найти ключи K1, K2, K3 зная сообщение С и части ответа R1, R2, R3. Ключ K3 не представляет никаких проблем, т. к. пространство перебора составляет всего
. Ключи K1 и K2 шифруют одно и то же сообщение, поэтому нужен всего один перебор ключевого пространства размером
.
Поэтому, от длины и сложности пароля ничего не зависит. Вычислительные затраты на брутфорс в среднем являются константой, а время взлома зависит только от вычислительной мощности.
Рассмот��им обмен пакетами:
Обмен пакетами MSCHAPv2
Для вычисления хэша атакующему необходимы: Authenticator Challenge (2) — может генерироваться атакующим, User Name, Peer Challenge, Challenge Response (3) — передаются суппликантом. Атакующий не может сформировать правильный ответ (4) и корректно завершить аутентификацию, но у него уже есть достаточно информации для офлайн-взлома.
Это дает возможность атакующим просто сидеть где-нибудь далеко от атакуемой организации и ловить проходящих мимо сотрудников.
Некоторых суппликантов можно «уговорить» пропустить завершающую проверку (4) и (5). В этом случае уязвимое устройство подключится к «сети» атакующего. После подключения устройство будет думать, что оно находится в сети организации и начнет обращаться к внутренним сервисам, вроде контроллера домена. Это может дать много интересной для атакующего информации. Пример такой уязвимости: Understanding PEAP In-Depth
Сколько надо времени на взлом и сколько это стоит?
Брутфорс стоит $20 (сайт-продолжатель дела cloudcracker.com) и занимает «пару дней». Не сказать, что это совсем бесплатно, но вполне демократично и доступно каждому.
Я также решил проверить, сколько займет брутфорс на моей старенькой RTX 2080. Я сделал дамп реального сетевого обмена EAP-MSCHAPv2 с использованием длинного случайного пароля в 32 символа с энтропией 190 бит, т.е. пароль заведомо более стойкий, чем хэш. Для брутфорса хэша использовал hashcat (mode 14000). При хэшрейте ~30 GH/s время полного перебора оказалось около 27 дней, соответственно среднее время будет около двух недель. Несколько утомительно, но вполне применимо.
Эксперимент завершился успешно, хэш был восстановлен. Понадобился перебор около 60% полного пространства.
RTX 5090 имеет хэшрейт 179 GH/s, для нее среднее время брутфорса составит пару дней. (Время полного перебора в днях: days_max = 2^56 [H] / hashrate [H/sec] / 86400 [sec/day])
Из этого становится понятно, что сейчас взлом реален даже в домашних условиях.
Это не означает, что MSCHAPv2 нельзя использовать. Но необходимо относиться к его защите также, как к защите plaintext-пароля: строго соблюдать безопасность канала связи и аутентифицировать сервер.
Валидация сертификата PEAP-сервера
Основной метод валидации — стандартная проверка цепочки сертификатов. Главное отличие от обычной проверки — необходимо явно указать, к какому корневому сертификату должна сходиться цепочка (чуть ниже рассмотрим почему).
Крайне полезно обеспечить возможность подключения только к конкретному серверу или списку серверов. Суппликант может дополнительно проверить сертификат сервера и ограничить подключение по определенным условиям. Стандарт в разделе 3.2.7.1 [MS-PEAP] регламентирует проверку полей Subject Name и Subject Alternative Name.
С точки зрения протокола PEAP, FQDN сервера не несет смысловой нагрузки так как этот адрес не используется при подключении. Сервер передает суппликанту сертификат, но с какого хоста происходит передача суппликант не знает. Поэтому имя, указанное в сертификате — это просто идентификатор, достоверность которого утверждена центром сертификации. Это имя может быть достоверным, но нерелевантным.
Из этого следует, что использование публичных центров сертификации небезопасно, если нет привязки подключения к конкретному серверу. Действительный сертификат любого домена может быть признан суппликантом валидным и использоваться для проведения атаки. Подробно можно почитать в статье: Connect to these servers.
Поэтому:
Windows проверяет только Subject Name сертификата и игнорирует Subject Alternative Name. (Этот факт в свое время попортил мне немного нервов при отладке). Проверка регистрозависима, поэтому если сертификат выдан на имя вида NPS.example.corp (что часто бывает), то только в такой форме и надо заполнять настройки подключения.
При проверке имени сертификата Windows дает возможность использовать регулярные выражения. Это может быть удобно, если есть несколько серверов. В таком случае, обязательно используйте явные маркеры начала (^) и окончания ($) строки. Допустим, ваш сервер имеет сертификат от публичного сервиса nps1.example.com, а проверяется регулярным выражением nps[0-9]\.example\.com. Атакующий может зарегистрировать домен nps1.example.com.hacker.net, который тоже пройдет валидацию по регулярному выражению, если нет явных маркеров. Правильное выражение ^nps[0-9]\.example\.com$. (Модель атаки взята из статьи, приведенной выше).
Еще одна огромная проблема — если пользователь подключается к неизвестному серверу или сервером предоставлен неизвестный сертификат, то никакой реальной возможности проверить достоверность предоставленной информации у пользователя нет, а возможность нажать кнопку «подключиться» — есть. Любая информация в предоставленном сертификате (кроме ключа) может быть подделана, а сервер может быть очень похож на настоящий. Этот метод продемонстрирован в статье Пентест WPA-Enterprise: от теории к практике.
По сути, задача валидации перекладывается на пользователя, не владеющего необходимой информацией. Кроме того, нажать кнопку подтверждения можно просто «на автомате» (бросьте в меня камень те, кто так не делал).
Необходимо отключать такое поведение везде, где это возможно.
Субъект аутентификации
При подключении WPA-Enterprise Windows умеет аутентифицировать как пользователя, так и компь��тер. При настройках по умолчанию, если мы просто нажали «подключиться» к произвольной сети, сначала идет запрос на аутентификацию компьютера, а затем, если не получилось — запрашивается пароль пользователя.
Пароль учетной записи компьютера — длинный и меняется регулярно. У атакующих будет ограниченное время для его эксплуатации (ЕМНИП по умолчанию срок действия пароля — 30 дней, а регулярность смены — две недели). Это исключает применение словарных атак на слабые пароли пользователей и вынуждает атакующих применять ресурсоемкий взлом NT-хэша.
Если аутентифицировать компьютер, а настройки распространяются при помощи GPO, то от пользователя не требуется никаких действий для подключения к сети. Принес ноутбук, включил — и все работает. Пользователи крайне положительно оценивают такое удобство.
Кроме того, компьютер получает доступ в сеть до входа пользователя, что позволяет отработать некоторым GPO. Например, установка ПО требует работы сети до входа пользователя.
ИМХО, если нет каких-то весомых причин аутентифицировать подключение именно пользователя, аутентификация компьютера — хорошая идея.
Подключение к неизвестным сетям
При подключении к новой сети WPA-Enterprise с аутентификацией PEAP-MSCHAPv2, для которой нет настроенного профиля, Windows использует настройки подключения по умолчанию: без проверки сертификата и других настроек. И главное — доменная аутентификация используется автоматически: сначала идет попытка аутентифицировать компьютер, и только после неудачи появляется запрос на ввод имени и пароля.
Еще раз: Windows автоматически сливает аутентификационные данные учетной записи компьютера неизвестной сети без никакой защиты по умолчанию! И настроек, чтобы изменить такое поведение я не нашел.
Атакующий может поднять вредоносную точку доступа в месте, где сотрудники с некоторой вероятностью могут подключаться к Wi-Fi (не корпоративной, а местной). Например, в кафе:
Wi-Fi в кафе
При подключении к сети появится предупреждение:
Подключение к новой сети
Предупреждение не релевантно угрозе, человек действительно ожидает увидеть эту сеть и хочет к ней подключиться. И как только будет нажата кнопка подтверждения, атаку можно считать успешной.
Мне не удалось найти решения этой проблемы. Можно полностью запретить подключение к неизвестным сетям. Это хорошее решение, если вы подключаете стационарные устройства в рамках офиса. Но для разъездных ноутбуков это не подходит, так как они должны работать дома или в командировках.
Можно обучить пользователей, что такое предупреждение это красный флаг и следует всегда отказывать в подключении. Но полагаться на постоянную внимательность пользователей в вопросах безопасности — плохая стратегия.
Подключение сторонних устройств
Увы, но использование доменных паролей для подключения сторонних устройств по Wi-Fi — очень плохая идея. Сошлюсь на уже упомянутые статьи:
Практически невозможно сделать так, чтобы любые сторонние устройства проходили аутентификацию правильно.
Для обеспечения безопасности мы должны контролировать каждый из параметров подключения на конечных устройствах и запретить пользователю совершать небезопасные действия вроде подтверждения неизвестных сертификатов.
Чаще всего люди просто хотят получить интернет на своем телефоне / ноутбуке. Для них можно сделать отдельную WPA2/WPA3-PSK сеть с доступом только в интернет. Так как доступа к внутренней сети нет — можно спокойно подключать всех, кто зашел в гости. Периодически пароль можно менять для профилактики.
Для тех, кто хочет со своего личного ноутбука работать в доменной сети — на ноутбуке настраивается VPN. Тогда человек может работать и дома и на работе одинаково и без создания дополнительных рисков (предполагается, что VPN уже есть и туда пускают с личных ноутбуков).
Криптографическое связывание (Cryptographic Binding)
Определено в 7.15 RFC 3748 и подробно рассматривается в RFC 7029. Эта техника направлена на предотвращение MITM-атак и позволяет криптографически доказать, что туннель (в нашем случае PEAP) и внутренний метод аутентификации (MSCHAPv2) выполняются одним и тем же субъектом. Сервер убеждается, что обе операции проводятся на суппликанте и наоборот. Атакующий посередине не может передать выполнение внутренней аутентификации другому участнику или проксировать ее в другой туннель, что ограничивает его возможности при проведении атаки.
К сожалению, связывание не заменяет проверку сертификата и не защищает от перехвата обмена MSCHAPv2. Вот обмен пакетами EAP-PEAP с выполнением связывания:
EAP-PEAP с криптографическим связыванием
Связывание выполняется после прохождения внутренней аутентификации. Поэтому, если атакующий будет действовать от имени сервера, а сертификат сервера не проверяется суппликантом, то атакующий может добраться до этапа обмена MSCHAPv2 и получить все необходимое для его взлома. Завершить подключение не получится, но этого и не требуется.
На ограниченную пользу связывания в случае MSCHAPv2 указывает также раздел 3.2.2 RFC 7029.
Цитата
Cryptographic binding is only a valuable component of a defense if the inner authentication is a key-deriving EAP method. Most tunnel methods also support non-EAP inner authentication such as Microsoft CHAP version 2 [RFC2759]. This may undermine cryptographic binding in a number of ways. An attacker may be able to convert an EAP method into a compatible non-EAP form of the same credential to suppress cryptographic binding. In addition, an inner authentication may be available through an entirely different means. For example, a Lightweight Directory Access Protocol [RFC4510] or other directory server may provide an attacker a way to get challenges and provide responses for an authentication mechanism entirely outside of the AAA/EAP context. An attacker with this capability may be able to get around server policy requiring an inner authentication be used only in a given type of tunnel.
Тем не менее, ряд работ рекомендует применение связывания даже при использовании MSCHAPv2. Оно может помочь, если сертификат сервера скомпрометирован, при проведении атак на понижение уровня защиты (downgrade-атаки), от некоторых атак непосредственно на сервер.
Пример атаки на PEAP-MSCHAPv2 с понижением и преобразованием метода аутентификации: Short paper: Exploiting WPA2-enterprise vendor implementation weaknesses through challenge response oracles. В результате, атакующий подключается к сети с использованием уязвимого устройства. Авторы указывают, что связывание предотвращает такой тип атак (но не предотвращает перехват аутентификационных данных).
Связывание не позволяет провести атаку немедленно и вынуждает атакующих проводить ресурсоемкую операцию взлома хэша. В этом смысле безопасность — это экономический баланс между средствами, которые необходимо вложить в ее обеспечение против средств на ее преодоление. Даже $20 это реальный финансовый барьер.
Связывание инициируется только сервером. Атакующий, играющий роль сервера может не включать связывание для суппликанта при проведении атаки. Поэтому правильное поведение суппликанта — обрывать подключение, если связывание не проведено. Связывание не является обязательным, поэтому его настройку на клиентских устройствах надо делать явно и только для тех сетей, где оно используется.
Аналогично должен настраиваться сервер - обрывать соединение для суппликантов, которые не прошли связывание.
Blast-RADIUS
Подробное описание: https://www.blastradius.fail/attack-details
Короткая выжимка:
NPS в курсе этой уязвимости и, если не принять мер, он будет сыпать предупреждениями Event 4421. Кроме того, использование Message-Authenticator входит во все рекомендации по безопасности RADIUS. Игнорировать рекомендации не будем, для NPS делаем следующее:
KB5040268: How to manage the Access-Request packets attack vulnerability associated with CVE-2024-3596
Фрагментация пакетов
Таймаут аутентификации при подключении к Wi-Fi — признак возможных проблем с MTU.
При использовании сертификатов (а мы их будем использовать) размер EAP пакета может оказаться слишком большим, чтобы упаковаться в один Ethernet фрейм -> возникает фрагментация пакетов -> пакеты теряются -> аутентификация не работает.
EAP-пакет на пути между суппликантом и сервером инкапсулируется в разные протоколы, имеющие разные MTU. Поэтому, даже если одна сторона сформировала пакет без фрагментации, то до другой стороны пакет все равно может не дойти.
Самое неприятное — это проблема сетевая и практически не оставляет следов в логах. Все настроено как положено, но просто молча не работает, а аутентификация завершается таймаутом.
Рекомендации по MTU для NPS: Configure Network Policies
Итого — необходимо установить параметр Framed-MTU <= 1344. Может потребоваться подбор в сторону уменьшения, но при стандартном L2 MTU = 1500 я с таким не сталкивался.
Сертификаты
Вариант 1 — Самоподписанные сертификаты
Для аутентификации сервера можно использовать самоподписанные сертификаты и распространять их с помощью той же GPO, что и настройки сети.
При компрометации сертификата сервера выпускаем новый, заменяем его на NPS, меняем GPO и на этом все. Минус — чтобы обновить GPO надо подключиться к сети, а подключиться по Wi-Fi со старым сертификатом уже нельзя, надо обязательно подключиться проводом. Учитывая, что многие современные ноутбуки не имеют проводного порта — это может стать проблемой для поддержки.
Можно организовать транзитный период — сначала выпускаем и распространяем новый сертификат сервера, затем меняем его на NPS. Но при компрометации сертификата это означает, что у атакующих будет больше времени для нехороших дел. А обновление GPO обязательно произойдет не на всех компьютерах (кто в отпуске, кто ноутбук давно на работу не приносил, а кто его вообще не включал).
Вариант 2 — Мини-PKI
Если серверов несколько, или есть еще какие-то места, где сертификаты могли бы пригодиться (а такая надобность зачастую есть) можно использовать мини-PKI.
Создаем корневой сертификат, выпускаем несколько сертификатов под наши нужды. При помощи GPO распространяем корневой сертификат на все компьютеры. Теперь нашим сертификатам есть доверие по умолчанию.
Компрометация корневого сертификата несет огромные риски, но в этой схеме ключ корневого сертификата можно держать офлайн.
Без реализации системы валидации и отзыва сертификатов (AIA, CDP и CRL/OCSP), компрометация любого сертификата (не только корневого) требует полной смены такой PKI. Мы никак не сможем всем клиентам сразу сказать — больше не доверяй сертификату X, если он подписан доверенным корневым сертификатом.
Тем не менее, при компрометации одного сертификата есть аварийный план — поместить его в список недоверенных при помощи GPO. Сменить сертификат сервера мы можем сразу, без необходимости транзитного периода. Это немедленно устранит значительное количество рисков, прекратит массовую рыбалку атакующими и даст время для смены корневого сертификата и перевыпуска всех остальных.
Почему этот план аварийный и не стоит его использовать как штатный? Потому, что эта процедура не гарантирует отзыв доверия к сертификату. Компьютеры, не обновившие GPO будут уязвимы. Возможно, сертификаты устанавливались куда-то еще. При наличии системы отзыва все проверяют действительность сертификата каждый раз при его применении. А при ее отсутствии очень легко допустить, что кто-то будет доверять скомпрометированному сертификату.
Тем не менее, этот вариант видится мне хорошим компромиссом. Есть аварийный план и некоторый запас времени на смену корневого сертификата.
Также, в этой схеме можно организовать регулярную смену сертификата сервера, например, раз в год. Это существенно снижает риски компрометации.
Вариант 3 — Полноценная PKI
Описывать подробно не буду, есть замечательная серия статей на русском языке:
https://www.sysadmins.lv/blog-ru/ustanavlivaem-certification-authority-podvedenie-itogov.aspx
Если у вас есть полноценная PKI, то надо немедленно забыть про MSCHAPv2 как про страшный сон, настроить выпуск сертификатов для компьютеров и использовать EAP-TLS. Дальше эту статью можно не читать.
Разворачиваем Wi-Fi
Что будем делать:
Настройку самих Wi-Fi точек доступа / NAS рассматривать не будем. Предполагается, что NAS уже есть, настроен на WPA2/WPA3-Enterprise и обращается к NPS-серверам по протоколу RADIUS.
Наша сеть:
Корневой сертификат:
Расширение Authority Key Identifier (AKI) для корневого сертификата необязательно.
Ключ от этого сертификата храним офлайн со сложным паролем.
Сертификат сервера:
Требования к сертификату NPS сервера: Configure Certificate Templates for PEAP and EAP requirements
Мы будем синхронизировать настройки NPS серверов, поэтому один и тот же сертификат будет использован на обоих серверах. Это компромиссное решение для упрощения синхронизации.
В этом примере сертификат сервера должен меняться ежегодно.
Для совсем небольших организаций, где нет регламентированных процедур или некому следить за сетью постоянно, можно установить срок действия сертификата сервера в те же 20 лет («установил и забыл»). Это менее безопасно, но намного лучше, чем отсутствие сертификата сервера вообще.
Генерируем сертификаты:
Скрипт ниже генерирует сертификаты и экспортирует их в pfx-файлы (сертификат+ключ) с установленным паролем. Пароли сохраняются в файле example_corp_pwd.txt. Их немедленно прячем в парольный менеджер.
Корневой сертификат и его ключ example_corp_root_ca_2026.pfx прячем офлайн.
Для корневого сертификата создается также файл example_corp_root_ca_2026.cer (сертификат без ключа). Его надо импортировать на NPS сервера и распространять на компьютеры.
Сертификат и ключ сервера example_corp_nps.pfx будем импортировать на оба сервера NPS.
Минутка душноты: шаблон SSLServerAuthentication почему-то не содержит расширения Basic Constraints со значением CA:FALSE, что является де-факто стандартом. Добавлено в явном виде вручную.
# Generate root certificate
$rootParams = @{
Subject = 'Example Corp Root CA 2026'
Type = 'Custom'
KeyLength = 4096
KeyAlgorithm = 'RSA'
HashAlgorithm = 'SHA384'
KeyExportPolicy = 'Exportable'
NotAfter = (Get-Date).AddYears(20)
KeyUsage = 'CertSign', 'CRLSign'
TextExtension = @(
# Basic Constraints
'2.5.29.19={critical}{text}CA=true'
)
CertStoreLocation = 'Cert:\CurrentUser\My'
}
$rootCert = New-SelfSignedCertificate @rootParams
# Export root certificate
Add-type -AssemblyName System.Web
$password = [System.Web.Security.Membership]::GeneratePassword(32, 0)
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String $password
Write 'Root certificate password:' $password | Out-File 'example_corp_pwd.txt' -Encoding ascii
[void](Export-PfxCertificate -Cert $rootCert -FilePath 'example_corp_root_ca_2026.pfx' -Password $securePassword)
[void](Export-Certificate -Cert $rootCert -FilePath 'example_corp_root_ca_2026.cer')
# Generate server certificates
$serverParams = @{
Subject = 'Example Corp NPS'
Type = 'SSLServerAuthentication'
Signer = $rootCert
KeyLength = 4096
KeyAlgorithm = 'RSA'
HashAlgorithm = 'SHA384'
KeyExportPolicy = 'Exportable'
NotAfter = (Get-Date).AddYears(1)
TextExtension = @(
# Basic Constraints
'2.5.29.19={critical}{text}CA=false'
)
CertStoreLocation = 'Cert:\CurrentUser\My'
}
$serverCert = New-SelfSignedCertificate @serverParams
# Export server certificate
$password = [System.Web.Security.Membership]::GeneratePassword(32, 0)
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String $password
Write 'Server certificate password:' $password | Out-File 'example_corp_pwd.txt' -Encoding ascii -Append
[void](Export-PfxCertificate -Cert $serverCert -FilePath 'example_corp_nps.pfx' -Password $securePassword)
# Cleanup
Remove-Item -DeleteKey -Path Cert:\CurrentUser\My\$($rootCert.Thumbprint)
Remove-Item -DeleteKey -Path Cert:\CurrentUser\My\$($serverCert.Thumbprint)
Установка Network Policy Server
Устанавливаем роль «Сервер политики сети».
Install-WindowsFeature NPAS -IncludeManagementTools
Противодействие Blast-RADIUS (рекомендованные настройки):
netsh nps set limitproxystate all = enable
netsh nps set requiremsgauth all = enable
Регистрируем сервер в Active Directory:
netsh nps add registeredserver
Открываем порты (UDP 1812, 1813). Встроенные правила фаервола для NPS могут не работать, проблема описана тут: Windows Server 2019 — Default NPS Firewall rules (Port 1812 UDP) Not working. Поэтому создаем новое правило:
New-NetFirewallRule -DisplayName 'Allow inbound NPS/RADIUS (UDP 1812, 1813)' -Direction Inbound -Action Allow -Protocol UDP -LocalPort 1812,1813
Импорт сертификатов (предварительно копируем их на сервер). Для импорта серверного сертификата с ключом вводим пароль от файла.
Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root -FilePath 'example_corp_root_ca_2026.cer'
$pwd = Get-Credential -UserName 'Enter cert password below' -Message 'Enter cert password below'
Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\My -FilePath 'example_corp_nps.pfx' -Password $pwd.password
Настройка Network Policy Server
Во многих полях и условиях NPS позволяет использовать регулярные выражения: Use Regular Expressions in NPS.
Добавляем RADIUS-клиента (наша точка доступа / NAS):
Создаем сетевую политику:
Устанавливаем условия:
Включаем PEAP-аутентификацию. Все методы, кроме PEAP обязательно убрать!
Настраиваем туннель.
Добавляем RADIUS-атрибут Framed-MTU=1344.
Синхронизация конфигурации
Я обычно устанавливаю два сервера. После установки и настройки мастер-сервера можно сделать экспорт конфигурации, а затем импортировать на второй. Чтобы не делать этого вручную после каждого изменения конфигурации делаем автоматическую синхронизацию.
Предполагается, что на каждом сервере есть каталог C:\NPS для файла конфигурации.
$path = 'C:\NPS\nps.xml'
$servers = @('nps2.example.corp')
Export-NpsConfiguration -Path $path
$servers | Foreach-Object {
$session = New-PSSession -ComputerName $_
Copy-Item -Path $path -ToSession $session -Destination $path
Invoke-Command -ComputerName $_ -ScriptBlock {
Import-NPSConfiguration -Path $using:path
Remove-Item -Force -Path $using:path
}
}
Remove-Item -Force -Path $path
При желании, можно дополнительно сделать архив конфигураций по датам или коммитить конфигурацию в git. Но следует иметь в виду, что файл конфигурации содержит секреты в открытом виде.
GPO
Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network (802.11) Policies
Добавляем политику для Windows Vista:
В политику добавляем нашу Wi-Fi сеть example-ssid:
Задаем параметры подключения. Включаем аутентификацию только компьютеров.
Настройки PEAP-туннеля:
Если у вас несколько серверов с разными сертификатами, то в поле проверки сертификата их можно перечислить через точку с запятой (
или использовать регулярные выражения.
Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies/Trusted Root Certification Authorities
Импортировать корневой сертификат из файла example_corp_root_ca_2026.cer:
Заключение
Высокий уровень безопасности Wi-Fi это не обязательно дорого или сложно, это можно сделать даже в небольшой организации. Для этого не обязательно разворачивать полноценную PKI.
Огромный пласт рисков можно предотвратить включением проверки сертификата сервера. Эта проверка одновременно и проста и сложна. Проста в том смысле, что ее включение — не рокет-саенс. Сложность в том, что проверку сертификата легко обойти и сложно гарантировать. Ошибки конфигурации не видны, все подключается и работает, словно никаких проблем нет.
Необходим строгий контроль настроек клиентского оборудования. Мы можем обеспечить такой контроль для доменных компьютеров, но не для личных устройств сотрудников. Поэтому, следует разделять доверенные и недоверенные конечные устройства. Недоверенные устройства не должны использовать доменную аутентификацию.
Я буду рассматривать подключение компьютеров домена Active Directory (AD) к Wi-Fi сети при помощи Network Policy Server (NPS). Статья разбита на две части. Теоретическая: общие вопросы, протоколы и их уязвимости, сценарии атак, настройки и особенности их применения. Практическая: производится пошаговая настройка Wi-Fi на базе Active Directory и Network Policy Server.
TL;DR: WPA-Enterprise требует обязательного применения и проверки сертификата сервера. Безальтернативно. Без сертификата WPA‑Enterprise становится просто красивой декорацией в театре безопасности. Статья написана для того, чтобы все и всегда проверяли сертификат сервера.
Определения
Определения
Суппликант — конечное устройство (телефон, ноутбук, компьютер), которое аутентифицируется в системе.
Аутентификатор / RADIUS-клиент / NAS — устройство, которое аутентифицирует подключающееся устройство и, в случае успеха, разрешает доступ к сети. Для Wi-Fi формирует ключи шифрования и организует защищенный канал связи. Аутентификатором может быть сама точка доступа или контроллер, управляющий точками. В рамках этой статьи тот факт, что NAS и точки доступа могут быть разными устройствами, не играет роли, поэтому мы не будем их различать.
Сервер аутентификации / RADIUS-сервер — принимает и обрабатывает запросы аутентификации в соответствии с установленными политиками. В нашем случае это Network Policy Server (NPS). Часто будет упоминаться как просто «сервер».
Каталог — база аутентификационных данных. В нашем случае в качестве каталога выступает Active Directory. В рамках этой статьи практически не рассматривается, поэтому на дальнейших схемах присутствовать не будет.
Процесс аутентификации и его проблемы
Суппликант подключается к NAS. Обязательный этап подключения — аутентификация устройства. WPA-Enterprise подразумевает использование EAP, поэтому дальнейший обмен между суппликантом и NAS идет по протоколу 802.1X (EAPOL).
NAS устанавливает соединение с RADIUS-сервером, извлекает EAP-пакеты и перед��ет их от суппликанта серверу и обратно, выступая в качестве прозрачного прокси, а протоколы 802.1X и RADIUS выступают транспортом для EAP. Фактически, в процессе аутентификации суппликант общается напрямую с сервером. В ходе обмена формируется ключ Master Session Key (MSK).
После завершения EAP-сессии сервер дает команду NAS разрешить или запретить доступ (сообщения RADIUS Access-Accept / Access-Reject). Так как NAS выступает только в качестве прокси, то ключа MSK он не знает. Ключ явно передается от RADIUS сервера в сообщении Access-Accept.
Для установления Wi-Fi-сессии необходим ключ Pairwise Master Key (PMK). NAS преобразует MSK -> PMK (такое же преобразование делает суппликант), а затем производит Wi-Fi хэндшейк (4-Way Handshake), который при помощи PMK формирует сессионные ключи.
Обмен пакетами при EAP аутентификации
В свою очередь, EAP — это фреймворк, а не конкретный протокол аутентификации. В качестве протокола аутентификации NPS предлагает аутентификацию по сертификату EAP-TLS, и аутентификацию по паролю EAP-MSCHAPv2.
Аутентификация по сертификату надежна, но требует развертывания полноценной инфраструктуры открытых ключей (Public Key Infrastructure, PKI) и выпуска сертификатов для всех компьютеров / пользователей, которые будут подключаться.
Единственным вариантом парольной аутентификации для схемы Active Directory c NPS до сих пор остается EAP-MSCHAPv2. Но он уязвим к перехвату. Атакующий может поднять поддельную точку доступа (Evil twin) и перехватить обмен:
Evil Twin MITM
В результате атакующий может:
Сразу подключиться к сети от имени жертвы.
Подобрать пароль по словарю, с помощью генератора или брутфорсом
Восстановить NT-хэш учетной записи.
Знания NT-хэша (даже без пароля) достаточно для подключения к сети, а при помощи техники pass-the-hash он может использоваться вместо пароля уже внутри сети.
Для атаки на MSCHAPv2 настоящий сервер аутентификации вообще не нужен, т.е. возможна следующая модель:
Evil Twin
В этой модели атакующий может просто пройти мимо уязвимого устройства в любом месте. Устройство, увидев знакомую сеть, попытается к ней подключиться и, начав обмен, сообщит атакующему достаточно информации для проведения атаки. После этого атакующий вычисляет пароль и/или хэш и подключается к сети организации.
При использовании EAP у суппликанта нет механизмов проверки NAS. Конечными точками протокола выступают суппликант и сервер аутентификации, только они могут провести взаимную аутентификацию непосредственно. Легитимность NAS и других промежуточных устройств в рамках протокола EAP не проверяется, на что прямо указывается в разделе 4.3.9 RFC 3579.
Цитата
In the case where the authenticator and authentication server reside on different machines, there are several implications for security. First, mutual authentication will occur between the peer and the authentication server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone.
Поэтому для WPA-Enterprise проблема MITM актуальна и сложна. И в этом смысле WPA-PSK действительно выглядит выигрышно по части безопасности.
В целом, для противодействия перехвату достаточно выполнения двух условий:
EAP трафик должен быть зашифрован.
Суппликант обязан аутентифицировать сервер.
PEAP vs Evil Twin
Шифрование обеспечивается EAP-PEAP — это EAP-метод, организующий TLS-туннель. Сначала между суппликантом и сервером создается туннель и дальнейшая аутентификация производится внутри, где могут использоваться те же методы: EAP-TLS и EAP-MSCHAPv2.
Есть еще EAP-TTLS — это тоже реализация идеи аутентификации внутри TLS-туннеля с применением разных внутренних методов. Но NPS его не реализует, поэтому подробно останавливаться на нем не будем.
На финальной стадии аутентификации RADIUS-сервер в сообщении Access-Accept передает NAS ключ MSK, который потом преобразуется в PMK и используется для хэндшейка Wi-Fi. Ключ MSK формируются, в частности, на основе ключей TLS-туннеля. Так как атакующий не знает ключей туннеля, то сформировать PMK и установить соединение он не может.
Но без аутентификации сервера шифрование бесполезно, атакующий может действовать по следующей схеме:
Evil Twin как PEAP-прокси
Увы, единственный надежный метод аутентификации сервера — это сертификат. Поэтому совсем без сертификатов никак нельзя.
Атака типа PEAP-MSCHAPv2 прокси подробно рассмотрена в статье: SIMULATION OF MITM IN PEAP WITH HOSTAP. Автор очень точно выразил свою главную мысль, постановка задачи начинается со слов: «So if I am the very user who skips certificate verification» («Допустим, что я тот самый пользователь, который не проверяет сертификат»).
MSCHAPv2 сломан
Он сломан уже очень давно. Еще в далеком 2012 году Moxie Marlinspike запустил сервис www.cloudcracker.com (уже не работает, но есть продолжатели его дела), который предлагал взлом MSCHAPv2 и получение NT-хэша полным перебором всего за сутки.
Суть проблемы описана тут: Weaknesses in MS-CHAPv2 authentication.
Пароль хэшируется как H=MD4(Unicode(Password)) (NT-хэш). Затем этот хэш длиной 128 бит разделяется на три части: K1,K2 по 56 бит и K3 длиной 16 бит, т.е. K1|K2|K3=H. (Здесь: | — конкатенация). Ключи служат ключами DES-шифрования сообщения C, формируя ответ R=R1|R2|R3=DES(K1, C)|DES(K2, C)|DES(K3, C).
Так как хэширование пароля происходит без соли, то NT-хэш функционально эквивалентен паролю и взломщику для прохождения аутентификации достаточно восстановить хэш. Чтобы это сделать, надо найти ключи K1, K2, K3 зная сообщение С и части ответа R1, R2, R3. Ключ K3 не представляет никаких проблем, т. к. пространство перебора составляет всего
Поэтому, от длины и сложности пароля ничего не зависит. Вычислительные затраты на брутфорс в среднем являются константой, а время взлома зависит только от вычислительной мощности.
Рассмот��им обмен пакетами:
Обмен пакетами MSCHAPv2
Для вычисления хэша атакующему необходимы: Authenticator Challenge (2) — может генерироваться атакующим, User Name, Peer Challenge, Challenge Response (3) — передаются суппликантом. Атакующий не может сформировать правильный ответ (4) и корректно завершить аутентификацию, но у него уже есть достаточно информации для офлайн-взлома.
Это дает возможность атакующим просто сидеть где-нибудь далеко от атакуемой организации и ловить проходящих мимо сотрудников.
Некоторых суппликантов можно «уговорить» пропустить завершающую проверку (4) и (5). В этом случае уязвимое устройство подключится к «сети» атакующего. После подключения устройство будет думать, что оно находится в сети организации и начнет обращаться к внутренним сервисам, вроде контроллера домена. Это может дать много интересной для атакующего информации. Пример такой уязвимости: Understanding PEAP In-Depth
Сколько надо времени на взлом и сколько это стоит?
Брутфорс стоит $20 (сайт-продолжатель дела cloudcracker.com) и занимает «пару дней». Не сказать, что это совсем бесплатно, но вполне демократично и доступно каждому.
Я также решил проверить, сколько займет брутфорс на моей старенькой RTX 2080. Я сделал дамп реального сетевого обмена EAP-MSCHAPv2 с использованием длинного случайного пароля в 32 символа с энтропией 190 бит, т.е. пароль заведомо более стойкий, чем хэш. Для брутфорса хэша использовал hashcat (mode 14000). При хэшрейте ~30 GH/s время полного перебора оказалось около 27 дней, соответственно среднее время будет около двух недель. Несколько утомительно, но вполне применимо.
Эксперимент завершился успешно, хэш был восстановлен. Понадобился перебор около 60% полного пространства.
RTX 5090 имеет хэшрейт 179 GH/s, для нее среднее время брутфорса составит пару дней. (Время полного перебора в днях: days_max = 2^56 [H] / hashrate [H/sec] / 86400 [sec/day])
Из этого становится понятно, что сейчас взлом реален даже в домашних условиях.
Это не означает, что MSCHAPv2 нельзя использовать. Но необходимо относиться к его защите также, как к защите plaintext-пароля: строго соблюдать безопасность канала связи и аутентифицировать сервер.
Валидация сертификата PEAP-сервера
Основной метод валидации — стандартная проверка цепочки сертификатов. Главное отличие от обычной проверки — необходимо явно указать, к какому корневому сертификату должна сходиться цепочка (чуть ниже рассмотрим почему).
Крайне полезно обеспечить возможность подключения только к конкретному серверу или списку серверов. Суппликант может дополнительно проверить сертификат сервера и ограничить подключение по определенным условиям. Стандарт в разделе 3.2.7.1 [MS-PEAP] регламентирует проверку полей Subject Name и Subject Alternative Name.
С точки зрения протокола PEAP, FQDN сервера не несет смысловой нагрузки так как этот адрес не используется при подключении. Сервер передает суппликанту сертификат, но с какого хоста происходит передача суппликант не знает. Поэтому имя, указанное в сертификате — это просто идентификатор, достоверность которого утверждена центром сертификации. Это имя может быть достоверным, но нерелевантным.
Из этого следует, что использование публичных центров сертификации небезопасно, если нет привязки подключения к конкретному серверу. Действительный сертификат любого домена может быть признан суппликантом валидным и использоваться для проведения атаки. Подробно можно почитать в статье: Connect to these servers.
Поэтому:
Мы не можем по умолчанию доверять всему списку доверенных корневых сертификатов. Необходим явный выбор центров сертификации.
Если используются сертификаты публичных сервисов, то ограничивать подключение только к конкретным серверам — обязательное требование.
Windows проверяет только Subject Name сертификата и игнорирует Subject Alternative Name. (Этот факт в свое время попортил мне немного нервов при отладке). Проверка регистрозависима, поэтому если сертификат выдан на имя вида NPS.example.corp (что часто бывает), то только в такой форме и надо заполнять настройки подключения.
При проверке имени сертификата Windows дает возможность использовать регулярные выражения. Это может быть удобно, если есть несколько серверов. В таком случае, обязательно используйте явные маркеры начала (^) и окончания ($) строки. Допустим, ваш сервер имеет сертификат от публичного сервиса nps1.example.com, а проверяется регулярным выражением nps[0-9]\.example\.com. Атакующий может зарегистрировать домен nps1.example.com.hacker.net, который тоже пройдет валидацию по регулярному выражению, если нет явных маркеров. Правильное выражение ^nps[0-9]\.example\.com$. (Модель атаки взята из статьи, приведенной выше).
Еще одна огромная проблема — если пользователь подключается к неизвестному серверу или сервером предоставлен неизвестный сертификат, то никакой реальной возможности проверить достоверность предоставленной информации у пользователя нет, а возможность нажать кнопку «подключиться» — есть. Любая информация в предоставленном сертификате (кроме ключа) может быть подделана, а сервер может быть очень похож на настоящий. Этот метод продемонстрирован в статье Пентест WPA-Enterprise: от теории к практике.
По сути, задача валидации перекладывается на пользователя, не владеющего необходимой информацией. Кроме того, нажать кнопку подтверждения можно просто «на автомате» (бросьте в меня камень те, кто так не делал).
Необходимо отключать такое поведение везде, где это возможно.
Субъект аутентификации
При подключении WPA-Enterprise Windows умеет аутентифицировать как пользователя, так и компь��тер. При настройках по умолчанию, если мы просто нажали «подключиться» к произвольной сети, сначала идет запрос на аутентификацию компьютера, а затем, если не получилось — запрашивается пароль пользователя.
Пароль учетной записи компьютера — длинный и меняется регулярно. У атакующих будет ограниченное время для его эксплуатации (ЕМНИП по умолчанию срок действия пароля — 30 дней, а регулярность смены — две недели). Это исключает применение словарных атак на слабые пароли пользователей и вынуждает атакующих применять ресурсоемкий взлом NT-хэша.
Если аутентифицировать компьютер, а настройки распространяются при помощи GPO, то от пользователя не требуется никаких действий для подключения к сети. Принес ноутбук, включил — и все работает. Пользователи крайне положительно оценивают такое удобство.
Кроме того, компьютер получает доступ в сеть до входа пользователя, что позволяет отработать некоторым GPO. Например, установка ПО требует работы сети до входа пользователя.
ИМХО, если нет каких-то весомых причин аутентифицировать подключение именно пользователя, аутентификация компьютера — хорошая идея.
Подключение к неизвестным сетям
При подключении к новой сети WPA-Enterprise с аутентификацией PEAP-MSCHAPv2, для которой нет настроенного профиля, Windows использует настройки подключения по умолчанию: без проверки сертификата и других настроек. И главное — доменная аутентификация используется автоматически: сначала идет попытка аутентифицировать компьютер, и только после неудачи появляется запрос на ввод имени и пароля.
Еще раз: Windows автоматически сливает аутентификационные данные учетной записи компьютера неизвестной сети без никакой защиты по умолчанию! И настроек, чтобы изменить такое поведение я не нашел.
Атакующий может поднять вредоносную точку доступа в месте, где сотрудники с некоторой вероятностью могут подключаться к Wi-Fi (не корпоративной, а местной). Например, в кафе:
Wi-Fi в кафе
При подключении к сети появится предупреждение:
Подключение к новой сети
Предупреждение не релевантно угрозе, человек действительно ожидает увидеть эту сеть и хочет к ней подключиться. И как только будет нажата кнопка подтверждения, атаку можно считать успешной.
Мне не удалось найти решения этой проблемы. Можно полностью запретить подключение к неизвестным сетям. Это хорошее решение, если вы подключаете стационарные устройства в рамках офиса. Но для разъездных ноутбуков это не подходит, так как они должны работать дома или в командировках.
Можно обучить пользователей, что такое предупреждение это красный флаг и следует всегда отказывать в подключении. Но полагаться на постоянную внимательность пользователей в вопросах безопасности — плохая стратегия.
Подключение сторонних устройств
Увы, но использование доменных паролей для подключения сторонних устройств по Wi-Fi — очень плохая идея. Сошлюсь на уже упомянутые статьи:
Практически невозможно сделать так, чтобы любые сторонние устройства проходили аутентификацию правильно.
Для обеспечения безопасности мы должны контролировать каждый из параметров подключения на конечных устройствах и запретить пользователю совершать небезопасные действия вроде подтверждения неизвестных сертификатов.
Чаще всего люди просто хотят получить интернет на своем телефоне / ноутбуке. Для них можно сделать отдельную WPA2/WPA3-PSK сеть с доступом только в интернет. Так как доступа к внутренней сети нет — можно спокойно подключать всех, кто зашел в гости. Периодически пароль можно менять для профилактики.
Для тех, кто хочет со своего личного ноутбука работать в доменной сети — на ноутбуке настраивается VPN. Тогда человек может работать и дома и на работе одинаково и без создания дополнительных рисков (предполагается, что VPN уже есть и туда пускают с личных ноутбуков).
Криптографическое связывание (Cryptographic Binding)
Определено в 7.15 RFC 3748 и подробно рассматривается в RFC 7029. Эта техника направлена на предотвращение MITM-атак и позволяет криптографически доказать, что туннель (в нашем случае PEAP) и внутренний метод аутентификации (MSCHAPv2) выполняются одним и тем же субъектом. Сервер убеждается, что обе операции проводятся на суппликанте и наоборот. Атакующий посередине не может передать выполнение внутренней аутентификации другому участнику или проксировать ее в другой туннель, что ограничивает его возможности при проведении атаки.
К сожалению, связывание не заменяет проверку сертификата и не защищает от перехвата обмена MSCHAPv2. Вот обмен пакетами EAP-PEAP с выполнением связывания:
EAP-PEAP с криптографическим связыванием
Связывание выполняется после прохождения внутренней аутентификации. Поэтому, если атакующий будет действовать от имени сервера, а сертификат сервера не проверяется суппликантом, то атакующий может добраться до этапа обмена MSCHAPv2 и получить все необходимое для его взлома. Завершить подключение не получится, но этого и не требуется.
На ограниченную пользу связывания в случае MSCHAPv2 указывает также раздел 3.2.2 RFC 7029.
Цитата
Cryptographic binding is only a valuable component of a defense if the inner authentication is a key-deriving EAP method. Most tunnel methods also support non-EAP inner authentication such as Microsoft CHAP version 2 [RFC2759]. This may undermine cryptographic binding in a number of ways. An attacker may be able to convert an EAP method into a compatible non-EAP form of the same credential to suppress cryptographic binding. In addition, an inner authentication may be available through an entirely different means. For example, a Lightweight Directory Access Protocol [RFC4510] or other directory server may provide an attacker a way to get challenges and provide responses for an authentication mechanism entirely outside of the AAA/EAP context. An attacker with this capability may be able to get around server policy requiring an inner authentication be used only in a given type of tunnel.
Тем не менее, ряд работ рекомендует применение связывания даже при использовании MSCHAPv2. Оно может помочь, если сертификат сервера скомпрометирован, при проведении атак на понижение уровня защиты (downgrade-атаки), от некоторых атак непосредственно на сервер.
Пример атаки на PEAP-MSCHAPv2 с понижением и преобразованием метода аутентификации: Short paper: Exploiting WPA2-enterprise vendor implementation weaknesses through challenge response oracles. В результате, атакующий подключается к сети с использованием уязвимого устройства. Авторы указывают, что связывание предотвращает такой тип атак (но не предотвращает перехват аутентификационных данных).
Связывание не позволяет провести атаку немедленно и вынуждает атакующих проводить ресурсоемкую операцию взлома хэша. В этом смысле безопасность — это экономический баланс между средствами, которые необходимо вложить в ее обеспечение против средств на ее преодоление. Даже $20 это реальный финансовый барьер.
Связывание инициируется только сервером. Атакующий, играющий роль сервера может не включать связывание для суппликанта при проведении атаки. Поэтому правильное поведение суппликанта — обрывать подключение, если связывание не проведено. Связывание не является обязательным, поэтому его настройку на клиентских устройствах надо делать явно и только для тех сетей, где оно используется.
Аналогично должен настраиваться сервер - обрывать соединение для суппликантов, которые не прошли связывание.
Blast-RADIUS
Подробное описание: https://www.blastradius.fail/attack-details
Короткая выжимка:
Уязвимость позволяет аутентифицировать учетную запись без знания пароля.
Это уязвимость протокола RADIUS как такового, а не конкретно NPS.
Атака требует MITM между NAS и сервером аутентификации, т.е. присутствия злоумышленников во внутренней сети.
При использовании EAP-методов аутентификации эксплуатация уязвимости менее вероятна.
NPS в курсе этой уязвимости и, если не принять мер, он будет сыпать предупреждениями Event 4421. Кроме того, использование Message-Authenticator входит во все рекомендации по безопасности RADIUS. Игнорировать рекомендации не будем, для NPS делаем следующее:
KB5040268: How to manage the Access-Request packets attack vulnerability associated with CVE-2024-3596
Фрагментация пакетов
Таймаут аутентификации при подключении к Wi-Fi — признак возможных проблем с MTU.
При использовании сертификатов (а мы их будем использовать) размер EAP пакета может оказаться слишком большим, чтобы упаковаться в один Ethernet фрейм -> возникает фрагментация пакетов -> пакеты теряются -> аутентификация не работает.
EAP-пакет на пути между суппликантом и сервером инкапсулируется в разные протоколы, имеющие разные MTU. Поэтому, даже если одна сторона сформировала пакет без фрагментации, то до другой стороны пакет все равно может не дойти.
Самое неприятное — это проблема сетевая и практически не оставляет следов в логах. Все настроено как положено, но просто молча не работает, а аутентификация завершается таймаутом.
Рекомендации по MTU для NPS: Configure Network Policies
Итого — необходимо установить параметр Framed-MTU <= 1344. Может потребоваться подбор в сторону уменьшения, но при стандартном L2 MTU = 1500 я с таким не сталкивался.
Сертификаты
Вариант 1 — Самоподписанные сертификаты
Для аутентификации сервера можно использовать самоподписанные сертификаты и распространять их с помощью той же GPO, что и настройки сети.
При компрометации сертификата сервера выпускаем новый, заменяем его на NPS, меняем GPO и на этом все. Минус — чтобы обновить GPO надо подключиться к сети, а подключиться по Wi-Fi со старым сертификатом уже нельзя, надо обязательно подключиться проводом. Учитывая, что многие современные ноутбуки не имеют проводного порта — это может стать проблемой для поддержки.
Можно организовать транзитный период — сначала выпускаем и распространяем новый сертификат сервера, затем меняем его на NPS. Но при компрометации сертификата это означает, что у атакующих будет больше времени для нехороших дел. А обновление GPO обязательно произойдет не на всех компьютерах (кто в отпуске, кто ноутбук давно на работу не приносил, а кто его вообще не включал).
Вариант 2 — Мини-PKI
Если серверов несколько, или есть еще какие-то места, где сертификаты могли бы пригодиться (а такая надобность зачастую есть) можно использовать мини-PKI.
Создаем корневой сертификат, выпускаем несколько сертификатов под наши нужды. При помощи GPO распространяем корневой сертификат на все компьютеры. Теперь нашим сертификатам есть доверие по умолчанию.
Компрометация корневого сертификата несет огромные риски, но в этой схеме ключ корневого сертификата можно держать офлайн.
Без реализации системы валидации и отзыва сертификатов (AIA, CDP и CRL/OCSP), компрометация любого сертификата (не только корневого) требует полной смены такой PKI. Мы никак не сможем всем клиентам сразу сказать — больше не доверяй сертификату X, если он подписан доверенным корневым сертификатом.
Тем не менее, при компрометации одного сертификата есть аварийный план — поместить его в список недоверенных при помощи GPO. Сменить сертификат сервера мы можем сразу, без необходимости транзитного периода. Это немедленно устранит значительное количество рисков, прекратит массовую рыбалку атакующими и даст время для смены корневого сертификата и перевыпуска всех остальных.
Почему этот план аварийный и не стоит его использовать как штатный? Потому, что эта процедура не гарантирует отзыв доверия к сертификату. Компьютеры, не обновившие GPO будут уязвимы. Возможно, сертификаты устанавливались куда-то еще. При наличии системы отзыва все проверяют действительность сертификата каждый раз при его применении. А при ее отсутствии очень легко допустить, что кто-то будет доверять скомпрометированному сертификату.
Тем не менее, этот вариант видится мне хорошим компромиссом. Есть аварийный план и некоторый запас времени на смену корневого сертификата.
Также, в этой схеме можно организовать регулярную смену сертификата сервера, например, раз в год. Это существенно снижает риски компрометации.
Вариант 3 — Полноценная PKI
Описывать подробно не буду, есть замечательная серия статей на русском языке:
https://www.sysadmins.lv/blog-ru/ustanavlivaem-certification-authority-podvedenie-itogov.aspx
Если у вас есть полноценная PKI, то надо немедленно забыть про MSCHAPv2 как про страшный сон, настроить выпуск сертификатов для компьютеров и использовать EAP-TLS. Дальше эту статью можно не читать.
Разворачиваем Wi-Fi
Что будем делать:
Мини-PKI в виде: корневой сертификат + сертификат сервера
Два NPS сервера с синхронизацией конфигурации
Тип аутентификации EAP-PEAP-MSCHAPv2
Аутентификация компьютера
Распространение конфигурации и сертификатов через GPO
Настройку самих Wi-Fi точек доступа / NAS рассматривать не будем. Предполагается, что NAS уже есть, настроен на WPA2/WPA3-Enterprise и обращается к NPS-серверам по протоколу RADIUS.
Наша сеть:
Название организации: Example Corp
Домен: example.corp
NPS сервера: nps1.example.corp, nps2.example.corp
NAS: wifi.example.corp
Имя Wi-Fi сети (SSID): example-ssid
Корневой сертификат:
Имя: Example Corp Root CA 2026
Тип: Центр сертификации
Срок действия: 20 лет
Ключ: RSA 4096
Расширения:
Basic Constraints (critical): CA:TRUE
Key Usage (critical): keyCertSign, cRLSign
Subject Key Identifier (SKI)
Расширение Authority Key Identifier (AKI) для корневого сертификата необязательно.
Ключ от этого сертификата храним офлайн со сложным паролем.
Сертификат сервера:
Требования к сертификату NPS сервера: Configure Certificate Templates for PEAP and EAP requirements
Имя: Example Corp NPS
Тип: Конечный субъект
Срок действия: 1 год
Ключ: RSA 4096
Расширения:
Basic Constraints (critical): CA:FALSE
Key Usage (critical): digitalSignature, keyEncipherment
Extended Key Usage (EKU) = serverAuth
Subject Key Identifier (SKI)
Authority Key Identifier (AKI)
Мы будем синхронизировать настройки NPS серверов, поэтому один и тот же сертификат будет использован на обоих серверах. Это компромиссное решение для упрощения синхронизации.
В этом примере сертификат сервера должен меняться ежегодно.
Для совсем небольших организаций, где нет регламентированных процедур или некому следить за сетью постоянно, можно установить срок действия сертификата сервера в те же 20 лет («установил и забыл»). Это менее безопасно, но намного лучше, чем отсутствие сертификата сервера вообще.
Генерируем сертификаты:
Скрипт ниже генерирует сертификаты и экспортирует их в pfx-файлы (сертификат+ключ) с установленным паролем. Пароли сохраняются в файле example_corp_pwd.txt. Их немедленно прячем в парольный менеджер.
Корневой сертификат и его ключ example_corp_root_ca_2026.pfx прячем офлайн.
Для корневого сертификата создается также файл example_corp_root_ca_2026.cer (сертификат без ключа). Его надо импортировать на NPS сервера и распространять на компьютеры.
Сертификат и ключ сервера example_corp_nps.pfx будем импортировать на оба сервера NPS.
Минутка душноты: шаблон SSLServerAuthentication почему-то не содержит расширения Basic Constraints со значением CA:FALSE, что является де-факто стандартом. Добавлено в явном виде вручную.
# Generate root certificate
$rootParams = @{
Subject = 'Example Corp Root CA 2026'
Type = 'Custom'
KeyLength = 4096
KeyAlgorithm = 'RSA'
HashAlgorithm = 'SHA384'
KeyExportPolicy = 'Exportable'
NotAfter = (Get-Date).AddYears(20)
KeyUsage = 'CertSign', 'CRLSign'
TextExtension = @(
# Basic Constraints
'2.5.29.19={critical}{text}CA=true'
)
CertStoreLocation = 'Cert:\CurrentUser\My'
}
$rootCert = New-SelfSignedCertificate @rootParams
# Export root certificate
Add-type -AssemblyName System.Web
$password = [System.Web.Security.Membership]::GeneratePassword(32, 0)
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String $password
Write 'Root certificate password:' $password | Out-File 'example_corp_pwd.txt' -Encoding ascii
[void](Export-PfxCertificate -Cert $rootCert -FilePath 'example_corp_root_ca_2026.pfx' -Password $securePassword)
[void](Export-Certificate -Cert $rootCert -FilePath 'example_corp_root_ca_2026.cer')
# Generate server certificates
$serverParams = @{
Subject = 'Example Corp NPS'
Type = 'SSLServerAuthentication'
Signer = $rootCert
KeyLength = 4096
KeyAlgorithm = 'RSA'
HashAlgorithm = 'SHA384'
KeyExportPolicy = 'Exportable'
NotAfter = (Get-Date).AddYears(1)
TextExtension = @(
# Basic Constraints
'2.5.29.19={critical}{text}CA=false'
)
CertStoreLocation = 'Cert:\CurrentUser\My'
}
$serverCert = New-SelfSignedCertificate @serverParams
# Export server certificate
$password = [System.Web.Security.Membership]::GeneratePassword(32, 0)
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String $password
Write 'Server certificate password:' $password | Out-File 'example_corp_pwd.txt' -Encoding ascii -Append
[void](Export-PfxCertificate -Cert $serverCert -FilePath 'example_corp_nps.pfx' -Password $securePassword)
# Cleanup
Remove-Item -DeleteKey -Path Cert:\CurrentUser\My\$($rootCert.Thumbprint)
Remove-Item -DeleteKey -Path Cert:\CurrentUser\My\$($serverCert.Thumbprint)
Установка Network Policy Server
Устанавливаем роль «Сервер политики сети».
Install-WindowsFeature NPAS -IncludeManagementTools
Противодействие Blast-RADIUS (рекомендованные настройки):
netsh nps set limitproxystate all = enable
netsh nps set requiremsgauth all = enable
Регистрируем сервер в Active Directory:
netsh nps add registeredserver
Открываем порты (UDP 1812, 1813). Встроенные правила фаервола для NPS могут не работать, проблема описана тут: Windows Server 2019 — Default NPS Firewall rules (Port 1812 UDP) Not working. Поэтому создаем новое правило:
New-NetFirewallRule -DisplayName 'Allow inbound NPS/RADIUS (UDP 1812, 1813)' -Direction Inbound -Action Allow -Protocol UDP -LocalPort 1812,1813
Импорт сертификатов (предварительно копируем их на сервер). Для импорта серверного сертификата с ключом вводим пароль от файла.
Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root -FilePath 'example_corp_root_ca_2026.cer'
$pwd = Get-Credential -UserName 'Enter cert password below' -Message 'Enter cert password below'
Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\My -FilePath 'example_corp_nps.pfx' -Password $pwd.password
Настройка Network Policy Server
Во многих полях и условиях NPS позволяет использовать регулярные выражения: Use Regular Expressions in NPS.
Добавляем RADIUS-клиента (наша точка доступа / NAS):
Название клиента: wifi.example.corp
Адрес: wifi.example.corp
Включаем использование Message-Authenticator
Пароль записываем в наш парольный менеджер и копируем в настройки точки доступа / NAS.
Создаем сетевую политику:
Устанавливаем условия:
Обрабатывать запросы от клиента: wifi.example.corp. Рекомендую всегда ограничивать источник запросов. Если надо указать несколько NAS, то можно использовать регулярные выражения.
Тип порта NAS: IEEE 802.11. Один NAS может обращаться к серверу для аутентификации разных типов. Это условие явно ограничит подключение только запросами от Wi-Fi.
Разрешаем подключение только от компьютеров в группе Компьютеры домена. Можно сделать более ограниченную группу только для избранных.
Включаем PEAP-аутентификацию. Все методы, кроме PEAP обязательно убрать!
Настраиваем туннель.
Выбираем наш сертификат: Example Corp NPS
Проверяем тип внутренней аутентификации: EAP-MSCHAPv2.
Включаем криптографическое связывание: Disconnect Clients without Cryptobinding
Добавляем RADIUS-атрибут Framed-MTU=1344.
Синхронизация конфигурации
Я обычно устанавливаю два сервера. После установки и настройки мастер-сервера можно сделать экспорт конфигурации, а затем импортировать на второй. Чтобы не делать этого вручную после каждого изменения конфигурации делаем автоматическую синхронизацию.
Предполагается, что на каждом сервере есть каталог C:\NPS для файла конфигурации.
$path = 'C:\NPS\nps.xml'
$servers = @('nps2.example.corp')
Export-NpsConfiguration -Path $path
$servers | Foreach-Object {
$session = New-PSSession -ComputerName $_
Copy-Item -Path $path -ToSession $session -Destination $path
Invoke-Command -ComputerName $_ -ScriptBlock {
Import-NPSConfiguration -Path $using:path
Remove-Item -Force -Path $using:path
}
}
Remove-Item -Force -Path $path
При желании, можно дополнительно сделать архив конфигураций по датам или коммитить конфигурацию в git. Но следует иметь в виду, что файл конфигурации содержит секреты в открытом виде.
GPO
Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network (802.11) Policies
Добавляем политику для Windows Vista:
В политику добавляем нашу Wi-Fi сеть example-ssid:
Задаем параметры подключения. Включаем аутентификацию только компьютеров.
Настройки PEAP-туннеля:
Разрешаем подключение только к правильным NPS-серверам. Копируем поле Subject Name сертификата в точности, с соблюдением регистра: Example Corp NPS
Указываем корень доверия: Example Corp Root CA 2026
Отключаем пользователю возможность подтверждать серверы и сертификаты: Don’t ask user to authorize new servers or trusted CAs
Проверяем метод внутренней аутентификации: EAP-MSCHAPv2
Включаем криптографическое связывание: Disconnect if server does not present cryptobinding TLV
Если у вас несколько серверов с разными сертификатами, то в поле проверки сертификата их можно перечислить через точку с запятой (
или использовать регулярные выражения.
Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies/Trusted Root Certification Authorities
Импортировать корневой сертификат из файла example_corp_root_ca_2026.cer:
Заключение
Высокий уровень безопасности Wi-Fi это не обязательно дорого или сложно, это можно сделать даже в небольшой организации. Для этого не обязательно разворачивать полноценную PKI.
Огромный пласт рисков можно предотвратить включением проверки сертификата сервера. Эта проверка одновременно и проста и сложна. Проста в том смысле, что ее включение — не рокет-саенс. Сложность в том, что проверку сертификата легко обойти и сложно гарантировать. Ошибки конфигурации не видны, все подключается и работает, словно никаких проблем нет.
Необходим строгий контроль настроек клиентского оборудования. Мы можем обеспечить такой контроль для доменных компьютеров, но не для личных устройств сотрудников. Поэтому, следует разделять доверенные и недоверенные конечные устройства. Недоверенные устройства не должны использовать доменную аутентификацию.
