Los geht’s mit dem Thema des Vortags – wirklich 😊

Nach einer zugegeben etwas längeren Einleitung nun aber zu Thema.

Im Active Directory gibt es sowohl Standardberechtigungen als auch historisch gewachsene Fehlkonfigurationen, die ein Angreifer ausnutzen kann. Zunächst gehen wir kurz darauf ein, wie Berechtigungen im AD funktionieren, beschreiben dann wieso dieses altbekannte Thema auch heute noch relevant ist um abschließend unseren Lösungsansatz vorzustellen.

Was sind AD ACLs / ACEs?

Jedes Objekt im Active Directory hat eine Access Control List (ACL). Genau wie im NTFS Filesystem beschreibt die ACL „wer was darf“. Die ACL setzt sich aus einzelnen Access Controll Entries (ACEs), die eine atomare Berechtigung definieren, zusammen. Das sieht dann so aus:

Das User Objekt „Andy“ hat eine ACL die sich aus 32 ACEs zusammensetzt. Um einige Beispiele zu nennen:

• • Die Gruppe „Account Operators“ hat das Recht „Full Control“
  • Die Gruppe „Cert Publishers“ hat das Recht die Eigenschaft „UserCertificate“ zu lesen und zu schreiben
  • Die Gruppe Service Desk hat das Recht „Reset Password“

Wie können ACLs ausgenutzt werden (Beispiele)

Bloodhound visualisiert die (bekannten) Ausnutzbaren ACLs in so genannten Edges:

In diesem Beispiel kann die Gruppe Helpdeskadmins Mitglieder zur Gruppe Serveradmins hinzufügen. Da Andy Mitglied dieser Gruppe ist, hat auch er dieses Recht. Die Gruppe Serveradmins hat wiederum das Recht „Generic All“ = Vollzugriff auf einen Server namens „Adminserver01“.

Das Recht „Vollzugriff“ kann auf verschiedene Arten ausgenutzt werden:

1. 1. 1. Wenn der Kunde LAPS einsetzt, kann der Angreifer das Passwort des lokalen Administrators auslesen
      2. Ein shadow credential Angriff mit dem das TGT oder der NTLM Hash des Objekts gestohlen wird
      3. Ein Resource Based Constrained Delegation Angriff der einen beliebigen User gegen das Objekt authentifiziert.

Warum sind ACLs auch heute noch ein Sicherheitsproblem?

ACL basierte Angriffe sind nicht neu, Miskonfigurationen begegnen uns aber in quasi jeder Umgebung.

Wir haben 4 Gründe identifiziert, warum das unserer Meinung nach so ist:

1. 1. 1. ACLs sind kompliziert.
         Der Default Security Descriptor definiert die Berechtigungen, die jedes neu erstellte Objekt hat. Würde z.B. ein Pentest Report aufzeigen, dass ein Angreifer die weiter oben beschriebene „Full Control“-Berechtigung ausgenutzt hat, könnte man denken, das das Entfernen der Berechtigung das Problem löst. In der Realität wird aber jedes neu erstellte Objekt diese ACE wieder enthalten und somit wieder ausnutzbar sein.
         Neben dem Default Security Descriptor gibt es noch den AdminSD Holder Prozess. Dieser schützt die aus Microsoft’s Sicht schützenswerten Objekte und überschreibt Änderungen an den Berechtigungen. Um beim Beispiel des Pentest Reports zu bleiben, würde man die Berechtigung eines geschützten Objekts nach dem Pentest anpassen, würde die Änderung nach einer Stunde wieder rückgängig gemacht werden. Leider werden nicht alle relevanten Objekte vom AdminSD Holder Prozess geschützt.
      2. Es werden nach wie vor neue Angriffswege die alle auf ACLs basieren gefunden. Hier ein Beispiel was allein in Bloodhound seit 2017 hinzugefügt wurde:
      3. Die Anzahl von ACLs und Beziehungen zu anderen Objekten ist unfassbar groß. Auf dem folgendem Bloodhound Enterprise Screenshot aus einer relativ kleinen Umgebung mit ~4500 Benutzern ist zu erkennen, dass es 360.000 ACLs bzw. ~480.000 Beziehungen gibt.

Das sind Größenordnungen weit jenseits von dem was manuell geprüft werden kann.

Was können wir jetzt tun?

Eine und die von uns favorisierte Lösung ist eine Tiering Struktur einführen und die Assets anhand ihres Schutzbedarfs zu schützen. Ein Teilaspekt und Kernthema des Troopers Vortrags / dieses Artikels ist der Aufbau einer geschützten OU Struktur als Grundgerüst für das Tiering. Über einige der anderen Maßnahmen haben wir schon gebloggt (LINK1, LINK2), weitere Artikel werden folgen.

Wir empfehlen ausdrücklich NICHT Berechtigungen in existierenden OUs anzupassen (vereinzelte Quick Wins ausgenommen). Stattdessen sollte eine neue OU-Struktur erstellt, mit den passenden Rechten versehen und befüllt werden.

Die Empfehlungen für die Berechtigungen basieren auf einem Best Practice Guide aus dem Jahre 2011 😊. Diese 12 Jahre alte Quelle ist nach wie vor gültig und, wir kennen derzeit keine neuere gültige Referenz. Falls jemand eine neuere Quelle hat, kann er sich sehr gerne melden. Wir würden auch ein Eis spendieren 😊.

Rollen und Verantwortlichkeiten definieren

Zuerst muss die Frage beantwortet werden – wer soll was machen? Was sich einfach anhört, ist oftmals nur sehr schwer zu beantworten. Unternehmen wissen oftmals nicht, wer was übernehmen soll. Oder es kommen Aussagen wie – alle in Team XY müssen lokaler Administrator auf allen Servern sein. Genau so funktioniert es aber nicht. Es ist mühsam und schmerzhaft, diese Altlast muss aber dennoch zwingend beseitigt werden. Hier ein Auszug als Beispiel wie eine Definition aussehen könnte:

Eine neue OU-Struktur Aufbauen

Microsoft empfiehlt im ESAE-Modell eine Unterteilung in Tier0, Tier1 und Tier2. Das kann beispielsweise so aussehen:

Die Struktur kann natürlich an die Bedürfnisse der jeweiligen Organisation angepasst werden.

Um es unseren Lesern einfacher zu machen, haben wir ein Skript zu Erstellung der OUs veröffentlicht:

https://github.com/teal-technology-consulting/New-TealTierOUs

Die OUs werden über eine XML definiert und per Skript angelegt. Einfach unseren Vorschlag übernehmen, oder die XML anpassen.

Berechtigungen setzen

Als nächstes müssen auf die neu erstellten OUs die Berechtigungen aus dem Best Practise Guide gesetzt werden. Auch hierfür haben wir ein Skript veröffentlicht: teal-technology-consulting/Set-TealTierOUAcl: Sets secure permissions on a tiering OU structure (github.com)

Es unterbindet die Vererbung auf der obersten Ebene (Administration OU im Beispiel oben), setzt die gewünschten Berechtigungen und entfernt alle direkten Berechtigungen auf untergeordneten OUs.

Die Vererbung auf den untergeordneten OUs bleibt eingeschaltet, damit Delegierungen wie gewohnt vererbt werden.

Hoch privilegierte Gruppen verschieben

Der Best Practise Guide besagt, dass die Standard Gruppen „Domain Admins“, „Schema Admins“ und Enterprise Admins in die gesicherte OU-Struktur verschoben werden sollen.

Aus unserer Sicht ist das nicht ausreichend. Neben den genannten Gruppen und den Gruppen die durch den Admin SD Holder Prozess geschützt sind, ist heute bekannt, dass weitere builtin-Gruppen ausgenutzt werden können.

Microsoft hat zwar eine Dokumentation welche Gruppen verschoben werden dürfen, aus unserer Sicht enthält die Dokumentation Fehler und ist auch nicht immer hilfreich:

Daher empfehlen wir alle Gruppen aus der „Users“ OU zu verschieben, NACHDEM man die Auswirkung in der eigenen Umgebung getestet hat.

Berechtigungen regelmäßig setzen

Nun wären wir eigentlich soweit, die restlichen Assets in die korrekten Ous zu verschieben. Weiter oben haben wir erwähnt, dass neue Objekte die ACLs aus dem Default Security Descriptor erhalten. Dadurch bekommen die Account Operatoren weitreichenden Zugriff auf Benutzer und Gruppenobjekte die innerhalb der geschützten OU Struktur neu angelegt werden:

“The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including accounts for users, Local groups, and Global groups. Group members can log in locally to domain controllers.”

Grundsätzlich empfehlen wir die Account Operators nicht zu nutzen, was natürlich einen Angreifer nicht davon abhält die Berechtigungen auszunutzen. Daher haben wir ein Skript geschrieben, welches regelmäßig z.B. alle 15 Minuten durch einen Scheduled Task ausgeführt werden soll und die Account und Print Operatoren aus den ACLs aller Objekte in der geschützten OU Struktur entfernt.

Das Skript ist hier zu finden:

teal-technology-consulting/Remove-AccAndPrintOpsFromOU: A script to remove the Print- and Account Operator groups from all objects in an OU structure. It is meant to run in a scheduled task. (github.com)

Eine alternative Option ist den Default Security Descriptor anzupassen. Da wir nicht ausschließen können, dass dies unbeabsichtigte Seiteneffekte nach sich zieht, bevorzugen wir die Skript Variante.

Neue Objekte, delegieren und verschieben

Die OU-Struktur ist nun einsatzbereit und es können Assets in die Struktur verschoben werden. Das ist je nach Organisationsgröße durchaus ein langwieriger Prozess.

Es empfiehlt sich zuerst mit den neu anzulegenden Objekten zu starten und die Administratoren im Umgang mit der neuen Struktur zu schulen.

Werden Bestandsobjekte verschoben, müssen die Berechtigungen kontrolliert werden, da direkt gesetzte ACEs mit umgezogen werden. Das gilt übrigens auch für Group Policy Objekte, die an die neue OU-Struktur verlinkt werden.

Um die Tiertrennung der Accounts durchzusetzen, sollten Kerberos Authentication Policy Silos eingerichtet werden. Aber das ist ein Thema für einen anderen Post 😉.

Fazit

Mit den aufgezeigten Änderungen kann ein erheblicher Beitrag zu Steigerung der IT-Sicherheit realisiert werden. Die gezeigten Tätigkeiten sind teilweise komplex und mühsam, lohnen sich aber definitiv. Zum einen hat man nach der Durchführung definiert wer welche Verantwortlichkeiten hat und veraltete Berechtigungsstrukturen aufgeräumt. Das ganze Thema kann vollständig ohne teuren Detection and Response Lösungen realisiert werden – kostet also keine Lizenzen, sondern „nur“ den Aufwand von vorhandenen IT-Ressourcen. Nicht falsch verstehen, Detection and Response Tools haben natürlich auch einen Mehrwert, aber oftmals hat man mehrere Tools im Einsatz die teilweise sogar dasselbe umsetzen. Hier könnte man sinnvoll sparen und stattdessen die Zeit und das Budget für die Beseitigung von Altlasten verwenden. Bei Fragen unterstützen wir gerne, einfach bei uns melden.

Off Topic

An dieser Stelle ein herzliches Dankeschön an unseren Alex, dass er diesen Vortrag vorbereiten und bei der Troopers präsentiert hat. Sobald der Talk online ist, werden wir diesen auch noch verlinken. Bis dahin ein paar Impressionen von der Troopers, inklusive Feueralarm mitten in der Nacht 😊.

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting)

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting)

LATEST POSTS