Elad Shamir

Manche Menschen sind wie ein Hammer auf der Suche nach einem Nagel, ich hingegen bin wie ein Hammer auf der Suche nach einer Kerberos-Delegierung. Als ich also erfuhr, dass in BloodHound 4.1 ein „WriteSPN“-Edge eingeführt wurde, begann ich, alternative Missbrauchstechniken jenseits des gezielten „Kerberoasting“ zu untersuchen, und stieß dabei auf einen Grenzfall (das Wortspiel ist beabsichtigt), der sich mit der „Kerberos Constrained Delegation“ verketten lässt.

Tl;dr

Angenommen, ein Angreifer erlangt Zugriff auf ein Konto, für das eine eingeschränkte Delegierung eingerichtet ist, verfügt jedoch nicht über die Berechtigung „SeEnableDelegation“. Der Angreifer kann die Einschränkungen (msDS-AllowedToDelegateTo) nicht ändern. Verfügt der Angreifer jedoch über „WriteSPN“-Rechte für das mit dem Ziel-SPN verknüpfte Konto sowie für ein anderes Computer- oder Dienstkonto, kann er das SPN vorübergehend kapern (eine als „SPN-Jacking“ bezeichnete Technik), es dem anderen Computer oder Server zuweisen und einen vollständigen S4U-Angriff durchführen, um diesen zu kompromittieren.

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

Ich gebe gerne zu, dass dies keine bahnbrechende Entdeckung ist, doch unter bestimmten Umständen kann sie scheinbar aussichtslose Angriffswege wiederbeleben. SPN-Jacking kann zudem eine alternative Übernahme-Technik darstellen, falls RBCD oder Shadow Credentials nicht in Frage kommen.

Kerberos Delegationsfibel

Die Kerberos-Delegierung ist ein Mechanismus, der es Diensten ermöglicht, gegenüber anderen Diensten die Rolle eines Benutzers zu übernehmen. So kann beispielsweise ein Benutzer auf eine Frontend-Anwendung zugreifen, und diese Anwendung kann wiederum mit der Identität und den Berechtigungen des Benutzers auf eine Backend-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 einer eingeschränkten Delegierung an einen bestimmten SPN konfiguriert. Der Angreifer hat ServerA sowie das Konto „NotAdmin“ kompromittiert, das über „WriteSPN“-Rechte für Computer- und 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 anschließend den vollständigen S4U-Angriff unter Verwendung des Kontos von ServerA durchführen, um ein Dienstticket für einen privilegierten Benutzer auf ServerC zu erlangen.

Der Dienstname dieses Tickets wäre für den Zugriff auf ServerC nicht gültig, da der Hostname nicht übereinstimmen würde und die Dienstklasse möglicherweise unbrauchbar wäre. Entscheidend ist jedoch, dass das Ticket für Dienst C verschlüsselt ist und der Dienstname nicht im verschlüsselten Teil des Tickets enthalten ist, sodass ein 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 danach zu ServerC hinzufügt. Anschließend kann der Angreifer den vollständigen S4U-Angriff unter Verwendung des Kontos 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.

Sollte der Angreifer versuchen, eine Dienstklasse anzusprechen, die HOST zugeordnet ist, domain controller der domain controller das Hinzufügen dieser Dienstklasse zu ServerC ablehnen, auch wenn sie nicht direkt mit ServerB verknüpft ist. Der Angreifer müsste zunächst die HOST-SPNs von ServerB entfernen und dann die Ziel-SPN explizit zu ServerC hinzufügen. Nach dem Hinzufügen der Ziel-SPN zu ServerC kann der Angreifer jedoch die HOST-SPNs wieder zu ServerB hinzufügen, ohne dass Validierungsfehler auftreten, obwohl bereits eine zu ServerC zugeordnete SPN vorhanden ist, wie im folgenden Screenshot dargestellt:

Wenn Service-Tickets für den mehrdeutigen SPN „cifs/SERVERB“ (wie im obigen Screenshot dargestellt) angefordert werden, Domain Controller der Domain Controller diese für ServerC statt für ServerB Domain Controller .

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 lösen Sicherheitsereignisse mit der ID 4742 (Ein Computerkonto wurde geändert) im „ domain controller “ aus. In den Ereignisdetails werden die geänderten Attribute und deren neue Werte angezeigt. Defenders können SPNs erkennen, deren Hostname von den DNS-Namen des Computers abweicht, wie im folgenden Screenshot dargestellt:

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.