Elad Shamir

Manche Leute sind ein Hammer auf der Suche nach einem Nagel, aber ich bin ein Hammer auf der Suche nach der Kerberos-Delegation. Als ich also hörte, dass in BloodHound 4.1 ein WriteSPN-Edge eingeführt wurde, begann ich, alternative Missbrauchstechniken jenseits von gezieltem Kerberoasting zu erforschen, und ich fand einen Edge Case (Wortspiel beabsichtigt), der mit Kerberos Constrained Delegation verkettet werden kann.

Tl;dr

Angenommen, ein Angreifer kompromittiert ein Konto, das auf eingeschränkte Delegation eingestellt ist, aber nicht über die Berechtigung SeEnableDelegation verfügt. Der Angreifer ist nicht in der Lage, die Einschränkungen zu ändern (msDS-AllowedToDelegateTo). Wenn der Angreifer jedoch über WriteSPN-Rechte für das mit dem Ziel-SPN verknüpfte Konto sowie für ein anderes Computer-/Dienstkonto verfügt, kann der Angreifer den SPN vorübergehend entführen (eine Technik, die SPN-Jacking genannt wird), ihn dem anderen Computer/Server zuweisen und einen vollständigen S4U-Angriff durchführen, um ihn zu kompromittieren.

Auch wenn der Ziel-SPN derzeit mit keinem Konto verbunden ist, kann der Angreifer ihn sich auf ähnliche Weise aneignen.

Ich werde der Erste sein, der zugibt, dass dies keine bahnbrechende Entdeckung ist, aber es kann unter bestimmten Umständen scheinbar aussichtslose Angriffspfade wiederbeleben. SPN-Jacking kann auch eine alternative Übernahmetechnik sein, wenn RBCD oder Shadow Credentials nicht durchführbar sind.

Kerberos Delegationsfibel

Die Kerberos-Delegation ist ein Mechanismus, der es Diensten ermöglicht, sich gegenüber anderen Diensten als Benutzer auszugeben. Ein Benutzer kann beispielsweise auf eine Front-End-Anwendung zugreifen und diese Anwendung kann wiederum mit der Identität und den Berechtigungen des Benutzers auf eine Back-End-API zugreifen.

Die Kerberos-Delegation gibt es in drei Varianten: Unbeschränkte Delegierung, eingeschränkte Delegierung und ressourcenbasierte eingeschränkte Delegierung (RBCD).

Uneingeschränkte Delegation

Bei der uneingeschränkten Delegation müssen Benutzer ihr Ticket (TGT) an den Front-End-Dienst (Server A) senden. Dann kann der Front-End-Dienst dieses Ticket verwenden, um den Benutzer bei jedem beliebigen Dienst, einschließlich dem Back-End-Dienst (Server B), auszugeben.

Eingeschränkte Delegation

Die eingeschränkte Delegation ermöglicht es dem Front-End-Dienst (Server A), Kerberos-Service-Tickets für Benutzer für eine vordefinierte Liste von Diensten zu erhalten, die durch ihren Service Principal Name (SPN) spezifiziert sind, wie z. B. der Back-End-Dienst, Server B.

Beachten Sie, dass Constrained Delegation es dem Dienst ermöglicht, sich als Benutzer auszugeben, unabhängig davon, ob diese sich beim Dienst authentifiziert haben oder nicht. Viele denken, dass dies von der Konfiguration des Attributs TrustedToAuthForDelegation abhängt. In Verbindung mit der ressourcenbasierten eingeschränkten Delegation kann diese Einschränkung jedoch umgangen werden, wie ich in diesem Blogbeitrag erläutere.

Ressourcenbasierte eingeschränkte Delegation

RBCD ist der eingeschränkten Delegation sehr ähnlich, mit dem Unterschied, dass die Richtung der Einschränkung umgedreht ist. Sie legt fest, wer an einen Dienst delegieren darf und nicht, an wen der Dienst delegieren darf. Mit anderen Worten: Wenn Server A bei der eingeschränkten Delegation an Server B delegieren darf, wird die Einschränkung in einem Attribut von Server A konfiguriert. Bei RBCD wird sie in einem Attribut von Server B konfiguriert.

Ein weiterer wichtiger Unterschied zwischen eingeschränkter Delegation und RBCD besteht darin, dass bei eingeschränkter Delegation der SPN des Zieldienstes angegeben wird. Im Gegensatz dazu wird bei RBCD die SID des Ursprungsdienstes in einem Security Descriptor angegeben.

Erforderliche Privilegien

Die Konfiguration von Unconstrained Delegation und Constrained Delegation erfordert das Recht SeEnableDelegation, das standardmäßig nur Domänenadministratoren gewährt wird. Selbst wenn ein Benutzer die volle Kontrolle (GenericAll) über ein AD-Konto hätte, könnte er daher keinen dieser Kerberos-Delegierungstypen konfigurieren, ohne auch über das Privileg SeEnableDelegation zu verfügen. Im Gegensatz zu Unconstrained Delegation und Constrained Delegation erfordert RBCD das Recht, das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity zu ändern, aber keine besonderen Berechtigungen.

Beachten Sie, dass Benutzer besondere Berechtigungen benötigen, um die Konfiguration der eingeschränkten Delegation zu ändern, aber keine besonderen Berechtigungen für die Änderung von SPNs erforderlich sind. Daher kann es interessant sein, Szenarien mit der Kompromittierung der eingeschränkten Delegation aus einem anderen Blickwinkel anzugehen - durch Manipulation des SPN-Attributs statt der Delegationskonfiguration.

Die Bühne bereiten

Angenommen, es gibt drei Server in der Umgebung: ServerA, ServerB und ServerC. ServerA ist mit eingeschränkter Delegation auf einen bestimmten SPN konfiguriert. Der Angreifer kompromittiert ServerA und das Konto NotAdmin, das über WriteSPN-Rechte auf Computer-/Dienstkonten in der Umgebung verfügt. Das Ziel des Angreifers ist es, ServerC zu kompromittieren.

Ghost SPN-Jacking

Das erste Szenario ist das einfachste. ServerA ist für die eingeschränkte Delegation an einen SPN konfiguriert, der zuvor mit einem Computer- oder Dienstkonto verbunden war, das nicht mehr existiert. Es könnte sich um einen Standard-SPN wie cifs/hostname handeln, der mit einem gelöschten Computer-/Dienstkonto oder einem umbenannten berechneten Konto verbunden ist, wenn die SPNs entsprechend aktualisiert wurden. Oder das Konto könnte ein benutzerdefinierter SPN mit einer nicht standardmäßigen Dienstklasse sein, der aus dem Computer-/Dienstkonto entfernt wurde, oder das Konto selbst könnte nicht mehr existieren.

In diesem Szenario kann der Angreifer den betroffenen SPN zu ServerC hinzufügen und dann den vollständigen S4U-Angriff mit dem Konto von ServerA ausführen, um ein Service-Ticket für einen privilegierten Benutzer auf ServerC zu erhalten.

Der Servicename dieses Tickets wäre für den Zugriff auf ServerC nicht gültig, da der Hostname nicht übereinstimmt, und die Serviceklasse könnte nutzlos sein. Wichtig ist jedoch, dass das Ticket für ServiceC verschlüsselt ist und der Servicename nicht im verschlüsselten Teil des Tickets enthalten ist, so dass der Angreifer ihn in einen gültigen Namen ändern kann.

Schließlich kann der Angreifer das Ticket übergeben und ServerC kompromittieren.

Die Angriffskette wird im folgenden Diagramm dargestellt:

Der Angriff wird im folgenden Screenshot demonstriert:

Live SPN-Jacking

Das zweite Szenario ist etwas ausgeklügelter. ServerA ist für eingeschränkte Delegation an einen SPN konfiguriert, der derzeit mit ServerB verbunden ist, und der Angreifer hat WriteSPN-Rechte auf ServerB und ServerC.

In vollständig gepatchten Umgebungen wäre es nur Domänenadministratoren gestattet, widersprüchliche SPNs zu konfigurieren, d.h. SPNs, die mit zwei oder mehr verschiedenen Konten verbunden sind. Wenn der Angreifer in diesem Szenario also versuchen würde, den Ziel-SPN zu ServerC hinzuzufügen, würde der DC diese Änderung ablehnen, da er bereits mit ServerB verbunden ist.

Der Angreifer kann diese Barriere umgehen, indem er den Ziel-SPN vorübergehend von ServerB entfernt und ihn erst dann zu ServerC hinzufügt. Der Angreifer kann dann den vollständigen S4U-Angriff mit dem Konto von ServerA durchführen, um ein Service-Ticket für einen privilegierten Benutzer auf ServerC zu erhalten.

Wie im vorherigen Szenario wäre der Dienstname dieses Tickets für den Zugriff auf ServerC nicht gültig. Wichtig ist jedoch, dass das Ticket für ServerC verschlüsselt ist und der Servicename nicht im verschlüsselten Teil des Tickets enthalten ist, so dass der Angreifer ihn ändern kann.

Schließlich kann der Angreifer das Ticket übergeben und ServerC kompromittieren.

Ein umsichtiger Angreifer sollte die Änderungen auch rückgängig machen, indem er den Ziel-SPN von ServerC entfernt und ihn auf ServerB wiederherstellt.

Die Angriffskette wird im folgenden Diagramm dargestellt:

SPN-Jacking mit der Serviceklasse HOST

Noch interessanter wird es, wenn der angestrebte SPN nicht explizit definiert ist. Standardmäßig haben Computerkonten SPNs, die mit den Dienstklassen TERMSRV, RestrictedKrbHost und HOST verbunden sind. Wenn andere Dienste installiert sind, wie LDAP oder SQL Server, werden auch für diese zusätzliche SPNs hinzugefügt.

Die Dienstklasse HOST wird standardmäßig den folgenden Dienstklassen zugeordnet:
alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc.

Wenn der Angreifer versucht, eine HOST zugeordnete Serviceklasse anzuvisieren, würde der Domänencontroller das Hinzufügen dieser Serviceklasse zu ServerC ablehnen, obwohl sie nicht direkt mit ServerB verbunden ist. Der Angreifer müsste zunächst die HOST-SPNs von ServerB entfernen und dann den Ziel-SPN explizit zu ServerC hinzufügen. Nachdem er jedoch den Ziel-SPN zu ServerC hinzugefügt hat, kann der Angreifer die HOST-SPNs wieder zu ServerB hinzufügen, ohne dass er auf Validierungsfehler stößt, obwohl bereits ein gemappter SPN mit ServerC verbunden ist, wie der folgende Screenshot zeigt:

Wenn Sie Service-Tickets für den zweideutigen SPN cifs/SERVERB im obigen Screenshot anfordern, stellt der Domain Controller sie für ServerC und nicht für ServerB aus.

Die Angriffskette wird im folgenden Diagramm dargestellt:

Wie können Angreifer SPN-Jacking nutzen?

Wenn ein Angreifer ein Konto mit GenericAll- oder GenericWrite-Rechten auf Computerkonten kompromittiert, könnte der Angreifer RBCD oder Shadow Credentials verwenden, um den zugehörigen Host oder Dienst zu kompromittieren. Ich vermute, dass die Kompromittierung eines Kontos, das nur über WriteSPN-Rechte für Computerkonten verfügt, nicht sehr wahrscheinlich ist. In Verbindung mit der Kompromittierung eines Hosts mit bereits konfigurierter eingeschränkter Delegation könnten Angreifer diese Technik jedoch in Umgebungen einsetzen, in denen RBCD und Shadow Credentials überwacht oder blockiert werden. Verteidiger sollten die folgenden Empfehlungen befolgen, um SPN-Jacking-Angriffe zu entschärfen.

Erkennen von SPN-Jacking

Änderungen am Attribut ServicePrincipalName eines Computerkontos erzeugen Sicherheitsereignisse mit der ID 4742 (Ein Computerkonto wurde geändert) auf dem Domänencontroller. Die Ereignisdetails zeigen die geänderten Attribute und ihren neuen Wert. Defenders kann SPNs mit einem von den DNS-Namen des Computers abweichenden Hostnamen erkennen, wie im folgenden Screenshot gezeigt:

Das Entfernen der Dienstklasse HOST aus einem Computerkonto kann ebenfalls verdächtig sein.

Der S4U-Angriff erzeugt zwei Sicherheitsereignisse mit der ID 4769 (Ein Kerberos-Service-Ticket wurde angefordert).

Das erste Ereignis ist für S4U2Self. Defenders kann es erkennen, wenn die Kontoinformationen und die Serviceinformationen auf dasselbe Konto verweisen, wie im Screenshot unten gezeigt:

Das zweite Ereignis ist für S4U2Proxy. Defenders kann es erkennen, wenn das Attribut Transited Services nicht leer ist, wie im Screenshot unten gezeigt:

Verhindern von SPN-Jacking

Verteidiger können verschiedene Taktiken anwenden, um diese Art von Missbrauch zu verhindern:

  • Überprüfen Sie Active Directory regelmäßig auf eingeschränkte Delegationen, die auf Geister-SPNs verweisen
  • Überprüfen Sie Active Directory regelmäßig auf anomale WriteSPN-Rechte
  • Fügen Sie alle privilegierten Konten zur Gruppe Geschützte Benutzer hinzu, um alle Versuche zu blockieren, sich über die Kerberos-Delegation als sie auszugeben.

Angreifer können den SPN von Computer-/Dienstkonten manipulieren, um vorkonfigurierte eingeschränkte Delegierung auf unbeabsichtigte Ziele umzuleiten, auch ohne SeEnableDelegation-Rechte zu erlangen.

Die in diesem Artikel beschriebenen Szenarien sind zwar nicht alltäglich, aber sie können praktikable Angriffswege darstellen, wenn ein kompromittiertes Konto für eine eingeschränkte Delegation konfiguriert ist, die ansonsten als harmlos oder als Alternative zu RBCD und Shadow Credentials betrachtet werden würde.

Verteidiger sollten die notwendigen Maßnahmen ergreifen, um solche Angriffe zu erkennen und zu verhindern.

Referenzen

Dieser Beitrag wurde auch auf shenaniganslabs.io und eladshamir.com veröffentlicht.