AD CS Domain Escalation
Dies ist eine Zusammenfassung der Eskalationstechnikabschnitte der Beiträge:
Fehlkonfigurierte Zertifikatvorlagen - ESC1
Erklärung
Fehlkonfigurierte Zertifikatvorlagen - ESC1 Erklärt
Anmeldeberechtigungen werden von der Enterprise-CA an Benutzer mit niedrigen Berechtigungen erteilt.
Managergenehmigung ist nicht erforderlich.
Es sind keine Signaturen von autorisiertem Personal erforderlich.
Sicherheitsdeskriptoren auf Zertifikatvorlagen sind übermäßig freizügig, was Benutzern mit niedrigen Berechtigungen ermöglicht, Anmeldeberechtigungen zu erhalten.
Zertifikatvorlagen sind so konfiguriert, dass sie EKUs definieren, die die Authentifizierung erleichtern:
Erweiterte Schlüsselverwendung (EKU)-Bezeichner wie Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2), PKINIT-Client-Authentifizierung (1.3.6.1.5.2.3.4), Smartcard-Login (OID 1.3.6.1.4.1.311.20.2.2), Jeder Zweck (OID 2.5.29.37.0) oder keine EKU (SubCA) sind enthalten.
Die Möglichkeit für Antragsteller, einen subjectAltName im Zertifikatanforderung (CSR) einzuschließen, ist durch die Vorlage erlaubt:
Das Active Directory (AD) priorisiert den subjectAltName (SAN) in einem Zertifikat zur Identitätsüberprüfung, wenn er vorhanden ist. Dies bedeutet, dass durch Angabe des SAN in einem CSR ein Zertifikat angefordert werden kann, um sich als beliebiger Benutzer (z. B. ein Domänenadministrator) auszugeben. Ob ein SAN vom Antragsteller angegeben werden kann, wird im AD-Objekt der Zertifikatvorlage durch die Eigenschaft
mspki-certificate-name-flagangezeigt. Diese Eigenschaft ist ein Bitmask und das Vorhandensein des FlagsCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTermöglicht die Angabe des SAN durch den Antragsteller.
Die beschriebene Konfiguration ermöglicht es Benutzern mit niedrigen Berechtigungen, Zertifikate mit einem beliebigen SAN ihrer Wahl anzufordern, was die Authentifizierung als beliebigen Domänenprinzipal über Kerberos oder SChannel ermöglicht.
Diese Funktion wird manchmal aktiviert, um die Echtzeitgenerierung von HTTPS- oder Hostzertifikaten durch Produkte oder Bereitstellungsdienste zu unterstützen oder aufgrund eines Mangels an Verständnis.
Es wird darauf hingewiesen, dass das Erstellen eines Zertifikats mit dieser Option eine Warnung auslöst, was nicht der Fall ist, wenn eine vorhandene Zertifikatvorlage (wie die WebServer-Vorlage, bei der CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT aktiviert ist) dupliziert und dann modifiziert wird, um eine Authentifizierungs-OID einzuschließen.
Missbrauch
Um anfällige Zertifikatvorlagen zu finden, können Sie ausführen:
Um diese Schwachstelle zu missbrauchen und sich als Administrator auszugeben, könnte man Folgendes ausführen:
Dann können Sie das generierte Zertifikat in das Format .pfx umwandeln und es erneut zur Authentifizierung mit Rubeus oder certipy verwenden:
Die Windows-Binärdateien "Certreq.exe" & "Certutil.exe" können verwendet werden, um das PFX zu generieren: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Die Auflistung von Zertifikatvorlagen im Konfigurationsschema des AD-Forest, insbesondere solche, die keine Genehmigung oder Signaturen erfordern, die über eine Client-Authentifizierung oder Smart-Card-Login EKU verfügen und bei denen die CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT-Flag aktiviert ist, kann durch Ausführen der folgenden LDAP-Abfrage durchgeführt werden:
Fehlkonfigurierte Zertifikatvorlagen - ESC2
Erklärung
Das zweite Missbrauchsszenario ist eine Variation des ersten:
Anmeldeberechtigungen werden von der Enterprise-CA an Benutzer mit niedrigen Berechtigungen erteilt.
Die Anforderung an die Genehmigung durch den Manager ist deaktiviert.
Die Notwendigkeit von autorisierten Signaturen wird ausgelassen.
Ein übermäßig freigebiger Sicherheitsdeskriptor auf der Zertifikatvorlage gewährt Benutzern mit niedrigen Berechtigungen Zertifikatsanmeldeberechtigungen.
Die Zertifikatvorlage ist definiert, um das EKU für jeden Zweck oder kein EKU einzuschließen.
Das EKU für jeden Zweck erlaubt es einem Angreifer, ein Zertifikat für jeden Zweck zu erhalten, einschließlich der Client-Authentifizierung, Server-Authentifizierung, Code-Signierung usw. Die gleiche Technik wie bei ESC3 kann verwendet werden, um dieses Szenario auszunutzen.
Zertifikate ohne EKUs, die als untergeordnete CA-Zertifikate fungieren, können für jeden Zweck ausgenutzt werden und können auch verwendet werden, um neue Zertifikate zu signieren. Daher könnte ein Angreifer beliebige EKUs oder Felder in den neuen Zertifikaten angeben, indem er ein untergeordnetes CA-Zertifikat verwendet.
Jedoch werden neue Zertifikate, die für die Domänenauthentifizierung erstellt wurden, nicht funktionieren, wenn die untergeordnete CA nicht vom Objekt NTAuthCertificates vertraut wird, was die Standardeinstellung ist. Dennoch kann ein Angreifer weiterhin neue Zertifikate mit beliebigen EKUs und beliebigen Zertifikatswerten erstellen. Diese könnten potenziell für eine Vielzahl von Zwecken missbraucht werden (z. B. Code-Signierung, Server-Authentifizierung usw.) und könnten erhebliche Auswirkungen auf andere Anwendungen im Netzwerk wie SAML, AD FS oder IPSec haben.
Um Vorlagen zu enumerieren, die dieses Szenario im Konfigurationsschema des AD-Forest entsprechen, kann die folgende LDAP-Abfrage ausgeführt werden:
Fehlkonfigurierte Antragsteller-Vorlagen - ESC3
Erklärung
Dieses Szenario ähnelt dem ersten und zweiten, missbraucht jedoch ein anderes EKU (Zertifikatsanforderungs-Agent) und 2 verschiedene Vorlagen (daher hat es 2 Sätze von Anforderungen).
Das Zertifikatsanforderungs-Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), bekannt als Enrollment Agent in der Microsoft-Dokumentation, ermöglicht es einem Prinzipal, sich im Namen eines anderen Benutzers für ein Zertifikat anzumelden.
Der "Enrollment Agent" meldet sich in einer solchen Vorlage an und verwendet das resultierende Zertifikat, um im Namen des anderen Benutzers eine CSR mitzuunterschreiben. Anschließend sendet er die mitunterschriebene CSR an die CA, meldet sich in einer Vorlage an, die "Anmelden im Namen von" erlaubt, und die CA antwortet mit einem Zertifikat, das dem "anderen" Benutzer gehört.
Anforderungen 1:
Anmeldeberechtigungen werden von der Enterprise-CA an Benutzer mit niedrigen Rechten vergeben.
Die Anforderung für die Genehmigung durch den Manager wird ausgelassen.
Keine Anforderung für autorisierte Signaturen.
Der Sicherheitsdeskriptor der Zertifikatsvorlage ist übermäßig freizügig und gewährt Anmeldeberechtigungen an Benutzer mit niedrigen Rechten.
Die Zertifikatsvorlage enthält das Zertifikatsanforderungs-Agent EKU, was die Anforderung anderer Zertifikatsvorlagen im Namen anderer Prinzipale ermöglicht.
Anforderungen 2:
Die Enterprise-CA gewährt Anmeldeberechtigungen an Benutzer mit niedrigen Rechten.
Die Genehmigung durch den Manager wird umgangen.
Die Schemaversion der Vorlage ist entweder 1 oder überschreitet 2 und gibt eine Anwendungsrichtlinien-Ausgabeanforderung an, die das Zertifikatsanforderungs-Agent EKU erfordert.
Ein im Zertifikatsvorlage definiertes EKU ermöglicht die Domänenauthentifizierung.
Einschränkungen für Antragsteller werden auf der CA nicht angewendet.
Missbrauch
Sie können Certify oder Certipy verwenden, um dieses Szenario zu missbrauchen:
Die Benutzer, die berechtigt sind, ein Antragstellerzertifikat zu erhalten, die Vorlagen, in denen Antragsteller zur Anmeldung berechtigt sind, und die Konten, für die der Antragsteller handeln darf, können von Unternehmens-CAs eingeschränkt werden. Dies wird erreicht, indem das certsrc.msc Snap-In geöffnet, mit der rechten Maustaste auf die CA geklickt und dann zu dem Tab "Antragsteller zur Anmeldung" navigiert wird.
Es ist jedoch zu beachten, dass die Standardeinstellung für CAs "Antragsteller zur Anmeldung nicht einschränken" ist. Wenn die Einschränkung für Antragsteller zur Anmeldung von Administratoren aktiviert wird, bleibt die Standardkonfiguration äußerst freizügig. Sie erlaubt Jedermann den Zugriff auf alle Vorlagen zur Anmeldung als jeder.
Anfällige Zugriffssteuerung für Zertifikatsvorlagen - ESC4
Erklärung
Der Sicherheitsdeskriptor auf Zertifikatsvorlagen definiert die Berechtigungen, die bestimmte AD-Prinzipale bezüglich der Vorlage besitzen.
Sollte ein Angreifer die erforderlichen Berechtigungen besitzen, um eine Vorlage zu ändern und ausnutzbare Fehlkonfigurationen aus vorherigen Abschnitten einzurichten, könnte eine Privilegieneskalation ermöglicht werden.
Bemerkenswerte Berechtigungen, die auf Zertifikatsvorlagen anwendbar sind, umfassen:
Besitzer: Gewährt implizite Kontrolle über das Objekt und ermöglicht die Änderung beliebiger Attribute.
Vollzugriff: Ermöglicht vollständige Autorität über das Objekt, einschließlich der Fähigkeit, beliebige Attribute zu ändern.
WriteOwner: Erlaubt die Änderung des Besitzers des Objekts zu einem Prinzipal unter der Kontrolle des Angreifers.
WriteDacl: Ermöglicht die Anpassung von Zugriffssteuerungen und gewährt möglicherweise einem Angreifer Vollzugriff.
WriteProperty: Autorisiert die Bearbeitung beliebiger Objekteigenschaften.
Missbrauch
Ein Beispiel für eine Privilegieneskalation wie die vorherige:
ESC4 tritt auf, wenn ein Benutzer Schreibberechtigungen für eine Zertifikatsvorlage hat. Dies kann beispielsweise missbraucht werden, um die Konfiguration der Zertifikatsvorlage zu überschreiben und die Vorlage anfällig für ESC1 zu machen.
Wie wir im obigen Pfad sehen können, hat nur JOHNPC diese Berechtigungen, aber unser Benutzer JOHN hat den neuen AddKeyCredentialLink-Zugriff auf JOHNPC. Da diese Technik mit Zertifikaten zusammenhängt, habe ich diesen Angriff ebenfalls implementiert, der als Shadow Credentials bekannt ist. Hier ist ein kleiner Einblick in den shadow auto-Befehl von Certipy, um den NT-Hash des Opfers abzurufen.
Certipy kann die Konfiguration einer Zertifikatvorlage mit einem einzigen Befehl überschreiben. Standardmäßig wird Certipy die Konfiguration überschreiben, um sie anfällig für ESC1 zu machen. Wir können auch den -save-old-Parameter angeben, um die alte Konfiguration zu speichern, was nützlich sein wird, um die Konfiguration nach unserem Angriff wiederherzustellen.
Anfällige PKI-Objektzugriffskontrolle - ESC5
Erklärung
Das umfangreiche Netzwerk von miteinander verbundenen ACL-basierten Beziehungen, das neben Zertifikatvorlagen und der Zertifizierungsstelle mehrere Objekte umfasst, kann die Sicherheit des gesamten AD CS-Systems beeinträchtigen. Diese Objekte, die die Sicherheit erheblich beeinflussen können, umfassen:
Das AD-Computerobjekt des CA-Servers, das durch Mechanismen wie S4U2Self oder S4U2Proxy kompromittiert werden kann.
Der RPC/DCOM-Server des CA-Servers.
Jedes nachgeordnete AD-Objekt oder Container innerhalb des spezifischen Containerpfads
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Dieser Pfad umfasst unter anderem Container und Objekte wie den Zertifikatvorlagen-Container, den Zertifizierungsstellen-Container, das NTAuthCertificates-Objekt und den Container für Anmeldedienste.
Die Sicherheit des PKI-Systems kann gefährdet sein, wenn ein wenig privilegierter Angreifer die Kontrolle über eine dieser kritischen Komponenten erlangt.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Erklärung
Das im CQure Academy-Beitrag behandelte Thema berührt auch die Auswirkungen der Flagge EDITF_ATTRIBUTESUBJECTALTNAME2, wie von Microsoft dargelegt. Diese Konfiguration, wenn sie auf einer Zertifizierungsstelle (CA) aktiviert ist, ermöglicht die Aufnahme von benutzerdefinierten Werten im alternativen Subjektnamen für jede Anforderung, einschließlich derer, die aus Active Directory® erstellt wurden. Folglich ermöglicht diese Bestimmung einem Eindringling, sich über eine beliebige Vorlage für die Domänenauthentifizierung zu registrieren - insbesondere solche, die für die Registrierung von nicht privilegierten Benutzern offen sind, wie die Standardbenutzervorlage. Dadurch kann ein Zertifikat gesichert werden, das es dem Eindringling ermöglicht, sich als Domänenadministrator oder eine andere aktive Entität innerhalb der Domäne zu authentifizieren.
Hinweis: Der Ansatz zum Anhängen von alternativen Namen zu einem Zertifikatanforderung (CSR) durch das Argument -attrib "SAN:" in certreq.exe (bezeichnet als "Name-Wert-Paare") stellt einen Kontrast zur Ausnutzungsstrategie von SANs in ESC1 dar. Hier liegt der Unterschied darin, wie Kontoinformationen eingekapselt sind - innerhalb eines Zertifikatsattributs anstelle einer Erweiterung.
Missbrauch
Um zu überprüfen, ob die Einstellung aktiviert ist, können Organisationen den folgenden Befehl mit certutil.exe verwenden:
Diese Operation nutzt im Wesentlichen den Zugriff auf die Remote-Registrierung, daher könnte ein alternativer Ansatz sein:
Tools wie Certify und Certipy sind in der Lage, diese Fehlkonfiguration zu erkennen und auszunutzen:
Um diese Einstellungen zu ändern, vorausgesetzt man besitzt Domänenadministrationsrechte oder äquivalente Rechte, kann der folgende Befehl von jedem Arbeitsplatz aus ausgeführt werden:
Um diese Konfiguration in Ihrer Umgebung zu deaktivieren, kann die Flagge mit dem folgenden Befehl entfernt werden:
Nach den Sicherheitsupdates im Mai 2022 enthalten neu ausgestellte Zertifikate eine Sicherheitserweiterung, die die objectSid-Eigenschaft des Anforderers integriert. Für ESC1 wird diese SID aus dem angegebenen SAN abgeleitet. Für ESC6 spiegelt die SID jedoch die objectSid des Anforderers wider, nicht das SAN.
Um ESC6 auszunutzen, ist es entscheidend, dass das System anfällig für ESC10 (Schwache Zertifikat-Zuordnungen) ist, das den SAN über die neue Sicherheitserweiterung priorisiert.
Anfällige Zugriffskontrolle für Zertifizierungsstellen - ESC7
Angriff 1
Erklärung
Der Zugriff auf eine Zertifizierungsstelle wird durch eine Reihe von Berechtigungen geregelt, die CA-Aktionen steuern. Diese Berechtigungen können eingesehen werden, indem Sie auf certsrv.msc zugreifen, mit der rechten Maustaste auf eine CA klicken, Eigenschaften auswählen und dann zum Sicherheits-Tab navigieren. Darüber hinaus können Berechtigungen mithilfe des PSPKI-Moduls mit Befehlen wie folgt aufgelistet werden:
Dies bietet Einblicke in die primären Rechte, nämlich ManageCA und ManageCertificates, die den Rollen "CA-Administrator" bzw. "Zertifikatsmanager" entsprechen.
Missbrauch
Das Vorhandensein von ManageCA-Rechten bei einer Zertifizierungsstelle ermöglicht es dem Prinzipal, Einstellungen remote über PSPKI zu manipulieren. Dies umfasst das Umschalten des Flags EDITF_ATTRIBUTESUBJECTALTNAME2, um die SAN-Spezifikation in jedem Template zu ermöglichen, ein entscheidender Aspekt der Domänenescalation.
Die Vereinfachung dieses Prozesses ist durch die Verwendung des Cmdlets Enable-PolicyModuleFlag von PSPKI möglich, was Modifikationen ohne direkte GUI-Interaktion erlaubt.
Der Besitz von ManageCertificates-Rechten erleichtert die Genehmigung ausstehender Anfragen und umgeht effektiv die Sicherheitsvorkehrung "Genehmigung durch den CA-Zertifikatsmanager".
Eine Kombination der Module Certify und PSPKI kann genutzt werden, um ein Zertifikat anzufordern, zu genehmigen und herunterzuladen:
Angriff 2
Erklärung
Im vorherigen Angriff wurden die Berechtigungen Manage CA verwendet, um die EDITF_ATTRIBUTESUBJECTALTNAME2-Flagge zu aktivieren und den ESC6-Angriff durchzuführen, jedoch wird dies keine Auswirkungen haben, bis der CA-Dienst (CertSvc) neu gestartet wird. Wenn ein Benutzer das Zugriffsrecht Manage CA hat, darf der Benutzer auch den Dienst neu starten. Dies bedeutet jedoch nicht, dass der Benutzer den Dienst aus der Ferne neu starten kann. Darüber hinaus funktioniert ESC6 in den meisten gepatchten Umgebungen aufgrund der Sicherheitsupdates vom Mai 2022 möglicherweise nicht sofort.
Daher wird hier ein weiterer Angriff vorgestellt.
Voraussetzungen:
Nur
ManageCA-BerechtigungManage Certificates-Berechtigung (kann vonManageCAgewährt werden)Zertifikatvorlage
SubCAmuss aktiviert sein (kann vonManageCAaktiviert werden)
Die Technik beruht darauf, dass Benutzer mit dem Zugriffsrecht Manage CA und Manage Certificates das Recht haben, fehlgeschlagene Zertifikatsanfragen auszustellen. Die Zertifikatvorlage SubCA ist anfällig für ESC1, aber nur Administratoren können sich in der Vorlage einschreiben. Somit kann ein Benutzer beantragen, sich in der SubCA einzuschreiben - was abgelehnt wird - aber dann vom Manager ausgestellt wird.
Missbrauch
Sie können sich das Zugriffsrecht Manage Certificates gewähren, indem Sie Ihren Benutzer als neuen Offizier hinzufügen.
Die SubCA Vorlage kann mit dem -enable-template Parameter auf dem CA aktiviert werden. Standardmäßig ist die SubCA Vorlage aktiviert.
Wenn wir die Voraussetzungen für diesen Angriff erfüllt haben, können wir damit beginnen, ein Zertifikat basierend auf der SubCA-Vorlage anzufordern.
Dieser Antrag wird abgelehnt, aber wir werden den privaten Schlüssel speichern und die Anfrage-ID notieren.
Mit unserem Manage CA und Manage Certificates können wir dann den fehlgeschlagenen Zertifikatsantrag mit dem ca Befehl und dem -issue-request <Anforderungs-ID> Parameter ausstellen.
Und schließlich können wir das ausgestellte Zertifikat abrufen mit dem req Befehl und dem -retrieve <Anforderungs-ID> Parameter.
NTLM-Relais zu AD CS HTTP-Endpunkten – ESC8
Erklärung
In Umgebungen, in denen AD CS installiert ist, besteht die Möglichkeit, dass ein Web-Registrierungsendpunkt verwundbar ist und mindestens eine Zertifikatvorlage veröffentlicht ist, die die Registrierung von Domänencomputern und die Clientauthentifizierung zulässt (wie z.B. die Standardvorlage Machine), dass jeder Computer mit aktivem Spooler-Dienst von einem Angreifer kompromittiert werden kann!
AD CS unterstützt mehrere HTTP-basierte Registrierungsmethoden, die über zusätzliche Serverrollen verfügbar sind, die Administratoren installieren können. Diese Schnittstellen für die HTTP-basierte Zertifikatsregistrierung sind anfällig für NTLM-Relaisangriffe. Ein Angreifer kann von einer kompromittierten Maschine aus jede AD-Konto nachahmen, das über eingehendes NTLM authentifiziert ist. Während er das Opferkonto nachahmt, können diese Webschnittstellen von einem Angreifer genutzt werden, um ein Clientauthentifizierungszertifikat unter Verwendung der Zertifikatvorlagen User oder Machine anzufordern.
Die Web-Registrierungsschnittstelle (eine ältere ASP-Anwendung, die unter
http://<caserver>/certsrv/verfügbar ist), ist standardmäßig nur für HTTP verfügbar, was keinen Schutz vor NTLM-Relaisangriffen bietet. Darüber hinaus erlaubt sie explizit nur die NTLM-Authentifizierung über ihren Autorisierungs-HTTP-Header, wodurch sicherere Authentifizierungsmethoden wie Kerberos unanwendbar sind.Der Zertifikatsregistrierungsdienst (CES), der Zertifikatsregistrierungsrichtlinien (CEP) Webdienst und der Netzwerkgeräteregistrierungsdienst (NDES) unterstützen standardmäßig die Verhandlungsauthentifizierung über ihren Autorisierungs-HTTP-Header. Die Verhandlungsauthentifizierung unterstützt sowohl Kerberos als auch NTLM, was einem Angreifer ermöglicht, während Relaisangriffen auf NTLM herabzustufen. Obwohl diese Webservices standardmäßig HTTPS unterstützen, bietet HTTPS allein keinen Schutz vor NTLM-Relaisangriffen. Schutz vor NTLM-Relaisangriffen für HTTPS-Dienste ist nur möglich, wenn HTTPS mit Kanalbindung kombiniert wird. Bedauerlicherweise aktiviert AD CS nicht die Erweiterte Authentifizierungsschutz auf IIS, der für die Kanalbindung erforderlich ist.
Ein häufiges Problem bei NTLM-Relaisangriffen ist die kurze Dauer von NTLM-Sitzungen und die Unfähigkeit des Angreifers, mit Diensten zu interagieren, die NTLM-Signierung erfordern.
Dennoch wird diese Einschränkung durch die Ausnutzung eines NTLM-Relaisangriffs überwunden, um ein Zertifikat für den Benutzer zu erhalten, da die Gültigkeitsdauer des Zertifikats die Dauer der Sitzung bestimmt und das Zertifikat mit Diensten verwendet werden kann, die NTLM-Signierung erfordern. Für Anweisungen zur Verwendung eines gestohlenen Zertifikats siehe:
pageAD CS Account PersistenceEine weitere Einschränkung von NTLM-Relaisangriffen besteht darin, dass eine von einem Angreifer kontrollierte Maschine von einem Opferkonto authentifiziert werden muss. Der Angreifer könnte entweder warten oder versuchen, diese Authentifizierung zu erzwingen:
pageForce NTLM Privileged AuthenticationMissbrauch
Certify’s cas listet aktivierte HTTP AD CS-Endpunkte auf:
Die Eigenschaft msPKI-Enrollment-Servers wird von Unternehmenszertifizierungsstellen (CAs) verwendet, um Endpunkte des Zertifikatanforderungsdienstes (CES) zu speichern. Diese Endpunkte können analysiert und aufgelistet werden, indem das Tool Certutil.exe verwendet wird:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Missbrauch mit Zertifikaten
Missbrauch mit Certipy
Die Anforderung eines Zertifikats erfolgt standardmäßig durch Certipy basierend auf der Vorlage Machine oder User, die durch das Enden des Kontonamens mit $ bestimmt wird. Die Spezifikation einer alternativen Vorlage kann durch die Verwendung des Parameters -template erreicht werden.
Eine Technik wie PetitPotam kann dann eingesetzt werden, um die Authentifizierung zu erzwingen. Bei der Arbeit mit Domänencontrollern ist die Spezifikation von -template DomainController erforderlich.
Keine Sicherheitserweiterung - ESC9
Erklärung
Der neue Wert CT_FLAG_NO_SECURITY_EXTENSION (0x80000) für msPKI-Enrollment-Flag, auch als ESC9 bezeichnet, verhindert das Einbetten der neuen Sicherheitserweiterung szOID_NTDS_CA_SECURITY_EXT in einem Zertifikat. Diese Flagge wird relevant, wenn StrongCertificateBindingEnforcement auf 1 (der Standardwert) gesetzt ist, im Gegensatz zu einer Einstellung von 2. Ihre Bedeutung wird in Szenarien erhöht, in denen eine schwächere Zertifikatabbildung für Kerberos oder Schannel ausgenutzt werden könnte (wie bei ESC10), da das Fehlen von ESC9 die Anforderungen nicht ändern würde.
Die Bedingungen, unter denen die Einstellung dieser Flagge signifikant wird, umfassen:
StrongCertificateBindingEnforcementist nicht auf2eingestellt (wobei der Standardwert1ist), oderCertificateMappingMethodsdenUPN-Flag enthält.Das Zertifikat ist mit der
CT_FLAG_NO_SECURITY_EXTENSION-Flagge innerhalb der Einstellung vonmsPKI-Enrollment-Flagmarkiert.Jedes Client-Authentifizierungs-EKU wird durch das Zertifikat angegeben.
GenericWrite-Berechtigungen sind über ein beliebiges Konto verfügbar, um ein anderes zu kompromittieren.
Missbrauchsszenario
Angenommen, John@corp.local hat GenericWrite-Berechtigungen über Jane@corp.local, mit dem Ziel, Administrator@corp.local zu kompromittieren. Die ESC9-Zertifikatvorlage, für die Jane@corp.local berechtigt ist, sich einzuschreiben, ist mit der CT_FLAG_NO_SECURITY_EXTENSION-Flagge in ihrer msPKI-Enrollment-Flag-Einstellung konfiguriert.
Zunächst wird der Hash von Jane mithilfe von Shadow Credentials erlangt, dank Johns GenericWrite:
Anschließend wird Jane's userPrincipalName absichtlich auf Administrator geändert, wobei der Domänenteil @corp.local ausgelassen wird:
Diese Modifikation verstößt nicht gegen die Einschränkungen, da Administrator@corp.local als userPrincipalName von Administrator weiterhin eindeutig bleibt.
Anschließend wird die als verwundbar markierte Zertifikatsvorlage ESC9 als Jane angefordert:
Es wird festgestellt, dass das Zertifikat userPrincipalName den Wert Administrator widerspiegelt, ohne eine "Objekt-SID".
Das userPrincipalName von Jane wird dann auf ihren ursprünglichen Wert Jane@corp.local zurückgesetzt:
Der Versuch der Authentifizierung mit dem ausgestellten Zertifikat ergibt nun den NT-Hash von Administrator@corp.local. Der Befehl muss -domain <domain> enthalten, aufgrund des fehlenden Domänenspezifikation im Zertifikat:
Schwache Zertifikat Zuordnungen - ESC10
Erklärung
Zwei Registrierungsschlüsselwerte auf dem Domänencontroller werden von ESC10 referenziert:
Der Standardwert für
CertificateMappingMethodsunterHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannelist0x18(0x8 | 0x10), zuvor auf0x1Fgesetzt.Die Standardeinstellung für
StrongCertificateBindingEnforcementunterHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdcist1, zuvor0.
Fall 1
Wenn StrongCertificateBindingEnforcement als 0 konfiguriert ist.
Fall 2
Wenn CertificateMappingMethods das UPN-Bit (0x4) enthält.
Missbrauchsfall 1
Mit StrongCertificateBindingEnforcement konfiguriert als 0, kann ein Konto A mit GenericWrite-Berechtigungen ausgenutzt werden, um ein beliebiges Konto B zu kompromittieren.
Beispielsweise, wenn man GenericWrite-Berechtigungen über Jane@corp.local hat, zielt ein Angreifer darauf ab, Administrator@corp.local zu kompromittieren. Das Verfahren ähnelt ESC9 und ermöglicht die Verwendung eines beliebigen Zertifikatvorlage.
Zunächst wird der Hash von Jane unter Ausnutzung des GenericWrite mit Schattenanmeldeinformationen abgerufen.
Anschließend wird Jane's userPrincipalName in Administrator geändert, wobei absichtlich der Teil @corp.local ausgelassen wird, um eine Einschränkungsverletzung zu vermeiden.
Nachfolgend wird ein Zertifikat zur Clientauthentifizierung als Jane angefordert, unter Verwendung der Standard Benutzer-Vorlage.
Janes userPrincipalName wird dann auf ihren ursprünglichen Wert Jane@corp.local zurückgesetzt.
Die Authentifizierung mit dem erhaltenen Zertifikat liefert den NT-Hash von Administrator@corp.local, was die Angabe der Domäne im Befehl erforderlich macht, aufgrund des Fehlens von Domänendetails im Zertifikat.
Missbrauchsfall 2
Mit den CertificateMappingMethods, die das UPN-Bit-Flag (0x4) enthalten, kann ein Konto A mit GenericWrite-Berechtigungen jedes Konto B kompromittieren, das über keine userPrincipalName-Eigenschaft verfügt, einschließlich Maschinenkonten und des integrierten Domänenadministrators Administrator.
Hier besteht das Ziel darin, DC$@corp.local zu kompromittieren, beginnend mit dem Erhalt des Hashes von Jane über Shadow Credentials und unter Ausnutzung des GenericWrite.
Janes userPrincipalName wird dann auf DC$@corp.local gesetzt.
Ein Zertifikat für die Client-Authentifizierung wird als Jane unter Verwendung der Standard Benutzer-Vorlage angefordert.
Janes userPrincipalName wird nach diesem Prozess auf seinen ursprünglichen Wert zurückgesetzt.
Um über Schannel zu authentifizieren, wird die Option -ldap-shell von Certipy verwendet, die den Erfolg der Authentifizierung als u:CORP\DC$ angibt.
Durch die LDAP-Shell ermöglichen Befehle wie set_rbcd Angriffe auf die ressourcenbasierte eingeschränkte Delegierung (RBCD), die potenziell den Domänencontroller gefährden.
Diese Schwachstelle betrifft auch jedes Benutzerkonto, das über keinen userPrincipalName verfügt oder bei dem dieser nicht mit dem sAMAccountName übereinstimmt. Besonders gefährdet ist das Standardkonto Administrator@corp.local aufgrund seiner erhöhten LDAP-Berechtigungen und dem standardmäßig fehlenden userPrincipalName.
Weiterleitung von NTLM an ICPR - ESC11
Erklärung
Wenn der CA-Server nicht mit IF_ENFORCEENCRYPTICERTREQUEST konfiguriert ist, können NTLM-Weiterleitungsangriffe ohne Signierung über den RPC-Dienst durchgeführt werden. Referenz hier.
Sie können certipy verwenden, um zu überprüfen, ob die Erzwingen der Verschlüsselung für Anfragen deaktiviert ist. Certipy zeigt dann die ESC11-Schwachstellen an.
Missbrauchsszenario
Es muss ein Relay-Server eingerichtet werden:
Hinweis: Für Domänencontroller müssen wir -template in DomainController angeben.
Oder mit sploutchy's Fork von impacket:
Shell-Zugriff auf ADCS-CA mit YubiHSM - ESC12
Erklärung
Administratoren können die Zertifizierungsstelle so einrichten, dass sie auf einem externen Gerät wie dem "Yubico YubiHSM2" gespeichert wird.
Wenn ein USB-Gerät über einen USB-Anschluss mit dem CA-Server verbunden ist oder ein USB-Geräteserver im Falle eines virtuellen CA-Servers, wird ein Authentifizierungsschlüssel (manchmal als "Passwort" bezeichnet) für den Key Storage Provider benötigt, um Schlüssel im YubiHSM zu generieren und zu nutzen.
Dieser Schlüssel/dieses Passwort wird im Klartext in der Registrierung unter HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword gespeichert.
Referenz hier.
Missbrauchsszenario
Wenn der private Schlüssel der CA auf einem physischen USB-Gerät gespeichert ist und Sie über Shell-Zugriff verfügen, ist es möglich, den Schlüssel wiederherzustellen.
Zunächst müssen Sie das CA-Zertifikat (dies ist öffentlich) erhalten und dann:
OID Gruppen Link Missbrauch - ESC13
Erklärung
Das Attribut msPKI-Certificate-Policy ermöglicht es, die Ausstellungspolitik der Zertifikatsvorlage hinzuzufügen. Die msPKI-Enterprise-Oid-Objekte, die für die Ausstellung von Richtlinien verantwortlich sind, können im Konfigurationsnamenskontext (CN=OID,CN=Public Key Services,CN=Services) des PKI-OID-Containers gefunden werden. Eine Richtlinie kann mithilfe des Attributs msDS-OIDToGroupLink dieses Objekts mit einer AD-Gruppe verknüpft werden, sodass ein System einem Benutzer, der das Zertifikat vorlegt, die Autorisierung wie einem Mitglied der Gruppe ermöglichen kann. Referenz hier.
Mit anderen Worten, wenn ein Benutzer die Berechtigung hat, ein Zertifikat zu beantragen und das Zertifikat mit einer OID-Gruppe verknüpft ist, kann der Benutzer die Berechtigungen dieser Gruppe erben.
Verwenden Sie Check-ADCSESC13.ps1, um OIDToGroupLink zu finden:
Missbrauchsszenario
Suchen Sie eine Benutzerberechtigung, die certipy find oder Certify.exe find /showAllPermissions verwenden kann.
Wenn John die Berechtigung hat, VulnerableTemplate zu beantragen, kann der Benutzer die Privilegien der Gruppe VulnerableGroup erben.
Alles, was es tun muss, ist das Template anzugeben, dann erhält es ein Zertifikat mit OIDToGroupLink-Rechten.
Kompromittierung von Forests mit Zertifikaten im Passiv erklärt
Brechen von Forest Trusts durch kompromittierte CAs
Die Konfiguration für die cross-forest enrollment ist relativ einfach. Das Root-CA-Zertifikat aus dem Ressourcen-Forest wird von Administratoren an die Account-Forests veröffentlicht, und die Enterprise-CA-Zertifikate aus dem Ressourcen-Forest werden den NTAuthCertificates- und AIA-Containern in jedem Account-Forest hinzugefügt. Um es klar auszudrücken, gewährt diese Anordnung der CA im Ressourcen-Forest die vollständige Kontrolle über alle anderen Forests, für die sie PKI verwaltet. Sollte diese CA von Angreifern kompromittiert werden, könnten Zertifikate für alle Benutzer sowohl im Ressourcen- als auch im Account-Forest von ihnen gefälscht werden, wodurch die Sicherheitsgrenze des Forests durchbrochen wird.
Enrollment-Privilegien für ausländische Prinzipale gewährt
In Multi-Forest-Umgebungen ist Vorsicht geboten bei Enterprise-CAs, die Zertifikatvorlagen veröffentlichen, die es Authentifizierten Benutzern oder ausländischen Prinzipalen (Benutzern/Gruppen extern zum Forest, zu dem die Enterprise-CA gehört) ermöglichen, Enrollment- und Bearbeitungsrechte zu haben. Bei der Authentifizierung über eine Trust-Beziehung wird die SID der Authentifizierten Benutzer vom AD zum Token des Benutzers hinzugefügt. Somit könnte, wenn eine Domäne eine Enterprise-CA mit einer Vorlage besitzt, die Authentifizierten Benutzern Enrollment-Rechte gewährt, eine Vorlage potenziell von einem Benutzer aus einem anderen Forest enrolliert werden. Ebenso, wenn Enrollment-Rechte explizit einem ausländischen Prinzipal durch eine Vorlage gewährt werden, wird dadurch eine cross-forest Zugriffssteuerungsbeziehung erstellt, die es einem Prinzipal aus einem Forest ermöglicht, sich in eine Vorlage aus einem anderen Forest einzuschreiben.
Beide Szenarien führen zu einer Erhöhung der Angriffsfläche von einem Forest zum anderen. Die Einstellungen der Zertifikatvorlage könnten von einem Angreifer ausgenutzt werden, um zusätzliche Privilegien in einer fremden Domäne zu erlangen.
Last updated
