Delegierungsbedrohungen: Tauchen Sie ein in den Microsoft-Patch der KCD-Schwachstelle CVE-2020-17049
Dezember 13th, 2020 Dor Segal
*****Von Dor Segal, Sicherheitsforscher bei Silverfort*****
Am 11. November 2020 veröffentlichte Microsoft CVE-2020-17049, ein neues Kerberos Sicherheitslücke bei der Umgehung von Sicherheitsfunktionen. Während die Schwachstelle selbst nicht vor dem 8. Februar 2021 behoben wird, hat Microsoft am 8. November und 8. Dezember Patches herausgegeben, um ihre Ausnutzung in der Zwischenzeit einzudämmen. Über die internen Abläufe der Schwachstelle wurde nur sehr wenig bekannt gegeben, es gab weder einen öffentlichen POC noch eine technische Analyse.
Dieser Beitrag versucht, einen Teil dieser Lücke zu schließen, indem er ein Licht auf die Kerberos-Delegierung im Allgemeinen wirft und tief in den Patch eintaucht, den Microsoft für die KCD-Schwachstelle CVE-2020-17049 selbst herausgegeben hat.
Inhaltsverzeichnis
Kerberos-Delegierung 101
Die Kerberos-Delegierung ist eines der kompliziertesten Konzepte von Kerberos Beglaubigung Verfahren. Diese Erweiterung des Standardprotokolls wurde ursprünglich für die Bereitstellung von Diensten entwickelt Dienstkonten Sie nutzen Zugriff auf Ressourcen, ohne ihnen tatsächlich irgendwelche Berechtigungen zu erteilen.
Seit ihrer ersten Einführung hat die Delegierung einige wichtige Änderungen erfahren, bis sie zur ressourcenbasierten eingeschränkten Delegierung wurde, die wir heute verwenden (auch bekannt als KCD). Bevor wir uns also der Schwachstelle selbst nähern, lassen Sie uns die verschiedenen Arten der Delegation und ihre jeweiligen Vor- und Nachteile betrachten.
Stufe 1: Uneingeschränkte Delegation
Die uneingeschränkte Delegierung wurde in Windows Server 2000 eingeführt und war die erste, die es Diensten ermöglichte, sich als Benutzer mit Zugriffsberechtigungen auszugeben. Wie der Name schon sagt, gibt diese Art der Delegierung einem Dienst die Möglichkeit, die Anmeldeinformationen des Benutzers zu verwenden, um jederzeit auf eine beliebige Ressource zuzugreifen.
Der Prozess erfordert, dass der Benutzer ein weiterleitbares TGT anfordert und es an das Dienstticket anhängt. Dann nimmt der Dienst das TGT und fügt es zur späteren Verwendung in den lokalen Cache von lsass.exe ein.
Heutzutage wissen wir, dass diese Methode sehr riskant ist, da sie unbegrenzten Zugriff auf die delegierten Dienste gewährt, was es dem Angreifer im Falle einer Kompromittierung ermöglichen würde, alle zwischengespeicherten Tickets zu stehlen und vollen Zugriff auf alle seine Privilegien zu erhalten.
Diese Art der Delegierung existiert auch heute noch, hauptsächlich um die Abwärtskompatibilität zu unterstützen, und kann durch Abfragen des ADS_UF_TRUSTED_FOR_DELEGATION-Flags im userAccountControl-Attribut erkannt werden. Dieses Flag wird auch von überwacht Silverfort, das über Dienste mit uneingeschränkter Delegierung berichtet.
Stufe 2: Eingeschränkte Delegation
Die nächste Generation der Delegierung ist eingeschränkter und ermöglicht dem Dienst, den Zugriff nur auf definierte Ressourcen zu imitieren, wenn das Flag „Konto ist vertraulich und kann nicht delegiert werden“ aktiviert ist Active Directory um bestimmte Benutzer vor Identitätsdiebstahl zu schützen.
Bei dieser Art der Delegierung führt der Dienst die Authentifizierung mithilfe von S4U2Self- und S4U2Proxy-Erweiterungen (MS-SFU) durch.
Wie funktioniert es?
Für unser Dienstkonto muss das TRUSTED_TO_AUTH_FOR_DELEGATION-Flag aktiviert sein und das ms-AllowedToDelegateTo-Attribut muss den SPN der Ressource enthalten.
Ein Benutzer authentifiziert sich wie gewohnt beim Dienst mithilfe der Kerberos-Aushandlung (TGT und TGS).
Jetzt wird es kompliziert: Ein delegiertes Dienstkonto fordert ein weiterleitbares TGT an sich selbst an. Wir haben dieses Ticket verwendet, um ein Serviceticket mit S4U2SELF anzufordern, wobei wir den imitierten Benutzernamen für unser cname PA-DATA-Feld verwenden.
Der Dienst nimmt dieses Ticket und hängt es mit dem Flag für eingeschränkte Delegierung an das Ressourcendienstticket (S4U2Proxy) an.
Das erhaltene Ticket ist eine Imitation des aktuellen Benutzers durch unseren Dienst.
Stufe 3: Ressourcenbasierte beschränkte Delegation
Der Hauptunterschied bei dieser Delegation ist hauptsächlich administrativer Natur.
Anstatt dem zu delegierenden Dienst den Zugriff auf eine Ressource zu gestatten, geben wir dem Ressourcenbesitzer die Befugnis, zu definieren, welcher Dienst die Delegierung durchführen darf.
Dies kann von PowerShell mit der konfiguriert werden PrincipalsAllowedToDelegateToAccountt-Parameter oder einfach durch Bearbeiten des Attributs msDS-AllowedToActOnBehalfOfOtherIdentity
Microsoft-Sicherheitspatch für CVE-2020-17049 – Technische Analyse
Protokollschwachstellen sind aufgrund der erforderlichen Abwärtskompatibilitätsunterstützung immer schwieriger zu beheben.
Wir haben uns den Microsoft-Patch angesehen, indem wir die auf der offiziellen Website veröffentlichten Informationen gelesen haben.
Wir haben verstanden, dass es bei der Schwachstelle um das „Manipulieren von Tickets“ geht und dass sie sich irgendwo im Prozess der eingeschränkten Kerberos-Delegierung befindet.
Wir haben uns entschieden, die Delegierung auf einem anfälligen Domänencontroller zu simulieren und sie auf einem gepatchten Controller zu reproduzieren, um den Unterschied zu überprüfen:
Die erste wahrnehmbare Änderung liegt in der Länge jedes Pakets, wir können sehen, dass die Anfrage für ein selbstsigniertes Ticket (S4U2Self) dieselbe ist, aber ihre Antwort ist 40 Byte länger.
Dies gilt auch für die nächste S4U2Proxy-Anfrage und -Antwort, was hat sich also geändert?
Ein Textabgleich war nicht hilfreich, da der geänderte Text im Ticket verschlüsselt ist.
Nach dem Entschlüsseln der Chiffre mit dem Keytab des Dienstes ist der Text lesbar, muss aber noch verstanden werden.
Wenn wir uns das AuthorizationData-Feld ansehen, sehen wir ein neues Unknown-Feld, das bei Offset 840 mit der Größe 20 beginnt.
Woher kommt dieses neue Feld? Wie geht KDC damit um?
Was ich am meisten an Protokollen liebe, ist, dass die meisten von ihnen RFCs regelmäßig pflegen und aktualisieren – und Kerberos ist da keine Ausnahme.
Besuch MS-SFU bemerkt, dass es am 11 aktualisiert wurde. Als wir die öffneten Diff-Dokument Wir haben in Abschnitt 3.2.5.2.2 erfahren, dass es eine neue Signatur gibt, die verwendet wird, um die Integrität des Tickets zu validieren. Darüber hinaus deutet Microsofts Patch darauf hin, dass das erste modifizierte Ticket das S4U2Self ist.
Wir haben weitere Informationen aus dem RFC extrahiert, indem wir uns die Referenz von Ticket Signature angesehen haben – MS-PAC 2.8.3:
„Das KDC wird den KDC (krbtgt)-Schlüssel [RFC4120] verwenden, damit andere KDCs diese Signatur beim Erhalt eines PAC verifizieren können.“
„Die Ticketsignatur wird verwendet, um die Manipulation von Tickets durch andere Parteien als das KDC zu erkennen. Die Ticketsignatur SOLLTE in Tickets aufgenommen werden, die nicht an das krbtgt-Konto (einschließlich des Passwortänderungsdienstes) oder an ein Treuhandkonto verschlüsselt sind.“
„entspricht der Ticketsignatur enthält den Wert 0x00000010“
Der MS-PAC-RFC enthüllte das Geheimnis hinter dem unbekannten Feld in Offset 840 – es handelt sich um eine neue Ticketsignatur, die mit dem krbtgt-Schlüssel verschlüsselt wurde, um ihre Integrität zu validieren.
Kerberos-Bronze-Gebiss
Am 8. Dezember eine Umsetzung von CVE-2020-17049 KCD-Schwachstelle in Kerberos Bronze-Bit-Angriff wurde detaillierter veröffentlicht und brachte mehr Licht in die Manipulation des S4U2Self-Tickets.
Der Exploit befasst sich mit dem Entschlüsseln und Bearbeiten des Bits des weiterleitbaren Felds innerhalb des encRepPart von ticket.
Ein Dienst mit Delegierungsfähigkeit kann S4U2Self-Tickets für erstellen Alle Nutzer sogar diejenigen, bei denen das Flag „Konto ist vertraulich und kann nicht delegiert werden“ aktiviert ist.
Dieses Flag setzt das Forwardable-Flag auf False, aber das Ticket wird im Falle einer Änderung nie von KDC validiert.
Zusammenfassung
Die Offenlegung neuer Schwachstellen weckt immer das Interesse von Sicherheitsforschern. Typischerweise beinhaltet eine solche Offenlegung keine detaillierte Beschreibung der beteiligten Bits und Bytes. Während dies aus betrieblicher Sicht sinnvoll sein kann, ist es ebenso wichtig, solche Offenlegungen zu nutzen, um bessere Einblicke in die Softwareimplementierung zu erhalten – in diesem Fall den Kerberos-Delegierungsmechanismus. Wenn Wissen Macht ist, hoffe ich, dass uns diese Analyse ein bisschen stärker gemacht hat.
