Darren Mar-Elia | Leitender Sicherheitsstratege

Wenn Sie diesen Blog verfolgen, wissen Sie, dass ich vor etwa zweieinhalb Jahren damit begonnen habe, über die heikle Rolle Policyfür die Sicherheitslage in einem typischen Unternehmen zu sprechen. Viele, wenn nicht sogar die meisten AD-Umgebungen nutzen Gruppenrichtlinien, um ihre Windows-Desktops und -Server sicherheitstechnisch abzusichern. Dies umfasst alles von der Anpassung von Betriebssystemeinstellungen über das Deaktivieren von NTLMv1 oder das Herumprobieren mit der Benutzerkontensteuerung (User Account Control, UAC) bis hin zur Steuerung, wer sich an welchen Rechnern anmelden darf und welche AD-Gruppen privilegierten Zugriff auf welche Desktops und Server haben. All dies wird in GPOs gespeichert, die standardmäßig für jeden authentifizierten Benutzer „weltweit lesbar“ sind. Nun ist diese Tatsache schon seit langer Zeit bekannt – eigentlich schon seit dem Jahr 2000, als AD und GP auf den Markt kamen –, doch erst in den letzten Jahren ist sie als potenzielles Informationssicherheitsproblem deutlicher in den Fokus gerückt, vor allem aufgrund von Tools wieBloodhound,PowerViewundGrouper, die offenlegen, dass diese Informationen für alle möglichen Arten von Missbrauch genutzt werden können.

Seitdem habe ich mich vor allem auf die defensive Seite des Themas konzentriert, insbesondere auf Empfehlungen zur Verringerung der Lesbarkeit sicherheitsrelevanter GPOs, um zu verhindern, dass ein Angreifer die Sicherheitslage eines Unternehmens leicht aufdecken kann. In jüngerer Zeit habe ich jedoch einige Zeit damit verbracht, über Möglichkeiten für eine destruktivere Nutzung von GPOs nachzudenken – nämlich die Nutzung bestehender Einstellungen in bearbeitbaren GPOs, um verschiedene böswillige Aufgaben innerhalb einer Umgebung auszuführen. Da GP oft die meisten, wenn nicht sogar alle Benutzer und Computer in einem Unternehmen betrifft, ist es ein sehr effizienter Mechanismus zur Verbreitung von Malware, wie ich bereits vor einiger Zeit in einemBlogbeitragdargelegt habe. Diese Art von Angriffen, bei denen bösartige Einstellungen in ein GPO eingeschleust werden, beruhen auf der Fähigkeit des Angreifers,Schreibrechtefür ein GPO zu erlangen – insbesondere für den SYSVOL-Teil des GPO, in dem die meisten (wenn auch nicht alle) GP Client Side Extensions (CSEs) ihre Einstellungen speichern.  Natürlich müssen Sie auch das Einstellungsformat des policy verstehen, den Sie manipulieren möchten, um ihn zu kapern, und ausnahmsweise einmal ist die chaotische Herangehensweise von Microsoft bei der Entwicklung von CSEs hier von Vorteil, da so gut wie jeder policy ein anderes Schema und eine andere Datenstruktur zur Speicherung seiner Einstellungen verwendet. Ein Punkt für architektonische Inkonsistenz!

Drei Wege, um Ärger zu verursachen

Als ich über GP und seine Schwächen nachgedacht habe, bin ich zu dem Schluss gekommen, dass es (mindestens) drei Hauptwege gibt, auf denen ein Angreifer GP für seine schändlichen Zwecke nutzen kann. Nämlich,

  • Nutzen Sie einen allzu freizügigen Lesezugriff auf GPOs, um etwas über die Sicherheitslage eines Unternehmens zu erfahren - wer wo privilegierten Zugriff hat usw. Wie ich bereits erwähnt habe, habe ich darüber ausführlich gebloggt und Vorschläge gemacht, wie Sie dieses Problem entschärfen können.
  • Nutzen Sie einen allzu freizügigen Schreibzugriff auf GPOs, um bösartige Einstellungen in bestehende GPOs einzuschleusen. Darauf gehe ich weiter unten im Abschnitt "GPO-Delegation" ein. Das New-GPOImmediateTaskcmdletvon PowerView ist ein perfektes Beispiel für diesen Ansatz, um eine geplante Aufgabe in ein GPO einzuschleusen und beliebigen Code auszuführen.
  • Nutzen Sie externe Pfade, auf die in GPOsverwiesen wirdunddie übermäßig großzügigeSchreibrechteaufweisen. Dies ist eine Variante von Punkt 2, und ich habe die Leistungsfähigkeit dieses Ansatzes erst richtig erkannt, als ich gemeinsam mit@mikelossan seinem oben erwähnten hervorragenden Dienstprogramm„Grouper2“getestet und daran gearbeitet habe. Grouper2 sucht in GPOs nach „interessanten“ Elementen, darunter alles von policy eingeschränkte Gruppen, policy privilegierten Zugriff policy , über veraltete GPP-Passwörter bis hin zu – was für mich besonders interessant ist – Verweisen auf externe ausführbare Dateien, Skripte oder Installationsprogramme. Ich gehe weiter unten im Abschnitt „Externe Pfade“ näher auf diese externen Pfade ein, doch@mikelossgebührt wirklich die Anerkennung dafür, dass er mich auf diesen Aspekt aufmerksam gemacht hat.

GPO-Delegation

Lassen Sie uns näher auf Punkt 2 oben eingehen. Die Delegierung von Gruppenrichtlinien funktioniert so, dass Sie Benutzern, Computern oder Gruppen unterschiedliche Zugriffsebenen auf eine Gruppenrichtlinie gewähren, in der Regel in der GPMC über die Registerkarte „Delegierung“ einer bestimmten Gruppenrichtlinie oder mithilfe von PowerShell. Diese Berechtigungen (zu denen „Read“, „ReadApply“, „Einstellungen bearbeiten“ und „Einstellungen bearbeiten, löschen und Sicherheit ändern“) werden dem entsprechenden AD-basierten Policy (GPC)-Objekt und dem mit einer GUID benannten Ordner in der Policy (GPT) (d. h. SYSVOL) zugewiesen. Nun entsprechen AD-Berechtigungen natürlich nicht eins zu eins den Berechtigungen des NTFS-Dateisystems, aber wenn Sie sich beide Teile eines GPO im ACL-Editor ansehen, werden Sie sehr ähnliche Berechtigungen feststellen (siehe unten).

Als Angreifer müssen Sie also Schreibzugriff auf die GPT (oder in manchen Fällen die GPC) eines bestimmten GPO erlangen, um diesen GPO zu kompromittieren. Dies ist natürlich nicht unmöglich, insbesondere wenn es dem Angreifer gelingt, sich in eine Administratorrolle zu erheben, die möglicherweise über Bearbeitungsrechte für einen GPO verfügt. Aus Sicht der Verteidigungunterstreicht dies jedoch,wie wichtig es ist, strenge Kontrollen über Ihre GPO-Delegierungen zu haben. Berechtigungen zum Bearbeiten oder Erstellen von GPOs sollten nur an eine kleine Handvoll Systemadministratoren delegiert werden, und diese Sicherheitsprinzipale sollten angesichts der potenziellen Auswirkungen, die eine böswillige GPO-Änderung auf die gesamte Umgebung haben kann, als„Tier-0“-Administratoren behandelt werden. Noch besorgniserregender ist, dass es sehr schwierig sein kann, diese böswilligen Änderungen zu erkennen, wenn ein Angreifer Schreibzugriff beispielsweise auf die GPT erlangt und die Einstellungsdateien direkt modifiziert, anstatt etablierte GPO-Änderungsmanagement-Tools wie den GP Editor zu nutzen. Im Wesentlichen müssen Sie nach Dateisystemänderungen im GPT suchen, um die meisten dieser unerwünschten Änderungen zu erkennen; da jedoch legitime GPO-Änderungen GPT-Änderungsbenachrichtigungen generieren, müssen Sie auch in der Lage sein, sowohl böswillige als auch gültige GPO-Änderungen zu sichten, um diejenigen zu finden, die Ihnen Kopfzerbrechen bereiten können.  Die gute Nachricht ist: Wenn ein Angreifervöllig neuepolicy zu einem GPO hinzufügen muss (d. h. er muss eine andere CSE als die bereits bereitgestellte aufrufen), steigen seine Chancen, entdeckt zu werden. Der Grund dafür ist, dass, damit ein Client (Server oder Workstation) eine neue policy verarbeiten kann, mehrere Änderungen im GPC erfolgen müssen (z. B. muss die versionNumber erhöht und die CSE-ExtensionGUIDs korrekt zum GPC hinzugefügt werden), um den Client auf diese Einstellungen aufmerksam zu machen; dies erschwert es einem Administrator, derüber eine angemessene GP-Überwachungverfügt, die Manipulation nicht zu bemerken. Was die policy betrifft, die sich am besten für diese Art von Manipulationen eignen, lesen Sie den ausgezeichneten Beitrag von @_wald0„A Red Teamer’s Guide to GPOs and OUs“, in dem einige policy aufgeführt sind, an denen man mit gutem Erfolg herumspielen kann. Dieser Punkt spricht auch dafür, GPOs, die besonders „ausnutzbare“ policy implementieren, besonders streng abzusichern.Fazit: Schränken Sie ein, wer diese GPOs bearbeiten darf!

Externe Pfade

Dies bringt mich zu meinem neuesten Interesse (Punkt 3 oben), nämlich der Verwendung von Verweisen auf „externe Pfade“ in GPOs, um die von Administratoren in Punkt 2 oben auferlegte Einschränkung zu umgehen. Was meine ich mit externen Pfaden? Nun, eigentlich jede Referenz in einem GPO, die auf eine ausführbare Datei, ein Skript, ein MSI-Paket oder eine andere Datei verweist, die bei Aufruf „etwas tut“ und sich außerhalb der normalen GPC- und GPT-Speicherorte (Sysvol) befindet. Warum sind diese interessant? Weil selbst wenn Sie den Schreibzugriff auf GPOs sperren, wie ich unter Punkt 2 vorgeschlagen habe, potenziell Skripte, ausführbare Dateien und MSI-Pakete auf Dateiservern in Ihrem gesamten Netzwerk verstreut sein könnten – mit unterschiedlichen Zugriffskontrollen –, die von eben jenen gesperrten GPOs aufgerufen und ausgeführt werden, die Sie für so sicher hielten. Ein Angreifer, dem es nicht gelingt,Schreibzugriffauf ein GPO zu erlangen, kann also seinenLesezugriff(siehe Punkt 1 oben) nutzen, um diese referenzierten externen Pfade aufzuspüren und zu versuchen, diese Skripte, EXE-Dateien und MSIs durch seine eigenen bösartigen Versionen zu ersetzen (diese Aufgabe wird durchGrouper2tatsächlich erheblich vereinfacht). Wenn dieses GPO das nächste Mal von einem Client verarbeitet wird, wird diese schädliche Datei vom GPO, das nichts davon ahnt, problemlos ausgeführt. Beispiele für policy , die typischerweise auf externe Pfade verweisen können (d. h. Pfade außerhalb von GPC und GPT), sind unter anderem:

  • Skripte zum Starten/Herunterfahren und An-/Abmelden
  • GP Software-Installation (MSI-Dateien)
  • GP-Einstellungen Geplante Aufgaben
  • GP-Einstellungen Drucker (bei TCP/IP-Druckern können Sie einen externen Pfad angeben, von dem der Client die Druckertreiber herunterladen soll - toll!)
  • GP Preferences Shortcuts, für Verknüpfungen, die an Orten mit automatischer Ausführung existieren, wie Startup
  • GP-Voreinstellungsdateien, in denen Sie Dateien haben, die von beliebigen externen Speicherorten in die automatische Ausführung oder andere "leicht auszuführende" lokale Dateispeicherorte kopiert werden können.

Um ehrlich zu sein, gibt es wahrscheinlich noch mehr solcher Orte, die in GP versteckt sind (und ich suche weiter...). Die oben genannten sind die offensichtlichsten.

Warum sollten Sie sich also Gedanken über diese externen Pfade machen? Nun, denken Sie einmal darüber nach: Das oben unter Punkt 2 beschriebene Problem, unerwünschte Manipulationen an GPOs zu verhindern, ist begrenzt. Sie müssen sich lediglich um die Delegierung dieser GPOs kümmern, um die Kontrolle über solche Vorgänge zu behalten. Wenn Sie jedoch GPOs haben, die auf ausführbaren Code auf externen Dateifreigaben verweisen, müssen SieIhren Blickwinkelnunauf JEDEN EINZELNEN DIESER DATEISPEICHERORTE ausweiten! Wie viele von Ihnen können sich der Berechtigungsverwaltung auf beliebigen Dateifreigaben in Ihrer Umgebung sicher sein (ganz zu schweigen von Ihren GPOs)? Wenn also ein GPO eine ausführbare Datei oder ein Installationsprogramm aufruft, das sich auf einer unsicheren Freigabe befindet, werden Ihre GPOs nun zu unbeabsichtigten Verbreitungskanälen für jeglichen beliebigen Müll, durch den ein Angreifer diese ausführbaren Dateien ersetzen kann. Und da innerhalb von GP natürlich keine CRC-Prüfung oder andere Gültigkeitsprüfungen durchgeführt werden, sind Sie den dort vorhandenen Dateien schutzlos ausgeliefert (eine Milderung hierfür ist die Tatsache, dass nicht alle policy ihre Payloads automatisch und jederzeit ausführen. Wenn ein Rechner beispielsweise bereits eine Softwarebereitstellung über policy „Softwareinstallation“ erhalten hat, wird er diese bösartige MSI unter normalen Umständen nicht erneut bereitstellen. Aber alle neuen Rechner erhalten natürlich das schädliche Paket).

Was ist also die Quintessenz in diesem Fall? Sichern Sie nicht nur Ihre GPO-Delegationen, sondern finden Sie zunächst heraus, wo sich Ihre externen Pfadverweise in Ihrer Umgebung befinden, und sichern Sie dann Ihre externen Pfade!!!!

Zusammenfassung

Ich hoffe, dass dies ein paar zusätzliche Denkanstöße für den Schutz Ihrer GP-Umgebung und damit Ihrer gesamten Windows-Umgebung liefert. Wenn Sie sich heute bei der Konfiguration Ihrer Windows-Systeme auf GP verlassen, kann ich nicht genug betonen, wie wichtig es aus der Sicht der Informationssicherheit ist, sicherzustellen, dass diese GPOs abgesichert sind und dass alles Externe, das sie aufrufen, als "in der gleichen Domäne von Belang" behandelt und ebenfalls abgesichert wird. Fassen wir also die Aktionspunkte zusammen:

  1. Sperren Sie den Lesezugriff auf kritische, sicherheitsrelevante GPOs, um sicherzustellen, dass Sie Ihre Sicherheitslage nicht verraten.
  2. Sperren Sie den Schreibzugriff auf alle GPOs, um sicherzustellen, dass sie nicht als Angriffsvektor missbraucht werden.
  3. Sperren Sie den Schreibzugriff auf alle externen Pfade, auf die von GPOs verwiesen wird

Darren