CVE-2025-60704: Validierungsfehler in Windows Kerberos S4U: Von der Protokollumstellung zur Rechteausweitung

Kerberos Constrained Delegation ist der Identitätswechselmechanismus von Kerberos, der verwendet wird, wenn ein Dienst oder eine Anwendung im Namen eines Benutzers handeln muss. 

Im Juli 2025 stieß ich auf interessante Probleme bei der Art und Weise, wie Windows Integritätsprüfungen innerhalb des Identitätswechsel-Subprotokolls durchsetzt. 

Konkret ermöglichte eine veraltete RSA-MD4-Unterstützung in Kombination mit einem fehlenden kryptografischen Validierungsschritt auf Clientseite einer dieser Integritätsprüfungen die Manipulation von Feldern, die eigentlich geschützt werden sollten. Dies schließt die Identität des Benutzers ein, dessen Identität imitiert wird. 

Unter den richtigen Bedingungen kann dieses Verhalten missbraucht werden, um die Vertrauensannahmen der Delegation zu umgehen, was dazu führt, dass unautorisierter Zugriff und Rechteausweitung. 

Kerberos und Delegation: Hintergrund 

Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das auf starken kryptografischen Primitiven basiert. Sein Hauptziel ist die Bereitstellung von gegenseitige AuthentifizierungDadurch können sowohl der Benutzer als auch die Anwendung die Identität des jeweils anderen überprüfen. 

Identitätswechsel ist in Kerberos schon lange vorhanden. Die ursprüngliche MIT-Kerberos-Spezifikation führte einen Delegierungsmechanismus ein. RFC 4120 (2005) – was in der Praxis im Wesentlichen bedeutete Weitergeben des Tickets als Funktion. 

Microsoft entschied sich für eine andere Implementierung der Delegierung. Mit der Einführung von Service-for-User (S4U) in Windows Server 2008und spätere Verbesserungen in Windows Server 2012Microsoft fügte eigene Protokollerweiterungen hinzu, darunter zwei verschiedene Formen von Beschränkte Delegierung. 

Kerberos und die Kerberos-Delegation wurden bereits ausführlich in Blogs und Forschungsarbeiten behandelt. Einige dieser Arbeiten dienten sowohl als Inspiration als auch als grundlegende Referenz für diese Forschung: 

• Mit dem Hund wedeln – Elad Shamir 
• RC4 wird weiterhin als schädlich angesehen – Projekt Null (James Forshaw) 
• S4U2Pwnage – harmj0y 

In diesem Artikel verzichte ich bewusst auf eine allgemeine Einführung in Kerberos und konzentriere mich stattdessen auf Microsofts Implementierung der Delegierungserweiterungen.  

Bevor wir uns mit der Schwachstelle selbst befassen, müssen wir zunächst verstehen, wie diese Funktionen funktionieren sollen. 

Kerberos-Delegation  

Delegierung ist der Mechanismus, der es einem Dienst ermöglicht, im Namen eines Benutzers auf Ressourcen zuzugreifen. Active DirectoryDie Delegierung ist die Methode, mit der mehrschichtige Anwendungen den Autorisierungskontext aufrechterhalten, ohne Anmeldeinformationen zu kopieren oder eine Identitätswechselfunktion auf Anwendungsebene zu implementieren. 

Die Grundidee ist einfach: Ein Benutzer authentifiziert sich bei Dienst 1 (das Frontend)und dieser Dienst muss Zugriff haben Dienst 2 (das Backend) als Benutzer. 

Was geschieht mit dem „klassischen“ Kerberos? 

In einem Standard-Kerberos-Ablauf: 

1. Der Benutzer authentifiziert sich am Frontend und präsentiert ein Serviceticket. 
2. Das Frontend kann dieses Ticket nicht zur Authentifizierung beim Backend wiederverwenden, weil: 
   • Tickets sind Standardmäßig nicht weiterleitbar. 
   • Das Ticket ist verschlüsselt mit langfristiger Schlüssel des FrontendsDaher kann nur das Frontend die Daten entschlüsseln. 

Eine Alternative wäre, wenn das Frontend seine Anfrage stellen würde. besitzen Service-Ticket an das Backend. Dies führt jedoch zu neuen Problemen: 

1. Der Autorisierungskontext gehört nicht mehr dem Benutzer, sondern dem Dienstkonto. 
2. Aus Sicherheitssicht bedeutet dies, dass das Backend dem Frontend uneingeschränkt vertrauen muss. 
   • Einem Dienst uneingeschränkten Zugriff auf eine Backend-Ressource zu gewähren, ist in der Regel nicht akzeptabel. 
   • Anwendungen sollten nicht pauschal Zugriff erhalten, nur um „das Funktionieren zu ermöglichen“. 

Beispiel: CA-Webregistrierung 

Nehmen wir die CA-Webanwendung als Beispiel: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-kerberos-constrained-delegation. 

Zunächst authentifiziert sich der Benutzer bei IIS, das die Weboberfläche der Zertifikatdienste hostet. IIS ist für die Ausstellung eines Zertifikats an den Benutzer zuständig, indem es über RPC mit dem CA-Backend kommuniziert. 

An dieser Stelle: 

• IIS verwaltet das Dienstticket des Benutzers. 
• IIS muss sich nun authentifizieren RPCSS auf der CA als Benutzer. 

Das Ticket des Benutzers kann jedoch nicht einfach weitergeleitet werden: 

• Es ist mit dem Langzeitschlüssel von IIS verschlüsselt. 
• Die Zertifizierungsstelle benötigt ein mit seinen eigenen Schlüssel um es zu entschlüsseln und den Benutzer zu authentifizieren. 

Wenn IIS stattdessen mithilfe seiner Authentifizierungsmethode authentifiziert besitzen Serviceticket: 

1. Das ausgestellte Zertifikat gehört dem/der Dienstkonto, nicht der Benutzer. 
2. Alternativ könnte die Anwendung ihre eigene Identitätswechsellogik implementieren, sodass IIS entscheiden kann, welches Zertifikat ausgestellt wird. 
   • Dadurch werden sensible Autorisierungsentscheidungen in die Anwendungslogik verlagert. 
   • Anwendungen sollten nicht mit solchen Berechtigungen ausgestattet werden. 

Die Lösung für dieses Problem ist Kerberos-Delegation: eine kontrollierte Form der Identitätsfälschung, bei der Dienst 1 (das Frontend) explizit vertraut Im Namen der Benutzer zu handeln, wenn diese auf Dienst 2 (das Backend) zugreifen. 

Kerberos-Delegierungstypen: Unbeschränkt / Beschränkt 

Es gibt zwei Hauptfamilien der Kerberos-Delegation: Uneingeschränkte Delegation und Beschränkte DelegierungObwohl beide Ansätze das gleiche Kernproblem lösen wollen – nämlich einem Dienst zu ermöglichen, im Namen eines Benutzers zu handeln –, tun sie dies auf unterschiedliche Weise, was unterschiedliche Sicherheitsimplikationen mit sich bringt. 

Uneingeschränkte Delegation 

Uneingeschränkte Delegation beruht auf der ok-to-delegate ein Flag und ermöglicht es einem Dienst, die Benutzerdaten zu empfangen und wiederzuverwenden. weitergeleitetes TGTMit anderen Worten: Sobald ein Dienst für die uneingeschränkte Delegierung als vertrauenswürdig eingestuft wird, verfügt er faktisch über das TGT des Benutzers und kann sich als dieser ausgeben. für Dienst in der Domäne. Dies macht die uneingeschränkte Delegierung mächtig – aber auch gefährlich, wenn dieser Dienst kompromittiert wird. 

Eingeschränkte Delegation (KCD) 

Die eingeschränkte Delegierung verfolgt einen kontrollierteren Ansatz. Anstatt das TGT des Benutzers weiterzugeben, wird dem Frontend-Dienst vertraut. Benutzer nur gegenüber bestimmten Backend-Diensten imitieren. durch die Nutzung ein weiterleitbarer Service-Ticket. 

Ressourcenbasierte eingeschränkte Delegation (RBCD)  

RBCD ist die neueste Weiterentwicklung von KCD, bei der Zielressource Steuert, welche Dienste an es delegieren dürfen, anstatt Delegierungsberechtigungen auf dem Front-End-Dienstkonto zu konfigurieren. 

KCD und RBCD reduzieren die Angriffsfläche im Vergleich zur unbeschränkten Delegierung erheblich – zumindest theoretisch. 

Für weitere Details folgen Sie diesem Link: https://www.silverfort.com/glossary/kerberos-delegation/. 

KCD und RBCD sind beides Microsoft-Implementierungen der Kerberos-Protokollerweiterung MS-SFU. 

Microsoft Service-For-User-Protokollerweiterung 

Microsoft's Service-for-User (S4U) Protokollerweiterungen definieren zwei zusammenhängende Mechanismen: Protokollübergang und eingeschränkte DelegationIn diesem Modell nutzt ein Dienst seine eigene TGT um spezielle Kerberos-Tickets anzufordern, die einen Benutzerprinzipal einbetten, während die KDC bleibt verantwortlich zur Durchsetzung der Delegationspolitik auf der Grundlage von Active Directory Konfiguration. 

Die S4U-Erweiterungen führen zwei TGS-Subprotokolle ein: 

S4U2Self (Service-for-User-to-Self) 
S4U2Self ist ein TGS-REQ-Subprotokoll, das verwendet wird für ProtokollübergangEs wurde entwickelt, um Szenarien zu adressieren, in denen sich der Endbenutzer nicht über Kerberos bei einer Anwendung authentifiziert, die Anwendung aber dennoch Kerberos-Tickets benötigt, die die Identität des Benutzers repräsentieren. 

S4U2Proxy (Dienst für Benutzer-zu-Proxy) 
S4U2Proxy ist ein TGS-REQ-Subprotokoll, das zur Durchführung von Operationen verwendet wird. eingeschränkte DelegationSein Zweck ist es, ein Weiterleitungs-Serviceticket an einen nachgelagerten Dienst im Auftrag eines Benutzers unter Verwendung zuvor erstellter Authentifizierungsnachweise. 

Diese beiden Subprotokolle fungieren als unabhängige Mechanismen und können separat verwendet werden. In der Praxis werden sie jedoch häufig gemeinsam eingesetzt. miteinander verbunden, wobei S4U2Self ein Nachweisticket erzeugt, das anschließend von S4U2Proxy verwendet wird, um den delegierten Zugriff abzuschließen. 

S4U2Proxy – Eingeschränkte Delegierung 

S4U2Proxy TGS-REQ Dies ist die eigentliche eingeschränkte Delegierungsnachricht. Der Dienst fordert ein Ticket an einen nachgelagerten Dienst an. Ziel-SPN Im Namen dieses Benutzers stellt der KDC dessen Ticket als Nachweis bereit. Der KDC setzt die Delegierungsrichtlinie (KCD oder RBCD) durch und stellt, sofern zulässig, ein nachgelagertes Ticket aus, dessen Clientidentität vom Nachweisticket abgeleitet wird. 

Im Gegensatz zu einer normalen TGS-Anfrage muss S4U2Proxy Folgendes bereitstellen: Beweis dass der Benutzer bereits authentifiziert wurde. Dieser Nachweis kann auf zwei Arten erbracht werden: 

• Aus einem ursprünglich vom Benutzer vorgelegten Serviceticket (bei Verwendung der Kerberos-Authentifizierung) oder 

• Aus einem Serviceticket, das über S4U2Selbst. 

S4U2Proxy ist als modifizierte Version implementiert. TGS-REQ und TGS-REP  und führt Änderungen ein in der KDC-Optionen, PA-Daten, PAC und zusätzliche Tickets. 

S4U2Proxy TGS-REQ Schlüsselparameter 

1. Die KDC-Option eingeschränkte Delegation (auch bekannt als cname-in-addl-tkt) muss eingestellt werden. 
   • Dieses Flag weist den KDC an, die Client-Principal-Kennung zu extrahieren (cname) Aus dem zusätzliches Ticket, und nicht vom Authentifikator, wie bei einer normalen TGS-REQ. 
2. Ein oder mehrere zusätzliche Tickets müssen enthalten sein. 
   • Dieses Ticket repräsentiert den authentifizierten Benutzer. 
3. (Optional) Der Kunde kann Folgendes umfassen: PA-PAC-OPTIONEN anfordern: 
   • Ressourcenbasierte eingeschränkte Delegation (RBCD) 
   • auf Basis von Leistungsansprüchen 

In dieser Phase validiert das KDC beides Delegierungsberechtigungen des anfragenden Dienstes und des Integrität des Beweismittels. 

Beispiel: S4U2Proxy TGS-REQ  

S4U2Proxy TGS-REP 

Die resultierende TGS-REP Sieht aus wie ein direkt vom Benutzer angefordertes Serviceticket. Allerdings werden zusätzliche Autorisierungsmetadaten in das Ticket eingefügt. PAC. 

Konkret fügt das KDC Folgendes hinzu: S4U_DELEGATION_INFO Struktur, die zwei kritische Felder enthält: 

• S4U2proxyTarget – der SPN des Zieldienstes 
• S4UTransitedServices – das Konto, das sich als der Benutzer ausgab 

Diese Informationen sind dazu bestimmt, von der Anwendung validiert den Ticketempfang ermöglichen, damit er versteht WER wird imitiert und welcher Dienst die Delegation durchgeführt hat. 

Beispiel: S4U2Proxy TGS-REP 

Wie bereits erwähnt, sollte, wenn der Benutzer die Anwendung über ein Nicht-Kerberos-Protokoll authentifiziert hat, das Nachweisticket über das S4U2Self-Protokoll angefordert werden. 

S4U2Self – Protokollübergang  

S4U2Self ist ein TGS-REQ-Subprotokoll wurde für den Protokollübergang verwendet. Es wurde entwickelt, um Fälle abzudecken, in denen der Endbenutzer kein Frontalunterricht. Die Authentifizierung bei der Anwendung erfolgt über Kerberos, die Anwendung benötigt jedoch weiterhin Kerberos-Servicetickets für nachgelagerte Ressourcen im Sicherheitskontext des Benutzers.  

In der Praxis bedeutet dies, dass, sobald ein Dienstkonto mit dem Attribut TRUSTED_TO_AUTH_FOR_DELEGATION konfiguriert ist, … Benutzerkontensteuerung Wenn Sie dieses Flag setzen, vertraut die Domäne diesem Dienst explizit. Benutzer in seinem Namen authentifizieren, anstatt sich auf den Domänencontroller für die initiale Authentifizierung zu verlassen.

Dieses Vertrauen ermöglicht es dem Dienst, eine Anfrage zu stellen. S4U2 Selbstbedienungsticket die die Identität des Benutzers darstellt, obwohl keine Kerberos-Authentifizierung zwischen dem Benutzer und dem Dienst stattfand. 

S4U2Self TGS-REQ Schlüsselparameter 

Eine S4U2Self-Anfrage unterscheidet sich in einigen wichtigen Punkten von einer normalen TGS-Anfrage: 

• Die ausziehen, starten, abheben, losfahren Feld ist auf gesetzt selbst (zum Beispiel: machineaccount1$). 

• TGT und Authentifikator cname Identitäten repräsentieren auch das vertrauenswürdige Konto. 

An dieser Stelle muss der Dienst noch angeben welchen Benutzer es imitieren willDa zwischen dem Benutzer und dem Dienst keine Kerberos-Authentifizierung stattfand, kann die Benutzeridentität nicht aus dem Ticket selbst abgeleitet werden. 

Dies geschieht mithilfe eines von zwei Vorauthentifizierungsdaten (PA-Daten) Strukturen: 

• PA-FOR-BENUTZER – Benutzernamebasierte Identifizierung  

• PA-FOR-X509-BENUTZER – zertifikatsbasierte Identifizierung 

Beispiel: S4U2Self TGS-REQ

Im folgenden Abschnitt werden wir den Unterschied zwischen diesen Datenstrukturen verstehen und die Schwäche aufdecken. 

PA-DATENTYP 129: PA-FOR-USER – Benutzernamebasierte Identifizierung  

Dies ist die einfache und gebräuchlichere PA-DATA-Struktur.  

Alle Felder sind Pflichtfelder: 

• Benutzername.Typ – Standardwert ist 0 (NT-UNBEKANNT) 
• Benutzername.Name-Zeichenfolge – Benutzername oder UPN 
• Benutzerbereich – der Bereich des Benutzers 
• auth-package – die Zeichenkette „Kerberos“ 

Die Prüfsumme (cksum) wird über alle oben genannten Felder wie folgt berechnet: 

S4UByteArray =  
(LE 4-Byte int) userName.type +  
userName string +  
userRealm string +  
“Kerberos” 

An HMAC-MD5 Die Prüfsumme wird dann wie folgt berechnet: 

• Die TGT-Sitzungsschlüssel 
• Schlüsselverwendungsnummer 17 (KERB_NON_KERB_CKSUM_SALT) 
• Das S4UByteArray 

cksum = HMAC-MD5(SessionKey, 17, S4UByteArray) 

Diese Konstruktion stellt sicher, dass ein Angreifer die TGT-Sitzungsschlüssel um ein beliebiges Feld in der Struktur zu ändern. 

Und wenn ein Angreifer bereits den Sitzungsschlüssel besitzt, nun, dann hat man ein anderes Problem:  

PA-DATENTYP 130: PA-FOR-X509-BENUTZER – Zertifikatsbasierte Identifizierung  

Diese Datenstruktur ist komplexer und aus Sicherheitsperspektive wesentlich interessanter. 

Es besteht aus zwei Hauptkomponenten: 

1. Benutzer-ID (S4UUserID), die die Benutzeridentitätsinformationen enthält 
2. Checksum, das dem Integritätsschutz dienen soll. 

Benutzer-ID (S4UUserID) 

Die S4UUserID Die Struktur enthält die Identitätsinformationen, denen der KDC letztendlich vertrauen wird. 

Pflichtfelder:  

• Nuntius: Aus dem KDC-Anfragetext kopiert 
• Cremelm: Der Benutzerbereich  

Optionale Felder: 

cname Wird die Angabe weggelassen, muss ein Zertifikat bereitgestellt werden. Ist kein CNAME vorhanden, extrahiert der KDC die Benutzeridentität aus den Zertifikatserweiterungen. 

Fachzertifikat: DER-kodiert öffentliches Schlüssel-X509-Zertifikat   

OptionenZusätzliche Flaggen:  

Checksum   

Die Prüfsumme wird über die DER-kodierte Benutzer-ID-Struktur (S4UUserID) berechnet. 

Im Gegensatz zu PA DATA 129, wo die Prüfsumme immer HMAC-MD5-kodiert und mit dem Sitzungsschlüssel des TGT verknüpft ist, ist hier der Prüfsummentyp hängt vom Verschlüsselungstyp des TGT-Sitzungsschlüssels ab(!) 

Beispielsweise: 

• Wenn der TGT-Sitzungsschlüsseltyp ist AES256-CTS-HMAC-SHA1-96 (18),  Der Prüfsummentyp wird sein  HMAC-SHA1-96-AES-256 (16) 
• Wenn der TGT-Sitzungsschlüsseltyp ist AES128-CTS-HMAC-SHA1-96 (17),  Der Prüfsummentyp wird sein HMAC-SHA1-96-AES-128 (15) 

Wird jedoch ein älterer, „nicht neuerer“ Verschlüsselungstyp verwendet, Erbe Prüfsumme Der Algorithmus kann verwendet werden. 

Beispielsweise: 

• Wenn der TGT-Sitzungsschlüsseltyp ist RC4-HMAC-NT (23), dann kann der Prüfsummentyp sein RSA-MD4 (2) 

HMAC-basierte Prüfsummen sind verschlüsseltDas bedeutet, dass ihre Integrität von geheimen Informationen abhängt, die nur den Kommunikationspartnern bekannt sind. Im Gegensatz dazu RSA-MD4 ist ein unbeschrieben Prüfsumme. 

Gemäß RFC3961, RSA-MD4 Message Integrity Check (MIC) ist einfach md4(Nachricht) – Es wird kein Sitzungsschlüssel benötigt. 

Unverschlüsselte Prüfsummen bieten keinen Schutz vor Manipulationen und eignen sich nicht zum Schutz von Klartextstrukturen. Daher wird ihre Verwendung nicht empfohlen und sie dient lediglich der Abwärtskompatibilität. 

Im Kontext von S4U sind die resultierenden PA-DATA-Strukturen flexibel genug, um beides zu unterstützen zertifikatsbasiert und benutzernamebasiert Identitätsaussagen für S4U2SelbstIn der Praxis können diese Strukturen nebeneinander bestehen und werden in manchen Fällen sogar gemeinsam weitergegeben. 

Warum das wichtig ist 

Der entscheidende Punkt ist, dass Es sind keine Benutzerdaten erforderlich. um im Namen eines Benutzers ein Kerberos-Ticket zu erhalten. Die einzige Eingabe, die zur Bestätigung der Benutzeridentität erforderlich ist, ist ein Benutzername.  

In einem S4U-Ablauf ist diese Zeichenkette nicht kryptografisch geschützt gegen Manipulation durch einen Angreifer. 

Das bedeutet, dass ein Angreifer, wenn er diese Zeichenkette kontrollieren kann, auch die Kontrolle über das System erlangen kann. Ablauf der IdentitätsfälschungDas resultierende Ticket wird dann weitergeleitet an S4U2Proxy, das dem Ergebnis von S4U2Self blind vertraut. Ab diesem Zeitpunkt verläuft die Delegationskette wie geplant. 

Um dieser Schwäche entgegenzuwirken, versuchte Microsoft, kompensierende Sicherheitsmaßnahmen einzuführen. 

Auf der Clientseite (Anwendungsseite): 

• Wenn eine „nicht neuer“ Es wird ausschließlich der TGT-Sitzungsschlüssel verwendet. PA-DATA 129 ist erlaubt. 
• PA-FOR-X509-USER wird nicht gesendet. 
• Dadurch MD4-basierte Prüfsummen sollten nicht erscheinen in der Anfrage. 

Auf der Serverseite (KDC): 

• Wenn die Funktion  MD4 wird verwendet, sowohl die Anforderung und antworten Prüfsummenwerte sind enthalten verschlüsselter Teil der KDC-Antwort. 
• Diese Werte werden an den Client zurückgegeben, der sie als zusätzliche Integritätsprüfung verifizieren soll. 

CVE-2025-60704 Teil I: Downgrade-fähige, nicht verschlüsselte Prüfsumme in PA-S4U-X509-USER 

Primitiver Überblick 

Das erste Grundprinzip ist die Fähigkeit, die zertifikatbasierte S4U2Self-Identitätsbestätigung zu einem Vermächtnis ungeschlüsselter Prüfsummenmodus. 

Dies wird sicherheitsrelevant, da die Prüfsumme, die die S4UUserID Die Struktur wird anhand der Ausgehandelter Verschlüsselungstyp für den TGT-Sitzungsschlüssel des DienstesWenn diese Verhandlung zu Folgendem führt RC4, die von PA-S4U-X509-BENUTZER kann sich zersetzen zu RSA-MD4, was keine kryptografische Schlüsselung ermöglicht. 

Sobald dies geschieht, geht der Integritätsschutz der behaupteten Benutzeridentität faktisch verloren. 

Schritt 1: Herabstufen des TGT-Verschlüsselungstyps mittels Machine-in-the-Middle (MITM)  

Um den MD4-Codepfad zu erreichen, müssen wir unseren Mutationscode in den Pfad zwischen der Anwendung einfügen (wir bezeichnen ihn als „Kunden“ von nun an) und die KDC („Server”), und den im Kerberos-Austausch verwendeten Verschlüsselungstyp herabzustufen. Dies bedeutet, die AS-REQ zu verhandeln RC4-HMAC (etype 23). 

Unter Windows gestaltet sich dies unkompliziert: 

• Der Standard AS-REQ wird im Klartext, ohne Signatur oder Versiegelung, versendet. 
• Der Client wird ältere Verschlüsselungstypen aushandeln, sofern dies durch die Richtlinien zulässig ist. 

Nach der Modifizierung antwortet der KDC mit einem AS-REPund ein neues TGT wird im Cache installiert. 

Ergebnis: 
Der TGT-Sitzungsschlüssel lautet jetzt RC4-HMAC-MD5 (etype 23). 

Beobachtung des Clientverhaltens: Herabstufung des Schutzes gegen nicht verschlüsselte Prüfsummen 

Wie erwartet, Clientverhalten für S4U2Self TGS-REQ ändert sich, wenn RC4 wird als Sitzungsschlüsselverschlüsselungstyp verwendet: 

• Nur PA-DATA 129 (PA-FOR-USER) ist fühlt. 
• PA-DATA 129 ist fest auf die Verwendung eingestellt. HMAC-MD5. 

An diesem Punkt ist Microsofts clientseitige Beschränkung Scheint wie vorgesehen zu funktionieren. 

Serverseitiges Verhalten und die Umgehungsbedingung 

Um zu verstehen, wie diese Einschränkung umgangen werden kann, müssen wir Folgendes untersuchen: serverseitige Implementierung, insbesondere die KDC-Logik in KDCSVC!KdcFindS4UClientAndRealm. 

Diese Funktion folgt einem einfachen Entscheidungsablauf: 

1. Es ruft zuerst an KerbFindPerAuthDataEntry um zu finden PA-DATA Typ 130. 
2. Wenn PA-DATA 130 nicht gefunden wird, wird auf Folgendes zurückgegriffen: PA-DATA Typ 129. 
3. Anschließend folgen weitere Validierungsschritte. 

Dieses Verhalten hat eine wichtige Konsequenz. Wenn Beide PA-DATA-Typen sind vorhanden., PA-DATA 129 wird ignoriert zugunsten von PA-DATA 130. 

In dieser Phase führt der KDC keine Validierung des ausgehandelten Verschlüsselungstyps durch und erzwingt keine Einschränkungen hinsichtlich der zulässigen PA-Datenstrukturen bei Verwendung von RC4. Da auch keine kryptografische Bindung oder Manipulationsschutz zwischen dem Sitzungsschlüsseltyp und den zur Identitätsbestätigung verwendeten PA-Daten besteht, kann ein Angreifer einen speziell präparierten Code einschleusen. PA-DATA Typ 130 sogar in einer RC4-basierten Börse.  

Mit anderen Worten: Auch wenn der Client keine PA-DATA 130 sendet, hindert nichts einen Angreifer daran, sie hinzuzufügen. 

Schritt 2: Einspritzen von PA-DATA 130 

An diesem Punkt kann ein Angreifer, der sich in die Verbindung einmischt, zusätzlich PA-S4U-X509-USER (Typ 130) Element in die S4U2Self TGS-REQ. 

Die eingeschleusten PA-Daten kodieren eine vom Angreifer gewählte Identität innerhalb der S4UUserID Struktur. Dies kann beispielsweise durch explizites Festlegen von Folgendem erfolgen: 

• cname an das Zielkonto 
• Cremelm zur Zieldomäne 

Je nach Konstruktionsmodus können weitere optionale Felder einbezogen oder weggelassen werden. 

Da die Prüfsumme nun nicht mehr verschlüsselt ist, ist ihre Berechnung ganz einfach: 

Checksum = md4(DER(S4UUserID)) 

Lösung 

Bei der Bearbeitung der Anfrage prüft der KDC die erster PA-DATA-Typ 130 Eintrag, Auswahl RSA-MD4 da der Prüfsummenalgorithmus die Anfrage als gültig akzeptiert. Die gefälschte Identitätsbehauptung wird daher vom KDC als vertrauenswürdig eingestuft. 

Errungenschaften von Teil I 

Wenn Teil I erfolgreich ist, kann der KDC ein gültiges S4U2Self-Serviceticket ausstellen, dessen Client-Principal und PAC einer vom Angreifer gewählten Identität entsprechen. Dies ist relevant, da das S4U2Self-Ticket anschließend während S4U2Proxy dem KDC vorgelegt wird und die nachgelagerte delegierte Ticketidentität davon abgeleitet wird. 

CVE-2025-60704 Teil II: Umgehung des Client-Validierungsprozesses 

Teil I erzeugt ein gültiges S4U2Self-Serviceticket, das eine vom Angreifer gewählte Identität repräsentiert. Dieses Ergebnis allein reicht jedoch nicht aus, da die Installation des Tickets auf dem Client fehlschlägt. Dies stellt ein kritisches Hindernis dar, da das S4U2Self-Ticket für die nachfolgende S4U2Proxy-Verarbeitung vorhanden und nutzbar sein muss. 

Teil II beschreibt die clientseitige Validierungslogik, die die Installation verhindert, sowie die Umgehungsmethode, die das Ticket nutzbar macht. 

TGS-REP verschlüsselte PA-Daten 

MS-SFU definiert einen kompensierenden Integritätsmechanismus für ältere oder unverschlüsselte Prüfsummenmodi. Wenn der KDC die relevanten S4U PA-DATA im Feld „encrypted-pa-data“ des verschlüsselten Teils des TGS-REP zurückgibt, muss der Client die Prüfsummenwerte der Anfrage und der Antwort überprüfen. Dieser Mechanismus erzwingt die Verknüpfung von Anfrage und Antwort mithilfe von Werten, die erst nach der Entschlüsselung der Antwort verfügbar sind. Dadurch wird der Umstand kompensiert, dass die äußeren PA-DATA-Strukturen bei Verwendung von Kompatibilitätsprüfsummenalgorithmen von Angreifern manipuliert werden können. 

TL; DR  

Entferne den S4U-bezogene PA-Daten Die Antwortnachricht veranlasst den Client vollständig dazu, Die Verifizierungslogik überspringen und das Ticket annehmen. 

Wenn Sie den Validierungsprozess nicht im Detail verstehen müssen und direkt zur Nutzung übergehen möchten, können Sie diesen Abschnitt überspringen. Schritt 1:. 

Verstehen warum Um diesen Umgehungsmechanismus zu nutzen, müssen wir zunächst untersuchen, wie der KDC die verschlüsselte Antwort erstellt und wie die Validierungsdaten eingebettet werden. Die folgenden Abschnitte erläutern diesen Prozess Schritt für Schritt. 

Den Prüfsummenvalidierungsprozess verstehen (KDC – Serverseite) 

Serverseitig wird diese Logik implementiert über KDCSVC.DLL und CRYPTDLL.DLL. 

Der Validierungsablauf beginnt in kdcsvc!HandleTGSRequest, das trotz seines Namens die Verarbeitung von beide Verarbeitung von Anfrage- und Antwortnachrichten. 

Die Überprüfung der Anfrage erfolgt wie folgt: 

1. HandleTGSRequest ruft kdcsvc!KdcFindS4UclientAndRealm auf, um den Clientnamen zu extrahieren.
2. KerbFindPreAuthDataEntry wird aufgerufen, um den Standort zu ermitteln. PA-DATA Typ 130. 
3. Die Struktur wird zur Prüfsummenverifizierung an KerbSignS4UpreauthDataEx übergeben. 
4. Der Prüfsummentyp wird ausgewählt, indem zuerst der Verschlüsselungstyp mithilfe folgender Methoden ermittelt wird: 
   • cryptdll!CDLocateCSystem 
   • crytdll!CDLocateCheckSum 
5. Ausgehend vom ermittelten Verschlüsselungstyp wird der geeignete Prüfsummenalgorithmus ausgewählt. 
   • Im Downgrade-Szenario ergibt sich folgende Lösung: MD4. 
6. Der KDC berechnet die Prüfsumme über die Anforderung und vergleicht sie mit der vom Client angegebenen Prüfsumme. 

Wenn das Ergebnis gültig ist, ruft HandleTGSRequest BuildReply auf, um die Antwortnachricht zu erstellen, und fährt mit den folgenden Schritten fort: 

1. KerbSignS4UPreauthDataEx wird erneut aufgerufen, um die Prüfsumme über die antworten. 
2. Wenn der Verschlüsselungstyp ist nicht AESDer KDC ruft KdcAddEncryptedS4uPaData auf. 
3. Der KDC verkettet die über die Prüfsumme berechnete Summe. Anforderung wobei die Prüfsumme über die antworten. 
4. Wenn die Prüfsumme der Anfrage gültig ist, fährt der KDC mit der Erstellung der Antwort fort. 
5. Beide Prüfsummenwerte (16-Byte-Anfrage + 16-Byte-Antwort) werden eingefügt in pa-for-x509-user unter dem verschlüsselte PA-Daten Abschnitt des TGS-REP.   
6. Der verschlüsselte Teil der Antwort wird mit dem Sitzungsschlüssel versiegelt und an den Client zurückgesendet. 

Wenn der Client die TGS-REP empfängt, wird erwartet, dass er den verschlüsselten Teil der Nachricht mithilfe des Sitzungsschlüssels entschlüsselt. PA-DATA Typ 130 und vergleichen Sie die Klartext-Prüfsumme in der antworten an. Nach der Installation können Sie HEIC-Dateien mit der die letzten 16 Bytes der verschlüsselten PA-Daten und vergleichen Sie die ersten 16 Bytes mit der Clientanfrage.  

Nur wenn alle diese Prüfungen erfolgreich sind, sollte das Ticket akzeptiert und im Cache installiert werden. 

Prüfsummenvalidierungsprozess (Clientseitig) 

Auf der Clientseite ist die Logik zur Prüfsummenvalidierung implementiert in KERBEROS.DLLhauptsächlich innerhalb einer Funktion mit einem sehr aussagekräftigen Namen: kerberos!KerbCheckX509S4uReply. Diese Funktion ist für die Validierung des angewendeten kompensierenden Integritätsmechanismus zuständig. PA-S4U-X509-BENUTZER Antworten. 

Der Validierungsablauf beginnt, sobald der Client den verschlüsselten Teil empfängt und entschlüsselt. TGS-REPDie Verarbeitungslogik verläuft dann wie folgt: 

1. Der Client prüft, ob die Antwortnachricht die erwarteten S4U-bezogenen Strukturen enthält. 
2. KerbFindPreAuthDataEntry wird aufgerufen, um den Standort zu ermitteln. PA-DATA Typ 130. 
3. Wenn der PA-Datentyp 130 gefunden wird, berechnet der Client die Prüfsumme über die antworten unter Verwendung von KerbCredIsoIum::SignS4UPreauthData. 
4. Die berechnete Antwortprüfsumme wird mit dem vom KDC gelieferten Prüfsummenwert verglichen. 
5. Nun prüft der Client den mit dem Sitzungsschlüssel verknüpften Verschlüsselungstyp. 
   • Wenn der Verschlüsselungstyp ist AES (etype 18 / 0x12)Die Validierung ist erfolgreich, und es wird keine weitere Überprüfung durchgeführt. 

Wenn der Verschlüsselungstyp ist RC4 (Typ 23)Die Funktion folgt einem anderen Kontrollpfad: 

6. Der Kunde erwartet, Folgendes vorzufinden verschlüsselte PA-Daten Typ 130 beides enthaltend: 
   • die reflektierte Prüfsumme der antwortenund die zurückgegebene Prüfsumme der ursprüngliche Anfrage. 
7. Der Code überprüft die Größe der Prüfsummenpuffer und versucht, einen Puffer zu extrahieren, der die über die ursprüngliche Anfrage berechnete Prüfsumme enthalten soll. 
8. Der Client versucht, diesen Wert mit einer lokal berechneten Prüfsumme für die Anfrage zu vergleichen. 

An diesem Punkt schlägt die Validierung fehl. 

Der Kunde berechnet nie ein MD4-Prüfsumme der AnfrageDaher existiert kein lokaler Wert, der mit der zurückgegebenen Prüfsumme der Anfrage verglichen werden könnte. Folglich beendet sich die Funktion mit einem Fehler, und das Ticket wird nicht installiert. 

Bei der Analyse der möglichen Erfolgswege sticht ein Zweig besonders hervor. Wenn PA-DATA Typ 130 ist nicht vorhandenDer Code springt zu einem internen Zweig mit der Bezeichnung ETIKETT72In diesem Ablauf werden mehrere Flags geprüft, der Rückgabewert wird auf Null gesetzt und die Funktion gibt Erfolg zurück. ohne Durchführung der Prüfsummenbindungsprüfung der verschlüsselten PA-Daten. 

Dieses Verhalten ermöglicht direkt die Umgehung. 

Schritt 1: Entfernen des PA-DATA-Objekts aus der Antwort  

Durch Ändern des padata-Typs auf einen anderen Wert als 130 oder durch Entfernen der PA-Daten Da die Struktur vollständig aus der Antwort abgeleitet wird, durchläuft der Client niemals den strikten Validierungspfad. Stattdessen folgt er dem alternativen Zweig und akzeptiert die Integritätsprüfung des Tickets. 

Kurz gesagt, die Anwesenheit von PA-DATA 130 Bestimmt, ob der Client die kompensierende Integritätsprüfung erzwingt. Wird diese entfernt, führt dies dazu, dass die Validierungslogik stillschweigend erfolgreich ist, sodass das gefälschte S4U2Self-Ticket den Installationsablauf fortsetzen kann. 

Schritt 2: Wiederherstellung von cname 

In dieser Phase ist die cname Das zurückgegebene Ticket muss wiederhergestellt werden. Zielidentität zurück zu den ursprünglicher Benutzer. 

Der Grund dafür ist subtil, aber wichtig. Die Anwendung initiierte ursprünglich die Identitätsfälschung für Benutzer A.Aber das manipulierte S4U TGS-REP enthält nun ein gültiges Serviceticket für Benutzer B.Wenn der Host, der die Identitätswechsel initiiert hat, dieses Ticket empfängt, führt die Diskrepanz zwischen dem erwarteten Clientnamen und dem CNAME des Tickets dazu, dass die Ticketinstallation fehlschlägt. Dies stellt eine zusätzliche Hürde für eine erfolgreiche Ausnutzung dar. 

Der Angreifer kann jedoch die Tatsache ausnutzen, dass cname Das Feld ist nicht integritätsgeschützt.Durch Ändern des CNAME im zurückgegebenen Ticket von Benutzer B. zurück zur Benutzer A.Das Ticket entspricht also erneut den Erwartungen der initiierenden Anmeldesitzung und wird akzeptiert. 

Dieses Verhalten verdeutlicht auch ein wichtiges Nebenproblem: Während der Ticketinstallation wird keine zusätzliche Überprüfung des PAC durchgeführt.Der Client akzeptiert das Ticket aufgrund oberflächlicher Konsistenzprüfungen, obwohl der im Ticket eingebettete PAC einen anderen Benutzer repräsentiert. 

Errungenschaften von Teil II 

An diesem Punkt erhält der Angreifer einen gültigen S4U2 Selbstbedienungsticket das installiert wird in Anmeldesitzung von Benutzer Awährend die eingebetteten PAC entspricht Benutzer B. 

Damit ist die letzte clientseitige Hürde beseitigt. Das Ticket ist nun voll funktionsfähig und kann in der nächsten Phase des Angriffs vorgelegt werden: S4U2Proxy, wobei die delegierte Service-Ticket-Identität aus diesem gefälschten S4U2Self-Ticket abgeleitet wird. 

Ausbeutung und Beispiele aus der realen Welt 

Um zu demonstrieren, wie dieses Verhalten in der Praxis ausgenutzt werden kann, habe ich eine kleine Webanwendung entwickelt, die Benutzer authentifiziert, die Kerberos-Delegierung durchführt und auf entfernte Dateien zugreift. CIFS.  

Die Anwendung folgt einem gängigen mehrschichtigen Muster: Ein IIS-Frontend authentifiziert den Benutzer und delegiert dann den Zugriff an einen Backend-Dateiserver.  

Wir werden uns mit einem Domänenkonto (Benutzer) mit geringen Berechtigungen authentifizieren, die Man-in-the-Middle-Technik anwenden und den Angriff ausführen, um Administratorrechte zu erlangen. 

Der Code wird jede Nachricht untersuchen und nur die notwendigen Felder in der Nachricht ändern. AS-REQ , TGS-ANFRAGE, TGS-REP Nachrichten wie folgt: 

Durch die Nutzung dieses Exploits erhält Benutzer1 die Berechtigungskontexte des „Administrators“ (oder eines anderen nicht sensiblen Benutzers):

Beispiele aus der Praxis 

Bei der Recherche nach praktischen Missbrauchsszenarien für diese Schwachstelle identifizierte ich zwei sensible und weit verbreitete Anwendungen die seine Auswirkungen veranschaulichen. 

Webregistrierung bei der Zertifizierungsstelle Es nutzt Delegierung in einem klassischen mehrschichtigen Modell. Ein IIS-Frontend authentifiziert den Benutzer und delegiert dann an eine Remote-Zertifizierungsstelle, die unter der Identität des Benutzers Zertifikate ausstellt und dabei Domänenrichtlinien, Vorlagenberechtigungen und Ausstellungsregeln anwendet. 

Entra Application Proxy nutzt Delegierung in einem Connector-basierten Modell. Ein lokaler Connector führt Protokollübergang und eingeschränkte Delegierung durch, um Single Sign-On von der Cloud-Identität zu lokalen Kerberos-Anwendungen zu ermöglichen. 

Obwohl diese Anwendungen unterschiedlichen Geschäftszwecken dienen, weisen sie eine entscheidende Gemeinsamkeit auf: Beide nutzen delegierte Identität, um sensible nachgelagerte Operationen zu autorisieren. Daher repräsentieren beide Eskalationsflächen mit hoher Aufprallenergie wenn die Integrität der delegierten Identität beeinträchtigt wird. 

Jede dieser Anwendungen kann ausgenutzt werden. unabhängigWichtiger noch, sie können auch sein kombiniertDadurch wird die Wirkung verstärkt und aufgezeigt, wie sich Identitätsverwirrung auf einer Ebene über Vertrauensgrenzen hinweg ausbreiten kann. 

CA Web-Registrierung   

Der Web-Registrierungsdienst der Zertifizierungsstelle (CA) ist ein Microsoft-Produkt. Active Directory Der Certificate Services (AD CS)-Dienst bietet eine webbasierte Schnittstelle, über die Benutzer und Computer mit einer Zertifizierungsstelle interagieren können. 

Es fungiert als Brücke, die es Benutzern ermöglicht, Zertifikatsanforderungen zu stellen, Zertifikate herunterzuladen und Zertifikatssperrlisten (CRLs) über einen Webbrowser abzurufen, ohne dass eine direkte, native Interaktion mit dem CA-Server erforderlich ist. 

Mehr erfahren: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-kerberos-constrained-delegation. 

Entra Application Proxy und Kerberos-Delegierung 

Entra Application Proxy ist ein repräsentatives Beispiel für eine hybride Identitätsarchitektur, bei der Die Authentifizierung erfolgt in der Cloud., während Die Autorisierung wird lokal mithilfe von Kerberos durchgesetzt.. 

Auf einer übergeordneten Ebene fungiert Entra Application Proxy als Cloudbasierter Reverse-Proxy für lokale Webanwendungen. Benutzer authentifizieren sich bei der Anwendung über Microsoft Entra ID Einmalige Anmeldungund die authentifizierte Sitzung wird dann durch den Tunnel geleitet. Lokaler Anwendungsproxy-Connector. 

Der Konnektor ist dafür verantwortlich, diese beiden Welten miteinander zu verbinden. 

Siehe hier: https://learn.microsoft.com/en-us/entra/identity/app-proxy/how-to-configure-sso-with-kcd. 

Sobald der Benutzer in der Cloud authentifiziert ist, muss der Konnektor diese Identität in ein Format übersetzen, das von den lokalen Diensten verstanden wird. Wenn die Backend-Anwendung auf Kerberos basiert, erfolgt diese Übersetzung mithilfe von S4U-Protokollübergang.  

Der Konnektor verwendet seinen eigenen Kerberos-Kontext, um eine Anfrage zu senden. S4U2 Selbstticket repräsentiert den authentifizierten Benutzer und verwendet dann eingeschränkte Delegierung (S4U2Proxy) um Service-Tickets für nachgelagerte lokale Ressourcen zu erhalten. 

Anders ausgedrückt: Protokollkonvertierung ist hier kein Sonderfall; sie ist grundlegend für das Design. 

Abbildung 20: Konfigurationsbeispiel aus dem Microsoft-Leitfaden, das den Protokollübergang durch Design veranschaulicht 

Dies ist genau die Voraussetzung für die in dieser Studie beschriebene Schwachstellenkette. Wenn Cloud-Authentifizierung, Protokollübergang und eingeschränkte Delegierung systembedingt kombiniert werden, werden Fehler im S4U-Vertrauensmodell sicherheitsrelevant. 

Sehen Sie sich hier das Beispiel der Entra Proxy App für CA WebEnroll an:

Die zentralen Thesen 

IdentitätsdiebstahlErst verstehen, dann implementieren. Delegation und S4U ermöglichen es einem Dienst, im Namen eines Benutzers zu handeln. Jedes System, das Tickets „im Namen“ eines Benutzers anfordern kann, muss als Sicherheitsgrenze behandelt werden. Missverständnisse darüber, woher die Identität stammt, wie sie gebunden wird und welche Komponente sie durchsetzt, machen die Delegation zu einer Eskalationsfläche. 

Authentifizierungs- Ein System ist nur so stark wie sein schwächstes Glied. Starke Kryptografie auf Ticket-Ebene nützt nichts, wenn die Identität über einen schwächeren Weg eingeführt, in einem schwächeren Modus verhandelt oder über einen schwächeren Validierungszweig akzeptiert wird. Die durchgängige Identitätssicherung wird durch den am wenigsten geschützten Schritt in der Kette bestimmt. 

Richtige Technik, richtige Anwendung: 

• Hashing wird verwendet für Integrität. 

• Signing / MACs werden verwendet für Authentizität und Integrität. 

• Versiegelung (Verschlüsselung) wird verwendet für Vertraulichkeit. 

In diesem Fall steht:  Man verließ sich allein auf Integrität. woher Integrität und Authentizität waren erforderlich.  

Milderungen 

1. Herstellerkorrekturen anwenden und Verhalten überprüfen. Windows-Systeme gemäß den Anweisungen patchen. Leitfaden für das Sicherheitsupdate vom November 2025 und überprüfen Sie, ob das Kerberos-Verhalten dem festen Modell in Ihrer Umgebung entspricht, wobei Domänencontroller und Systeme, die Protokollübergänge und -delegierungen durchführen, Priorität haben. 

2. Aktivieren Sie Kerberos FAST (Armoring), um die Möglichkeiten für Downgrades und Manipulationen durch MITMs bei der Vorauthentifizierung und -verhandlung zu reduzieren und die Integrität des Kerberos-Austauschs gegen Störungen auf Verkehrsebene zu stärken.  

3. Verbessern Sie die kryptografische Sicherheit und die Kompatibilität. Reduzieren Sie die Anfälligkeit für Legacy-Modi, indem Sie ältere Verschlüsselungstypen nach Möglichkeit deaktivieren, da diese schwächere Prüfsummenzuordnungen durch Aushandlung zugänglich machen. Überwachen Sie die Richtlinieneinstellungen für Dienstkonten und Domänen auf Abweichungen von den aktuellen Standardwerten. 

4. Behandeln Sie die Delegierung als Konfigurationspunkt mit hohem Risiko. Minimieren Sie die Anzahl der für Protokollübergang und Delegierung vertrauenswürdigen Dienstkonten. Bevorzugen Sie eingeschränkte Delegierung und beschränken Sie die zulässigen Ziel-SPNs auf einen eng begrenzten Bereich. Prüfen Sie, welche Dienstkonten für den Protokollübergang vertrauenswürdig sind, an welche SPNs sie delegieren können und stellen Sie sicher, dass privilegierte Konten als nicht delegierbar gekennzeichnet sind, es sei denn, es besteht eine klar definierte Geschäftsanforderung. 

5. Hinweise zur Überwachung und Erkennung – Überwachen Sie ungewöhnliche Nutzungsmuster von S4U2Self und S4U2Proxy, unerwartete Ziel-SPNs und Identitätsdiskontinuitäten, bei denen delegierte Tickets Prinzipale widerspiegeln, die nicht mit der initiierenden Sitzung übereinstimmen. Überwachen Sie bei Zertifikatsdiensten die unerwartete Registrierung privilegierter Identitäten, die ungewöhnliche Verwendung von Vorlagen und die Ausstellungsaktivität, die vom Proxy-veröffentlichten Anwendungspfad ausgeht. 

Referenzen 

MS-SFU

Kerberos v5 rfc4120

Verschlüsselungs- und Prüfsummenspezifikationen für Kerberos 5 RFC 3961

Implementieren Sie die Identitätswechselfunktion in der Anwendung

Konfigurieren der eingeschränkten Delegierung für CA Web Enroll-Seiten

'Mit dem Hund wedeln'

„RC4 gilt weiterhin als schädlich.“

'S4U2Pwnage'

FAST (Kerberos-Panzerung)