Privilege Escalation & Lateral Movement mit GPO Poisoning

Einleitung

In meinem Video Simulation eines Angriffs aus meiner Video-Serie Hacking & Defense habe ich eine Privilege Escalation bzw. ein Lateral Movement mit einer GPO-Veränderung erreicht: Ich konnte mit der Identität eines niederen Admins ein Konto der Domain Admins übernehmen. In diesem Artikel möchte ich dazu die Hintergründe erläutern und mögliche Schutzmaßnahmen erklären.

Wie funktioniert das “Vergiften” der GPO?

Zur Abwechslung habe ich das mal in einem Video aufgezeichnet:

Der Exploit der Schwachstelle ist also lediglich das Erweitern einer vorhandenen Richtliniendatei, auf die ein GPO-Editor bzw. ein ehemaliger Editor (!) Schreibrechte hat. Das ist nicht nur wie hier geplant für geplante Aufgaben möglich: ich kann durch das Verändern einer registry.pol z.B. gezielt die Registry des Computers/Benutzers bearbeiten oder mit der Veränderung einer GptTmpl.inf die lokalen Gruppenmitgliedschaften auf einem Computer editieren:

Damit kann der Angreifer seine Rechte ausweiten (Privilege Escalation) und/oder andere Systeme übernehmen (Lateral Movement).

Ursachen für diese Problematik sind:

• eine falsche Rechtedelegation von GPO: Man kann das Bearbeitungsrecht einer GPO nicht weiter einschränken. Wer dieses Recht hat, kann alle Teile einer GPO anpassen. Man muss dann also aufpassen, welche Benutzer/Computer die Richtlinie nachher verarbeiten. Delegiere ich z.B. die Bearbeitungsrechte an einer Microsoft-Edge-GPO an einen Tier-2-Admin und mappe diese GPO aber für alle Benutzerkonten, dann kann der Tier-2-Admin auch Einstellungen für höherprivilegierte Tier-0-Admins schreiben – und das kann dann auch ein Angreifer, der eine Tier-2-Kennung kontrolliert!
• ein Bug beim Entfernen einer GPO-Rechtedelegation: Die grafische Komponente lässt eine Editierung einer GPO nach dem Entfernen der Berechtigung nicht mehr zu. Aber bei der Anlage der GPO-Einstellungen werden einige Dateien und Verzeichnisse im Kontext des Editors angelegt. Diese Berechtigungen werden nicht sauber bereinigt (daher ist das für mich ein Bug!). So kann der ehemals Delegierte weiter die Dateien mit den Einstellungen editieren – und ein Angreifer in dessen Benutzerkontext eben auch.

Gegenmaßnahmen

Was könnt ihr tun, damit diese Lücke nicht zum Problem wird?

1. Kontrolliert regelmäßig, wer außer den Domain Admins noch die GPO editieren kann.
2. Delegiert Gruppenrichtlinien nur nach sorgfältiger Prüfung: Wer darf die GPO editieren und für wen gilt die GPO danach? Hier darf die Administration immer nur von oben nach unten gehen. Ein niederer Account darf niemals einen höheren Account beeinflussen können.
3. Achtet beim nachträglichen Verknüpfen von GPO immer auf deren Berechtigungen. Hier gilt das Ziel aus #2
4. Denkt an die verwaisten Dateiberechtigungen und Datei-Owner, nachdem ihr Rechtedelegationen entfernt habt. Diese sind leicht für Angreifer zu finden. Bereinigt diese mit meinem Script GPO-ACL-Cleanup

Zusammenfassung

Gruppenrichtlinien sind ein tolles Instrument für eine einfache, zentrale Konfiguration – aber eben auch ein Risiko, wenn man die Lücken darin nicht kennt.

Stay tuned!