AD CS Domain Escalation
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
To jest podsumowanie sekcji technik eskalacji z postów:
Źle skonfigurowane szablony certyfikatów - ESC1
Wyjaśnienie
Źle skonfigurowane szablony certyfikatów - ESC1 wyjaśnione
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ść flagiCT_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.
Nadużycie
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:
Źle skonfigurowane szablony certyfikatów - ESC2
Wyjaśnienie
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:
Źle skonfigurowane szablony agentów rejestracji - ESC3
Wyjaśnienie
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.
Wykorzystanie
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.
Kontrola dostępu do szablonów certyfikatów - ESC4
Wyjaśnienie
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.
Nadużycie
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.
Vulnerable PKI Object Access Control - ESC5
Explanation
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.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Explanation
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.
Abuse
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 do podatnej jednostki certyfikującej - ESC7
Atak 1
Wyjaśnienie
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.
Nadużycie
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:
Atak 2
Wyjaśnienie
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
uprawnienieUprawnienie
Manage Certificates
(może być przyznane zManageCA
)Szablon certyfikatu
SubCA
musi być włączony (może być włączony zManageCA
)
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.
Nadużycie
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.
Jeśli spełniliśmy wymagania wstępne dla tego ataku, możemy zacząć od zażądania certyfikatu opartego na szablonie SubCA
.
To żądanie zostanie odrzucone, ale zapiszemy klucz prywatny i zanotujemy identyfikator żądania.
Z naszymi Manage CA
i Manage Certificates
możemy następnie wydać nieudane żądanie certyfikatu za pomocą polecenia ca
i parametru -issue-request <request ID>
.
A na koniec możemy pobrać wydany certyfikat za pomocą polecenia req
i parametru -retrieve <request ID>
.
NTLM Relay do punktów końcowych AD CS HTTP – ESC8
Wyjaśnienie
W środowiskach, w których zainstalowane jest AD CS, jeśli istnieje punkt końcowy rejestracji internetowej podatny i przynajmniej jeden szablon certyfikatu jest opublikowany, który zezwala na rejestrację komputerów domenowych i uwierzytelnianie klientów (takich jak domyślny Machine
), możliwe jest, aby jakikolwiek komputer z aktywną usługą spoolera został skompromitowany przez atakującego!
Kilka metod rejestracji opartych na HTTP jest obsługiwanych przez AD CS, udostępnionych przez dodatkowe role serwera, które mogą być instalowane przez administratorów. Te interfejsy do rejestracji certyfikatów opartych na HTTP są podatne na ataki NTLM relay. Atakujący, z skomprymowanej maszyny, może podszyć się pod dowolne konto AD, które uwierzytelnia się za pomocą przychodzącego NTLM. Podszywając się pod konto ofiary, te interfejsy internetowe mogą być wykorzystywane przez atakującego do żądania certyfikatu uwierzytelniania klienta przy użyciu szablonów certyfikatów User
lub Machine
.
Interfejs rejestracji internetowej (starsza aplikacja ASP dostępna pod adresem
http://<caserver>/certsrv/
), domyślnie obsługuje tylko HTTP, co nie zapewnia ochrony przed atakami NTLM relay. Dodatkowo, wyraźnie zezwala tylko na uwierzytelnianie NTLM przez nagłówek HTTP Authorization, co sprawia, że bardziej bezpieczne metody uwierzytelniania, takie jak Kerberos, są nieodpowiednie.Usługa rejestracji certyfikatów (CES), Polityka rejestracji certyfikatów (CEP) Web Service oraz Usługa rejestracji urządzeń sieciowych (NDES) domyślnie obsługują uwierzytelnianie negotiate przez swój nagłówek HTTP Authorization. Uwierzytelnianie negotiate obsługuje zarówno Kerberos, jak i NTLM, co pozwala atakującemu na obniżenie poziomu do uwierzytelniania NTLM podczas ataków relay. Chociaż te usługi internetowe domyślnie włączają HTTPS, HTTPS sam w sobie nie chroni przed atakami NTLM relay. Ochrona przed atakami NTLM relay dla usług HTTPS jest możliwa tylko wtedy, gdy HTTPS jest połączone z wiązaniem kanałów. Niestety, AD CS nie aktywuje Rozszerzonej Ochrony dla Uwierzytelniania na IIS, co jest wymagane do wiązania kanałów.
Powszechnym problemem z atakami NTLM relay jest krótki czas trwania sesji NTLM oraz niemożność atakującego do interakcji z usługami, które wymagają podpisywania NTLM.
Niemniej jednak, to ograniczenie jest przezwyciężane poprzez wykorzystanie ataku NTLM relay do uzyskania certyfikatu dla użytkownika, ponieważ okres ważności certyfikatu dyktuje czas trwania sesji, a certyfikat może być używany z usługami, które wymagają podpisywania NTLM. Aby uzyskać instrukcje dotyczące wykorzystania skradzionego certyfikatu, zapoznaj się z:
AD CS Account PersistenceInnym ograniczeniem ataków NTLM relay jest to, że maszyna kontrolowana przez atakującego musi być uwierzytelniona przez konto ofiary. Atakujący może albo czekać, albo próbować wymusić to uwierzytelnienie:
Force NTLM Privileged AuthenticationNadużycie
Certify’s cas
wylicza włączone punkty końcowe HTTP AD CS:
Właściwość msPKI-Enrollment-Servers
jest używana przez korporacyjne urzędy certyfikacji (CA) do przechowywania punktów końcowych usługi rejestracji certyfikatów (CES). Punkty te można analizować i wyświetlać, korzystając z narzędzia Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Nadużycie z Certify
Abuse with Certipy
Żądanie certyfikatu jest domyślnie składane przez Certipy na podstawie szablonu Machine
lub User
, w zależności od tego, czy nazwa konta, które jest przekazywane, kończy się na $
. Określenie alternatywnego szablonu można osiągnąć za pomocą parametru -template
.
Technika taka jak PetitPotam może być następnie wykorzystana do wymuszenia uwierzytelnienia. W przypadku kontrolerów domeny wymagane jest określenie -template DomainController
.
No Security Extension - ESC9
Explanation
Nowa wartość CT_FLAG_NO_SECURITY_EXTENSION
(0x80000
) dla msPKI-Enrollment-Flag
, określana jako ESC9, zapobiega osadzaniu nowego szOID_NTDS_CA_SECURITY_EXT
rozszerzenia zabezpieczeń w certyfikacie. Flaga ta staje się istotna, gdy StrongCertificateBindingEnforcement
jest ustawione na 1
(domyślne ustawienie), co kontrastuje z ustawieniem 2
. Jej znaczenie wzrasta w scenariuszach, w których słabsze mapowanie certyfikatów dla Kerberos lub Schannel może być wykorzystane (jak w ESC10), biorąc pod uwagę, że brak ESC9 nie zmieniłby wymagań.
Warunki, w których ustawienie tej flagi staje się istotne, obejmują:
StrongCertificateBindingEnforcement
nie jest dostosowane do2
(z domyślnym ustawieniem1
), lubCertificateMappingMethods
zawiera flagęUPN
.Certyfikat jest oznaczony flagą
CT_FLAG_NO_SECURITY_EXTENSION
w ustawieniumsPKI-Enrollment-Flag
.Jakiekolwiek EKU uwierzytelniania klienta jest określone przez certyfikat.
Uprawnienia
GenericWrite
są dostępne dla dowolnego konta, aby skompromitować inne.
Abuse Scenario
Załóżmy, że John@corp.local
ma uprawnienia GenericWrite
do Jane@corp.local
, z celem skompromitowania Administrator@corp.local
. Szablon certyfikatu ESC9
, do którego Jane@corp.local
ma prawo się zarejestrować, jest skonfigurowany z flagą CT_FLAG_NO_SECURITY_EXTENSION
w swoim ustawieniu msPKI-Enrollment-Flag
.
Początkowo, hash Jane
jest pozyskiwany za pomocą Shadow Credentials, dzięki GenericWrite
Johna
:
Następnie userPrincipalName
Jane
jest modyfikowany na Administrator
, celowo pomijając część domeny @corp.local
:
Ta modyfikacja nie narusza ograniczeń, ponieważ Administrator@corp.local
pozostaje odrębny jako userPrincipalName
Administratora
.
Po tym, szablon certyfikatu ESC9
, oznaczony jako podatny, jest żądany jako Jane
:
Zauważono, że userPrincipalName
certyfikatu odzwierciedla Administrator
, pozbawiony jakiegokolwiek “object SID”.
userPrincipalName
Jane
jest następnie przywracany do jej oryginalnego, Jane@corp.local
:
Próba uwierzytelnienia za pomocą wydanego certyfikatu teraz zwraca hasz NT Administrator@corp.local
. Polecenie musi zawierać -domain <domain>
z powodu braku specyfikacji domeny w certyfikacie:
Słabe mapowania certyfikatów - ESC10
Wyjaśnienie
Dwie wartości kluczy rejestru na kontrolerze domeny są określane przez ESC10:
Wartość domyślna dla
CertificateMappingMethods
wHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
to0x18
(0x8 | 0x10
), wcześniej ustawiona na0x1F
.Domyślne ustawienie dla
StrongCertificateBindingEnforcement
wHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
to1
, wcześniej0
.
Przypadek 1
Gdy StrongCertificateBindingEnforcement
jest skonfigurowane jako 0
.
Przypadek 2
Jeśli CertificateMappingMethods
zawiera bit UPN
(0x4
).
Przypadek nadużycia 1
Gdy StrongCertificateBindingEnforcement
jest skonfigurowane jako 0
, konto A z uprawnieniami GenericWrite
może zostać wykorzystane do skompromitowania dowolnego konta B.
Na przykład, mając uprawnienia GenericWrite
do Jane@corp.local
, atakujący dąży do skompromitowania Administrator@corp.local
. Procedura odzwierciedla ESC9, umożliwiając wykorzystanie dowolnego szablonu certyfikatu.
Początkowo, hash Jane
jest pozyskiwany za pomocą Shadow Credentials, wykorzystując GenericWrite
.
Następnie userPrincipalName
Jane
jest zmieniany na Administrator
, celowo pomijając część @corp.local
, aby uniknąć naruszenia ograniczenia.
Następnie żądany jest certyfikat umożliwiający uwierzytelnianie klienta jako Jane
, przy użyciu domyślnego szablonu User
.
Jane
's userPrincipalName
jest następnie przywracany do pierwotnej wersji, Jane@corp.local
.
Uwierzytelnienie za pomocą uzyskanego certyfikatu da NT hash Administrator@corp.local
, co wymaga określenia domeny w poleceniu z powodu braku szczegółów domeny w certyfikacie.
Abuse Case 2
Z flagiem bitowym UPN
w CertificateMappingMethods
(0x4
), konto A z uprawnieniami GenericWrite
może skompromitować każde konto B, które nie ma właściwości userPrincipalName
, w tym konta maszynowe oraz wbudowanego administratora domeny Administrator
.
Celem jest skompromitowanie DC$@corp.local
, zaczynając od uzyskania hasha Jane
za pomocą Shadow Credentials, wykorzystując GenericWrite
.
Jane
's userPrincipalName
jest następnie ustawiony na DC$@corp.local
.
Certyfikat do uwierzytelniania klienta jest żądany jako Jane
przy użyciu domyślnego szablonu User
.
Jane
's userPrincipalName
jest przywracany do pierwotnej wersji po tym procesie.
Aby uwierzytelnić się za pomocą Schannel, używana jest opcja -ldap-shell
Certipy, która wskazuje na pomyślne uwierzytelnienie jako u:CORP\DC$
.
Poprzez powłokę LDAP, polecenia takie jak set_rbcd
umożliwiają ataki oparte na delegacji ograniczonej zasobami (RBCD), co może zagrozić kontrolerowi domeny.
Ta luka dotyczy również każdego konta użytkownika, które nie ma userPrincipalName
lub gdy nie pasuje do sAMAccountName
, przy czym domyślne Administrator@corp.local
jest głównym celem z powodu swoich podwyższonych uprawnień LDAP i braku userPrincipalName
domyślnie.
Relaying NTLM to ICPR - ESC11
Wyjaśnienie
Jeśli serwer CA nie jest skonfigurowany z IF_ENFORCEENCRYPTICERTREQUEST
, może to prowadzić do ataków NTLM relay bez podpisywania za pośrednictwem usługi RPC. Referencja tutaj.
Możesz użyć certipy
, aby sprawdzić, czy Enforce Encryption for Requests
jest wyłączone, a certipy pokaże luki ESC11
.
Scenariusz nadużycia
Należy skonfigurować serwer przekaźnikowy:
Note: Dla kontrolerów domeny musimy określić -template
w DomainController.
Lub używając forka sploutchy'ego impacket :
Shell access to ADCS CA with YubiHSM - ESC12
Explanation
Administratorzy mogą skonfigurować Urząd Certyfikacji, aby przechowywał go na zewnętrznym urządzeniu, takim jak "Yubico YubiHSM2".
Jeśli urządzenie USB jest podłączone do serwera CA przez port USB, lub serwer urządzenia USB w przypadku, gdy serwer CA jest maszyną wirtualną, wymagany jest klucz uwierzytelniający (czasami nazywany "hasłem"), aby Dostawca Przechowywania Kluczy mógł generować i wykorzystywać klucze w YubiHSM.
Ten klucz/hasło jest przechowywane w rejestrze pod HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
w postaci niezaszyfrowanej.
Referencja tutaj.
Abuse Scenario
Jeśli prywatny klucz CA jest przechowywany na fizycznym urządzeniu USB, gdy uzyskasz dostęp do powłoki, możliwe jest odzyskanie klucza.
Najpierw musisz uzyskać certyfikat CA (to jest publiczne), a następnie:
Finally, use the certutil -sign
command to forge a new arbitrary certificate using the CA certificate and its private key.
OID Group Link Abuse - ESC13
Explanation
Atrybut msPKI-Certificate-Policy
pozwala na dodanie polityki wydania do szablonu certyfikatu. Obiekty msPKI-Enterprise-Oid
, które są odpowiedzialne za wydawanie polityk, można odkryć w Kontekst Nazewniczy Konfiguracji (CN=OID,CN=Public Key Services,CN=Services) kontenera PKI OID. Polityka może być powiązana z grupą AD za pomocą atrybutu msDS-OIDToGroupLink
tego obiektu, co umożliwia systemowi autoryzację użytkownika, który przedstawia certyfikat, tak jakby był członkiem grupy. Reference in here.
In other words, when a user has permission to enroll a certificate and the certificate is link to an OID group, the user can inherit the privileges of this group.
Use Check-ADCSESC13.ps1 to find OIDToGroupLink:
Abuse Scenario
Znajdź uprawnienia użytkownika, które można wykorzystać certipy find
lub Certify.exe find /showAllPermissions
.
Jeśli John
ma uprawnienia do rejestracji VulnerableTemplate
, użytkownik może dziedziczyć uprawnienia grupy VulnerableGroup
.
Wszystko, co musi zrobić, to określić szablon, a otrzyma certyfikat z prawami OIDToGroupLink.
Kompromitacja Lasów z Certyfikatami Wyjaśniona w Stronie Biernej
Łamanie Zaufania Lasów przez Kompromitowane CA
Konfiguracja dla cross-forest enrollment jest stosunkowo prosta. Certyfikat CA root z lasu zasobów jest publikowany do lasów kontowych przez administratorów, a certyfikaty CA enterprise z lasu zasobów są dodawane do kontenerów NTAuthCertificates
i AIA w każdym lesie kontowym. Aby wyjaśnić, to ustawienie przyznaje CA w lesie zasobów pełną kontrolę nad wszystkimi innymi lasami, dla których zarządza PKI. Jeśli to CA zostanie skompromentowane przez atakujących, certyfikaty dla wszystkich użytkowników w obu lasach, zasobów i kontowych, mogą być fałszowane przez nich, łamiąc w ten sposób granicę bezpieczeństwa lasu.
Uprawnienia do Rejestracji Przyznane Obcym Podmiotom
W środowiskach wielolasowych należy zachować ostrożność w odniesieniu do CA Enterprise, które publikują szablony certyfikatów, które pozwalają Użytkownikom Uwierzytelnionym lub obcym podmiotom (użytkownikom/grupom zewnętrznym do lasu, do którego należy CA Enterprise) na prawa rejestracji i edycji. Po uwierzytelnieniu w ramach zaufania, SID Użytkowników Uwierzytelnionych jest dodawany do tokena użytkownika przez AD. Tak więc, jeśli domena posiada CA Enterprise z szablonem, który pozwala Użytkownikom Uwierzytelnionym na prawa rejestracji, szablon może potencjalnie być zarejestrowany przez użytkownika z innego lasu. Podobnie, jeśli prawa rejestracji są wyraźnie przyznawane obcemu podmiotowi przez szablon, tworzy to relację kontroli dostępu między lasami, umożliwiając podmiotowi z jednego lasu rejestrację w szablonie z innego lasu.
Oba scenariusze prowadzą do zwiększenia powierzchni ataku z jednego lasu do drugiego. Ustawienia szablonu certyfikatu mogą być wykorzystane przez atakującego do uzyskania dodatkowych uprawnień w obcej domenie.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated