AD CS Domain Escalation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
To jest podsumowanie sekcji technik eskalacji z postów:
Prawa do rejestracji są przyznawane użytkownikom o niskich uprawnieniach przez Enterprise CA.
Zgoda menedżera nie jest wymagana.
Nie są potrzebne podpisy od upoważnionego personelu.
Deskriptory zabezpieczeń na szablonach certyfikatów są zbyt liberalne, co pozwala użytkownikom o niskich uprawnieniach uzyskać prawa do rejestracji.
Szablony certyfikatów są skonfigurowane w celu zdefiniowania EKU, które ułatwiają uwierzytelnianie:
Identyfikatory Extended Key Usage (EKU) takie jak Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0) lub brak EKU (SubCA) są uwzględnione.
Możliwość dla wnioskodawców do dołączenia subjectAltName w żądaniu podpisania certyfikatu (CSR) jest dozwolona przez szablon:
Active Directory (AD) priorytetowo traktuje subjectAltName (SAN) w certyfikacie do weryfikacji tożsamości, jeśli jest obecny. Oznacza to, że poprzez określenie SAN w CSR, można zażądać certyfikatu do podszywania się pod dowolnego użytkownika (np. administratora domeny). To, czy wnioskodawca może określić SAN, jest wskazane w obiekcie AD szablonu certyfikatu przez właściwość mspki-certificate-name-flag. Ta właściwość jest maską bitową, a obecność flagi CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT pozwala wnioskodawcy na określenie SAN.
Skonfigurowanie opisane powyżej pozwala użytkownikom o niskich uprawnieniach na żądanie certyfikatów z dowolnym wybranym SAN, co umożliwia uwierzytelnianie jako dowolny podmiot domeny przez Kerberos lub SChannel.
Funkcja ta jest czasami włączana, aby wspierać generację certyfikatów HTTPS lub hostów w locie przez produkty lub usługi wdrożeniowe, lub z powodu braku zrozumienia.
Zauważono, że utworzenie certyfikatu z tą opcją wywołuje ostrzeżenie, co nie ma miejsca, gdy istniejący szablon certyfikatu (taki jak szablon WebServer, który ma włączoną CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) jest duplikowany, a następnie modyfikowany w celu uwzględnienia OID uwierzytelniania.
Aby znaleźć podatne szablony certyfikatów, możesz uruchomić:
Aby wykorzystać tę lukę do podszywania się pod administratora, można uruchomić:
Następnie możesz przekształcić wygenerowany certyfikat do formatu .pfx i użyć go do uwierzytelnienia za pomocą Rubeus lub certipy ponownie:
Binaries Windows "Certreq.exe" i "Certutil.exe" mogą być używane do generowania PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Enumeracja szablonów certyfikatów w schemacie konfiguracji lasu AD, szczególnie tych, które nie wymagają zatwierdzenia lub podpisów, posiadających EKU Client Authentication lub Smart Card Logon oraz z włączonym flagą CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, może być przeprowadzona poprzez uruchomienie następującego zapytania LDAP:
Drugi scenariusz nadużycia jest wariantem pierwszego:
Prawa do rejestracji są przyznawane użytkownikom o niskich uprawnieniach przez Enterprise CA.
Wymóg zatwierdzenia przez menedżera jest wyłączony.
Wymóg autoryzowanych podpisów jest pomijany.
Zbyt liberalny opis zabezpieczeń na szablonie certyfikatu przyznaje prawa do rejestracji certyfikatów użytkownikom o niskich uprawnieniach.
Szablon certyfikatu jest zdefiniowany tak, aby obejmował Any Purpose EKU lub nie miał EKU.
Any Purpose EKU pozwala na uzyskanie certyfikatu przez atakującego w dowolnym celu, w tym uwierzytelnianie klienta, uwierzytelnianie serwera, podpisywanie kodu itp. Ta sama technika używana w ESC3 może być wykorzystana do wykorzystania tego scenariusza.
Certyfikaty z brakiem EKU, które działają jako certyfikaty podrzędnych CA, mogą być wykorzystywane w dowolnym celu i mogą również być używane do podpisywania nowych certyfikatów. W związku z tym atakujący mógłby określić dowolne EKU lub pola w nowych certyfikatach, wykorzystując certyfikat podrzędnego CA.
Jednak nowe certyfikaty utworzone do uwierzytelniania domeny nie będą działać, jeśli podrzędny CA nie jest zaufany przez obiekt NTAuthCertificates, co jest ustawieniem domyślnym. Niemniej jednak atakujący może nadal tworzyć nowe certyfikaty z dowolnym EKU i dowolnymi wartościami certyfikatu. Mogłyby one być potencjalnie nadużywane do szerokiego zakresu celów (np. podpisywanie kodu, uwierzytelnianie serwera itp.) i mogłyby mieć znaczące konsekwencje dla innych aplikacji w sieci, takich jak SAML, AD FS lub IPSec.
Aby wyliczyć szablony, które pasują do tego scenariusza w schemacie konfiguracji lasu AD, można uruchomić następujące zapytanie LDAP:
Ten scenariusz jest podobny do pierwszego i drugiego, ale wykorzystuje inny EKU (Agent Żądania Certyfikatu) oraz 2 różne szablony (dlatego ma 2 zestawy wymagań),
EKU Agenta Żądania Certyfikatu (OID 1.3.6.1.4.1.311.20.2.1), znany jako Agent Rejestracji w dokumentacji Microsoft, pozwala podmiotowi zarejestrować certyfikat w imieniu innego użytkownika.
„agent rejestracji” rejestruje się w takim szablonie i używa uzyskanego certyfikatu do współpodpisania CSR w imieniu innego użytkownika. Następnie wysyła współpodpisany CSR do CA, rejestrując się w szablonie, który zezwala na „rejestrację w imieniu”, a CA odpowiada certyfikatem należącym do „innego” użytkownika.
Wymagania 1:
Prawa do rejestracji są przyznawane użytkownikom o niskich uprawnieniach przez Enterprise CA.
Wymóg zatwierdzenia przez menedżera jest pomijany.
Brak wymogu autoryzowanych podpisów.
Opis zabezpieczeń szablonu certyfikatu jest nadmiernie liberalny, przyznając prawa do rejestracji użytkownikom o niskich uprawnieniach.
Szablon certyfikatu zawiera EKU Agenta Żądania Certyfikatu, umożliwiając żądanie innych szablonów certyfikatów w imieniu innych podmiotów.
Wymagania 2:
Enterprise CA przyznaje prawa do rejestracji użytkownikom o niskich uprawnieniach.
Zatwierdzenie przez menedżera jest pomijane.
Wersja schematu szablonu to 1 lub przekracza 2, a on określa Wymóg Wydania Polityki Aplikacji, który wymaga EKU Agenta Żądania Certyfikatu.
EKU zdefiniowane w szablonie certyfikatu zezwala na uwierzytelnianie w domenie.
Ograniczenia dla agentów rejestracji nie są stosowane w CA.
Możesz użyć Certify lub Certipy, aby wykorzystać ten scenariusz:
The użytkownicy, którzy mają prawo do uzyskania certyfikatu agenta rejestracji, szablony, w których agenci rejestracji mogą się rejestrować, oraz kont w imieniu których agent rejestracji może działać, mogą być ograniczeni przez korporacyjne CA. Osiąga się to poprzez otwarcie snap-in certsrc.msc, kliknięcie prawym przyciskiem myszy na CA, wybranie Właściwości, a następnie przejście do zakładki „Agenci rejestracji”.
Należy jednak zauważyć, że domyślne ustawienie dla CA to „Nie ograniczaj agentów rejestracji.” Gdy ograniczenie dla agentów rejestracji jest włączone przez administratorów, ustawienie na „Ogranicz agentów rejestracji” pozostaje niezwykle liberalne. Umożliwia to dostęp Wszystkim do rejestracji we wszystkich szablonach jako ktokolwiek.
Opis zabezpieczeń na szablonach certyfikatów definiuje uprawnienia, które konkretne podmioty AD posiadają w odniesieniu do szablonu.
Jeśli atakujący posiada wymagane uprawnienia do zmiany szablonu i wprowadzenia jakichkolwiek wykorzystywalnych błędów konfiguracyjnych opisanych w poprzednich sekcjach, eskalacja uprawnień może być ułatwiona.
Znaczące uprawnienia stosowane do szablonów certyfikatów obejmują:
Właściciel: Przyznaje domyślną kontrolę nad obiektem, umożliwiając modyfikację dowolnych atrybutów.
Pełna kontrola: Umożliwia pełną władzę nad obiektem, w tym zdolność do zmiany dowolnych atrybutów.
Zapisz właściciela: Umożliwia zmianę właściciela obiektu na podmiot kontrolowany przez atakującego.
Zapisz Dacl: Umożliwia dostosowanie kontroli dostępu, potencjalnie przyznając atakującemu Pełną kontrolę.
Zapisz właściwość: Upoważnia do edytowania dowolnych właściwości obiektu.
Przykład eskalacji uprawnień jak w poprzednim przypadku:
ESC4 to sytuacja, gdy użytkownik ma uprawnienia do zapisu nad szablonem certyfikatu. Może to być na przykład nadużyte do nadpisania konfiguracji szablonu certyfikatu, aby uczynić szablon podatnym na ESC1.
Jak widać w powyższej ścieżce, tylko JOHNPC ma te uprawnienia, ale nasz użytkownik JOHN ma nowy AddKeyCredentialLink do JOHNPC. Ponieważ ta technika jest związana z certyfikatami, wdrożyłem również ten atak, znany jako Shadow Credentials. Oto mały podgląd polecenia shadow auto Certipy do odzyskania NT hasha ofiary.
Certipy może nadpisać konfigurację szablonu certyfikatu za pomocą jednego polecenia. Domyślnie Certipy nadpisze konfigurację, aby uczynić ją wrażliwą na ESC1. Możemy również określić parametr -save-old, aby zapisać starą konfigurację, co będzie przydatne do przywracania konfiguracji po naszym ataku.
Rozbudowana sieć powiązań opartych na ACL, która obejmuje kilka obiektów poza szablonami certyfikatów i urzędami certyfikacji, może wpłynąć na bezpieczeństwo całego systemu AD CS. Obiekty te, które mogą znacząco wpłynąć na bezpieczeństwo, obejmują:
Obiekt komputera AD serwera CA, który może być skompromitowany za pomocą mechanizmów takich jak S4U2Self lub S4U2Proxy.
Serwer RPC/DCOM serwera CA.
Każdy obiekt lub kontener AD będący potomkiem w określonej ścieżce kontenera CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Ścieżka ta obejmuje, ale nie ogranicza się do, kontenerów i obiektów takich jak kontener szablonów certyfikatów, kontener urzędów certyfikacji, obiekt NTAuthCertificates oraz kontener usług rejestracji.
Bezpieczeństwo systemu PKI może zostać skompromitowane, jeśli atakujący o niskich uprawnieniach zdoła przejąć kontrolę nad którymkolwiek z tych krytycznych komponentów.
Temat poruszony w poście CQure Academy dotyczy również implikacji flagi EDITF_ATTRIBUTESUBJECTALTNAME2, jak opisano przez Microsoft. Ta konfiguracja, gdy jest aktywowana na Urzędzie Certyfikacji (CA), pozwala na włączenie wartości zdefiniowanych przez użytkownika w alternatywnym nazwie podmiotu dla dowolnego żądania, w tym tych skonstruowanych z Active Directory®. W związku z tym, ten przepis pozwala intruzowi na rejestrację za pomocą dowolnego szablonu skonfigurowanego do uwierzytelniania w domenie—szczególnie tych otwartych na rejestrację użytkowników bez uprawnień, jak standardowy szablon użytkownika. W rezultacie można zabezpieczyć certyfikat, umożliwiając intruzowi uwierzytelnienie jako administrator domeny lub jakikolwiek inny aktywny podmiot w domenie.
Note: Podejście do dodawania alternatywnych nazw do Żądania Podpisania Certyfikatu (CSR), za pomocą argumentu -attrib "SAN:" w certreq.exe (nazywanego „Pary Nazwa-Wartość”), stanowi kontrast w porównaniu do strategii wykorzystania SAN w ESC1. Tutaj różnica polega na tym, jak informacje o koncie są enkapsulowane—w atrybucie certyfikatu, a nie w rozszerzeniu.
Aby sprawdzić, czy ustawienie jest aktywowane, organizacje mogą wykorzystać następujące polecenie z certutil.exe:
Ta operacja zasadniczo wykorzystuje zdalny dostęp do rejestru, dlatego alternatywne podejście może być:
Narzędzia takie jak Certify i Certipy są w stanie wykryć tę błędną konfigurację i ją wykorzystać:
Aby zmienić te ustawienia, zakładając, że posiada się prawa administracyjne domeny lub równoważne, można wykonać następujące polecenie z dowolnej stacji roboczej:
Aby wyłączyć tę konfigurację w swoim środowisku, flaga może zostać usunięta za pomocą:
Po aktualizacjach zabezpieczeń z maja 2022 roku, nowo wydane certyfikaty będą zawierać rozszerzenie zabezpieczeń, które włącza właściwość objectSid wnioskodawcy. Dla ESC1, ten SID pochodzi z określonego SAN. Jednak dla ESC6, SID odzwierciedla objectSid wnioskodawcy, a nie SAN.
Aby wykorzystać ESC6, system musi być podatny na ESC10 (Słabe mapowania certyfikatów), które priorytetowo traktuje SAN nad nowym rozszerzeniem zabezpieczeń.
Kontrola dostępu dla jednostki certyfikującej jest utrzymywana przez zestaw uprawnień, które regulują działania CA. Te uprawnienia można zobaczyć, uzyskując dostęp do certsrv.msc, klikając prawym przyciskiem myszy na CA, wybierając właściwości, a następnie przechodząc do zakładki Zabezpieczenia. Dodatkowo, uprawnienia można enumerować za pomocą modułu PSPKI przy użyciu poleceń takich jak:
To zapewnia wgląd w podstawowe prawa, mianowicie ManageCA i ManageCertificates, które odpowiadają rolom „administrator CA” i „menedżer certyfikatów” odpowiednio.
Posiadanie praw ManageCA na urzędzie certyfikacji umożliwia głównemu użytkownikowi zdalne manipulowanie ustawieniami za pomocą PSPKI. Obejmuje to przełączanie flagi EDITF_ATTRIBUTESUBJECTALTNAME2 w celu zezwolenia na specyfikację SAN w dowolnym szablonie, co jest kluczowym aspektem eskalacji domeny.
Uproszczenie tego procesu jest możliwe dzięki użyciu cmdletu Enable-PolicyModuleFlag w PSPKI, co pozwala na modyfikacje bez bezpośredniej interakcji z GUI.
Posiadanie praw ManageCertificates ułatwia zatwierdzanie oczekujących wniosków, skutecznie omijając zabezpieczenie „zatwierdzenie menedżera certyfikatów CA”.
Kombinacja modułów Certify i PSPKI może być wykorzystana do żądania, zatwierdzania i pobierania certyfikatu:
W poprzednim ataku Manage CA uprawnienia zostały użyte do włączenia flagi EDITF_ATTRIBUTESUBJECTALTNAME2 w celu przeprowadzenia ataku ESC6, ale nie będzie to miało żadnego efektu, dopóki usługa CA (CertSvc) nie zostanie ponownie uruchomiona. Kiedy użytkownik ma prawo dostępu Manage CA, użytkownik ma również prawo do ponownego uruchomienia usługi. Jednak nie oznacza to, że użytkownik może ponownie uruchomić usługę zdalnie. Ponadto, ESC6 może nie działać od razu w większości załatanych środowisk z powodu aktualizacji zabezpieczeń z maja 2022 roku.
Dlatego przedstawiony jest tutaj inny atak.
Wymagania wstępne:
Tylko ManageCA uprawnienie
Uprawnienie Manage Certificates (może być przyznane z ManageCA)
Szablon certyfikatu SubCA musi być włączony (może być włączony z ManageCA)
Technika opiera się na fakcie, że użytkownicy z prawem dostępu Manage CA i Manage Certificates mogą wydawać nieudane żądania certyfikatów. Szablon certyfikatu SubCA jest wrażliwy na ESC1, ale tylko administratorzy mogą się zarejestrować w szablonie. Tak więc, użytkownik może zażądać rejestracji w SubCA - co zostanie odmówione - ale następnie wydane przez menedżera.
Możesz przyznać sobie prawo dostępu Manage Certificates dodając swojego użytkownika jako nowego oficera.
Szablon SubCA może być włączony na CA za pomocą parametru -enable-template. Domyślnie szablon SubCA jest włączony.
