Поддержка расширенной защиты для проверки подлинности (EPA) в службе

Статья
10/18/2023

Особенность	Применимо к
EPA	все поддерживаемые ОС Windows
Режим аудита EPA	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Что такое проблема?

Существует класс атак на аутентифицированные службы, называемых атаками пересылки. Эти атаки позволяют злоумышленникам обходить проверку подлинности и выступать в качестве другого пользователя. Поскольку это атаки на службу, а не на сам протокол проверки подлинности, задача предотвращения атак с пересылками ложится на службу, прошедшую проверку подлинности.

Как работает переадресация атак?

Когда служба или приложение вызывает API AcceptSecurityContext для аутентификации клиента, оно передает данные, полученные от вызова клиента в InitializeSecurityContext. Протокол проверки подлинности отвечает за проверку того, что предоставленный blob исходит от указанного пользователя. AcceptSecurityContext не может делать никаких утверждений о подлинности оставшейся части сообщения приложения, которое он не видел.

Распространенная ошибка безопасности в приложениях заключается в том, что трафик приложения считается аутентифицированным после успешной аутентификации внутреннего блоба аутентификационного протокола. Это чаще всего происходит с приложениями, используюющими TLS для их проводного протокола. ПРОТОКОЛ TLS обычно не использует сертификаты клиента; он предоставляет серверу гарантии целостности и конфиденциальности, но не проверку подлинности. Внутренняя проверка подлинности обеспечивает проверку подлинности клиента, но только для его блока данных. Он не проходит проверку подлинности канала TLS или оставшейся части протокола приложения, содержащегося в нем.

Злоумышленник выполняет атаку пересылки, вставляя объект проверки подлинности из одного источника с запросом, созданным злоумышленником. Например, злоумышленник может наблюдать за трафиком проверки подлинности в сети и вставить его в собственный запрос к серверу. Это позволяет злоумышленнику получить доступ к серверу в качестве клиента из захваченного трафика проверки подлинности.

Основная концепция заключается в том, что сообщения проверки подлинности SSPI предназначены для предоставления в проводной сети; они не должны храниться в секрете. Это отличается от многих веб-основанных схем аутентификации, использующих токены доступа, которые всегда хранятся в конфиденциальных каналах TLS.

Что такое решение?

Предпочтительное решение — использовать ключ сеанса протокола проверки подлинности для подписи или шифрования (MakeSignature, EncryptMessage) другого трафика. Поскольку во время обмена в процессе аутентификации ключ сеанса криптографически создается, можно гарантировать, что его аутентифицированные данные и любой трафик, защищенный этим ключом, поступают от аутентифицированного клиента.

Это не всегда вариант. В некоторых случаях формат сообщения протокола приложения фиксируется стандартами, предназначенными для маркеров носителя. В этом случае расширенная защита для проверки подлинности (EPA), также известная как привязка канала, может защититься от перенаправления по каналу TLS/SSL.

Что такое EPA?

EPA криптографически привязывает ключ сеанса TLS к ключу сеанса протокола проверки подлинности, что позволяет TLS предоставлять ту же проверку подлинности клиента, что и ключ протокола проверки подлинности. Дополнительные сведения см. в разделе Обзор расширенной защиты проверки подлинности.

Привязка службы

Вторая часть EPA называется Привязка службы. В отличие от привязки канала, это не обеспечивает криптографические гарантии и служит защитой в крайнем случае, когда привязка канала невозможна. Этот механизм позволяет серверу вызывать QueryContextAttributes для получения атрибута SECPKG_ATTR_CLIENT_SPECIFIED_TARGET, который содержит имя клиента, прошедшего проверку подлинности, переданное в InitializeSecurityContext.

Например, представьте, что служба находится за балансировщиком нагрузки с завершением TLS. Он не имеет доступа к ключу сеанса TLS и может определить только из привязки канала, что проверка подлинности клиента предназначена для защищенной службы TLS. Имя, предоставленное клиентом, должно совпадать с именем, которое использовалось для проверки сертификата сервера TLS. Убедившись, что клиент прошел проверку подлинности на имя, соответствующее сертификату TLS сервера из подсистемы балансировки нагрузки, служба получает высокую уверенность в том, что проверка подлинности была получена из того же клиента, что и канал TLS.

В этой статье не рассматривается поддержка привязки службы. Дополнительные сведения см. в разделе Как указать привязку службы в конфигурации.

Как вы поддерживаете EPA?

При применении EPA службы могут заметить, что клиенты не проходят проверку подлинности из-за проблем совместимости. Поэтому мы создали режим аудита EPA, где службы могут включить аудит, предоставляя администраторам контрольные меры для наблюдения за тем, как клиенты реагируют перед применением EPA.

К службам Майкрософт, поддерживающим режим аудита, относятся:

LDAP

Заметка

Ниже приведены необязательные шаги по включению функций аудита EPA. Обратите внимание, что активизация функций аудита EPA без применения EPA не защищает от ретрансляционных атак. Мы рекомендуем службам, которые решили сначала включить EPA только в режиме аудита, позже предпринять шаги по исправлению несовместимых клиентов и в конечном итоге строго использовать EPA, чтобы избежать любых потенциальных атак ретрансляции.

Заметка

Привязки каналов, передаваемые в AcceptSecurityContext, не обязаны быть исключительно аудиторскими, чтобы получить результаты аудита. Службы могут выполнять режим аудита одновременно с применением EPA.

Клиент

Используйте QueryContextAttributes(TLS), чтобы получить привязки каналов (заполнить уникальные и конечные точки)
Вызывайте InitializeSecurityContextи передавайте привязки каналов в SECBUFFER_CHANNEL_BINDINGS

Сервер

Используйте QueryContextAttributes(TLS), как на клиенте
(Необязательно) Переводит только в режим аудита через вызов SspiSetChannelBindingFlags
(Необязательно) Добавьте буфер результатов привязки канала в выходные буферы для ASC.
Задайте уровень EPA и другие конфигурации путем вызова AcceptSecurityContext с SECBUFFER_CHANNEL_BINDINGS
(Необязательно) Используйте флаги для управления поведением в крайних случаях:
- ASC_REQ_ALLOW_MISSING_BINDINGS - Не останавливайте клиентов, которые вообще ничего не сообщили, подобно старым сторонним устройствам. Просвещенные клиенты, которые не получили SECBUFFER_CHANNEL_BINDINGS, будут отправлять пустую привязку, а не ничего.
- ASC_REQ_PROXY_BINDINGS — редкий случай для конечных подсистем балансировки нагрузки TLS. У нас нет SECBUFFER_CHANNEL_BINDINGS для передачи, но мы по-прежнему хотим убедиться, что клиенты отправляют запросы через канал TLS. Это наиболее полезно при связываниях сервисов, чтобы убедиться, что клиент также присоединяется к каналу TLS, для которого сертификат сервера соответствует нашему имени.

Как обеспечить соблюдение норм EPA?

Когда служба начинает поддерживать EPA, администраторы могут управлять состоянием EPA от аудита до полного принуждения. Это дает службам средства для оценки готовности экосистемы к EPA, исправлению несовместимых устройств и постепенному применению EPA для защиты их среды.

Следующие атрибуты и значения можно использовать для применения различных уровней EPA в вашей среде:

Имя	Описание
Никакой	Проверка привязки канала не выполняется. Это поведение всех серверов, которые не были обновлены.
Разрешать	Все клиенты, которые были обновлены, должны предоставить сведения о привязке канала к серверу. Клиенты, которые не были обновлены, не должны делать это. Это промежуточный параметр, позволяющий обеспечить совместимость приложений.
Требовать	Все клиенты должны предоставлять сведения о привязке канала. Сервер отклоняет запросы проверки подлинности от клиентов, которые этого не делают.

Эти атрибуты могут быть связаны с функциями аудита для сбора сведений о совместимости устройств на различных уровнях применения EPA. Вы должны передать желаемую конфигурацию в SspiSetChannelBindingFlags.

режима аудита — этот режим можно использовать в сочетании с любым из указанных выше уровней выполнения требований EPA.

Как интерпретировать результаты аудита EPA?

Результаты аудита — это набор битовых флагов:

Флаг	Описание
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	Клиент указал, что он может выполнять привязки каналов.
ОТСУТСТВИЕ РЕЗУЛЬТАТА СВЯЗУЮЩИХ ДАННЫХ КАНАЛА	Клиент не предоставил привязку к внешнему каналу.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH (Результат привязки канала не действителен - несовпадение)	Привязки клиента указывают другой канал, отличный от сервера.
Не удалось определить параметры привязки канала.	Сбой привязки канала из-за SEC_CHANNEL_BINDINGS_RESULT_ABSENT.
РЕЗУЛЬТАТ_СОПОСТАВЛЕНИЯ_КАНАЛА_ДЕЙСТВИТЕЛЕН_СОВПАДЕНИЕ	Каналы успешно привязаны.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	Клиент указал привязку к внешнему каналу, что произошло из-за ASC_REQ_PROXY_BINDINGS.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Привязка канала прошла благодаря ASC_REQ_ALLOW_MISSING_BINDINGS.

Существуют также определения для наборов битов:

Флаг	Описание
SEC_CHANNEL_BINDINGS_RESULT_VALID	Используется для тестирования для всех случаев SEC_CHANNEL_BINDINGS_VALID_* .
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	Используется для тестирования для всех случаев SEC_CHANNEL_BINDINGS_NOTVALID_* .

Поток аудита

Любая ОС, поддерживающая эти результаты, всегда будет устанавливать по крайней мере один бит из SEC_CHANNEL_BINDINGS_RESULT_VALID и SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

Не удалось выполнить связывание канала : проверить наличие любых битов из SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Для привязок, которые не предназначены исключительно для аудита, это соответствует сбою ASC с STATUS_BAD_BINDINGS или SEC_E_BAD_BINDINGS.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: клиент и сервер оба знают о привязках каналов, но не согласны по поводу канала. Это случай атаки или неправильная конфигурация безопасности, неотличимая от атаки, так как конфигурация скомпрометировала HTTPS для проверки трафика (например, Fiddler). Это также может быть связано с тем, что клиент и сервер не сходятся во мнении о уникальных и конечных привязках.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING разделяется на два случая:
- С SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTэто означает, что клиент подтверждает, что он знает о привязках каналов и сообщил, что канала не было. Это может быть атака пересылки из службы, отличной от TLS, но более вероятно, что это неосведомлённое приложение, работающее на клиенте, которое использует ПРОТОКОЛ TLS, но не сообщает об этом внутренней аутентификации.
- Без SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTэто клиент, который не может выполнять привязки каналов. Все поддерживаемые версии Windows способны выполнять привязку каналов, следовательно, дело в стороннем ПО или системе с установленным значением реестра SuppressExtendedProtection. Это случай, который превратился в SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING, если вы передаете ASC_REQ_ALLOW_MISSING_BINDINGS.

привязка канала выполнена успешно: это является обратной проверкой на сбой или тестом на SEC_CHANNEL_BINDINGS_RESULT_VALID.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED является успешным случаем. Система безопасности работает (или будет работать, если EPA включен в режиме только аудита).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING означает, что был передан ASC_REQ_ALLOW_MISSING_BINDINGS, поэтому мы разрешили клиенту, который не заявлял о поддержке привязки канала. Клиенты, которые попадают в этот случай, не защищены и должны быть расследованы, чтобы увидеть, что неправильно. Их необходимо обновить для поддержки привязки каналов, или значение реестра SuppressExtendedProtection должно быть снято после обновления неработающих приложений.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY — это особый случай, связанный с флагом ASC_REQ_PROXY_BINDINGS, который используется, когда завершение TLS происходит на балансировщике нагрузки вместо достижения сервера. Серверу невозможно проверить, что клиент использует то же подключение TLS, которое завершено на балансировщике нагрузки. В целях аудита это обрабатывается так же как SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.