Wenn Sie diesen Blog verfolgen, wissen Sie, dass ich vor etwa zweieinhalb Jahren damit begonnen habe, über die prekäre Rolle der Gruppenrichtlinien in der Sicherheitslage des typischen Unternehmens zu sprechen. Viele, wenn nicht sogar die meisten AD-Geschäfte verwenden Gruppenrichtlinien, um die Sicherheit ihrer Windows-Desktops und -Server zu erhöhen. Dazu gehört alles, von der Anpassung der Betriebssystemeinstellungen über die Deaktivierung von NTLMv1 oder das Herumspielen mit der Benutzerkontensteuerung (UAC) bis hin zur Kontrolle, wer sich bei welchen Rechnern anmelden kann und welche AD-Gruppen auf welchen Desktops und Servern privilegierten Zugriff haben. All dies wird in GPOs gespeichert, die standardmäßig von jedem authentifizierten Benutzer gelesen werden können. Diese Tatsache ist schon lange bekannt - eigentlich schon seit dem Jahr 2000, als AD & GP auf den Markt kamen - aber erst in den letzten Jahren ist sie als potenzielles InfoSec-Problem deutlicher sichtbar geworden, vor allem dank Tools wie Bloodhound, PowerView und Grouper, die die Tatsache aufdecken, dass diese Informationen für alle möglichen Arten von Unfug verwendet werden können.
Seitdem habe ich mich weitgehend auf die defensive Seite der Gleichung konzentriert, und zwar in erster Linie auf Empfehlungen zur Verringerung der Lesbarkeit von sicherheitsrelevanten GPOs, um zu verhindern, dass ein Angreifer die Sicherheitslage eines Unternehmens leicht entdecken kann. In letzter Zeit habe ich jedoch einige Zeit damit verbracht, über Möglichkeiten für eine destruktivere Nutzung von GPOs nachzudenken - die Ausnutzung vorhandener Einstellungen innerhalb editierbarer GPOs, um verschiedene bösartige Aufgaben in einer Umgebung durchzuführen. Da sich GP oft auf die meisten, wenn nicht sogar alle Benutzer und Computer in einem Unternehmen auswirkt, ist es ein sehr effizienter Mechanismus zur Verbreitung von Malware, wie ich vor einiger Zeit in einem Blogbeitrag erläutert habe. Diese Arten von Angriffen, bei denen bösartige Einstellungen in ein GPO eingeschleust werden, beruhen auf der Fähigkeit des Angreifers, Schreibrechte für ein GPO zu erhalten - insbesondere für den SYSVOL-Teil des GPO, in dem die meisten (aber nicht alle) GP Client Side Extensions (CSEs) ihre Einstellungen speichern. Natürlich müssen Sie auch das Einstellungsformat des Richtlinienbereichs, auf den Sie Einfluss nehmen möchten, verstehen, um ihn zu kapern. Und ausnahmsweise ist die umständliche Art und Weise, mit der Microsoft an die Entwicklung von CSEs herangegangen ist, hier von Vorteil, denn so ziemlich jeder Richtlinienbereich verwendet ein anderes Schema und eine andere Datenstruktur, um seine Einstellungen zu speichern. Ein Punkt für architektonische Inkonsequenz!
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 GPOs verwiesen wird und die übermäßig freie Schreibrechte haben. Dies ist eine Abwandlung von Nr. 2. Ich habe diese Idee beim Testen und bei der Zusammenarbeit mit @mikeloss an seinem hervorragenden Dienstprogramm Grouper2 (siehe oben) entdeckt. Grouper2 sucht nach "interessantem" Material in GPOs, das alles umfassen kann, von Richtlinien für eingeschränkte Gruppen, die privilegierten Zugriff gewähren, über verweilende GPP-Passwörter bis hin zu, was für mich noch interessanter ist, Verweisen auf externe ausführbare Dateien, Skripte oder Installationsprogramme. Auf diese externen Pfade gehe ich weiter unten im Abschnitt "Externe Pfade" näher ein, aber @mikeloss gebührt das Verdienst, mich auf diesen Punkt aufmerksam gemacht zu haben.
GPO-Delegation
Lassen Sie uns mehr über #2 oben sprechen. Die Funktionsweise der GPO-Delegation besteht darin, dass Sie Benutzern, Computern oder Gruppen unterschiedliche Zugriffsrechte auf ein GPO gewähren, in der Regel im GPMC auf der Registerkarte "Delegation" eines bestimmten GPO oder mit der PowerShell. Diese Berechtigungen (einschließlich Lesen, ReadApply, "Einstellungen bearbeiten" und "Einstellungen bearbeiten, löschen und Sicherheit ändern") werden auf das entsprechende AD-basierte Gruppenrichtlinien-Container-Objekt (GPC) und den GUID-benannten Ordner in der Gruppenrichtlinienvorlage (GPT) (d.h. SYSVOL) übertragen. Natürlich entsprechen die AD-Berechtigungen nicht 1:1 den NTFS-Dateisystemberechtigungen, aber wenn Sie sich beide Teile eines GPO im ACL-Editor ansehen, werden Sie sehr ähnliche Berechtigungen sehen (siehe unten).
Als Angreifer müssen Sie also in der Lage sein, Schreibzugriff auf den GPT (oder in einigen Fällen auf den GPC) eines bestimmten GPOs zu erhalten, um dieses GPO zu kompromittieren. Das ist natürlich nicht unmöglich, vor allem, wenn der Angreifer in der Lage ist, sich in eine Administratorrolle zu versetzen, die möglicherweise über Bearbeitungsrechte für ein GPO verfügt. Aus der Sicht eines Verteidigers unterstreicht dies jedoch , wie wichtig es ist, die Delegierung von GPOs genau zu kontrollieren. Berechtigungen zum Bearbeiten oder Erstellen von GPOs sollten an eine kleine Handvoll Systemadministratoren delegiert werden, und diese Sicherheitsbeauftragten 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, wenn ein Angreifer Schreibzugriff auf z.B. den GPT erhält, sehr schwierig sein kann, diese böswilligen Änderungen zu entdecken, wenn der Angreifer die Einstellungsdateien direkt ändert und nicht über etablierte GPO-Änderungsmanagement-Tools wie GP Editor. Sie müssen im Wesentlichen nach Dateisystemänderungen auf dem GPT suchen, um die meisten dieser unerwünschten Änderungen erkennen zu können. Da jedoch legitime GPO-Änderungen GPT-Änderungsbenachrichtigungen erzeugen, müssen Sie auch in der Lage sein, sowohl bösartige als auch gültige GPO-Änderungen zu erkennen, um diejenigen zu finden, die Ihnen Kopfzerbrechen bereiten können. Die gute Nachricht ist, dass die Chancen, entdeckt zu werden, steigen, wenn ein Angreifer einem GPO neue Einstellungen für den Richtlinienbereich hinzufügen muss (d.h. er muss eine andere CSE aufrufen als die, die bereits bereitgestellt wurde). Denn damit ein Client (Server oder Workstation) eine neue GPO-Richtlinienbereichseinstellung verarbeiten kann, müssen mehrere Änderungen im GPC vorgenommen werden (z.B. wird die Versionsnummer erhöht und die CSE ExtensionGUIDs werden dem GPC korrekt hinzugefügt), damit der Client von diesen Einstellungen Kenntnis erhält. Was die Richtlinienbereiche betrifft, die sich am besten für diese Art von Manipulationen eignen, so finden Sie in @_wald0shervorragendem Beitrag "A Red Teamer's Guide to GPOs and OUs" einige Beispiele für Richtlinienpfade, an denen mit gutem Erfolg herumgepfuscht werden kann. Dieser Punkt spricht auch dafür, GPOs, die hochgradig "ausnutzbare" Richtlinienbereiche implementieren, besonders abzusichern. Fazit: Schränken Sie ein, wer diese GPOs bearbeiten kann!
Externe Pfade
Das bringt mich zu meiner neuesten Faszination (#3 oben), nämlich der Verwendung von Verweisen auf "externe Pfade" in GPOs, um die von Admins auferlegte Beschränkung (#2 oben) 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 beim Aufruf "etwas tut" und die außerhalb der normalen GPC- und GPT- (Sysvol-) Speicherorte existiert. Warum sind diese interessant? Denn selbst wenn Sie den Schreibzugriff auf GPOs sperren, wie ich in Nr. 2 vorgeschlagen habe, könnten Sie möglicherweise Skripte, ausführbare Dateien und MSI-Pakete auf Dateiservern in Ihrem gesamten Netzwerk haben, die mit unterschiedlichen Zugriffskontrollen versehen sind und die von denselben gesperrten GPOs aufgerufen und ausgeführt werden, die Sie für so sicher hielten. Ein Angreifer, dem es nicht gelingt, Schreibzugriff auf ein GPO zu erhalten, kann also seinen Lesezugriff (ala #1 oben) nutzen, um diese referenzierten externen Pfade ausfindig zu machen und zu versuchen, diese Skripte, Exes und MSIs durch seine eigenen bösartigen Versionen zu ersetzen (diese Aufgabe wird durch Grouper2 in der Tat erheblich erleichtert). Wenn das GPO das nächste Mal von einem Client verarbeitet wird, wird diese bösartige Datei fröhlich von dem GPO ausgeführt, das davon nichts mitbekommt. Beispiele für Richtlinienbereiche, die typischerweise auf externe Pfade verweisen können (d.h. Pfade außerhalb von GPC und GPT) sind
- 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 müssen Sie sich also Gedanken über diese externen Pfade machen? Denken Sie einmal darüber nach - das Problem, unerwünschte Manipulationen von GPOs zu verhindern, wie in Punkt 2 beschrieben, ist begrenzt. Sie müssen sich nur um die Delegierung dieser GPOs kümmern, um die Kontrolle über diese Art von Verhalten zu behalten. Wenn Sie jedoch GPOs haben, die auf ausführbaren Code auf externen Dateifreigaben verweisen, müssen Sie sich jetzt um JEDEN DIESER DATEISÄTZE kümmern! Wie viele von Ihnen können sicher sein, dass die Berechtigungsverwaltung für beliebige Dateifreigaben in Ihrer Umgebung (geschweige denn für Ihre GPOs) funktioniert? Wenn also ein GPO eine ausführbare Datei oder ein Installationsprogramm aufruft, das sich auf einer unsicheren Freigabe befindet, werden Ihre GPOs nun zu ungewollten Verteilern für jeden beliebigen Mist, mit dem ein Angreifer diese ausführbaren Dateien ersetzen kann. Und da innerhalb von GP keine CRC-Prüfung oder andere Gültigkeitsprüfung durchgeführt wird, sind Sie natürlich den dort vorhandenen Dateien ausgeliefert (eine Abschwächung dieses Problems ist die Tatsache, dass nicht alle Richtlinienbereiche ihre Nutzdaten immer automatisch ausführen. Wenn ein Rechner beispielsweise bereits eine Softwareverteilung über die Richtlinie Softwareinstallation erhalten hat, wird diese bösartige MSI unter normalen Umständen nicht erneut verteilt. 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:
- Sperren Sie den Lesezugriff auf kritische, sicherheitsrelevante GPOs, um sicherzustellen, dass Sie Ihre Sicherheitslage nicht verraten.
- Sperren Sie den Schreibzugriff auf alle GPOs, um sicherzustellen, dass sie nicht als Angriffsvektor missbraucht werden.
- Sperren Sie den Schreibzugriff auf alle externen Pfade, auf die von GPOs verwiesen wird
Darren
