Пять критических уязвимостей Microsoft Certificate Authority, о которых вы не знали - SafeTech | SafeTech

Пять критических уязвимостей Microsoft Certificate Authority, о которых вы не знали

Уход Microsoft три года назад стал поворотным моментом для обеспечения информационной безопасности в большинстве отраслей экономики. Отсутствие поддержки и обновлений программного обеспечения от вендора создало серьезные проблемы для устойчивости коммерческих и государственных ИТ-инфраструктур.

Центр сертификации Microsoft Certificate Authority (CA) — один из ключевых сервисов вендора, который применяется для обеспечения безопасности и стабильности работы информационных систем. С его помощью выпускают, приостанавливают и отзывают сертификаты, используемые внутри компании для различных технологических нужд.

Долгое время существовала уверенность, что Microsoft CA «просто есть», успешно решая текущие задачи. Несмотря на многочисленные вопросы по поводу ограниченного функционала, удобства использования и неактуальности интерфейсов, продукт, предоставляемый бесплатно и входящий в комплект серверной ОС, оставался вне зоны критики. Но длиться бесконечно долго это не могло.

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

Поговорим об уязвимостях

Все вышеперечисленные риски использования Microsoft CA в текущих условиях вам, безусловно, хорошо известны. Но в этой статье мы хотели бы поднять гораздо более важную и не столь очевидную для многих проблему и рассказать о критичных уязвимостях центра сертификации от Microsoft, которые создают серьезные и реальные угрозы безопасности ИТ-инфраструктуры.

Накопленные годами уязвимости конфигурации сервисов AD CS (Active Directory Certificate Services), включая сервис Microsoft CA, легли в основу отчета, опубликованного компанией SpecterOps. В аналитическом документе собран внушительный набор выявленных в конфигурации сервисов AD CS уязвимостей, которые могут привести к критическим последствиям для компаний. Чтобы понять масштаб этих последствий для безопасности инфраструктуры, стоит чуть глубже разобраться с тем, что же такое сервисы AD CS и зачем они нужны.

Сервисы AD CS созданы для выдачи сертификатов инфраструктуры открытых ключей (PKI), используемых в протоколах безопасной связи и проверки подлинности. AD CS широко применяются в корпоративных сетях для управления сертификатами систем, пользователей, приложений и других компонентов. То есть некорректные настройки и уязвимости AD CS могут быть использованы для кражи учетных данных, повышения привилегий в домене и получения полного контроля над сетью компании, что, конечно, является недопустимым.

И что же с этим делать, спросите вы. Сегодня на российском рынке есть несколько отечественных центров сертификации, призванных решить накопившиеся проблемы вокруг безопасности сервисов AD CS и Microsoft CA. Одно из таких решений — SafeTech CA, разработанное SafeTech Group, технологическим лидером создания современных инструментов безопасности для обеспечения цифрового доверия в инфраструктуре и онлайн-сервисах на базе средств криптографической защиты информации.

SafeTech CA — не адаптация Open Source, а полностью российский продукт, выпущенный компанией, которая более 14 лет создает решения в области информационной безопасности. При этом сервис обладает гораздо более широким по сравнению с Microsoft СА функционалом и закрывает все уязвимости из перечня, представленного в отчете компании SpecterOps.

Уязвимости сервисов AD CS и Microsoft CA — как обезопасить себя от них

Рассмотрим некоторые из уязвимостей и разберем реализацию защиты от них на примере SafeTech CA.

1. Уязвимость «ESC1: Misconfigured Certificate Templates»

Шаблон сертификата MS CA (при соответствующей настройке) может позволять заявителю включать поле subjectAltName (SAN) в запрос на сертификат (PKCS#10). В среде Active Directory при проверке личности приоритет отдается полю SAN, если оно присутствует. Это создает угрозу, так как злоумышленник, указав SAN в CSR, может запросить сертификат для выдачи от имени любого пользователя, включая привилегированных, таких как администратор домена.

Решение в SafeTech CA: при выпуске сертификата в SafeTech CA игнорируется значение расширения SAN, указанное в запросе. Значения для SAN вычисляются на базе значений атрибутов пользователя или компьютера, полученных из LDAP-каталога согласно настройке шаблона. Таким образом, уязвимость отсутствует «by design».

2. Уязвимость «ESC2: Misconfigured Certificate Templates»

Уязвимость «eSC2: Misconfigured Certificate Templates» вытекает из ESC1, только для шаблонов с EKU «Any Purpose» или без EKU (Extended Key Usage – это расширение сертификата, которое указывает одну или несколько целей, для которых действителен сертифицированный открытый ключ). Шаблон сертификата MS CA может включать в себя EKU «Any Purpose» или не включать EKU вовсе. EKU «Any Purpose» позволяет злоумышленнику получить сертификат для любых целей, включая аутентификацию клиента, аутентификацию сервера, подпись кода и т.д. Сертификаты без EKU, которые действуют как сертификаты подчиненного центра сертификации, могут быть использованы для любых целей и применяться для подписания новых сертификатов. Злоумышленник может подставить нужные ему значения SAN в CSR и запросить сертификат.

Решение в SafeTech CA: при выпуске сертификата в SafeTech CA игнорируется значение расширения SAN, указанное в запросе. Значения для SAN вычисляются на базе значений атрибутов пользователя или компьютера, полученных из LDAP-каталога согласно настройке шаблона.

3. Уязвимость «ESC3: Misconfigured Enrollment Agent Templates»

В AD CS существует понятие «агент регистрации» (как отдельный EKU с OID = 1.3.6.1.4.1.311.20.2.1), он позволяет субъекту запрашивать сертификат от имени другого пользователя. Обычно в центре сертификации установлены разрешения на становление агентом регистрации (по группам, по шаблонам и т.д.), однако доменная политика по умолчанию их не ограничивает («Не ограничивать агентов регистрации»). Это приводит к тому, что любой пользователь может выпустить сертификат на любого другого субъекта домена по любому шаблону.

Решение в SafeTech CA: не применимо для SafeTech CA, так как схема выпуска сертификатов с агентом регистрации не поддерживается.

4. Уязвимость «ESC8: NTLM Relay to AD CS HTTP Endpoints»

Enrollment-сервисы MS CA (CEP, CES, NDES) поддерживают возможность аутентификации как через Kerberos, так и через NTLM (по умолчанию поддерживают аутентификацию Negotiate через заголовок HTTP Authorization). В случае использования протокола HTTP для доступа к Enrollment-сервисам, они подвержены атаке с NTLM-ретрансляцией. Таким образом, злоумышленник, скомпрометировав чужой NTLM-хэш, может получить доступ к выпуску сертификатов от имени жертвы.

Решение в SafeTech CA: в SafeTech CA аутентификация Negotiate через заголовок HTTP Authorization возможна только по Kerberos-тикету, NTLM не поддерживается. В SafeTech CA сервисы CEP и CES поддерживают работу только по HTTPS.

5. Уязвимость «DPERSIST1: Forging Certificates with Stolen CA Certificates»

Cертификат центра сертификации AD CS зачастую хранится на сервере CA и доступен для извлечения с закрытым ключом даже через GUI-оснастку MMC, так как не имеет дополнительных паролей или ПИН-кодов, закрывающих к нему доступ. Если злоумышленник получает сертификат и ключ центра сертификации, то он может самостоятельно выпустить поддельные сертификаты на других пользователей и воспользоваться ими (например, выпустить сертификат доменного администратора). Такие сертификаты будут приняты инфраструктурой как действительные.

Решение в SafeTech CA: SafeTech CA обеспечивает поддержку хранения ключей ЦС на внешних HSM. При работе без поддержки HSM рекомендуется использование Linux, где нет понятия «реестр ОС». В этом случае доступ к ключам регламентируется ядром операционной системы через разрешения файлов.

Вместо выводов

Мы рассмотрели далеко не полный перечень уязвимостей, с которыми сталкиваются ИТ- и ИБ-специалисты, обслуживающие Microsoft-инфраструктуру и сервисы AD CS, включая Microsoft CA. Поэтому задача повышения уровня информационной безопасности при использовании данных сервисов весьма нетривиальна и достаточно трудоемка. Да и зачастую закрыть эти и другие подобные уязвимости могут только специалисты, обладающие соответствующими компетенциями, а на рынке труда нынче большой дефицит высококвалифицированных кадров. Именно поэтому в текущих реалиях существенно проще и дешевле решить данную задачу перейдя на отечественное решение, которое изначально проектировалось и разрабатывалось исходя из понимания существующих уязвимостей сервисов Microsoft.

Кроме того, российские разработчики учли все «боли» использования Microsoft CA, а также пожелания заказчиков в части функциональности и юзабилити сервиса и предлагают рынку по-настоящему удобные и надежные решения для управления технологическими сертификатами. А бесшовный переход позволяет быстро и без потерь заменить зарубежное решение на безопасный, надежный и соответствующий всем требованиям законодательства отечественный продукт.

Автор: Александр Санин, генеральный директор SafeTech Lab (SafeTech Group)

Источник: https://www.itsec.ru/articles/5-kriticheskih-uyazvimostej-microsoft-certificate-authority