CVE-2022-26923: Kennen Sie Ihre AD-Schwachstelle

Am 10. Mai 2022 wurde eine Sicherheitslücke in Active Directory (AD) und Active Directory Certificate Services (AD CS) bekannt gegeben und gepatcht. Diese AD-Schwachstelle kann zu einer Privilegienerweiterung führen. In Standardinstallationen von AD CS kann ein Benutzer mit geringen Privilegien die Schwachstelle ausnutzen, indem er ein Authentifizierungszertifikat anfordert und sich dann mit diesem Zertifikat als ein anderes Computerkonto ausgibt, was zu einer vollständigen Übernahme der Domäne führt. Was hat es mit dieser AD-Schwachstelle auf sich? Lesen Sie weiter, um einen umfassenden Leitfaden zu CVE-2022-26923 zu erhalten.

Was führt zu dieser AD-Schwachstelle?

AD wurde erstmals 1999 von Microsoft als zentralisiertes Identitätsmanagementsystem veröffentlicht, das aus einer Reihe von Prozessen und Diensten besteht. AD enthält mehrere Protokolle, die für die Authentifizierung und Autorisierung von Identitäten in einem Unternehmen verwendet werden können. Am häufigsten wird AD für die einfache Verwaltung von Benutzern, Gruppen und Computern innerhalb eines Unternehmens verwendet. AD ist inzwischen das am weitesten verbreitete Identitätsmanagementsystem und wird in den meisten Unternehmen zur Verwaltung von Identitäten eingesetzt.

Mit Windows Server 2008 führte Microsoft AD CS ein, das die einfache Erstellung und Verwaltung von Public Key Infrastructure (PKI)-Zertifikaten ermöglicht. Diese Zertifikate können für digitale Signaturen, Protokollschutz und Authentifizierung verwendet werden.

Wenn Zertifikate von AD CS für die Authentifizierung innerhalb einer AD-Umgebung (PKINIT) verwendet werden, eröffnen sich viele neue Angriffswege, darunter sowohl Fehlkonfigurationen als auch Schwachstellen. Im Juni 2021 veröffentlichten Will Schroeder und Lee Christensen ein Whitepaper, in dem sie mehrere Fehlkonfigurationen aufzeigten, die zu einer Privilegienerweiterung führen können. Einige dieser Fehlkonfigurationen waren bei der Installation von AD CS voreingestellt und können zu einer vollständigen Übernahme der Domäne führen. Diese Fehlkonfigurationen sind unabhängig von der in diesem Beitrag beschriebenen Sicherheitslücke.

Verwandte Lektüre

• Active Directory Sicherheit: Top-Risiken und beste Praktiken

Privilegienerweiterung mit der AD-Schwachstelle CVE-2022-26923

CVE-2022-26923 ist eine von Oliver Lyak entdeckte Schwachstelle, die zu einer Ausweitung der Privilegien führt. Die Ausnutzung beruht auf zwei primären Aktionen:

1. Ändern eines Computerkontos dNSHostName um mit dem eines anderen Computerkontos übereinzustimmen.
2. Anfordern eines Zertifikats für das Computerkonto unter Verwendung einer Vorlage, die mit der Option SubjectAltRequireDns

Das Flag SubjectAltRequireDns für Zertifikatsvorlagen bedeutet, dass Zertifikate, die mit dieser Vorlage angefordert werden, ein Zertifikat Betreff haben, der dem dNSHostName-Attribut des anfordernden AD-Kontos entspricht.

Diese beiden Aktionen sind bei einer Standardinstallation von AD und AD CS möglich.

Durch die Anforderung eines Zertifikats über ein Computerkonto, das denselben dNSHostName wie ein anderes Computerkonto hat, können sich Angreifer als das Zielcomputerkonto authentifizieren und ihre Berechtigungen erweitern. Diese Schwachstelle kann dazu verwendet werden, jeden aktiven Computer innerhalb von AD anzugreifen.

Ändern des Rechnerkontos dNSHostName

In einer AD-Standardinstallation kann jeder authentifizierte Benutzer Maschinenkonten hinzufügen. Diese Aktion wird durch die folgenden Einstellungen gesteuert:

• Die Workstations zur Domäne hinzufügen in der Domänencontroller-Richtlinie, die festlegt, wer die Berechtigung erhält, Computerkonten zur Domäne hinzuzufügen (standardmäßig auf Authentifizierte Benutzer eingestellt; Abbildung 1)

• Die ms-DS-MachineAccountQuota Attribut auf dem Kopf des Namenskontextes (NC), das die Anzahl der Computerkonten festlegt, die Benutzer mit niedrigen Privilegien hinzufügen dürfen (standardmäßig auf 10 gesetzt; Abbildung 2)

Mit diesen Standardeinstellungen kann jedes Konto mit niedrigen Privilegien problemlos bis zu 10 Computerkonten in der Domäne erstellen, indem Sie mit dem Powermad-Cmdlet New-MachineAccount ein Computerkonto mit dem Namen LowPrivComputer hinzufügen(Abbildung 3).

Die Discretionary Access Control List (Dacl) für dieses neue Computerkonto zeigt, dass das Erstellerkonto die Berechtigung Validiert auf DNS-Hostnamen schreiben hat(Abbildung 4).

Daher kann das Attribut dNSHostName von demselben Konto geändert werden, das es erstellt hat, indem Sie einfach das Cmdlet Set-DomainObject von PowerViewverwenden(Abbildung 5).

Zertifikatsvorlage mit SubjectAltRequireDns-Flag

In einer AD CS-Standardinstallation ist bei mehreren Zertifikatsvorlagen das Flag SubjectAltRequireDns gesetzt. So wird beispielsweise die Vorlage Maschine standardmäßig verwendet, um Computerkonten für die Zertifikatsauthentifizierung zu registrieren. Das Cmdlet Get-DomainCertificateTemplate von PowerView wird verwendet, um das Attribut msPKI-Certificate-Name-Flag der Vorlage Machine anzuzeigen(Abbildung 6).

Mit dem zuvor erstellten Maschinenkonto können Sie mit dieser Vorlage ein Zertifikat für das LowPrivComputer-Konto mit dem geänderten dnshostname(somethingelse.f105-d01.lab) anfordern. Hierfür wird das Python-Tool Certipy verwendet(Abbildung 7).

Missbräuche der AD-Schwachstelle CVE-2022-26923

Wie bereits erwähnt, kann diese Methode verwendet werden, um die Privilegien innerhalb einer AD-Domäne zu erweitern. Ein gängiger Angriffsweg besteht darin, einen Domänencontroller (DC) anzugreifen. Nach der Erstellung des Computerkontos(LowPrivComputer) ändern die Angreifer zunächst das dNSHostName-Attribut des Kontos auf den gleichen Namen wie den DC(F105-D02-DC01.f105-d01.lab), wie in Abbildung 8 gezeigt.

Für diesen Angriffspfad muss der Inhalt des servicePrincipalName (SPN) gelöscht werden. Wenn das Attribut dNSHostName aktualisiert wird, werden auch alle SPN-Einträge auf den neuen Namen aktualisiert. Dies führt zu einem Konflikt mit den SPN-Einträgen für das echte Konto(F105-D01-DC01) und die Änderung schlägt fehl.

Nach der Änderung des dNSHostName kann ein Zertifikat für diesen neuen Namen angefordert werden(Abbildung 9).

Nach dem Abruf des Zertifikats muss der dNSHostName erneut geändert werden(Abbildung 10), damit es bei der Verwendung des Zertifikats und der Suche des DC nach dem Client-Namen nur eine Übereinstimmung gibt (das echte DC-Konto).

Jetzt ist es möglich, sich mit dem Konto des DC-Computers zu authentifizieren. Rubeus bietet einen Schalter /getcredentials für die asktgt Befehl, der eine User-to-User (U2U) Anfrage verwendet. Wenn ein Zertifikat zur Authentifizierung angegeben wird, kann der NT-Hash des anfragenden Kontos aufgrund der NTLM_SUPPLEMENTAL_CREDENTIAL PAC-Anmeldedaten PAC_INFO_BUFFER abgerufen werden(Abbildung 11).

Dieser NT-Hash kann zur weiteren Authentifizierung als DC verwendet werden (mit Pass-the-Hash oder Overpass-the-Hash) oder Silver Tickets können gefälscht werden.

Variationen des Angriffswegs

Abgesehen von dem in den vorherigen Beispielen gezeigten Angriffspfad können mehrere leichte Variationen verwendet werden, um diese AD-Schwachstelle auszunutzen.

Erstens benötigt ein Angreifer mit einer gewissen Kontrolle über ein bestehendes Computerobjekt nicht die Fähigkeit, ein Computerkonto zu erstellen. Abbildung 12 zeigt, dass das niedrigprivilegierte Benutzerkonto über die GenericWrite Berechtigung für das Computerobjekt DatabaseServer hat.

Mit dieser Berechtigung kann ein Angreifer die SPNs löschen und das Attribut dNSHostName so ändern, dass es mit dem eines anderen Computerkontos übereinstimmt(Abbildung 13).

Zwei Dinge sind hier erwähnenswert:

• Ein Nicht-DC-System ist das Ziel. Diese Schwachstelle kann für jedes beliebige domänenverbundene System genutzt werden, nicht nur für DCs.
• Dieser Teil des Angriffs kann auf vollständig aktuellen DCs durchgeführt werden. Wenn das Konto, das die Änderung vornimmt, über spezielle GenericAll- oder GenericWrite-Berechtigungen verfügt, kann der dNSHostName so geändert werden, dass er mit dem eines anderen Computerkontos übereinstimmt. (Dies ist nicht möglich, wenn dem Ersteller eines Computerkontos die Berechtigung Validated write to DNS host name erteilt wurde).

Mit dem geänderten dNSHostName kann ein Zertifikat unter Verwendung des Ziel-DNS-Hostnamens angefordert werden(Abbildung 14).

Da der dNSHostName wie im vorherigen Angriffspfad wieder geändert wurde, kann der Angreifer nun das erworbene Zertifikat verwenden, um sich als Konto des Zielcomputers zu authentifizieren.

Ein weiterer Unterschied zwischen dem vorherigen Angriffsweg und diesem: Der Angreifer muss das Zertifikat nicht verwenden, um sich bei Kerberos zu authentifizieren und ein Ticket Granting Ticket (TGT) für das Zielkonto anzufordern. Der Angreifer kann das Zertifikat verwenden, um sich direkt bei einigen Diensten zu authentifizieren. Im folgenden Beispiel wird das Zertifikat verwendet, um eine direkte Verbindung zu LDAP herzustellen und ressourcenbasierte eingeschränkte Delegation (RBCD) auf dem Zielcomputerobjekt zu konfigurieren(Abbildung 15).

Beachten Sie, dass die Konfiguration von RBCD nur ein Beispiel dafür ist, was ein Angreifer tun kann, indem er das Zertifikat zur direkten Authentifizierung gegenüber Diensten verwendet. WinRM, RDP und IIS unterstützen alle die Client-Authentifizierung mit Zertifikaten, so dass es noch viele weitere Möglichkeiten gibt. Andere Aktionen, wie z.B. die Konfiguration von Shadow Credentials, können über LDAP durchgeführt werden, je nach Umgebung und Berechtigungen des kompromittierten Computerkontos.

Um den Angriffspfad zu beenden, kann der Angreifer die Kerberos-Erweiterung Service-for-User (S4U) verwenden, um ein Service-Ticket für das Zielsystem als administrativer Benutzer zu erhalten (vorausgesetzt, der administrative Benutzer wurde nicht gegen Delegation geschützt), wie in Abbildung 16 und Abbildung 17 gezeigt.

Der Angreifer kann das daraus resultierende Dienstticket verwenden, um auf den Dienst auf dem Zielsystem als der verkörperte Benutzer zuzugreifen. Eine gute Demonstration ist die Verwendung von WinRM/PowerShell Remoting, um den Wert von "whoami" auszugeben, der ein Dienstticket für den HTTP-Dienst auf dem Zielsystem erfordert(Abbildung 18).

ServicePrincipalNames

Bei diesen beiden demonstrierten Angriffswegen mussten die SPNs gelöscht werden, bevor der dNSHostName geändert wurde. Dies mag wie eine harte Voraussetzung für die Ausnutzung der Schwachstelle erscheinen, ist es aber nicht. Unter Verwendung des MS-SAMR-Protokolls zur Erstellung eines Computerkontos mit der Methode SamrCreateUser2InDomain kann ein Angreifer ein Computerkonto ohne SPNs erstellen, indem er einfach das Beispielskript addcomputer.py von impacketverwendet, um ein Computerkonto namens NoSPNComputer zu erstellen(Abbildung 19).

Das resultierende Computerkonto hat keine SPNs und muss nicht gelöscht werden (siehe Abbildung 20).

Mildernde Faktoren

Wenn Sie die Fähigkeit von Benutzern mit geringen Rechten, Computerkonten zu erstellen, einschränken, indem Sie entweder das Attribut ms-DS-MachineAccountQuota auf dem NC-Kopf auf 0 setzen oder das Recht " Add workstations to domain user" in der Richtlinie für den Domänencontroller auf eine bestimmte Gruppe anstelle von " Authenticated Users" ändern , verringern Sie die möglichen Angriffspfade für diese Sicherheitslücke. Weitere Maßnahmen zur Verringerung des Ausnutzungspotenzials:

• Ändern Sie alle Zertifikatsvorlagen von "DNS-Name" in etwas wie "User principal name (UPN)"(Abbildung 21).

• Konfigurieren Sie die Zertifikatsvorlagen so, dass eine Genehmigung des Managers für die Registrierung erforderlich ist(Abbildung 22).

DSP Entdeckung dieser AD-Schwachstelle

Da dieser Exploit nur zwei obligatorische Aktionen umfasst, hat Semperis Directory Services Protector (DSP) zwei Möglichkeiten, ihn zu entdecken:

• Wenn die Änderung des dNSHostName erfolgt
• Wenn das Zertifikat angefordert wird

DSP sammelt bereits die AD-Änderungsdaten, so dass es naheliegend ist, einen Versuch, diese Schwachstelle auszunutzen, zu erkennen, wenn der dNSHostName geändert wird. Der Indikator DSP tut dies zunächst, indem er auf eine Änderung des Attributs dNSHostName eines Computerkontos achtet.

Wenn eine solche Änderung erkannt wird, führt DSP eine LDAP-Abfrage nach allen Computerkonten mit diesem dNSHostName-Wert durch, wobei der Objekt-DN ( Distinguished Name ) des Kontos, das die LDAP-Abfrage ausgelöst hat, ausgeschlossen wird. DSP kennzeichnet jedes Ergebnis als Indikator für eine Kompromittierung (IoC). Dieser Indikator sollte jeden Versuch abfangen, diese Schwachstelle auszunutzen, unabhängig davon, ob der gesamte Angriff erfolgreich war. Wie in Abbildung 23 dargestellt, gibt der IoC folgende Informationen zurück:

• Das Konto, das die Änderung vorgenommen hat
• Die DNs der beiden beteiligten Computerkonten
• Der ursprüngliche dNSHostName des Kontos, dessen Attribut geändert wurde
• Das Attribut dNSHostName des anvisierten Kontos

Andere Entdeckungen von CVE-2022-26923

Mehrere relevante Windows-Ereignisse können ebenfalls dazu beitragen, Versuche zur Ausnutzung dieser Sicherheitslücke zu erkennen.

SPNs löschen

Wenn ein Angriffspfad die Löschung der SPNs des bei dem Angriff verwendeten Computerkontos erfordert, wird für jeden der konfigurierten SPNs ein 5136-Ereignis mit dem Operationstyp Wert gelöscht erstellt(Abbildung 24).

Ändern von dNSHostName

Wenn das Attribut dNSHostName geändert wird, wird ein 4742-Ereignis erzeugt(Abbildung 25).

Der Abschnitt Geänderte Attribute dieses Ereignisses zeigt den neuen Wert des DNS-Hostnamens(Abbildung 26).

Zusammen mit dem Ereignis 4742 werden zwei Ereignisse 5136 erstellt. Das erste zeigt den ursprünglichen dNSHostName-Wert an und hat den Vorgangstyp Value Deleted(Abbildung 27).

Die zweite zeigt den neuen dNSHostName-Wert und hat den Operationstyp Value Added(Abbildung 28).

Computererstellung ohne SPNs

Wie bereits erwähnt, können Angreifer mithilfe von MS-SAMR Computerkonten ohne anfängliche SPNs erstellen. Wenn sie dies tun, wird ein 4741-Ereignis erstellt(Abbildung 29).

Im Abschnitt Attribute dieses Ereignisses sind die Service Principal Names leer, wie in Abbildung 30 gezeigt.

Zertifikat anfordern

Wenn ein Zertifikat angefordert wird, wird bei der Zertifizierungsstelle (CA) ein Ereignis 4887 erstellt. Dieses Ereignis zeigt den Namen des anfordernden Kontos(Requester) an. Der Wert des Attributs dNSHostName wird als Betreff angezeigt(Abbildung 31).

Behebung von AD-Schwachstellen

Ein Patch für diese Sicherheitslücke wurde im Rahmen der Sicherheitsupdates vom Mai 2022 veröffentlicht. Mit diesem Patch wurden einige Änderungen vorgenommen:

• Konten mit der Berechtigung Validiertes Schreiben auf DNS-Hostnamen sind nicht mehr in der Lage, das Attribut dNSHostName so zu ändern, dass es dem eines anderen Kontos auf gepatchten DCs entspricht. Versuche, dies zu tun, führen zu einer Verletzung der Einschränkung(Abbildung 32).

Hinweis: Wie bereits erwähnt, können Angreifer auch nach diesem Patch das dNSHostName-Attribut eines Computerkontos so ändern, dass es mit dem eines anderen Computerkontos übereinstimmt, auch wenn diese Aktion jetzt höhere Berechtigungen wie GenericAll/GenericWrite erfordert.

• Von gepatchten CAs angeforderte Zertifikate enthalten die neue OID szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2.1)(Abbildung 33).

Dieses Feld enthält eine ASCII-Zeichenkette (in Hexadezimal) mit der SID des Kontos, das das Zertifikat angefordert hat. Wenn ein Zertifikat, das diese Sicherheitslücke ausnutzt, zur Authentifizierung gegen einen gepatchten DC verwendet wird, wird ein CERTIFICATE_MISMATCH-Fehler zurückgegeben(Abbildung 34).

Hinweis: Wenn dieses Zertifikat zur Authentifizierung gegenüber einem ungepatchten DC verwendet wird, ist die Authentifizierung erfolgreich und die Sicherheitslücke ausnutzbar(Abbildung 35). Daher ist es sehr wichtig, dass alle DCs und CAs mit dem entsprechenden Patch aktualisiert werden.

Mehr erfahren

Um mehr über diese AD-Schwachstelle zu erfahren und darüber, wie Sie Ihr Unternehmen schützen können, lesen Sie die folgenden Referenzen und Ressourcen.

Ressourcen

Erfahren Sie mehr über Semperis Directory Services Protector ( DSP)

Erfahren Sie mehr über Purple Knight Active Directory Sicherheitsbewertungstool

Referenzen

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923
• https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
• https://offsec.almond.consulting/authenticating-with-certificates-when-pkinit-is-not-supported.html
• https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/
• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html