Als ich mit Kerberos-Tickets spielte, entdeckte ich ein Problem, das es mir ermöglichte, mich bei anderen Domänen innerhalb einer Active Directory (AD)-Gruppe über externe nicht-transitive Trusts zu authentifizieren. Das bedeutet, dass es so etwas wie einen "nicht-transitiven Trust" eigentlich nicht gibt. Der Begriff ist bestenfalls irreführend und gibt Systemadministratoren ein falsches Gefühl von Sicherheit. Im Rahmen des in diesem Beitrag erörterten Problems können sich Angreifer über eine nichttransitive Vertrauensstellung bei anderen Domänen authentifizieren und möglicherweise die Berechtigungen innerhalb der vertrauenswürdigen Domäne erhöhen. Dieser Beitrag beschreibt das entdeckte Problem im Detail.
Nachdem ich dieses Problem an Microsoft gemeldet hatte, erhielt ich die folgende Antwort:
Da Microsoft festgestellt hat, dass dieses Problem keine Auswirkungen auf die Sicherheit hat und daher nicht plant, das Verhalten zu ändern, gibt es keine Möglichkeit, das Problem zu vermeiden - abgesehen davon, dass Sie einfach keine externen Vertrauensstellungen verwenden.
Trusts und Transitivität
Hinweis: Dieser Beitrag setzt ein grundlegendes Verständnis von Trusts und deren Funktionsweise voraus. (Für weitere Informationen zu diesen Themen empfehle ich Ihnen, den großartigen Beitrag von Will Schroederüber Trusts zu lesen.) Dieser Beitrag befasst sich nicht mit Trusts innerhalb eines Forests (d.h. Trusts innerhalb eines einzelnen Forests) - es sei denn, sie beziehen sich auf den besprochenen Angriffspfad - oder mit selektiven Authentifizierungs-Trusts, die in realen Umgebungen unglaublich selten sind.
Die übrigen Trusts sind Wald-Trusts und externe Trusts.
- Forest-Trusts sind Trusts zwischen zwei Forests. Genauer gesagt handelt es sich um transitive Vertrauensstellungen zwischen den Stammdomänen zweier Forests. Jeder Benutzer aus einer beliebigen Domäne innerhalb der vertrauenswürdigen Struktur kann sich bei jeder Domäne innerhalb der vertrauenswürdigen Struktur authentifizieren.
- Externe Trusts sind Trusts zwischen zwei Domänen. Diese Vertrauensstellungen sind nicht übertragbar. Nur Benutzer innerhalb der vertrauenswürdigen Domäne können sich nur gegenüber der vertrauenswürdigen Domäne authentifizieren(Abbildung 2).
Microsoft beschreibt die Transitivität des Vertrauens wie folgt:
Die Transitivität bestimmt, ob ein Vertrauen außerhalb der beiden Bereiche, mit denen es gebildet wurde, erweitert werden kann.
- Ein transitives Vertrauen kann verwendet werden, um Vertrauensbeziehungen mit anderen Domänen zu erweitern.
- Ein nicht-transitiver Trust kann verwendet werden, um Vertrauensbeziehungen mit anderen Domänen zu verweigern.
Diese Beschreibung ist eindeutig: Bei nicht-transitiven Trusts können sich nur die beiden an dem Trust beteiligten Domänen gegenseitig authentifizieren und nicht darüber hinaus.
Wie ich in diesem Beitrag zeigen werde, ist dies leider nicht der Fall.
Laboreinrichtung
Um das Problem des nicht-transitiven Vertrauens richtig zu demonstrieren, habe ich das Labor mit mehreren Multi-Domänen-Wäldern eingerichtet, die sich externe Vertrauensstellungen teilen(Abbildung 3).
Diese Einrichtung umfasst drei (3) Forests. Zwei (2) der Forests enthalten drei (3) Domänen. Der dritte Wald enthält zwei (2) Domänen. Die Domänen semperis.lab und treetest.lab teilen sich ein bidirektionales externes nicht-transitives Vertrauen(Abbildung 4).
Die Domänen grandchild1.child1.semperis.lab und semperisaz.lab teilen sich ebenfalls ein bidirektionales externes nicht-transitives Vertrauen(Abbildung 5).
Auf diese Weise lassen sich die Auswirkungen und Grenzen des nicht-transitiven Vertrauensproblems demonstrieren.
So funktioniert die vertrauensübergreifende Kerberos-Authentifizierung
Um sich bei einem Dienst über einen Trust mit Kerberos zu authentifizieren, benötigen Sie eine Überweisung (auch bekannt als Überweisungsticket, Granting Ticket [TGT]). Dies ist ein Ticket, das von Ihrem lokalen Domänencontroller (DC) für die fremde Domäne angefordert wird. Um zu zeigen, wie Ticketanfragen über Vertrauensstellungen hinweg durchgeführt werden, konzentriert sich dieser Abschnitt auf die semperis.lab-Forest. Diese Informationen sind jedoch auf jeden "erlaubten" Vertrauenspfad anwendbar.
Hinweis: Dieser Beitrag setzt ein grundlegendes Verständnis des normalen Kerberos-Authentifizierungsablaufs voraus. (Eine ausführliche Erklärung dieses Ablaufs finden Sie im Beitrag Detecting Kerberoasting Activity von Sean Metcalf). Der Rest des Beitrags verwendet Rubeus, um Tickets manuell anzufordern.
Das einfachste Beispiel für eine vertrauensübergreifende Authentifizierung ist die Authentifizierung eines Dienstes in einer Domäne, die eine direkte Vertrauensbeziehung zur lokalen Domäne hat. Die Vertrauensbeziehung zwischen der Domäne grandchild1.child1.semperis.lab und child1.semperis.lab(Abbildung 5) ist ein Beispiel für diese Art von Vertrauen. In dieser Situation besteht der erste Schritt, um ein Service-Ticket für ein Konto in grandchild1.child1.semperis.lab für einen Service in child1.semperis.lab zu erhalten, darin, eine Überweisung für child1.semperis.lab zu erhalten(Abbildung 6, Abbildung 7), nachdem man ein erstes TGT erhalten hat.
Die Anfrage wurde an einen DC(SGC1DC1.grandchild1.child1.semperis.lab) innerhalb der Domäne(grandchild1.child1.semperis.lab) gerichtet, die dem authentifizierenden Benutzer(lowpriv) gehört. Die Anfrage wurde für den Dienst krbtgt/child1.semperis.lab gestellt . Die Tatsache, dass die ServiceRealm (srealm) die lokale Domäne(grandchild1.child1.semperis.lab) im resultierenden Ticket ist, zeigt, dass es sich bei diesem Ticket um eine Verweisung handelt.
Mit dieser Verweisung können Sie nun Service-Tickets (STs) vom ausländischen DC(SC1DC1.child1.semperis.lab) für den Service-Host/SC1DC1.child1.semperis.lab anfordern(Abbildung 8, Abbildung 9).
Um noch einen Schritt weiter zu gehen: Wenn ein Dienst auf der Stammdomäne des Forests(semperis.lab) benötigt wird, kann eine Überweisung für diese Domäne nicht direkt von der lokalen Domäne(grandchild1.child1.semperis.lab) angefordert werden. Eine Überweisung für krbtgt/semperis.lab wird von dem lokalen DC sgc1dc1.grandchild1.child1.semperis.lab angefordert. Der DC gibt jedoch ein Ticket für den Dienst krbtgt/child1.semperis.lab zurück, was darauf hinweist, dass diese Verweisung für die Domäne child1.semperis.lab und nicht für semperis.lab gilt(Abbildung 10, Abbildung 11).
Sie können dieses Problem erkennen, wenn Sie versuchen, mit diesem Ticket eine ST für die Domäne semperis.lab anzufordern. Dies führt zu einem AP_ERR_BAD_INTEGRITY-Fehler. Dies liegt daran, dass das Verweisungsticket mit dem Vertrauensschlüssel für die Vertrauensstellung grandchild1.child1.semperis.lab -> child1.semperis.lab verschlüsselt ist. Die DCs in der Root-Domäne semperis.lab haben keine Kenntnis von diesem Schlüssel und können das Ticket daher nicht entschlüsseln(Abbildung 12, Abbildung 13).
Um ein Service-Ticket für die Root-Domäne semperis.lab anzufordern, muss zunächst eine Verweisung für semperis.lab von einem DC in der Domäne child1.semperis.lab angefordert werden , wobei diese Verweisung verwendet wird. Abbildung 14 und Abbildung 15 zeigen eine Anfrage an den fremden DC(sc1dc1.child1.semperis.lab) unter Verwendung der Verweisung für die Domäne child1.semperis.lab, um eine weitere Verweisung für die Stammdomäne semperis.lab anzufordern.
Beachten Sie, dass für die Anforderung dieses Tickets die Option /Zieldomäne Argument erforderlich ist. Standardmäßig verwendet Rubeus die Domäne in dem Ticket, das ihm übergeben wurde, um die Domäne in der TGS-REQ auszufüllen. In diesem Fall wäre diese Domäne grandchild1.child1.semperis.lab und würde zu einem ERR_WRONG_REALM-Fehler führen, da die lokale Domäne des DCs child1.semperis.lab ist. Diese Information wird im nächsten Abschnitt wichtig sein.
Schließlich kann diese resultierende Verweisung für semperis.lab verwendet werden, um STs für die Domäne semperis.lab anzufordern. Abbildung 16 zeigt die ST-Anfrage, die vom Benutzer lowpriv@grandchild1.child1.semperis.lab an den DC SDC1.semperis.lab für den SPN-Host/SDC1.semperis.lab gestellt wurde. Da der Vertrauenspfad erlaubt ist, war diese Anfrage erfolgreich, obwohl zwischen den beiden beteiligten Domänen kein direktes Vertrauen besteht(Abbildung 17).
Mit dieser Methode zur Beantragung von Verweisen für vertrauenswürdige Domänen können Sie STs für jeden Dienst innerhalb jeder Domäne anfordern, für die der Vertrauenspfad zulässig ist.
Das nicht-transitive Vertrauen transitiv machen
Wie ist es also möglich, externe Trusts zu durchlaufen, um sich bei Domänen zu authentifizieren, die eigentlich verboten sein sollten?
Die Domänen semperisaz.lab und grandchild1.child1.semperis.lab haben ein bidirektionales externes Vertrauen. Daher ist es nach dem Abrufen eines TGT für ein beliebiges Konto innerhalb der Domäne semperisaz.lab möglich, eine Überweisung für grandchild1.child1.semperis.lab anzufordern(Abbildung 18, Abbildung 19).
Diese Verweisung kann verwendet werden, um STs für Dienste in der Domäne grandchild1.child1.semperis.lab anzufordern. Der Versuch, eine Verweisung auf andere Domänen innerhalb desselben Forest (z.B. child1.semperis.lab) zu erhalten, gibt jedoch erwartungsgemäß einen ERR_PATH_NOT_ACCEPTED-Fehler zurück(Abbildung 20).
Dieser Fehler tritt auf, weil das Vertrauen semperisaz.lab -> granchild1.child1.semperis.lab nicht transitiv ist. Daher ist der Pfad von semperisaz.lab zu child1.semperis.lab nicht zulässig(Abbildung 21).
Sie können jedoch einen lokalen TGT für grandchild1.child1.semperis.lab anfordern. Ich nenne dies ein lokales TGT, weil im Gegensatz zur Verweisung - die eine ServiceRealm (srealm) von semperisaz.labhat - dieServiceRealm dieses TGTs grandchild1.child1.semperis.lab ist(Abbildung 22, Abbildung 23).
Mit diesem lokalen TGT kann nun eine Überweisung für child1.semperis.lab angefordert werden(Abbildung 24, Abbildung 25).
Sie haben nun eine brauchbare Referenz, mit der Sie STs für child1.semperis.lab anfordern können, und zwar unter Verwendung eines beliebigen Kontos aus der Domäne semperisaz.lab und ohne Änderungen an Trusts oder Konten innerhalb von AD vorzunehmen. Abbildung 26 und Abbildung 27 zeigen eine ST-Anfrage vom DC sc1dc1.child1.semperis.lab für den Dienst host/sc1dc1.child1.semperis.lab als Benutzer lowpriv@semperisaz.lab.
Außerdem kann diese Methode verwendet werden, um in jeder Domäne innerhalb desselben Forest zu springen, in dem grandchild1.child1.semperis.lab existiert. Wir können dies demonstrieren, indem wir eine Verweisung auf die Stammdomäne semperis.lab anfordern. Eine Verweisung wurde für semperis.lab vom DC sc1dc1.child1.semperis.lab als Benutzer lowpriv@semperisaz.lab angefordert(Abbildung 28, Abbildung 29).
Glücklicherweise ist das Springen über weitere Trusts außerhalb des Forests (externe oder Forest-Trusts) mit dieser Methode nicht möglich. Wie Abbildung 3 zeigt, hat die Stammdomäne semperis.lab eine bidirektionale externe Vertrauensstellung mit treetest.lab. Anhand dieser Vertrauensstellung können Sie diese Einschränkung demonstrieren(Abbildung 30, Abbildung 31).
Dies verhindert zumindest, dass ein Angreifer mit dieser Methode in einen anderen Forest hüpfen kann. Dennoch ist dieses nicht-transitive Vertrauensproblem eindeutig nützlich für Angreifer, die versuchen, ihre Privilegien innerhalb eines Forests über einen Trust hinweg zu erhöhen. Angreifer könnten Domäneninformationen von vermeintlich unzulässigen Domänen abfragen, sensiblere Domänen oder Domänen mit potenziell schwächerer Sicherheit abfragen oder Kerberoasting-Angriffe oder NTLM-Authentifizierungszwang auf Domänen durchführen, von denen angenommen wird, dass sie unzulässig sind.
Weiter hüpfen
Obwohl Angreifer mit der in diesem Beitrag beschriebenen Methode allein nicht weiterkommen, könnte das Problem neue Angriffsmöglichkeiten eröffnen. Ich habe bereits einen Beitrag geschrieben, in dem ich gezeigt habe, dass es möglich ist, Rechnerkonten über Vertrauensstellungen hinweg zu erstellen und welche Auswirkungen das hat. Wenn Sie diese Methode des Domain-Hoppings mit dieser neuen Methode kombinieren, können Sie die am Ende des vorherigen Abschnitts beschriebene Einschränkung überwinden.
Mithilfe der für semperis.lab abgerufenen Referenz (am Ende des vorherigen Abschnitts) ist es möglich, ein Ticket für den LDAP-Dienst auf einem DC in semperis.lab anzufordern. Hier wurde ein ST für ldap/sdc1.semperis.lab angefordert, wobei die Referenz für semperis.lab als Benutzer lowpriv@semperisaz.lab verwendet wurde(Abbildung 32, Abbildung 33).
Diese ST kann injiziert und verwendet werden, um ein Maschinenkonto direkt in semperis.lab zu erstellen, wenn die Konfiguration Authentifizierte Benutzer zulässt, was die Standardeinstellung ist(Abbildung 34).
Diese Aktion veranlasst den DC sdc1.semperis.lab, das Maschinenkonto TestComp innerhalb der Domäne semperis.lab zu erstellen(Abbildung 35).
Das neue TestComp-Maschinenkonto ist ein lokales Konto innerhalb der Domäne semperis.lab. Jetzt können Sie einen TGT für dieses Maschinenkonto abrufen(Abbildung 36, Abbildung 37).
Dieses Maschinenkonto TGT ist berechtigt, eine Verweisung auf die vertrauenswürdige Domäne treetest.lab zu beantragen. Das Maschinenkonto TGT kann verwendet werden, um eine Verweisung für die Domäne treetest.lab vom DC SDC1.semperis.lab anzufordern(Abbildung 38, Abbildung 39).
Schließlich kann das in diesem Beitrag beschriebene Problem genutzt werden, um Zugriff auf die unzugängliche Domäne dsptest.lab zu erhalten. Fordern Sie zunächst ein lokales TGT für treetest.lab an. Das lokale TGT wird unter Verwendung des Verweises für treetest.lab als Konto TestComp$@semperis.lab vom DC TDC1.treetest.lab angefordert(Abbildung 40, Abbildung 41).
Als nächstes verwenden Sie diesen lokalen TGT, um eine Überweisung für dsptest.lab anzufordern. Abbildung 42 und Abbildung 43 zeigen, dass eine Verweisung für die Domäne dsptest.lab vom DC TDC1.treetest.lab als Benutzer TestComp$@semperis.lab beantragt wurde.
Die Kombination dieser beiden Methoden könnte es ermöglichen, sehr tief in AD-Unternehmensinfrastrukturen einzudringen, indem ein beliebiges Konto mit niedrigen Privilegien in einer Domäne verwendet wird, die eine externe Vertrauensstellung zu einer beliebigen Domäne innerhalb eines Forest hat.
Entdeckung der Verwundbarkeit der Transitivität des Vertrauens
Angesichts der Antwort von Microsoft besteht die einzige Möglichkeit, das Problem zu vermeiden, darin, externe Vertrauensstellungen zu entfernen.
Wenn es nicht möglich ist, alle externen Vertrauensstellungen zu entfernen, müssen Sie auf das Windows-Ereignis 4769(Ein Kerberos-Service-Ticket wurde angefordert) achten. Das erste Anzeichen dafür ist, dass ein lokales TGT von einem Konto in einem anderen Forest angefordert wurde(Abbildung 44).
Hier ist das Feld Kontodomäne eine Domäne, die zu einem anderen Forest gehört, und der Dienstname lautet krbtgt. Auf dieses Ereignis folgt ein weiteres Ereignis 4769, das eine Überweisung anfordert(Abbildung 45).
Hier ist die Kontodomäne eine Domäne in einer anderen Gesamtstruktur und der Dienstname eine andere Domäne in der lokalen Gesamtstruktur.
Beachten Sie, dass diese beiden Ereignisse auf verschiedenen DCs innerhalb derselben Domäne auftreten können. Die Ereignisse müssen nicht auf demselben DC auftreten. Zu diesem Zeitpunkt haben alle angeforderten STs (Ereignis 4769), die diese Verweisung verwenden, eine Kontodomäne, die eine Domäne enthält, die nicht zur Authentifizierung bei der lokalen Domäne zugelassen werden sollte.
Die Überwachung dieser Ereignisse und die Erkennung dieser Art von Angriffen werden in einer zukünftigen Version von Semperis Directory Services Protector (DSP).
Wem können Sie vertrauen?
Wie Sie sehen, ist die offizielle Beschreibung von externen nicht-transitiven Vertrauensstellungen irreführend. Wenn Sie eine externe, nichttransitive Vertrauensstellung erstellen, müssen Sie akzeptieren, dass jedes Konto innerhalb der vertrauenswürdigen Domäne in der Lage ist, sich bei jeder Domäne innerhalb der gesamten Gesamt struktur, in der sich die vertrauenswürdige Domäne befindet, zu authentifizieren.
Wie im Abschnitt "Hopping Further" dieses Beitrags gezeigt, ist es die beste Vorgehensweise, die Erstellung von Computerkonten durch authentifizierte Benutzer zu verbieten. Wenn Sie dies nicht tun, sind nicht nur die Domänen innerhalb der Gesamtstruktur einem höheren Angriffsrisiko ausgesetzt, sondern auch alle Domänen (und die Gesamtstruktur, in der sie sich befinden), die eine externe Vertrauensstellung mit einer Domäne innerhalb der Gesamtstruktur haben, sind einem höheren Risiko ausgesetzt, da sie in der Lage sind, Computerkonten über Vertrauensstellungen hinweg zu erstellen und sich gegenüber Domänen zu authentifizieren, denen dies untersagt werden sollte. (Weitere Informationen über die Kontingentierung von Maschinenkonten und darüber, wie Sie die Erstellung von Maschinenkonten mit niedrigen Privilegien verhindern können, finden Sie in Kevin Robertsonshervorragendem Beitrag "MachineAccountQuota is USEFUL Sometimes").
Zumindest hoffe ich, dass dieser Beitrag Systemadministratoren über das reale Risiko informiert, das mit der Implementierung externer Trusts verbunden ist.
Zeitleiste
- 4. Mai 2022: MSRC-Fall erstellt
- 12. Mai 2022: Der Fallstatus wurde auf „Überprüfung/Repro“ geändert.
- 17. Juni 2022: Der Status des Falls wurde auf "Entwickeln" geändert, mit einer E-Mail, in der es heißt: "Wir haben das von Ihnen gemeldete Verhalten bestätigt. Wir werden unsere Untersuchung fortsetzen und entscheiden, wie wir dieses Problem angehen."
- 17. Juni 2022: Der Fallstatus wurde auf "Vollständig - Gelöst" geändert.
- 24. August 2022: Kommentar zum Fall hinterlassen, um den Fallstatus zu erfahren
- 2. September 2022: Follow-up-Kommentar zum Fall, um den Status des Falls zu erfahren
- 14. September 2022: Nachfass-E-Mail gesendet, um den Fallstatus zu erfahren
- 29. September 2022: E-Mail erhalten, in der erklärt wird, dass das Problem nicht als sicherheitsrelevant eingestuft wurde
- 07. März 2023: Öffentliche Bekanntgabe
Danksagung
- Will Schroeder für die Entwicklung von Rubeus, ohne die diese Forschung nicht möglich gewesen wäre
- An alle, die diesen Beitrag gelesen und uns ihr Feedback gegeben haben, einschließlich:
- Elad Shamir
- Harjinder Nijjar
- Andrew Schwartz
- Jonny Johnson
Mehr erfahren
Wollen Sie mehr AD-Sicherheitsforschung? Sehen Sie sich diese Artikel an.
