AD CS. Архитектура и уязвимости
Информация в этой главе критически важная. Ее цель — заложить фундаментальное понимание архитектуры и работы Active Directory Certificate Services (AD CS), без которого анализ техник атак ESC невозможен. Мы разберем, как устроена инфраструктура сертификации в домене, из каких компонентов она состоит, какие параметры определяют поведение шаблонов сертификатов и почему одна галочка в настройках может стоить вам всей инфраструктуры.
Да, здесь не будет чего-то захватывающего вроде взлома за 30 секунд. Но без этой главы вы не поймете, почему в ESC1 можно стать администратором домена, просто указав чужой UPN в запросе, и почему один-единственный EKU открывает путь к Kerberos.
Active Directory Certificate Services (AD CS) — это серверная роль Microsoft, реализующая инфраструктуру открытых ключей (public key infrastructure, PKI) в среде Active Directory. В последнее время AD CS стала популярной целью атак злоумышленников из-за сочетания ошибок конфигурации, позволяющих ее компрометировать, и критической важности этой службы для доменной инфраструктуры.
AD CS позволяет развернуть внутренний удостоверяющий центр в сети Active Directory: создать центр сертификации (certificate authority, CA) для выдачи цифровых сертификатов пользователям и системам домена. Такие сертификаты представляют собой электронные документы, связывающие идентичность объекта (пользователя или компьютера) с криптографическим ключом, и используются для различных целей: аутентификации (например, вход по смарт-карте), подписи кода, шифрования данных и др.
AD CS тесно интегрируется с Active Directory: для Enterprise CA (в отличие от автономного) все шаблоны сертификатов хранятся в AD, а сами центры сертификации и их корневые сертификаты публикуются в каталоге Active Directory, чтобы пользователи и устройства домена могли им автоматически доверять.
Сертификаты, выпускаемые через AD CS, позволяют реализовать аутентификацию в домене на основе сертификатов. Например, при наличии у пользователя сертификата с соответствующими атрибутами домен может принять его вместо пароля для входа. По нашему опыту, AD CS широко внедряется в корпоративных сетях, поэтому ошибки в ее настройке имеют огромные последствия для безопасности. Исследователи выявили больше десятка различных векторов атак, связанных с уязвимостью AD CS (их обозначают ESC1 — ESC16), позволяющих злоумышленнику повышать привилегии вплоть до компрометации всего домена. Чтобы понять, как совершаются атаки и как от них защититься, необходимо разобраться в основах работы AD CS: ее архитектуре, шаблонах сертификатов и ключевых параметрах безопасности.
Архитектура инфраструктуры сертификации на базе AD CS обычно имеет иерархическое устройство и включает несколько ключевых компонентов.
- Корневой центр сертификации (Root CA). Наивысший доверенный удостоверяющий центр, корень цепочки доверия. Как правило, корневой CA держат офлайн для безопасности, так как он подписывает сертификаты всех подчиненных CA. Компрометация корневого CA фатальна для всей PKI. Например, кража приватного ключа Root CA требует полной перестройки системы и аннулирования всех выданных сертификатов.
- Подчиненный центр сертификации (Subordinate CA). Рабочий (издающий) удостоверяющий центр, которому доверяет Root CA. В развертывании Active Directory обычно используется Enterprise Subordinate CA, он подключен к домену и публикует шаблоны сертификатов для выдачи. Подчиненный CA непосредственно принимает запросы и выпускает сертификаты для пользователей, компьютеров и сервисов домена. Доверие к подчиненному CA определяется цепочкой сертификации: его собственный сертификат выпущен корневым CA, который в свою очередь распространяется всем клиентам домена (через AD) в доверенное хранилище. Компрометация подчиненного CA также критична: злоумышленник сможет выпускать любые сертификаты от имени доверенного CA, практически получая те же привилегии, что и при компрометации домена.
- Службы регистрации (enrollment services). Компоненты AD CS, обеспечивающие взаимодействие между клиентами и CA. В Active Directory существует контейнер enrollment services, где публикуются объекты Enterprise CA, — это позволяет клиентам автоматически обнаруживать действующие центры сертификации в лесу при необходимости запроса сертификата. Кроме того, AD CS может предоставлять веб-сервисы для регистрации сертификатов, например веб-интерфейс Web Enrollment или служба регистрации устройств NDES (Network Device Enrollment Service). Эти сервисы слушают запросы по HTTP(S) и позволяют в том числе выполнять кросс-доменную или удаленную регистрацию сертификатов.
- NTAuthCertificates. Объект в конфигурационном разделе Active Directory, содержащий сертификаты корневых и подчиненных CA, которым доверяют контроллеры домена для аутентификации пользователей по сертификатам. При входе с использованием смарт-карты или сертификата контроллер домена проверяет, присутствует ли издатель сертификата в этом хранилище: если нет — вход будет отклонен. При установке Enterprise CA его сертификат автоматически добавляется в NTAuthCertificates, что делает все выданные им аутентификационные сертификаты доверенными в домене. Злоумышленник, получивший возможность добавить вредоносный CA, может выпустить поддельные, но полностью доверенные сертификаты для входа.
- Список отозванных сертификатов (certificate revocation list, CRL). Каждый CA периодически публикует CRL, содержащий серийные номера сертификатов, признанных недействительными до окончания срока действия. Клиенты при проверке подлинности сертификата должны скачать актуальный CRL, чтобы убедиться, что сертификат не отозван. CRL обычно публикуется в каталоге (для Enterprise CA) или по HTTP-/файловому пути, указанному в расширении CDP (CRL distribution point) сертификата.
- Служба оперативной проверки статуса сертификата (online certificate status protocol, OCSP). AD CS позволяет развернуть OCSP rеsponder, который отвечает на запросы о статусе конкретного сертификата («действителен» или «отозван») в реальном времени без необходимости загрузки всего CRL. OCSP дополняет CRL и ускоряет процесс проверки статуса сертификатов в крупных инфраструктурах.
Рассмотрим схему архитектуры AD CS и ответим на несколько вопросов, которые могут возникнуть.
1. Почему инфраструктуру PKI обычно разделяют на корневой CA и подчиненные CA? Почему нельзя использовать только один CA?
Разделение на корневой и подчиненные центры сертификации — это стандартная практика повышения безопасности. Root CA изолируется и используется редко, только для подписи сертификатов Subordinate CA. Подчиненные CA выполняют все повседневные задачи по выпуску сертификатов, принимая на себя основные риски компрометации. Таким образом, если злоумышленник получит доступ к Subordinate CA, инфраструктуру можно восстановить, выпустив новый подчиненный CA, не затрагивая доверие к корневому CA и не переиздавая все сертификаты.
2. В чем опасность компрометации подчиненного центра сертификации?
Подчиненный CA напрямую выпускает конечные сертификаты, которыми пользователи и машины аутентифицируются в домене. Если злоумышленник получит доступ к приватному ключу Subordinate CA, он сможет создавать поддельные сертификаты для любых учетных записей, в том числе для администраторов домена. Такие сертификаты технически будут валидны и позволят злоумышленнику незаметно захватить контроль над инфраструктурой.
3. Что делать, если скомпрометирован приватный ключ Root CA или Subordinate CA?
Компрометация Root CA требует полной перестройки инфраструктуры, перевыпуска всех подчиненных сертификатов и обновления доверенных сертификатов на всех клиентах. Компрометация Subordinate CA требует отозвать сертификат скомпрометированного CA и выпустить новый подчиненный CA, но при этом не требует заменить сертификат корневого CA, если он не был скомпрометирован.
4. Как и какие именно данные публикует CA в AD?
Вот что Enterprise CA публикует в AD:
- собственный сертификат и информацию о своем местоположении (объект enrollment services);
- шаблоны сертификатов (certificate templates), по которым клиенты могут запрашивать сертификаты;
- свой сертификат в хранилище NTAuthCertificates, если он используется для аутентификации пользователей;
- ссылки на списки отзыва (CRL) и службу проверки статуса сертификатов (OCSP).
Это позволяет клиентам автоматически находить CA, доверять ему и проверять статус сертификатов без ручной настройки.
5. Как контроллер домена проверяет, доверять ли сертификату при аутентификации?
Контроллер домена при аутентификации с сертификатом проверяет три условия:
- корректна ли цепочка сертификатов, завершается ли она доверенным корневым CA;
- присутствует ли сертификат издающего CA в специальном хранилище NTAuthCertificates;
- не был ли сертификат отозван (проверка через CRL или OCSP).
Несоблюдение любого из условий означает, что сертификат будет отвергнут.
6. Почему используются сразу два механизма проверки статуса сертификатов: CRL и OCSP?
Список отзыва сертификатов — это тяжелый файл со всеми отозванными сертификатами, который клиенты должны регулярно скачивать. В больших инфраструктурах это неудобно и неэффективно. Поэтому используется OCSP, который позволяет в реальном времени запрашивать статус конкретного сертификата («действителен» или «отозван») без необходимости скачивать целый CRL. OCSP ускоряет проверку и снижает нагрузку на сеть.
7. Что такое службы регистрации (enrollment services) и почему они требуют особой защиты?
Enrollment services — это службы, которые принимают запросы на выпуск сертификатов от клиентов и передают их в CA. Это может быть как локальный интерфейс (RPC/DCOM), так и удаленные веб-службы (например, Web Enrollment, NDES). Эти службы часто становятся целью атак, например атак типа NTLM relay (техника ESC8), если неправильно настроены (отсутствует extended protection, не используется HTTPS и т. д.). Поэтому такие службы требуют дополнительной защиты и строгой конфигурации.
Ниже описаны все ключевые вкладки и параметры конфигурации центра сертификации в интерфейсе Certification Authority. В контексте техник ESC эти параметры напрямую влияют на возможность эксплуатации шаблонов, обхода проверок и захвата инфраструктуры.
Отображает имя центра сертификации, установленные CA-сертификаты, криптопровайдер и используемый хеш-алгоритм.
Определяет поведение центра сертификации при получении нового запроса на сертификат. В частности, он отвечает за то, нужно ли отправлять запрос в ожидание (статус Pending) или выпускать сертификат автоматически, в зависимости от конфигурации.
Доступны два режима:
-
Set the certificate request status to pending. The administrator must explicitly issue the certificate. Все запросы автоматически получают статус Pending. Администратор должен вручную одобрить каждый запрос через консоль CA.
Этот режим безопасен, предотвращает автоматическую выдачу сертификатов. Но может нарушить автоматизацию, если применяется ко всем шаблонам. -
Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. Выбран по умолчанию. CA проверяет настройки шаблона: если в шаблоне установлен флаг Certificate manager approval required, запрос будет ожидать утверждения.
Если в шаблоне не установлено требование ручного одобрения, CA выпустит сертификат автоматически без участия администратора. При слабой настройке шаблонов и открытом доступе к ним это создает условия для атак ESC: злоумышленник получает сертификат сразу после запроса.
Срабатывает после выпуска сертификата. Обычно этот механизм не используется и редко бывает активным, но, если настроен, может содержать пользовательскую логику, например отправку копии сертификата или экспорт в стороннюю систему.
Если exit module неактивен, риск низкий. Однако при использовании отличных, нестандартных модулей необходим аудит их логики, чтобы исключить утечку сертификатов или несанкционированный экспорт данных.
Управляет правами доступа к центру сертификации. Каждый пользователь или группа может иметь следующие разрешения:
- Read. Право просмотра конфигурации CA и шаблонов. Злоумышленник может использовать его на этапе разведки, например, с помощью Certify или BloodHound для анализа доступных шаблонов и прав.
- Request Certificates. Разрешает отправку запросов на выпуск сертификатов. Это базовое право для пользователей, но в сочетании с уязвимыми шаблонами (включен Supply in the request, EKU = Client Authentication, открытый Enroll) дает возможность получить сертификат с чужим UPN — основа для атак ESC1 и ESC6.
- Issue and Manage Certificates. Позволяет утверждать или отклонять сертификаты, находящиеся в статусе Pending, а также отзывать ранее выданные. Это право критично, если есть шаблоны с флагом Pend all requests. В технике ESC3 это право позволяет злоумышленнику самостоятельно одобрить запросы, отправленные от имени других пользователей.
- Manage CA. Полное администрирование CA: управление шаблонами, публикацией, политиками, конфигурацией модулей и флагами в реестре. Обладание этим правом дает возможность, например, включить
EDITF_ATTRIBUTESUBJECTALTNAME2и тем самым превратить даже безопасный шаблон в уязвимый. Это основной вектор при атаке ESC7, он позволяет злоумышленнику добиться полного контроля над выдачей сертификатов.
Все критичные права должны быть строго ограничены администраторами PKI через выделенные группы. Компрометация пользователя с правами Manage CA или Issue and Manage Certificates — это фактическая компрометация всей инфраструктуры AD CS.
Позволяет ограничить, кто может утверждать запросы на сертификаты, находящиеся в статусе Pending. Если активен флаг Restrict certificate managers, можно указать, какие пользователи или группы могут утверждать запросы только по определенным шаблонам. Это позволяет делегировать управление выпуском сертификатов, не давая полных прав на весь CA.
По умолчанию включен флаг Do not restrict certificate managers: то есть любой пользователь с правом Issue and Manage Certificates может утверждать любой pending-запрос, вне зависимости от шаблона. Это особенно опасно, если в инфраструктуре есть шаблоны с флагом Pend all requests (см. описание Policy Module выше).
В таком случае становится возможной атака ESC3: злоумышленник с правом утверждения может сам подписывать себе сертификаты, запрошенные от имени жертв.
Главное отличие этого раздела от вкладки Policy Module — в том, что последняя отвечает за то, нужна ли ручная выдача сертификата по умолчанию (через флаг Pend all requests), а Certificate Managers — кто именно имеет право подтверждать такие запросы.
Без ограничения менеджеров сертификатов любое утверждение запросов централизовано, а злоумышленник с правами Issue and Manage Certificates получает контроль над выпуском критичных сертификатов.
Определяет, кто может восстанавливать приватные ключи пользователей, если этот параметр настроен. Наличие агентов восстановления с правом дешифровать ключи существенно повышает риск компрометации. Если злоумышленник получит такой сертификат, он может расшифровывать любые пользовательские данные (техника ESC12).
Отвечает за включение аудита ключевых действий центра сертификации.
Все выбранные события при соответствующей настройке групповой политики (Audit object access) будут фиксироваться в журнале безопасности Windows, что критично для обнаружения, расследования и реагирования на атаки на AD CS.
Для аудита доступны следующие события:
- Back up and restore the CA database. Операции резервного копирования и восстановления базы данных CA. Их аудит важен для отслеживания подозрительных действий с целью скрыть следы или подготовить компрометацию.
- Change CA configuration. Любые изменения в конфигурации центра (шаблоны, политики, расширения). Это позволяет зафиксировать попытки включения опасных параметров, как
EDITF_ATTRIBUTESUBJECTALTNAME2(используется в ESC6). - Change CA security settings. Изменения ACL, прав доступа. Полезно для выявления атак типа ESC7, где злоумышленник назначает себе права Manage CA или Issue and Manage Certificates.
- Issue and manage certificate requests. Ключевое событие: выдача, отзыв, утверждение pending-запросов. Это один из важнейших индикаторов атак ESC1, ESC2, ESC3.
- Revoke certificates and publish CRLs. Отзыв сертификатов и публикация CRL. Позволяет фиксировать попытки скрыть сертификаты, полученные злоумышленником.
- Store and retrieve archived keys. Действия с архивированными ключами (восстановление, расшифровка). Важно при расследовании атак на зашифрованные данные.
- Start and stop Active Directory Certificate Services. Запуск и остановка службы CA. Злоумышленник может использовать это, чтобы применять настройки или скрывать следы.
При отключенном аудите критические события останутся незамеченными. Это лишает возможности провести расследование и исключает обратную трассировку действий злоумышленника.
Аудит рекомендуется включать на всех CA, особенно в средах с уязвимыми или массово используемыми шаблонами.
Отвечает за пути хранения базы данных центра сертификации и журнала запросов. Эти файлы содержат критически важную информацию: все выпущенные сертификаты, связанные запросы, статусы (в том числе Pending, Failed) и метаданные.
Во вкладке есть следующие поля:
- Certificate database. Это путь к основной базе данных CA (по умолчанию:
C:\Windows\System32\CertLog), где хранятся все выданные сертификаты и информация о них. Без доступа к этой базе невозможен аудит инцидентов, в том числе анализ атак ESC1 — ESC3, например поиск сертификатов с подмененным SAN. - Request log. Журнал всех поступивших запросов, включая отклоненные и ожидающие. Полезен для анализа попыток эксплуатации шаблонов, особенно с флагами Supply in the request или Pend all requests.
- Active Directory. Флаг всегда отмечен. Указывает, что CA публикует свою конфигурацию и корневой сертификат в AD, включая контейнер Enrollment Services, объект NTAuthCertificates и опубликованные шаблоны.
Без сохранения базы и логов расследование атак ESC становится невозможным. Кроме того, если шаблон отключает запись в базу данных CA (опция на вкладке Server шаблона), информация о сертификате может не попасть в эти файлы. Злоумышленники используют это для скрытной выдачи сертификатов (тихая техника ESC1).
Управляет делегированием прав на подачу запросов от имени других пользователей. Используется при выпуске сертификатов по шаблонам с EKU Certificate Request Agent, которые позволяют агенту регистрации выпускать сертификаты не для себя, а для других субъектов.
Во вкладке есть следующие параметры:
- Do not restrict enrollment agents. Любой пользователь с агентским сертификатом может подавать запросы от имени других. Это крайне опасная конфигурация, часто используется в атаке ESC3.
- Restrict enrollment agents. Разрешает использовать агентский сертификат только заданным пользователям или группам.
Ниже можно указать:
- Enrollment agents — кто может выступать агентом.
- Certificate Templates — для каких шаблонов разрешено выступать агентом.
- Permissions — какие права есть у пользователей или групп (Allow/Deny).
На скриншоте видно, что Everyone разрешен в роли агента для всех шаблонов, что делает инфраструктуру уязвимой: злоумышленник, получивший агентский сертификат, сможет запросить сертификат на любого пользователя, включая администраторов.
Это классическая предпосылка к атаке ESC3. Рекомендуется всегда включать Restrict enrollment agents и указывать строго ограниченные группы, которым действительно нужна эта функциональность
Содержит сведения о расширениях CA:
- CRL Distribution Points (CDP),
- Authority Information Access (AIA),
- OCSP и др.
Как упоминалось, шаблоны сертификатов (certificate templates) — это объекты Active Directory, определяющие политику выдачи и параметры сертификатов в Enterprise CA.
В шаблоне настраиваются свойства выпускаемого сертификата: кто может запросить сертификат по этому шаблону, как формируется имя субъекта, какие расширения и ограничения будут включены, срок действия, алгоритмы криптографии и многое другое.
Шаблоны позволяют централизованно задавать типы сертификатов для различных нужд, например для аутентификации пользователей, для серверов, для удостоверяющих агентов. Enterprise CA при получении запроса всегда ссылается на шаблон: либо клиент указывает имя шаблона в запросе, либо (в случае авторегистрации) шаблон определяется политикой. Неверная настройка шаблонов — основная причина атак по техникам ESC, использующих уязвимости AD CS.
Ниже представлены все разделы шаблона сертификата и их роль в безопасности.
Определяет, как формируется имя субъекта сертификата.
Возможны два режима:
- Build from this Active Directory information. Имя генерируется автоматически на основе данных из AD.
- Supply in the request. Заявитель вручную указывает имя в запросе.
Режим Supply in the request особенно опасен при открытом доступе к шаблону, так как позволяет заявителю указать произвольный UPN или имя субъекта, что используется в атаках ESC1 и ESC6.
Основные параметры: имя шаблона, период действия сертификата и период обновления.
Для критичных шаблонов рекомендуется устанавливать ограниченный срок действия, чтобы при компрометации злоумышленник не смог удерживать доступ длительное время.
Определяет совместимость с клиентами и CA: версии шаблона и операционной системы. Чем ниже выбранная версия шаблона (например, V1), тем меньше механизмов защиты доступно: нет возможности настроить SAN или дополнительные ограничения. Это делает их уязвимыми по умолчанию (техника ESC15).
Настройки обработки запроса сертификата, включая генерацию и хранение ключей. Параметр позволяет установить требование использовать приватный ключ только на аппаратных устройствах (смарт-карты). Без требований по использованию аппаратных модулей (например, TPM или HSM) ключи можно экспортировать и повторно использовать — это упрощает реализацию техник, таких как ESC12.
Выбор криптографических алгоритмов (RSA, ECC), длина ключа, тип CSP (Crypto Service Provider). Короткие ключи (1024 бит и менее) повышают риск компрометации сертификатов перебором. Рекомендуется использовать ключи минимум 2048 бит. Также важно использовать безопасные алгоритмы и современные CSP для предотвращения атак на криптографию (техника ESC12).
Настройка аттестации ключей для проверки, что приватный ключ действительно создан на аппаратном устройстве (TPM). Аттестация ключей позволяет предотвратить запрос сертификатов на украденные или виртуальные ключи, усложняя атаки ESC. Отсутствие этого механизма позволяет злоумышленникам легче создавать фальшивые сертификаты на украденные ключи.
Указывает шаблоны сертификатов, которые заменяет этот шаблон (делает их устаревшими). Важно убедиться, что после замены старый шаблон отзывается и удаляется из публикации в AD. Иначе злоумышленник может использовать старые, более уязвимые шаблоны для таких атак, как ESC1 и ESC2.
Расширенное назначение ключа (EKU) — набор OID, указывающих допустимые области применения сертификата, например OID 1.3.6.1.5.5.7.3.2 — Client Authentication (клиентская аутентификация), 1.3.6.1.5.5.7.3.3 — Code Signing (подписание кода).
EKU, заданные в шаблоне (атрибут pKIExtendedKeyUsage), определяют, для чего может использоваться выданный сертификат. С точки зрения атак особо опасны шаблоны, у которых EKU содержит Client Authentication или Smartcard Logon: такие сертификаты могут использоваться для входа в домен.
Наиболее рискованный вариант — EKU Any Purpose (OID 2.5.29.37.0) или полное отсутствие EKU. В этом случае выданный сертификат может использоваться для любых целей, включая аутентификацию в домене. Помимо аутентификационных, существует особый EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1): если шаблон содержит этот EKU, получивший сертификат субъект становится агентом регистрации и может запрашивать сертификаты от имени других пользователей. Выдача такого агентского сертификата злоумышленнику дает ему возможность выпускать сертификаты от имени жертв (вектор ESC3).
ACL (access control list) — разрешения доступа к шаблону: Read, Write, Enroll, AutoEnroll. Неправильно настроенные ACL, например разрешение Enroll для группы Domain Users, — одна из самых распространенных ошибок, ведущих к эскалации прав. Права Write позволяют злоумышленнику изменить настройки шаблона, что ведет к прямой эскалации (техника ESC4).
Определяет специфичные настройки, связанные с хранением сертификатов и проверкой их отзыва:
- Do not store certificates and requests in the CA database. Если включено, сервер CA не хранит информацию о выпущенных сертификатах и их запросах в своей базе данных. Это делает невозможным последующий аудит: выданный сертификат не попадет в логи, что позволяет злоумышленнику действовать скрытно (пример: тихая техника ESC1).
- Do not include revocation information in issued certificates. Если включено, сертификаты не будут содержать ссылки на списки отзыва (CRL Distribution Points). В таком случае клиенты не смогут проверять актуальный статус сертификатов. Это приводит к невозможности своевременного отзыва скомпрометированных сертификатов, значительно повышая риск успешных атак (техники ESC1, ESC6, ESC8).
Оба параметра должны быть выключены для критичных шаблонов, используемых для аутентификации и привилегированных операций.
Требования к выдаче сертификата:
- CA certificate manager approval. Требует ручного одобрения запроса.
- Require authorized signatures. Требует подписи агентом регистрации (Enrollment Agent).
Если не заданы требования к одобрению запроса или подписи агентом, злоумышленник сможет получить сертификат сразу после отправки запроса без каких-либо дополнительных проверок. Включение этих требований существенно усиливает защиту шаблонов.
Шаблоны сертификатов в инфраструктуре AD CS — это не просто конфигурационные объекты, а основа логики выдачи сертификатов. Любые ошибки в их создании, правах или публикации приводят к уязвимостям, описанным в атаках ESC. Ниже приведен пошаговый процесс, как создается и публикуется шаблон сертификата в Active Directory и CA.
Все шаблоны хранятся в каталоге Active Directory в контейнере:
CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=...
Создание шаблона происходит через оснастку Certificate Templates Console (certtmpl.msc):
- Кликните правой кнопкой мыши и выберите Duplicate Template.
- Настройте параметры:
- Имя шаблона.
- Версия шаблона (v2/v3 — обязательно, если нужны расширенные настройки безопасности).
- Вкладки: Subject Name, Request Handling, Extensions, Security и т. д.
- Назначьте права Enroll/AutoEnroll.
- Проверьте, отключен ли опасный флаг Supply in the request (если не требуется).
- Нажмите Apply и сохраните шаблон.
На этом этапе шаблон еще не опубликован — его нельзя использовать до добавления на сервер конкретного CA.
Публикация выполняется через оснастку Certification Authority (certsrv.msc) на сервере подчиненного CA:
Каждая из папок в консоли certsrv.msc отображает различные аспекты работы AD CS и управления службой: от обработки заявок до управления шаблонами и отозванными сертификатами. Вот что они означают:
- Revoked Certificates. Список всех отозванных сертификатов, включая дату отзыва, причину и серийный номер. Используется при генерации CRL. Позволяет аннулировать выданные ранее сертификаты, в том числе скомпрометированные.
- Issued Certificates. Журнал всех успешно выданных сертификатов. Показывает, кому, когда, по какому шаблону, с каким серийным номером и сроком действия выдавался сертификат. Ключевой источник при анализе атак ESC1, ESC3 и др.
- Pending Requests. Запросы, ожидающие утверждения вручную (если шаблон использует флаг Pend all requests). Если у злоумышленника есть право Issue and Manage Certificates, он может сам утвердить их, как в ESC3.
- Failed Requests. Запросы, отклоненные CA автоматически или вручную. Полезно при отладке или при выявлении попыток атак, например, с подменой Subject/SAN.
- Certificate Templates. Список шаблонов, опубликованных на сервере конкретного CA. Только эти шаблоны можно использовать для запроса сертификатов на этом сервере. Если шаблон не опубликован здесь, он не применяется, даже если существует в AD.
Чтобы опубликовать созданный шаблон:
- Перейдите на узел Certificate Templates.
- Кликните правой кнопкой мыши и выберите New, а затем — Certificate Template to Issue.
- Выберите ранее созданный шаблон.
После этого CA:
- начинает принимать запросы по данному шаблону,
- публикует шаблон в Active Directory (через объект CA в Enrollment Services),
- учитывает его при авторегистрации пользователей или машин.
Хотя шаблон и существует в AD, без публикации в CA он будет недоступен ни через авторегистрацию, ни для ручного запроса.
Клиенты (пользователи или компьютеры) могут обнаруживать опубликованные шаблоны через Group Policy, интерфейс запроса сертификатов в MMC или утилиты, например certutil -template:
Когда настроен AutoEnroll, шаблон автоматически применится для нужных пользователей, если:
- CA опубликован в AD,
- у субъекта есть право AutoEnroll на шаблон,
- политика в GPO активирует автоматическую регистрацию.
Рассмотрим схематически этапы выдачи сертификата в AD CS: от отправки запроса до получения готового сертификата.
- Формирование запроса. Учетная запись (пользователь или компьютер) генерирует пару криптографических ключей: открытый и закрытый. На основе открытого ключа готовится CSR (Certificate Signing Request) — запрос на выдачу сертификата, содержащий открытый ключ, запрашиваемое имя субъекта (Subject) и указание на шаблон сертификата, по которому требуется выпуск. При необходимости в запрос также включаются дополнительные атрибуты, такие как SAN.
- Передача CSR на сервер CA. Сформированный CSR отправляется на сервер центра сертификации (Enterprise CA). В среде AD это обычно происходит по протоколу RPC/DCOM, например через утилиту certreq или механизм авторегистрации. Если есть веб-сервис, его использование тоже возможно.
- Проверка прав и требований. Сервис CA принимает запрос и проверяет, имеет ли запрашивающий право получить сертификат по указанному шаблону. Для этого CA считывает из Active Directory объект шаблона сертификата, указанного в CSR, и проверяет его ACL: например, входит ли учетная запись заявителя в список тех, у кого есть разрешение Enroll по этому шаблону. Также проверяются настроенные требования выдачи: нужно ли менеджерское одобрение (флаг Pend all requests) или подпись агента (атрибут
msPKI-RA-Signature > 0) и предоставлены ли они. Если какие-либо условия не выполнены, запрос отклоняется или помещается в ожидание (Pending) до выполнения условий. - Выпуск (подписание) сертификата. Если запрос удовлетворяет всем требованиям, CA выпускает сертификат на основе настроек шаблона. Генерируется новый сертификационный документ: в него включаются атрибуты и расширения согласно шаблону (EKU, ограничения, период действия и т. д.). При этом информация, предоставленная заявителем в CSR (например, Subject или SAN), тоже встраивается, если это разрешают настройки шаблона. Полученный сертификат подписывается закрытым ключом CA, что связывает его с центром сертификации и подтверждает подлинность. После подписания сертификат сохраняется в базе данных CA для учета и контроля.
- Получение и установка сертификата. Подписанный сертификат передается обратно клиенту (заявителю). В случае авторегистрации система сама установит сертификат в нужное хранилище, например в личное хранилище пользователя в Windows. При ручном запросе пользователь импортирует полученный сертификат себе в систему. Закрытый ключ, сгенерированный на первом этапе, либо уже находится в хранилище пользователя/компьютера (если генерировался локально), либо может храниться на токене/смарт-карте. В итоге субъект получает полноценный сертификат, выданный доверенным CA, и может использовать его согласно заявленным EKU, например для доступа к ресурсам домена без ввода пароля (аутентификация по сертификату), для расшифровки ранее зашифрованных файлов или подписания документов.
Важно отметить, что, если шаблон требовал ручного одобрения, на этапе 4 сертификат не выпускается сразу — вместо этого запрос висит в очереди Pending до вмешательства администратора. Только после явного подтверждения уполномоченным лицом CA перейдет к этапу 4 и завершит выпуск. Аналогично при требовании подписей регистрационных агентов без нужных подписей запрос не будет обработан.
Служба AD CS — критический компонент безопасности Active Directory, так как сертификаты, которая она выдает, фактически дают доступ к ресурсам домена по доверенной схеме. Неправильная настройка AD CS почти неизбежно приводит к компрометации домена.
Злоумышленники могут злоупотребить доверенными сертификатами аналогично краже паролей: получив выданный доменом сертификат на привилегированную учетную запись, атакующий способен войти в систему под этой учетной записью (техника Pass-the-Certificate для получения Kerberos TGT). Более того, скомпрометированный центр сертификации позволяет выпускать поддельные сертификаты для любого объекта — такая ситуация эквивалентна полномасштабному взлому домена.
На практике основные слабые места AD CS, ведущие к эскалации привилегий, связаны с конфигурацией шаблонов и прав доступа. Например, чрезмерно открытые шаблоны (с включенным SAN и доступные для Enroll всем пользователям) позволяют обычному пользователю получить сертификат, выдающийся за администратора (техника ESC1). Небезопасные параметры шаблонов (Any Purpose EKU, отсутствие Manager approval, обязательных подписей и т. п.) усугубляют проблему, давая возможность автоматически и незаметно выдавать мощные сертификаты с расширенными правами (техники ESC2, ESC3 и др.).
Другой класс проблем — опасная настройка самого CA: пример тому флаг EDITF_ATTRIBUTESUBJECTALTNAME2 на сервере, позволяющий всегда включать SAN из запроса даже без соответствующего флага в шаблоне (атака ESC6), или избыточные права на администрирование CA, позволяющие злоумышленнику скомпрометировать CA-сервер (техника ESC7).
Также уязвимости могут скрываться во вспомогательных службах AD CS. Так, недостаточная защита веб-интерфейса Enrollment Services от атак типа NTLM relay позволяла атакующим удаленно получать сертификаты от имени компьютеров, в частности контроллеров домена (техника ESC8).
Наконец, отметим проблемы сопоставления сертификатов и учетных записей AD: слабые механизмы привязки сертификата к учетной записи (так называемый Explicit Mapping) могут допустить вход с сертификатом, не принадлежащим пользователю, если атрибуты сертификата частично совпадают (уязвимые настройки, эксплуатирующиеся в атаках ESC9, ESC10, ESC14). Таким образом, спектр проблем безопасности AD CS широк.
Администраторам Active Directory необходимо уделять повышенное внимание защите AD CS. Исследователи Уилл Шредер и Ли Кристенсен (SpecterOps) в 2021 году показали в своей книге Certified Pre-Owned, что при сочетании неправильно настроенных шаблонов и прав AD CS — это «мощное оружие в руках злоумышленников». Они перечислили множество сценариев эскалации привилегий, присутствовавших в корпоративных сетях на протяжении приблизительно 20 лет. Впоследствии были опубликованы дополнительные векторы, и сейчас известно 16 способов компрометации домена через уязвимости AD CS (ESC1 — ESC16).
Понимание приведенных выше основ — архитектуры AD CS, принципов работы центра сертификации, устройства шаблонов сертификатов и их параметров — это необходимая база для изучения каждой из техник атаки ESC. Далее в исследовании мы рассматриваем конкретные техники ESC1 — ESC16 и показываем, как именно ошибки в настройке AD CS превращаются в практические векторы атаки.
