Letzten Monat hat Microsoft ein Advisory für CVE-2020-1317 veröffentlicht, das eine Schwachstelle für die Ausweitung von Berechtigungen in Gruppenrichtlinien beschreibt. Der Entdecker der Sicherheitslücke hat dies auf der Cyberark-Website näher erläutert. Die Art dieses Problems ist interessant und es lohnt sich, es zu verstehen. Seit Jahren ist dieser Zwiespalt in das Design der Gruppenrichtlinien eingebaut worden. Nämlich die Notwendigkeit, Richtlinien für einzelne Benutzer über einen Mechanismus, der als privilegierter Prozess ausgeführt wird - nämlich die Gruppenrichtlinien-Engine - an ansonsten nicht privilegierte Benutzer weiterzugeben. Microsoft hat dies auf verschiedene Weise gelöst. So wurden beispielsweise die Richtlinien für die benutzerspezifischen Verwaltungsvorlagen an zwei Registrierungsschlüssel in HKEY_CURRENT_USER übergeben, die zufällig so berechtigt waren, dass ein Benutzer nicht auf sie schreiben konnte, obwohl er auf so ziemlich jeden anderen Schlüssel in diesem Hive schreiben konnte. Im Fall dieses CVE gab es jedoch ein paar eklatante Lücken. Die erste davon wurde in dem Cyberark-Blogbeitrag ausführlich beschrieben. GP Preferences hat nämlich schon immer das Konzept der Verlaufsdateien verwendet. Diese Dateien wurden erstellt, um den Zustand bestimmter GP-Einstellungen rückgängig zu machen, wenn diese Einstellungen nicht mehr gültig waren. Diese Verlaufsdateien waren im Wesentlichen Kopien der eigentlichen Einstellungsdatei, die in SYSVOL für das GPO, das die Einstellungen bereitstellt, gespeichert war, und wurden im Profil des Benutzers 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.
Nach Angaben des Autors dieses Exploits hat Microsoft fast ein Jahr gebraucht, um dieses Problem zu beheben. Ich kann mir durchaus vorstellen, dass dies der Fall ist. Wenn man bedenkt, dass alle Bereiche der GP-Einstellungen und alle Bereiche, die ntuser.pol verwenden, einschließlich Admin Templates, AppLocker, Windows Firewall, Public Key Policy und wahrscheinlich noch ein paar andere, die ich übersehe, eine Menge Code enthalten, den man durchgehen musste, um sicherzustellen, dass das Verschieben dieser Dateien nicht alles kaputt macht. Es würde mich nicht überraschen, wenn in irgendeiner obskuren Ecke der Richtlinie noch eine Lücke auftaucht, bevor das Ganze vorbei ist. Nichtsdestotrotz war dies ein interessanter Exploit, der durch einige 20 Jahre alte Warzen, die GP mitgebracht hat, noch interessanter wurde.
Möchten Sie mehr über die Verwaltung von Gruppenrichtlinien unter Berücksichtigung der Sicherheit erfahren? Sehen Sie sich unser Webinar an, in dem ich meine fast vierjährige Forschungsarbeit über die verschiedenen Möglichkeiten der Ausnutzung von Gruppenrichtlinien durch Angreifer zusammenfasse. Und was noch wichtiger ist: Ich werde Ihnen die wichtigsten Schritte aufzeigen, die Sie unternehmen können, um Ihre Gruppenrichtlinien-Umgebung und damit auch Ihre Windows-Umgebung vor Missbrauch zu schützen. Ich hoffe, Sie dort zu sehen.
