mirror of https://github.com/carlospolop/hacktricks synced 2024-11-30 00:20:59 +00:00

History

CPol a7bfd36df7 GitBook: No commit message		2024-04-06 19:41:21 +00:00
..
account-persistence.md	Translated to Ukranian	2024-03-29 19:49:46 +01:00
certificate-theft.md	Translated to Ukranian	2024-03-29 19:49:46 +01:00
domain-escalation.md	Translated to Ukranian	2024-03-29 19:49:46 +01:00
domain-persistence.md	Translated to Ukranian	2024-03-29 19:49:46 +01:00
README.md	GitBook: No commit message	2024-04-06 19:41:21 +00:00

README.md

Сертифікати AD

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію в рекламі на HackTricks або завантажити HackTricks у PDF Перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks мерч
Дізнайтеся про Сім'ю PEASS, нашу колекцію ексклюзивних NFT
Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

Вступ

Компоненти сертифіката

Суб'єкт сертифіката вказує на його власника.
Публічний ключ спарений з приватним ключем для зв'язку сертифіката з його законним власником.
Період дії, визначений датами NotBefore та NotAfter, вказує на ефективний термін дії сертифіката.
Унікальний Серійний номер, наданий Центром сертифікації (CA), ідентифікує кожен сертифікат.
Видавець вказує на CA, який видав сертифікат.
SubjectAlternativeName дозволяє додаткові імена для суб'єкта, покращуючи гнучкість ідентифікації.
Основні обмеження визначають, чи сертифікат призначений для CA чи кінцевого об'єкта та визначають обмеження використання.
Розширені використання ключів (EKUs) визначають конкретні цілі сертифіката, такі як підписання коду або шифрування електронної пошти, за допомогою ідентифікаторів об'єктів (OIDs).
Алгоритм підпису вказує метод підпису сертифіката.
Підпис, створений за допомогою приватного ключа видавця, гарантує автентичність сертифіката.

Спеціальні врахування

Альтернативні імена суб'єктів (SANs) розширюють застосовність сертифіката на кілька ідентичностей, що є важливим для серверів з декількома доменами. Надійні процеси видачі є важливими для уникнення ризиків імітації з боку зловмисників, які маніпулюють специфікацією SAN.

Центри сертифікації (CAs) в Active Directory (AD)

AD CS визнає сертифікати CA в лісі AD через відповідні контейнери, кожен з яких виконує унікальні ролі:

Контейнер Certification Authorities містить довірені кореневі сертифікати CA.
Контейнер Enrolment Services містить підприємницькі CA та їх шаблони сертифікатів.
Об'єкт NTAuthCertificates включає сертифікати CA, схвалені для аутентифікації AD.
Контейнер AIA (Authority Information Access) сприяє перевірці ланцюжка сертифікатів з проміжними та перехресними сертифікатами.

Отримання сертифіката: Потік запиту клієнтського сертифіката

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

Шаблони сертифікатів

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

Реєстрація сертифікатів

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

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

Права на реєстрацію шаблону

Ці права визначаються через записи контролю доступу (ACEs), деталізуючи дозволи, такі як:

Права Certificate-Enrollment та Certificate-AutoEnrollment, кожне пов'язане з конкретними GUID.
Розширені права, що дозволяють всі розширені дозволи.
FullControl/GenericAll, надаючи повний контроль над шаблоном.

Права на реєстрацію Підприємницького CA

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

Додаткові контролі видачі

Можуть застосовуватися певні контролі, такі як:

Схвалення менеджера: Покладає запити в стан очікування до схвалення менеджером сертифікатів.
Агенти реєстрації та авторизовані підписи: Вказують кількість необхідних підписів на CSR та необхідні об'єкти політики додатків OIDs.

Методи запиту сертифікатів

Сертифікати можна запитати через:

Протокол реєстрації сертифікатів клієнта Windows (MS-WCCE), використовуючи інтерфейси DCOM.
Віддалений протокол ICertPassage (MS-ICPR), через іменовані канали або TCP/IP.
Веб-інтерфейс реєстрації сертифікатів, з встановленою роллю веб-реєстрації сертифікатів авторитета.
Служба реєстрації сертифікатів (CES), разом із службою політики реєстрації сертифікатів (CEP).
Служба реєстрації пристроїв мережі (NDES) для мережевих пристроїв, використовуючи простий протокол реєстрації сертифікатів (SCEP).

Користувачі Windows також можуть запитувати сертифікати через GUI (certmgr.msc або certlm.msc) або інструменти командного рядка (certreq.exe або команду Get-Certificate PowerShell).

# Example of requesting a certificate using PowerShell
Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"

Аутентифікація сертифікатів

Active Directory (AD) підтримує аутентифікацію за допомогою сертифікатів, в основному використовуючи протоколи Kerberos та Secure Channel (Schannel).

Процес аутентифікації Kerberos

У процесі аутентифікації Kerberos запит користувача на отримання квитка для отримання квитка (TGT) підписується за допомогою приватного ключа сертифіката користувача. Цей запит проходить кілька перевірок контролера домену, включаючи валідність, шлях та статус відкликання сертифіката. Перевірки також включають перевірку того, що сертифікат походить від довіреного джерела та підтвердження присутності видавця в сховищі сертифікатів NTAUTH. Успішні перевірки призводять до видачі TGT. Об'єкт NTAuthCertificates в AD, знаходиться за адресою:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>

Безпека каналу (Schannel) аутентифікація

Schannel сприяє безпечним з'єднанням TLS/SSL, де під час рукостискання клієнт представляє сертифікат, який, якщо успішно перевірений, авторизує доступ. Відображення сертифіката на обліковий запис AD може включати функцію S4U2Self Kerberos або Subject Alternative Name (SAN) сертифіката, серед інших методів.

Перелік служб сертифікатів AD

Служби сертифікатів AD можуть бути перелічені за допомогою запитів LDAP, розкриваючи інформацію про Enterprise Certificate Authorities (CAs) та їх конфігурації. Це доступно будь-якому користувачеві, який має аутентифікацію домену без спеціальних привілеїв. Інструменти, такі як Certify та Certipy використовуються для переліку та оцінки вразливостей в середовищах AD CS.

Команди для використання цих інструментів включають:

# Enumerate trusted root CA certificates and Enterprise CAs with Certify
Certify.exe cas
# Identify vulnerable certificate templates with Certify
Certify.exe find /vulnerable

# Use Certipy for enumeration and identifying vulnerable templates
certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128

# Enumerate Enterprise CAs and certificate templates with certutil
certutil.exe -TCAInfo
certutil -v -dstemplate

Посилання