Kerberos-Delegierung im Active Directory: Angriffsvektoren und Schutzmaßnahmen

Dieser Artikel befasst sich ausgiebig mit den Gefahren von Kerberos-Delegierung und soll dir einen Überblick verschaffen, welche Sicherheitsvorkehrungen getroffen werden können, um deine Active Directory Domäne so sicher wie möglich zu gestalten. Dazu schauen wir uns die Funktionsweise von Unconstrained und Constrained Kerberos-Delegierung genauer an. Resource Based Constrained Delegation lasse ich für diesen Artikel bewusst außen vor. Solltest du daran interessiert sein, wie man Kerberos-Delegierung im Active Directory konfiguriert, kann ich dir diesen Microsoft Docs Artikel empfehlen. Starten wir direkt mit dem ersten Kapitel.

Kerberos-Delegierung

Wozu braucht man Kerberos-Delegierung?

Wozu braucht man eine Kerberos-Delegierung überhaupt? Ein Beispiel:

Unsere Domäne besteht aus einem Domain Controller, Webserver und einem Datenbankserver. Unser Webserver reagiert auf HTTP-Requests und ist im Backend an die MSSQL-Instanz am Datenbankserver angebunden. Wir melden uns am Webserver mit unseren AD-Zugangsdaten an und möchten einen Eintrag in der Datenbank anpassen. Jetzt gäbe es zwei unterschiedliche Implementierungsmöglichkeiten:

1. Ohne Delegierung: Der Webserver spricht mit der Datenbank mit eigenen, vordefinierten Credentials (beispielsweise eines reinen SQL-Users) oder dem eigenen Computer-Konto. Der User authentifiziert sich also nur gegenüber dem Webserver. Alles weitere übernimmt der Webserver mit seinen Zugangsdaten.
2. Mit Delegierung: Der Webserver tritt gegenüber der Datenbank im Namen des zugreifenden Nutzers auf. Er benötigt also eine Möglichkeit, sich gegenüber dem MSSQL mit der Identität des Nutzers zu authentifizieren und nicht mit seinen eigenen Zugangsdaten.

Wieso sollte man nun aber überhaupt Variante 2 implementieren, wenn dies doch einen zusätzlichen Angriffsvektor öffnet? Dafür gibt es mehrere Gründe:

• Der Webserver greift stellvertretend für den jeweiligen Nutzer auf die Datenbank zu. Somit wird automatisch im Audit der korrekte User protokolliert.
• Wurden Berechtigungen auf Datenbank- oder Instanz-Niveau gesetzt, greifen diese sofort. Es ist keine mühsame Implementierung eines Berechtigungssystems am Webserver notwendig. Gerade in Enterprise Applikationen ist das ein entscheidender Faktor.
• Der Webserver allein hat keinerlei Zugriff auf die MSSQL-Instanz (Least Privilege) und benötigt immer einen authentifizierten Nutzer.

Im Active Directory hat man bei einem AD-Objekt folgende Delegierungs-Einstellungsmöglichkeiten:

Solltest du noch nicht wissen, wie Kerberos grundsätzlich aufgebaut ist und funktioniert, würde ich dir vorab diesen Artikel empfehlen. Ansonsten können die nachfolgenden Kapitel schwer verständlich sein.

Unconstrained Delegation

Unconstrained Delegation bedeutet im Grunde, dass man dem jeweiligen AD-Objekt erlaubt, sich als jede beliebige Person (bzw. AD-Identität) auszugeben. Das ist im Grunde ein Freifahrtschein und läuft, um bei dem Beispiel von vorhin zu bleiben, wie folgt ab:

1. Der Nutzer authentifiziert sich beim Webserver via Kerberos und fordert dafür beim Domain Controller ein Service-Ticket an (wie wir es vom Kerberos Protokoll gewohnt sind)
2. Der Domain Controller prüft das Computerkonto des Webservers und erkennt, dass dort „Unconstrained Delegation“ gesetzt ist. Das ist das Signal, dass der Client des Nutzers ein weiterleitbares TGT anfordern und dem Webserver mitschicken darf.
3. Der Client des Nutzers bekommt das TGS-Ticket für den Zugriff auf den Webserver. Im TGS-Ticket (bzw. im AP-REQ Authenticator Teil) ist dabei aber noch das forwarded-TGT des Nutzers eingebettet. Das ist nur der Fall, wenn „Unconstrained Delegation“ für das Computerkonto aktiviert wurde und birgt ein großes Sicherheitsrisiko, denn wie wir wissen, kann man mit dem TGT des Nutzers beliebige weitere TGS-Tickets für andere Services beim DC anfragen.
4. Der Client schickt nun das TGS-Ticket an den Webserver.
5. Der Webserver liest im Authenticator der AP-REQ-Nachricht das mitgelieferte TGT und speichert es in der lokalen LSASS. Dieser besitzt nun eine vollwertige Kopie des Nutzer-TGTs und kann sich damit bei Bedarf selbst ein TGS-Ticket für den MSSQL-Server holen. Das TGT ist universell einsetzbar und kann zur Authentifizierung für jeden Domänendienst verwendet werden.

Und genau das ist das große Problem. Man stelle sich nun vor, das Computerkonto des Webservers wäre kompromittiert. Ein Angreifer hat administrativen Zugriff darauf und kann sich ausgestellte Nutzer-TGTs aus dem LSASS-Speicher holen. Hat sich dann noch ein Domain Admin in der Vergangenheit (innerhalb des Ablaufdatums des TGTs) authentifiziert, ist die Domäne innerhalb von Minuten kompromittiert.

Constrained Delegation

Weil das Thema nicht schon kompliziert genug ist, gibt es Constrained Delegation in zwei Geschmacksrichtungen:

• Use Kerberos Only
• Use any authentication protocol (auch bekannt als „Protocol Transition“)

Kerberos Only

Um darauf einzugehen, schauen wir uns einmal den Authentifizierungsflow an, wenn wir Kerberos-Only verwenden:

Der Client ist bereits an der Domäne angemeldet, besitzt also sein reguläres TGT. Anschließend möchte sich dieser via Kerberos am Webserver authentifizieren und bekommt vom Domain Controller ein forwardable TGS-Ticket für den Webserver (und nicht für den Datenbankserver). Der Webserver nutzt nun die S4U2Proxy-Erweiterung, um stellvertretend für den Nutzer ein Service-Ticket für den Datenbankserver anzufordern:

1. Der Webserver fragt beim DC ein TGS-Ticket für den Datenbankserver an und bettet dabei das weiterleitbare TGS-Ticket des Nutzers (das er bei der Anmeldung erhalten hat) als Nachweis im Feld additional-tickets des TGS_REQ ein.
2. Der Domain Controller prüft, ob das übergebene Ticket gültig ist und ob im Attribut msDS-AllowedToDelegateTo des Webserver-Computerkontos auch wirklich der SPN des Datenbankservers steht. Falls dem so ist, stellt der DC ein neues TGS-Ticket für den Datenbankserver im Namen des Nutzers aus und schickt es dem Webserver.
3. Der Webserver kann sich nun mit dem neuen TGS-Ticket beim Datenbankserver als der jeweilige Nutzer authentifizieren.

Doch was passiert, wenn der Client nicht via Kerberos auf die Applikation zugreifen kann? Beispielsweise weil es sich um eine Webapplikation handelt und der Client gar nicht Teil der Domäne ist oder einfach keinen Domain Controller erreicht? Hier kann die Authentifizierung beispielsweise auf NTLM zurückfallen. Da der oben genannte Flow ein TGS-Ticket des Clients und somit Kerberos voraussetzt, würde die Authentifizierung nicht mehr funktionieren.

Protocol Transition

Hier kommt erstmalig die Protocol Transition zum Tragen. Zusätzlich zur oben genannten S4U2Proxy-Erweiterung, kommt hier auch noch S4U2Self zum Einsatz. Diese Extension greift vor dem oben genannten Flow und holt sich für den jeweiligen User ein entsprechendes Service-Ticket. Der Knackpunkt: nicht der Client des Users fragt das Service-Ticket an, sondern der Webserver im Auftrag des Nutzers selbst.

1. Der Webserver möchte sich beim Datenbankserver stellvertretend für den Nutzer anmelden. Dazu meldet er sich beim Domain Controller mit seinem eigenen TGT und fragt mittels S4U2Self ein (non-forwardable) Service-Ticket für sich selbst an, ausgestellt im Namen des jeweiligen Nutzers. Dabei ist es nicht relevant, ob sich der Nutzer in diesem Zuge tatsächlich beim Webserver angemeldet hat. Der Webserver kann dieses Ticket unaufgefordert und selbstständig beim DC jederzeit einholen.
2. Der Domain Controller stellt ein Service-Ticket für den Webserver aus – im Namen des Nutzers, aber weiterhin nur für den Webserver selbst gültig.

Anschließend folgt wieder der oben angeführte Flow beim S4U2Proxy Protokoll.

Vergleich der beiden Kerberos-Delegierungen

Schauen wir uns zum besseren Verständnis die wichtigsten Unterschiede an:

Wird ein Server mit Unconstrained Delegation kompromittiert, ist jede AD-Identität in Gefahr, die sich am jeweiligen Service authentifiziert hat. Bei der Constrained Delegation hingegen können TGS-Tickets nur für Services angefragt werden, die explizit konfiguriert wurden. Allein das limitiert den Angriffsvektor massiv. Dadurch, dass beim Computerkonto des Webservers klar definiert ist, für welche SPNs dieser Service-Tickets anfragen darf, ist ein Lateral Movement innerhalb des ADs zwar möglich, aber bei korrekter Konfiguration stark eingeschränkt.

Das Thema wird auch exzellent und noch ausführlicher von SeverSerenity und Pixis erklärt (absolut empfehlenswert).

Die Angriffsvektoren

Wir sollten nun ausreichend geklärt haben, wie die Grundsätze der Kerberos-Delegierung funktionieren. Zwar lassen sich aus dem Kapitel zuvor schon klare Angriffsvektoren ableiten, ich möchte sie aber trotzdem noch einmal klar hervorheben.

Unconstrained Delegation

Hat sich ein Angreifer administrativen Zugriff auf einen Server verschafft, der Unconstrained Delegation im AD hinterlegt hat, hat dieser nun mehrere Möglichkeiten:

• Er wartet geduldig, bis sich am Webserver ein privilegierter Nutzer authentifiziert und holt sich dessen TGT aus dem LSASS Speicher des Servers. Mit diesem TGT kann er nun beliebige TGS-Tickets innerhalb der Domäne ausstellen lassen. Handelt es sich dabei um einen Domain Admin, ist die Domäne ab diesen Zeitpunkt vollständig kompromittiert.

Es geht aber auch noch schlimmer. Mittels Unconstrained Delegation kann der Angreifer unter den richtigen Bedingungen nicht nur die eigene Domäne übernehmen, sondern auch Domänen, die mittels Forest Trust angebunden sind. Dabei müssen nur folgende Voraussetzungen gegeben sein:

• Forest Trust mit aktivierter Delegierung
• Ein Server mit Unconstrained Delegation
• Ein Domain Controller in der Partner Domäne mit aktiviertem Print Spooler Dienst

Verschafft sich der Angreifer administrativen Zugriff auf den Server mit Unconstrained Delegation, kann er einen RPC-Call an den Domain Controller mit aktiviertem Print Spooler Dienst schicken. Dieser RPC-Call fordert den Domain Controller auf, sich beim kompromittierten Server mittels TGS-Ticket zu authentifizieren. Da der kompromittierte Server Unconstrained Delegation gesetzt hat, wird, wie wir das in den vorherigen Kapiteln herausgearbeitet haben, auch das TGT des Maschinenkontos des Domain Controllers mitgeschickt. Sobald der Angreifer im Besitz des TGT des Domain Controllers ist, ist die Partner Domäne vollständig kompromittiert.

Dazu hat Sean Metcalf einen interessanten Beitrag verfasst.

Constrained Delegation

Auch wenn Constrained Delegation deutlich sicherer ist, bringt es eigene, gravierende Angriffsvektoren mit sich. Sobald ein Angreifer die Kontrolle über ein Computerkonto erlangt, für das Constrained Delegation konfiguriert ist, kann er diese Rechte ausnutzen, um im Netzwerk lateral zu wandern oder Rechte auszuweiten.

Wir müssen hierbei strikt zwischen den beiden Varianten Kerberos Only und Protocol Transition unterscheiden.

Kerberos Only

Bei der Variante Kerberos Only fordert S4U2Proxy zwingend ein weiterleitbares TGS-Ticket eines echten Benutzers als Nachweis. Ist der Webserver kompromittiert, kann der Angreifer nicht einfach beliebig Identitäten fälschen. Er ist darauf angewiesen, dass sich ein Ziel-Benutzer aktiv am Dienst authentifiziert. Wenn dieser lange genug wartet, ist die Wahrscheinlichkeit aber nicht gering, dass sich doch einmal ein privilegierter Nutzer authentifiziert.

Aufgrund der eingeschränkten Delegierung auf bestimmte SPNs, ist der Angriffsvektor aber bedeutend geringer. Der Angreifer kann sich nur bei den in der Delegation hinterlegten Services authentifizieren. Das kann aber in vielen Fällen auch schon ausreichen, damit sich dieser lateral im Netzwerk bewegt und sich weitere Schwachstellen und Ziele sucht.

Protocol Transition

Die Option Protocol Transition ist aus Sicherheitssicht der gefährlichste Modus der Constrained Delegation. Da der Server hier mittels S4U2Self eigenständig Tickets im Namen beliebiger Nutzer anfordern kann, entfällt die Notwendigkeit, auf eine echte Benutzeranmeldung zu warten.

Das weitere Lateral Movement ist aber im Grunde gleich, wie bei der Kerberos Only Variante.

Sicherheitsvorkehrungen

Allgemein

Da wir nun über mögliche Angriffsvektoren gesprochen haben, dürfen entsprechende Sicherheitsmaßnahmen als Vorkehrung nicht fehlen:

• Verwendet unter keinen Umständen „Unconstrained Delegation“. Natürlich ist es immer am einfachsten, die Berechtigungen so weitläufig wie möglich zu setzen und wenn eine temporäre Lösung sich erstmal etabliert hat, wird diese auch so schnell nicht mehr umgebaut – glaubt mir, ich kenne das selbst. In diesem Fall bietet das allerdings eine riesige Angriffsfläche und Administratoren sollten ihre Domänen auf solche Fallstricke durchsuchen.
• Stattdessen verwendet, da wo möglich, immer „Resource Based Constrained Delegation“ oder „Constrained Delegation“ mit „Kerberos Only“.
• Setzt die Delegations mit Bedacht und nur jene, die absolut notwendig sind.
• Deaktiviert bei allen Identitäten die Delegierung, wenn diese nicht absolut notwendig ist.
• Verwendet bei allen sensiblen und administrativen Accounts das Flag „Account is sensitive and cannot be delegated“ oder fügt sie zur „Protected users“ Gruppe hinzu

Administrative Accounts schützen

Kerberos Delegierung ist grundsätzlich für jeden AD-Nutzer aktiviert. Es gibt aber Flags, welche die Delegierung für Accounts vollständig deaktiviert und das ist auch zugleich ein hervorragender Schutz.

Das Flag „Account is sensitive and cannot be delegated“ bietet genau diesen angesprochenen Schutz und kann pro AD-Nutzer aktiviert werden. Es ist ohnehin sehr empfehlenswert, dieses Flag für alle administrativen Accounts standardmäßig zu setzen. Hierbei wird jegliche Delegierung (Unconstrained und Constrained) für den Nutzer deaktiviert. Damit wird dem Domain Controller angewiesen, weder ein forwardable TGS-Ticket auszustellen (Constrained Delegation), noch das bestehende TGT weiterzuleiten (Unconstrained Delegation).

Wer einen Schritt weiter gehen möchte, kann seine administrativen Nutzer in die „Protected Users“ Gruppe aufnehmen. Hierbei wird nicht nur die Delegierung unterbunden, sondern auch beispielsweise NTLM vollständig deaktiviert (weitere Infos dazu in den Microsoft Docs). In vielen Fällen kann man administrative User allerdings nicht einfach in diese Gruppe aufnehmen, da erfahrungsgemäß beispielsweise NTLM nach wie vor weit verbreitet ist und man sich somit mit seinem Nutzer aussperrt.