Im vergangenen Monat veröffentlichte Microsoft einen Sicherheitshinweis zu CVE-2020-1317, in dem eine Sicherheitslücke in Policy beschrieben wird, die eine Ausweitung von Berechtigungen ermöglicht. Der Entdecker der Sicherheitslücke hat diese auf derCyberark-Website näher erläutert. Die Natur dieses Problems ist interessant und es lohnt sich, sie zu verstehen. Seit Jahren Policy diese Dichotomie in das Design von Group Policy integriert. Es geht dabei um die Notwendigkeit, benutzerspezifische policy ansonsten nicht privilegierte Benutzer zu übermitteln, und zwar über einen Mechanismus, der als privilegierter Prozess ausgeführt wird – nämlich die Policy . Microsoft hat dies auf verschiedene Weise gelöst. Beispielsweise policy benutzerspezifische policy für administrative Vorlagen an zwei Registrierungsschlüssel in HKEY_CURRENT_USER übermittelt, die zufällig so berechtigterlegt waren, dass ein Benutzer nicht in sie schreiben konnte, obwohl er in so gut wie jeden anderen Schlüssel in diesem Hive schreiben konnte. Im Fall dieser CVE gab es jedoch einige eklatante Lücken. Die erste davon wurde im Blogbeitrag von Cyberark detailliert beschrieben. Nämlich, dass GP-Einstellungen schon immer das Konzept von Verlaufsdateien kannten. Diese Dateien wurden im Wesentlichen erstellt, um den Zustand bestimmter GP-Einstellungen rückgängig zu machen, wenn diese Einstellungen nicht mehr galten. Diese Verlaufsdateien waren im Wesentlichen Kopien der eigentlichen Einstellungsdatei, die in SYSVOL für das GPO gespeichert war, das die Einstellungen bereitstellte, und wurden im Benutzerprofil unter %appdata%LocalMicrosoftGroup Policy gespeichert, wie Sie hier sehen können:
Verwandte Lektüre
Der Speicherort dieser Datei war der Schlüssel zu dieser privesc-Schwachstelle. Die Dateien selbst sind im Profil des Benutzers in einem Bereich gespeichert, auf den ein normaler, nicht privilegierter Benutzer volle Rechte hat. Die Dateien werden jedoch immer dann hierher geschrieben, wenn eine neue GPP-Einstellung verarbeitet oder die Einstellung von der GP-Engine geändert wird, die selbst als localSystem läuft. Wir haben also einen localSystem-Prozess, der Daten in den unprivilegierten Benutzerbereich schreibt, und hier beginnt der Spaß.
Bei diesem speziellen Exploit verwendet der Autor symbolische Object Manager-Links, um eine beliebige GPP-XML-Datei an einen Speicherort in c:windowsystem32 umzuleiten, wo sie von einem weiteren Prozess ausgenutzt werden kann, um im Wesentlichen einen Prozess zu öffnen, der als localSystem läuft. Die Details des eigentlichen Eskalationscodes zu localSystem werden nicht gezeigt, aber die Verwendung von symbolischen OM-Links (und die Ausnutzung anderer Arten von symbolischen Windows-Links) wird in diesem hervorragenden Video von James Forshaw beschrieben, der hier auch Beispielcode für die Erstellung dieser Links bereitstellt. Um dies auszunutzen, muss ein Angreifer lediglich die Datei löschen, die GPP in seinem Benutzerprofil hinterlassen hat, und sie durch einen symbolischen OM-Link ersetzen. Die GP-Engine wird dann fröhlich als lokales System laufen und eine neue XML-Datei in das in c:windowssystem32 angegebene Ziel schreiben. Sie können dann jeden beliebigen Inhalt in diese Datei schreiben und sie von dort aus nutzen. Ziemlich raffiniert.
Alternative Ausnutzungspfade und der Patch
Als ich zum ersten Mal die Beschreibung dieses Exploits sah, fragte ich mich laut, ob die GPP-History-Dateien der einzige Ort sind, an dem dies ausgenutzt werden kann. Ich wusste genau, dass mein guter Freund, die Registrierungsarchivdatei (ntuser.pol), eine weitere dieser benutzerspezifischen GPO-Dateien war, die im Profil des Benutzers gespeichert und vom Benutzer beschreibbar ist, aber von der GP Engine aktualisiert wird. Es war also logisch anzunehmen, dass auch diese Datei auf die gleiche Weise ausgenutzt werden konnte wie die GP Preferences History-Dateien. Als ich mir also ein Windows-System ansah, nachdem ich den Patch für diese Sicherheitslücke installiert hatte, fielen mir einige interessante Dinge auf. Erstens hat Microsoft das Problem gelöst, indem es die GPP-Verlaufsdateien aus dem Benutzerprofil in den geschützten Ordner %programdata% (speziell unter %programdata%MicrosoftGroup PolicyUsers) verschoben hat. Dieser Ordner ist für normale Benutzer nicht beschreibbar, was dazu beiträgt, die Verwendung von symbolischen Links in der vorherigen Version zu vermeiden. Der vollständige Pfad zu der Datei ist ein wenig verworren, wie Sie hier sehen können:
Die Ordnerstruktur ist pro Benutzer (d.h. der SID-Ordnerpfad), dann pro GPO (die GPO-GUID), dann wieder pro Benutzer (ein weiterer SID-Ordner), was mir etwas übertrieben vorkommt, aber ich bin sicher, sie hatten einen Grund dafür 🙂 .
The next question I was curious about, was the ntuser.pol file I mentioned above. Sure enough, Microsoft also moved that file to a location in %programdata% as well, albeit in a different folder structure from GPP history files. Namely, under %programdata%MicrosoftGroupPolicyUsers<SID of User>. I thought it was mildly funny that they have two folder structures under the Microsoft folder, one called “Group Policy” and the other called “GroupPolicy”. Oh well. This latter path is also where the per-user Group Policy Cache files are kept. See this article for a review of the Group Policy cache.
Nun, laut dem Autor dieses Exploits hat Microsoft fast ein Jahr gebraucht, um diesen Fehler zu beheben. Ich kann mir durchaus vorstellen, dass dies der Fall ist. Angesichts der Tatsache, dass es zwischen all den GP-Einstellungsbereichen und allen Bereichen, die ntuser.pol verwenden – einschließlich Admin-Vorlagen, AppLocker, Windows-Firewall, Policy und wahrscheinlich noch einigen, die ich übersehen habe – potenziell eine Menge Code zu durchforsten galt, um sicherzustellen, dass die Verschiebung dieser Dateien nicht alles lahmlegt. Es würde mich nicht überraschen, wenn sich noch einige Fehler in irgendeiner versteckten Ecke der policy zeigen würden, policy das Ganze vorbei ist. Nichtsdestotrotz war dies ein interessanter Exploit, der durch einige 20 Jahre alte Schwachstellen, die GP mitbrachte, noch interessanter wurde.
Möchten Sie mehr über die Policy Verwaltung Policy erfahren? Sehen Sie sich unser Webinar an, in dem ich meine fast vierjährige Forschungsarbeit zu den verschiedenen Methoden zusammenfasse, mit denen Angreifer Policy ausnutzen. Vor allem werde ich Ihnen die wichtigsten Maßnahmen erläutern, mit denen Sie Ihre Gruppenrichtlinienumgebung und damit Ihre Windows-Umgebung vor Missbrauch schützen können. Ich freue mich darauf, Sie dort zu sehen.
