AD CS Domain Escalation
To jest podsumowanie sekcji technik eskalacji z postów:
Błędnie skonfigurowane szablony certyfikatów - ESC1
Wyjaśnienie
Błędnie skonfigurowane szablony certyfikatów - ESC1 Wyjaśnione
Prawa do zapisu są przyznawane nisko uprzywilejowanym użytkownikom przez Enterprise CA.
Zatwierdzenie menedżera nie jest wymagane.
Nie są wymagane podpisy od upoważnionego personelu.
Deskryptory zabezpieczeń na szablonach certyfikatów są zbyt liberalne, co pozwala nisko uprzywilejowanym użytkownikom uzyskać prawa do zapisu.
Szablony certyfikatów są skonfigurowane tak, aby definiować EKU ułatwiające 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ść dołączenia subjectAltName w żądaniu podpisania certyfikatu (CSR) jest dozwolona przez szablon:
Katalog 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, certyfikat można zażądać w celu podszywania się pod dowolnego użytkownika (np. administratora domeny). Czy żądający może określić SAN jest wskazane w obiekcie AD szablonu certyfikatu za pomocą właściwości
mspki-certificate-name-flag. Ta właściwość jest bitem maski, a obecność flagiCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTpozwala na określenie SAN przez żądającego.
Konfiguracja ta pozwala nisko uprzywilejowanym użytkownikom żądać certyfikatów z dowolnym SAN wyborem, umożliwiając uwierzytelnianie jako dowolny podmiot domeny za pośrednictwem Kerberos lub SChannel.
Ta funkcja jest czasami włączana w celu wsparcia generowania certyfikatów HTTPS lub hosta na żywo przez produkty lub usługi wdrożeniowe, lub z powodu braku zrozumienia.
Zauważono, że tworzenie certyfikatu z tą opcją powoduje ostrzeżenie, czego nie ma w przypadku istniejącego szablonu certyfikatu (takiego jak szablon WebServer, który ma włączone CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) jest duplikowany, a następnie zmodyfikowany w celu uwzględnienia OID uwierzytelniania.
Nadużycie
Aby znaleźć podatne szablony certyfikatów, można uruchomić:
Aby wykorzystać tę podatność do podszywania się pod administratora, można uruchomić:
Następnie możesz przekształcić wygenerowany certyfikat do formatu .pfx i ponownie użyć go do uwierzytelniania za pomocą Rubeus lub certipy:
Windows binaries "Certreq.exe" & "Certutil.exe" można użyć do wygenerowania pliku PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Enumeracja szablonów certyfikatów w schemacie konfiguracyjnym lasu AD, szczególnie tych nie wymagających zatwierdzenia ani podpisów, posiadających uwierzytelnianie klienta lub EKU logowania kartą inteligentną oraz z włączoną flagą CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, może być wykonana poprzez uruchomienie następującego zapytania LDAP:
Źle skonfigurowane szablony certyfikatów - ESC2
Wyjaśnienie
Drugi scenariusz nadużycia to wariacja pierwszego:
Uprawnienia do zapisu są przyznawane nisko uprzywilejowanym użytkownikom przez Enterprise CA.
Wymaganie zgody menedżera jest wyłączone.
Pominięto konieczność autoryzowanych podpisów.
Nadmiernie liberalny deskryptor zabezpieczeń na szablonie certyfikatu przyznaje uprawnienia do zapisu certyfikatu nisko uprzywilejowanym użytkownikom.
Szablon certyfikatu jest zdefiniowany tak, aby zawierał dowolny cel EKU lub brak EKU.
Dowolny cel EKU pozwala na uzyskanie certyfikatu przez atakującego do dowolnego celu, w tym uwierzytelniania klienta, uwierzytelniania serwera, podpisywania kodu, itp. Ta sama technika używana w ESC3 może być wykorzystana do wykorzystania tego scenariusza.
Certyfikaty bez EKU, które działają jako certyfikaty podrzędne CA, mogą być wykorzystane do dowolnego celu i mogą również służyć do podpisywania nowych certyfikatów. Dlatego atakujący mógłby określić dowolne EKU lub pola w nowych certyfikatach, korzystając z certyfikatu podrzędnego CA.
Jednakże, nowe certyfikaty utworzone do uwierzytelniania domeny nie będą działać, jeśli certyfikat podrzędny CA nie jest zaufany przez obiekt NTAuthCertificates, co jest ustawieniem domyślnym. Niemniej jednak, atakujący nadal może tworzyć nowe certyfikaty z dowolnym EKU i arbitralnymi wartościami certyfikatu. Mogą one potencjalnie być wykorzystane do szerokiego zakresu celów (np. podpisywania kodu, uwierzytelniania serwera, itp.) i mogą mieć znaczące implikacje dla innych aplikacji w sieci, takich jak SAML, AD FS, czy IPSec.
Aby wyliczyć szablony pasujące do tego scenariusza w schemacie konfiguracji lasu AD, można uruchomić następujące zapytanie LDAP:
Niewłaściwie skonfigurowane szablony agenta zapisu - ESC3
Wyjaśnienie
Ten scenariusz jest podobny do pierwszego i drugiego, ale wykorzystuje inne EKU (Agent żądania certyfikatu) i 2 różne szablony (dlatego ma 2 zestawy wymagań),
Agent żądania certyfikatu EKU (OID 1.3.6.1.4.1.311.20.2.1), znany jako Agent zapisu w dokumentacji firmy Microsoft, umożliwia podmiotowi zapisanie się na certyfikat w imieniu innego użytkownika.
"Agent zapisu" zapisuje się w takim szablonie i używa wynikowego certyfikatu do współpodpisywania CSR w imieniu innego użytkownika. Następnie wysyła współpodpisany CSR do CA, zapisując się w szablonie, który pozwala na "zapisanie się w imieniu", a CA odpowiada certyfikatem należącym do "innego" użytkownika.
Wymagania 1:
Uprawnienia do zapisu są udzielane nisko uprzywilejowanym użytkownikom przez CA przedsiębiorstwa.
Wymóg zgody menedżera jest pominięty.
Brak wymogu podpisów autoryzowanych.
Deskryptor zabezpieczeń szablonu certyfikatu jest nadmiernie przyzwalający, udzielając uprawnień do zapisu nisko uprzywilejowanym użytkownikom.
Szablon certyfikatu zawiera EKU agenta żądania certyfikatu, umożliwiając żądanie innych szablonów certyfikatów w imieniu innych podmiotów.
Wymagania 2:
CA przedsiębiorstwa udziela uprawnień do zapisu nisko uprzywilejowanym użytkownikom.
Zgoda menedżera jest pomijana.
Wersja schematu szablonu to albo 1, albo przekracza 2, i określa Wymaganie wydania zasady aplikacji, które wymaga EKU agenta żądania certyfikatu.
EKU zdefiniowane w szablonie certyfikatu umożliwia uwierzytelnianie domeny.
Ograniczenia dla agentów zapisu nie są stosowane w CA.
Nadużycie
Możesz użyć Certify lub Certipy, aby nadużyć tego scenariusza:
Użytkownicy, którzy mają prawo uzyskać certyfikat agenta enrollment, szablony, w których agenci enrollment mogą się zarejestrować, oraz konta, w imieniu których agent enrollment może działać, mogą być ograniczone przez przedsiębiorstwowe CA. Można to osiągnąć, otwierając certsrc.msc snap-in, klikając prawym przyciskiem myszy na CA, klikając Właściwości, a następnie przechodząc do karty "Agenci Enrollment".
Jednakże zauważono, że domyślne ustawienie dla CA to "Nie ograniczaj agentów enrollment". Gdy administratorzy włączają ograniczenie agentów enrollment, ustawiając je na "Ogranicz agentów enrollment", domyślna konfiguracja pozostaje bardzo liberalna. Pozwala to Wszystkim uzyskać dostęp do zapisu we wszystkich szablonach jako ktokolwiek.
Kontrola dostępu do szablonów certyfikatów podatna na ataki - ESC4
Wyjaśnienie
Deskryptor zabezpieczeń na szablonach certyfikatów określa uprawnienia, jakie posiadają konkretne podmioty AD w odniesieniu do szablonu.
Jeśli atakujący posiada wymagane uprawnienia do zmiany szablonu i wprowadzenia jakichkolwiek wykorzystywanych błędów konfiguracyjnych opisanych w poprzednich sekcjach, ułatwione może być eskalacja uprawnień.
Najważniejsze uprawnienia dotyczące szablonów certyfikatów to:
Właściciel: Zapewnia kontrolę nad obiektem, umożliwiając modyfikację dowolnych atrybutów.
Pełna kontrola: Umożliwia pełną kontrolę nad obiektem, w tym możliwość zmiany dowolnych atrybutów.
Zapisz właściciela: Umożliwia zmianę właściciela obiektu na podmiot znajdujący się pod kontrolą atakującego.
ZapiszDacl: Pozwala na dostosowanie kontroli dostępu, potencjalnie przyznając atakującemu pełną kontrolę.
ZapiszWłaściwość: Uprawnia do edycji dowolnych właściwości obiektu.
Nadużycie
Przykład eskalacji uprawnień podobny do poprzedniego:
ESC4 to sytuacja, gdy użytkownik ma uprawnienia do zapisu w szablonie certyfikatu. Może to być na przykład wykorzystane do nadpisania konfiguracji szablonu certyfikatu, aby uczynić szablon podatnym na ESC1.
Jak widać na powyższej ścieżce, tylko JOHNPC ma te uprawnienia, ale nasz użytkownik JOHN ma nowy krawędź AddKeyCredentialLink do JOHNPC. Ponieważ ta technika dotyczy certyfikatów, zaimplementowałem również ten atak, który jest znany jako Shadow Credentials. Oto mały podgląd polecenia shadow auto z Certipy do pobrania hasha NT ofiary.
Certipy może nadpisać konfigurację szablonu certyfikatu jednym poleceniem. Domyślnie Certipy nadpisze konfigurację, aby uczynić ją podatną na ESC1. Możemy również określić parametr -save-old w celu zapisania starej konfiguracji, co będzie przydatne do przywrócenia konfiguracji po naszym ataku.
Podatny kontrola dostępu do obiektów PKI - ESC5
Wyjaśnienie
Rozległa sieć powiązań oparta na listach kontroli dostępu (ACL), która obejmuje kilka obiektów poza szablonami certyfikatów i urzędem certyfikacyjnym, może wpłynąć na bezpieczeństwo całego systemu AD CS. Te obiekty, które mogą znacząco wpłynąć na bezpieczeństwo, obejmują:
Obiekt komputera AD serwera CA, który może zostać skompromitowany poprzez mechanizmy takie jak S4U2Self lub S4U2Proxy.
Serwer RPC/DCOM serwera CA.
Dowolny obiekt potomny AD lub kontener w określonej ścieżce kontenera
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Ta ścieżka obejmuje, między innymi, kontenery i obiekty takie jak kontener Szablony certyfikatów, kontener Certyfikujące urzędy, obiekt NTAuthCertificates i kontener Usługi zapisywania.
Bezpieczeństwo systemu PKI może zostać naruszone, jeśli nisko uprzywilejowany atakujący zdobędzie kontrolę nad którymkolwiek z tych kluczowych komponentów.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Wyjaśnienie
Temat omawiany w poście Akademii CQure dotyczy również implikacji flagi EDITF_ATTRIBUTESUBJECTALTNAME2, jak to opisano przez firmę Microsoft. Ta konfiguracja, gdy jest aktywowana na Urzędzie Certyfikacji (CA), pozwala na uwzględnienie wartości zdefiniowanych przez użytkownika w alternatywnej nazwie podmiotu dla każdego żądania, w tym tych skonstruowanych z Active Directory®. W rezultacie ta możliwość pozwala intruzowi na zapisanie się poprzez dowolny szablon ustawiony dla uwierzytelniania domeny—szczególnie tych otwartych dla zapisu przez nieuprzywilejowanych użytkowników, takich jak standardowy szablon Użytkownika. W rezultacie certyfikat może być zabezpieczony, umożliwiając intruzowi uwierzytelnienie się jako administrator domeny lub dowolna inna aktywna jednostka w domenie.
Uwaga: Sposób dodawania alternatywnych nazw do Wniosku o Wydanie Certyfikatu (CSR), poprzez argument -attrib "SAN:" w certreq.exe (nazywany „Pary Wartości Nazw”), prezentuje kontrast w porównaniu ze strategią eksploatacji SANów w ESC1. Tutaj różnica polega na enkapsulacji informacji o koncie—w atrybucie certyfikatu, a nie w rozszerzeniu.
Nadużycie
Aby sprawdzić, czy ustawienie jest aktywowane, organizacje mogą skorzystać z następującej komendy z certutil.exe:
Ta operacja wykorzystuje w zasadzie zdalny dostęp do rejestru, dlatego alternatywnym podejściem może być:
Narzędzia takie jak Certify i Certipy potrafią wykryć tę błędną konfigurację i ją wykorzystać:
Aby zmienić te ustawienia, zakładając, że posiada się prawa administratora domeny lub równoważne, można wykonać poniższą komendę z dowolnej stacji roboczej:
Aby wyłączyć tę konfigurację w swoim środowisku, flagę można usunąć za pomocą:
Po aktualizacjach zabezpieczeń z maja 2022 r. nowo wydane certyfikaty będą zawierać rozszerzenie zabezpieczeń, które zawiera właściwość objectSid żądającego. Dla ESC1 SID ten jest pochodną określonego SAN. Jednakże dla ESC6 SID odzwierciedla objectSid żądającego, a nie SAN.
Aby wykorzystać ESC6, konieczne jest, aby system był podatny na ESC10 (Słabe mapowania certyfikatów), które priorytetowo traktuje SAN nad nowym rozszerzeniem zabezpieczeń.
Wrażliwa kontrola dostępu do certyfikatu CA - ESC7
Atak 1
Wyjaśnienie
Kontrola dostępu do certyfikatu CA jest utrzymywana poprzez zestaw uprawnień regulujących działania CA. Te uprawnienia można zobaczyć, przechodząc do certsrv.msc, klikając prawym przyciskiem myszy na CA, wybierając właściwości, a następnie przechodząc do karty Zabezpieczenia. Dodatkowo uprawnienia można wyliczyć, używając modułu PSPKI za pomocą poleceń takich jak:
To zapewnia wgląd w podstawowe uprawnienia, mianowicie ManageCA i ManageCertificates, odpowiadające rolom "administratora CA" i "Menedżera certyfikatów" odpowiednio.
Nadużycie
Posiadanie uprawnień ManageCA w władzy certyfikacji umożliwia podmiotowi zdalne manipulowanie ustawieniami za pomocą PSPKI. Obejmuje to przełączanie flagi EDITF_ATTRIBUTESUBJECTALTNAME2 w celu zezwolenia na określenie SAN w dowolnym szablonie, co stanowi istotny aspekt eskalacji domeny.
Uproszczenie tego procesu jest osiągalne poprzez użycie polecenia Enable-PolicyModuleFlag w PSPKI, umożliwiające modyfikacje bez bezpośredniej interakcji z interfejsem GUI.
Posiadanie uprawnień ManageCertificates ułatwia zatwierdzanie oczekujących żądań, efektywnie omijając zabezpieczenie "zatwierdzenie przez 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 wykorzystano uprawnienia Manage CA do włączenia flagi EDITF_ATTRIBUTESUBJECTALTNAME2 w celu przeprowadzenia ataku ESC6, ale nie będzie on miał żadnego efektu, dopóki usługa CA (CertSvc) nie zostanie zrestartowana. Gdy użytkownik ma prawo dostępu Manage CA, ma również zezwolenie na ponowne uruchomienie usługi. Jednakże nie oznacza to, że użytkownik może zdalnie zrestartować usługę. Ponadto ESC6 może nie działać od razu w większości zaktualizowanych środowisk z powodu aktualizacji zabezpieczeń z maja 2022 roku.
Dlatego tutaj przedstawiony jest kolejny atak.
Wymagania wstępne:
Tylko uprawnienie
ManageCAUprawnienie
Manage Certificates(może być udzielone z uprawnieniaManageCA)Szablon certyfikatu
SubCAmusi być włączony (może być włączony z uprawnieniaManageCA)
Technika polega na tym, że użytkownicy posiadający prawo dostępu Manage CA i Manage Certificates mogą wydawać nieudane żądania certyfikatów. Szablon certyfikatu SubCA jest podatny na ESC1, ale tylko administratorzy mogą zapisać się do szablonu. Dlatego użytkownik może złożyć wniosek o zapisanie się do SubCA - który zostanie odrzucony - ale następnie zostanie wydany przez menedżera.
Nadużycie
Możesz przyznać sobie uprawnienie Manage Certificates dodając swojego użytkownika jako nowego oficera.
Szablon SubCA można włączyć na CA za pomocą parametru -enable-template. Domyślnie szablon SubCA jest włączony.
Jeśli spełniliśmy wymagane warunki dla tego ataku, możemy rozpocząć od żądania certyfikatu opartego na szablonie SubCA.
To żądanie zostanie odrzucone, ale zachowamy klucz prywatny i zapiszemy identyfikator żądania.
Z naszymi Zarządzaj CA i Zarządzaj Certyfikatami, możemy następnie wydać nieudany certyfikat żądanie za pomocą polecenia ca i parametru -issue-request <ID żądania>.
I wreszcie możemy pobrać wydany certyfikat za pomocą polecenia req i parametru -retrieve <request ID>.
Przekazywanie NTLM do punktów końcowych HTTP AD CS – ESC8
Wyjaśnienie
W środowiskach, w których zainstalowano AD CS, jeśli istnieje podatny punkt końcowy do zapisu w sieci Web i co najmniej jeden szablon certyfikatu jest opublikowany, który pozwala na zapis komputera domenowego i uwierzytelnianie klienta (tak jak domyślny szablon Machine), staje się możliwe, że dowolny komputer z aktywną usługą spoolera może zostać skompromitowany przez atakującego!
AD CS obsługuje kilka metod zapisu opartych na protokole HTTP, udostępnianych poprzez dodatkowe role serwera, które administratorzy mogą zainstalować. Te interfejsy do zapisu certyfikatów opartych na protokole HTTP są podatne na ataki przekazywania NTLM. Atakujący z skompromitowanego komputera może podszyć się pod dowolne konto AD, które uwierzytelnia się za pomocą przychodzącego NTLM. Podszywając się pod konto ofiary, atakujący może uzyskać dostęp do tych interfejsów sieci Web, aby żądać certyfikatu uwierzytelniania klienta, korzystając z szablonów certyfikatów User lub Machine.
Interfejs zapisu sieci Web (starsza aplikacja ASP dostępna pod adresem
http://<caserver>/certsrv/), domyślnie obsługuje tylko protokół HTTP, który nie zapewnia ochrony przed atakami przekazywania NTLM. Dodatkowo, wyraźnie zezwala tylko na uwierzytelnianie NTLM za pomocą nagłówka HTTP Authorization, co uniemożliwia stosowanie bardziej bezpiecznych metod uwierzytelniania, takich jak Kerberos.Usługa Zapisu Certyfikatów (CES), Usługa Sieci Web Polityki Zapisu Certyfikatów (CEP) i Usługa Zapisu Urządzeń Sieciowych (NDES) domyślnie obsługują uwierzytelnianie negocjowane za pomocą nagłówka HTTP Authorization. Uwierzytelnianie negocjowane obsługuje zarówno Kerberos, jak i NTLM, pozwalając atakującemu zmniejszyć poziom uwierzytelniania do NTLM podczas ataków przekazywania. Chociaż te usługi sieci Web domyślnie obsługują protokół HTTPS, samo HTTPS nie chroni przed atakami przekazywania NTLM. Ochrona przed atakami przekazywania NTLM dla usług HTTPS jest możliwa tylko wtedy, gdy HTTPS jest łączone z powiązaniem kanału. Niestety AD CS nie aktywuje Rozszerzonej Ochrony dla Uwierzytelniania w IIS, co jest wymagane do powiązania kanału.
Powszechnym problemem z atakami przekazywania NTLM jest krótki czas trwania sesji NTLM i niemożność atakującego interakcji z usługami, które wymagają podpisu NTLM.
Niemniej jednak, to ograniczenie jest pokonywane poprzez wykorzystanie ataku przekazywania NTLM do uzyskania certyfikatu dla użytkownika, ponieważ okres ważności certyfikatu określa czas trwania sesji, a certyfikat może być używany z usługami, które wymagają podpisu NTLM. Aby uzyskać instrukcje dotyczące wykorzystania skradzionego certyfikatu, zapoznaj się z:
pageAD CS Account PersistenceKolejnym ograniczeniem ataków przekazywania NTLM jest to, że maszyna kontrolowana przez atakującego musi zostać uwierzytelniona przez konto ofiary. Atakujący może albo czekać, albo próbować wymusić to uwierzytelnienie:
pageForce NTLM Privileged AuthenticationWykorzystanie
Certify’s cas wylicza włączone punkty końcowe AD CS protokołu HTTP:
Właściwość msPKI-Enrollment-Servers jest używana przez przedsiębiorstwowe władze certyfikujące (CAs) do przechowywania punktów końcowych Usługi Enrollingu Certyfikatów (CES). Te punkty końcowe mogą być analizowane i wyświetlane za pomocą narzędzia Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Nadużycie z certyfikatem
Wykorzystanie Certipy
Żądanie certyfikatu jest domyślnie wykonywane przez Certipy na podstawie szablonu Machine lub User, określonego na podstawie tego, czy nazwa konta kończy się na $. Określenie alternatywnego szablonu można osiągnąć poprzez użycie parametru -template.
Technika taka jak PetitPotam może być następnie wykorzystana do wymuszenia uwierzytelnienia. Przy pracy z kontrolerami domeny, konieczne jest określenie -template DomainController.
Brak rozszerzenia zabezpieczeń - ESC9
Wyjaśnienie
Nowa wartość CT_FLAG_NO_SECURITY_EXTENSION (0x80000) dla msPKI-Enrollment-Flag, oznaczana jako ESC9, zapobiega osadzaniu nowego rozszerzenia zabezpieczeń szOID_NTDS_CA_SECURITY_EXT w certyfikacie. Ta flaga staje się istotna, gdy StrongCertificateBindingEnforcement jest ustawione na 1 (domyślne ustawienie), w przeciwieństwie do ustawienia 2. Jej znaczenie wzrasta w scenariuszach, gdzie słabsze odwzorowanie certyfikatu dla Kerberos lub Schannel może być wykorzystane (jak w ESC10), ponieważ brak ESC9 nie zmieniłby wymagań.
Warunki, w których ustawienie tej flagi staje się istotne, obejmują:
StrongCertificateBindingEnforcementnie jest dostosowane do2(gdzie domyślnie jest to1), lubCertificateMappingMethodszawiera flagęUPN.Certyfikat jest oznaczony flagą
CT_FLAG_NO_SECURITY_EXTENSIONw ustawieniumsPKI-Enrollment-Flag.Certyfikat określa dowolne EKU uwierzytelniania klienta.
Dostępne są uprawnienia
GenericWritedo kompromitacji innego konta.
Scenariusz nadużycia
Załóżmy, że John@corp.local posiada uprawnienia GenericWrite nad Jane@corp.local, z celem skompromitowania Administrator@corp.local. Szablon certyfikatu ESC9, do którego Jane@corp.local ma prawo zapisu, jest skonfigurowany z flagą CT_FLAG_NO_SECURITY_EXTENSION w ustawieniu msPKI-Enrollment-Flag.
Początkowo, skrót Jane jest pozyskiwany za pomocą Cieniowych Poświadczeń, dzięki uprawnieniom GenericWrite Johna:
Następnie userPrincipalName użytkownika Jane zostaje zmodyfikowany na Administrator, celowo pomijając część domeny @corp.local:
Ta modyfikacja nie narusza ograniczeń, pod warunkiem, że Administrator@corp.local pozostaje odrębny jako userPrincipalName Administratora.
W związku z tym szablon certyfikatu ESC9, oznaczony jako podatny, jest żądany jako Jane:
Zauważono, że atrybut userPrincipalName certyfikatu odzwierciedla Administrator, pozbawiony jakiegokolwiek „object SID”.
Następnie userPrincipalName Jane zostaje przywrócone do jej pierwotnego, czyli Jane@corp.local:
Próba uwierzytelnienia za pomocą wydanego certyfikatu teraz zwraca wartość skrótu NT Administrator@corp.local. Polecenie musi zawierać -domain <domain>, ze względu na brak specyfikacji domeny w certyfikacie:
Słabe odwzorowania certyfikatów - ESC10
Wyjaśnienie
Dwa wartości klucza rejestru na kontrolerze domeny są odnoszone przez ESC10:
Wartość domyślna dla
CertificateMappingMethodspodHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannelto0x18(0x8 | 0x10), wcześniej ustawiona na0x1F.Domyślne ustawienie dla
StrongCertificateBindingEnforcementpodHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdcto1, 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 nad Jane@corp.local, atakujący ma na celu skompromitowanie Administrator@corp.local. Procedura jest podobna do ESC9, pozwalając na wykorzystanie dowolnego szablonu certyfikatu.
Początkowo, skrót Jane jest pozyskiwany za pomocą Cieniowych Poświadczeń, wykorzystując GenericWrite.
Następnie userPrincipalName Jane zostaje zmienione na Administrator, celowo pomijając część @corp.local, aby uniknąć naruszenia ograniczeń.
Następnie żądany jest certyfikat umożliwiający uwierzytelnianie klienta jako Jane, korzystając z domyślnego szablonu User.
userPrincipalName użytkownika Jane jest następnie przywrócone do pierwotnego Jane@corp.local.
Autoryzacja za pomocą uzyskanego certyfikatu ujawni wartość skrótu NT dla Administrator@corp.local, co wymaga określenia domeny w poleceniu z powodu braku szczegółów domeny w certyfikacie.
Przypadek nadużycia 2
Dzięki CertificateMappingMethods zawierającemu flagę UPN (0x4), konto A posiadające uprawnienia GenericWrite może skompromitować dowolne konto B, które nie ma właściwości userPrincipalName, w tym konta maszynowe i wbudowanego administratora domeny Administrator.
Celem jest skompromitowanie DC$@corp.local, zaczynając od uzyskania hasha Jane poprzez Shadow Credentials, wykorzystując GenericWrite.
userPrincipalName Jane jest następnie ustawione na DC$@corp.local.
Wniosek o certyfikat do uwierzytelniania klienta jest składany jako Jane przy użyciu domyślnego szablonu User.
userPrincipalName użytkownika Jane jest przywracane do swojej pierwotnej postaci po tym procesie.
Aby uwierzytelnić się za pomocą Schannel, wykorzystywana jest opcja -ldap-shell z programu Certipy, co wskazuje na sukces uwierzytelnienia jako u:CORP\DC$.
Za pomocą powłoki LDAP polecenia takie jak set_rbcd umożliwiają ataki oparte na zleceniach zasobów (RBCD), potencjalnie kompromitując kontroler domeny.
Ta podatność dotyczy również każdego konta użytkownika, które nie ma userPrincipalName lub w którym nie pasuje on do sAMAccountName, przy czym domyślny Administrator@corp.local jest głównym celem ze względu na swoje podwyższone uprawnienia LDAP i brak domyślnego userPrincipalName.
Przekazywanie NTLM do ICPR - ESC11
Wyjaśnienie
Jeśli serwer CA nie jest skonfigurowany z IF_ENFORCEENCRYPTICERTREQUEST, ataki przekazywania NTLM mogą być wykonywane bez podpisywania za pośrednictwem usługi RPC. Odniesienie tutaj.
Możesz użyć certipy, aby sprawdzić, czy Wymuś Szyfrowanie dla Żądań jest wyłączone, a certipy pokaże podatności ESC11.
Schemat nadużycia
Należy skonfigurować serwer przekazywania:
Wskazówka: Dla kontrolerów domeny musimy określić -template w DomainController.
Lub używając forka impacket autorstwa sploutchy'ego:
Dostęp do powłoki ADCS CA z YubiHSM - ESC12
Wyjaśnienie
Administratorzy mogą skonfigurować Certyfikat Uprawnień w celu przechowywania go na zewnętrznym urządzeniu, takim jak "Yubico YubiHSM2".
Jeśli urządzenie USB jest podłączone do serwera CA za pośrednictwem portu USB, lub serwer urządzeń USB w przypadku, gdy serwer CA jest maszyną wirtualną, wymagany jest klucz uwierzytelniający (czasami nazywany "hasłem") dla dostawcy przechowywania kluczy w celu generowania i wykorzystywania kluczy w YubiHSM.
To hasło/klucz jest przechowywane w rejestrze pod HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword w postaci zwykłego tekstu.
Odniesienie tutaj.
Scenariusz nadużycia
Jeśli prywatny klucz CA jest przechowywany na fizycznym urządzeniu USB, gdy uzyskasz dostęp do powłoki, istnieje możliwość odzyskania klucza.
Po pierwsze, musisz uzyskać certyfikat CA (jest to publiczne) a następnie:
Nadużycie łącza grup OID - ESC13
Wyjaśnienie
Atrybut msPKI-Certificate-Policy pozwala na dodanie polityki wydawania do szablonu certyfikatu. Obiekty msPKI-Enterprise-Oid, które są odpowiedzialne za wydawanie polityk, można odkryć w Kontekście Nazw Konfiguracji (CN=OID,CN=Public Key Services,CN=Services) kontenera OID PKI. Polityka może być powiązana z grupą AD za pomocą atrybutu msDS-OIDToGroupLink tego obiektu, umożliwiając systemowi autoryzację użytkownika, który przedstawia certyfikat, jak gdyby był członkiem grupy. Odniesienie tutaj.
Innymi słowy, gdy użytkownik ma uprawnienie do zapisania certyfikatu i certyfikat jest powiązany z grupą OID, użytkownik może odziedziczyć uprawnienia tej grupy.
Użyj Check-ADCSESC13.ps1, aby znaleźć OIDToGroupLink:
Scenariusz nadużycia
Znajdź uprawnienie użytkownika, które może użyć certipy find lub Certify.exe find /showAllPermissions.
Jeśli John ma uprawnienie do zapisywania w VulnerableTemplate, użytkownik może odziedziczyć uprawnienia grupy VulnerableGroup.
Wszystko, co musi zrobić, to określić szablon, a otrzyma certyfikat z uprawnieniami OIDToGroupLink.
Kompromitowanie Lasów za pomocą Certyfikatów Wyjaśnione w stronie biernej
Łamanie Zaufania Lasów przez Skompromitowane CA
Konfiguracja enrollmentu między lasami jest stosunkowo prosta. Certyfikat root CA z lasu zasobów jest opublikowany w lasach kont przez administratorów, a certyfikaty enterprise CA z lasu zasobów są dodane do kontenerów NTAuthCertificates i AIA w każdym z lasów kont. Dla jasności, ta konfiguracja nadaje CA w lesie zasobów pełną kontrolę nad wszystkimi innymi lasami, którymi zarządza PKI. Jeśli ten CA zostanie skompromitowany przez atakujących, certyfikaty dla wszystkich użytkowników zarówno z lasu zasobów, jak i z lasów kont mogą być podrabiane przez nich, co prowadzi do złamania granicy bezpieczeństwa lasu.
Przyznawanie Uprawnień do Enrollmentu Obcym Podmiotom
W środowiskach wielolasowych należy ostrożnie podchodzić do Enterprise CA, które publikują szablony certyfikatów, które pozwalają Użytkownikom uwierzytelnionym lub obcym podmiotom (użytkownikom/grupom spoza lasu, do którego należy Enterprise CA) na prawa do enrollmentu i edycji. Podczas uwierzytelniania przez zaufanie, SID Użytkowników uwierzytelnionych jest dodawany do tokena użytkownika przez AD. Dlatego jeśli domena posiada Enterprise CA z szablonem, który pozwala Użytkownikom uwierzytelnionym na prawa do enrollmentu, szablon mógłby potencjalnie być zainstalowany przez użytkownika z innego lasu. Podobnie, jeśli prawa do enrollmentu są wyraźnie przyznane obcemu podmiotowi przez szablon, w ten sposób tworzony jest związek kontroli dostępu między lasami, umożliwiający podmiotowi z jednego lasu zainstalowanie szablonu 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.
Last updated
