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

В чем проблема?

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

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

Когда служба или приложение вызывает API AcceptSecurityContext для проверки подлинности клиента, он передает большой двоичный объект данных, полученный от вызова клиента InitializeSecurityContext. Протокол проверки подлинности отвечает за проверку того, что предоставленный большой двоичный объект был получен от указанного пользователя. 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

Клиент

1. Используйте QueryContextAttributes(TLS) для получения привязок каналов (заполнение уникальной и конечной точки)
2. Вызов инициализацииSecurityContext и передача привязок каналов в SECBUFFER_CHANNEL_BINDINGS

Сервер

1. Использование QueryContextAttributes(TLS) как на клиенте
2. (Необязательно) Выполняет аудит только путем вызова SspiSetChannelBindingFlags
3. (Необязательно) Добавьте буфер результатов привязки канала в выходные буферы для ASC.
4. Укажите уровень EPA и другие конфигурации, вызвав AcceptSecurityContext с SECBUFFER_CHANNEL_BINDINGS
5. (Необязательно) Используйте флаги для управления поведением в угловых случаях:
   • 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_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.

См. также

AcceptSecurityContext

InitializeSecurityContext

MakeSignature

EncryptMessage

QueryContextAttributes

Общие сведения о расширенной защите для проверки подлинности

Практическое руководство. Указание привязки службы в конфигурации