Active Directory Security: Den GAU verstehen und verhindern (Teil 2)

Vorbemerkung

Dieses ist der zweite Teil der Blogreihe „Active Directory Security – Den GAU verstehen und verhindern“. In diesem Teil werden Verfahren aufgezeigt wie man sich durch die Einführung von administrativen Sicherheitsgrenzen wirkungsvoll vor dem super GAU schützen kann, wie man diese Sicherheitsgrenzen plant und wie man sie letztendlich auf technischer Ebene umsetzen kann.

Blog Part 1:

1. Die Macht in einem Windows basierten Netzwerk und der super GAU

2. Wie „hackt“ man ein Active Directory Infrastruktur – Teil 1: Identity Theft

3. Wie „hackt“ man ein Active Directory Infrastruktur – Teil 2: Privilege Escalation

4. Wie „hackt“ man ein Active Directory Infrastruktur – Teil 3: Social Engeneering

Blog Part 2:

1. Wie kann man sich wirkungsvoll vor dem super GAU schützen?

2. Grundlagen der administrativen Sicherheitszonen

3. Technische Umsetzung der administrativen Sicherheitszonen

Wie kann man sich wirkungsvoll vor dem super GAU schützen?

Die Ergebnisse unserer Audits zeigen uns, dass Keylogger, unzureichende NTFS-Berechtigungen oder gar Passwörter, die im Klartext oder in einer reversiblen Form gespeichert wurden, eine große Gefahr für das Active Directory darstellen und somit als „Schlüsselkasten“ eines Windows-basierten Netzwerks oftmals sehr leicht geknackt werden kann. Die spannende Frage, die man sich hierbei stellen muss, ist, wie sich Unternehmen wirkungsvoll gegen solche Angriffe auf ihre Active Directory-Infrastruktur schützen können.

Zunächst einmal muss für dieses Problem ein Umdenken bei den Administratoren erfolgen. Statt ausschließlich zu versuchen, die Symptome, die ich in diesem Blog erläutert habe, zu bekämpfen (einige davon lassen sich nicht wirklich bekämpfen und es existieren noch viele andere), sollte man die gemeinsame Ursachen verstehen, die es einem Angreifer ermöglichen, aufgrund dieser eher kleinen Sicherheitsprobleme letztendlich einen Vollzugriff auf die gesamte Active Directory-Infrastruktur zu erlangen.

In den Dokumentationen zu unseren Security Audits beschreiben wir die gemeinsame Ursache meist unter dem Finding „Mangelnde/Fehlende Sicherheitsgrenzen innerhalb des Active Directory“. Darin analysieren wir die administrative Delegation innerhalb der Windows-Landschaft und bewerten gleichzeitig, wie sorgsam mit Benutzerkonten umgegangen wird, die weitreichende Rechte und Berechtigungen innerhalb der Active Directory-Infrastruktur zugewiesen bekommen haben (e.g. Domänen-Administratoren).

Abbildung 9: ITaCS Security Finding

Existieren zum Beispiel in einem Unternehmen eine Vielzahl an Domänen-Administratoren-Konten, die für die tägliche Administration, den User-Helpdesk und sogar netzwerkweit zur Ausführung von Diensten und Tasks verwendet werden, gehen wir in unserem Security Audits meist vom schlimmsten aus. In diesem Fall würde bereits die kleinste Sicherheitslücke auf einem der beteiligten Systeme mit sehr hoher Wahrscheinlichkeit das gesamte Kartenhaus zum Einsturz bringen. Für uns als Penetrationstester, aber auch für Angreifer, ist es in diesem Fall einfach, Vollzugriff auf die Active Directory-Infrastruktur zu erlangen. Wir müssen nur die Einsatzorte der Domänen-Administratoren-Konten analysieren und etwaige Sicherheitsprobleme ausfindig machen. Existiert nur auf einem System ein schwerwiegendes Problem, sind gleich alle Systeme davon betroffen („BORE“ Prinzip).

Wird jedoch im Unternehmen die Anzahl der Domänen-Administratoren stark eingeschränkt und der Einsatz dieser Konten nur auf die notwendigsten Aufgaben und auch nur auf gewissen Systemen reduziert, stehen die Chancen eher schlecht, Vollzugriff auf das gesamte Active Directory zu erlangen. Die Anzahl der möglichen Fehlerquellen und somit auch die Chance, einen qualifizierten Exploit innerhalb der relevanten Systemkonfiguration zu finden, würde in diesem Fall stark reduziert, so dass die Wahrscheinlichkeit eines super GAUs drastisch abnimmt. Das oben aufgeführte Beispiel eines Client PCs, der von einem böswilligen Benutzer manipuliert bzw. präpariert wurde, würde bei einer Etablierung von administrativen Sicherheitsgrenzen womöglich keine Gefahr mehr für die Active Directory Domäne darstellen, da sich in diesem Fall niemals ein Domänen-Administrator auf diesem Client anmeldet. Anstelle dessen würde in diesem Fall ein spezielles User-Helpdesk-Benutzerkonto zum Einsatz kommen, das ausschließlich auf den Client PCs des Unternehmens (oder sogar nur für gewisse Client PCs des Unternehmens) administrative Berechtigungen und Rechte besitzt, jedoch nicht für die gesamte Active Directory-Domäne.

Grundlagen der administrativen Sicherheitszonen

Die administrativen Sicherheitszonen haben den Zweck, die administrative Gewalt in einem Netzwerk auf kleine Teilbereiche aufzuteilen, um im Fehlerfall eine Abschottung zu anderen Systemen zu ermöglichen. Bei der Verwendung von administrativen Sicherheitszonen gilt es sicherzustellen, dass die administrativen Benutzerkonten, die in den jeweiligen Zonen zum Einsatz kommen, niemals Zugriff auf andere administrative Zonen erlangen können. Einzige Ausnahme stellt in diesem Fall die Sicherheitszone des Active Directory und der Management-Systeme (Softwareverteilung, Backup-Systeme, Administrations PCs) dar, da diese Systeme unternehmensweit Konfigurationen bereitstellen. Hierbei darf jedoch kein Umkehrschluss ermöglicht werden, so dass Systeme aus anderen Sicherheitsbereichen keine administrative Kontrolle über diese unternehmensweiten Dienste erlangen können.

Unterteilung  der administrativen Sicherheitszonen

Vor der Etablierung der administrativen Sicherheitszonen sollte für die jeweilige Firma ein geeignetes Konzept entwickelt werden, in wie weit und welche Systeme voneinander abgetrennt werden müssen und welche Benutzergruppen (Administratoren-Teams) einen administrativen Zugriff auf die jeweiligen Systeme benötigen. Um die maximale Abgrenzung zwischen den Systemen zu erlangen, könnte eine Firma theoretisch jedes einzelne System in eine eigene administrative Zone unterteilen. Dieses würde jedoch den Aufwand bei der täglichen Administration immens steigern. Deshalb sollten sinnvollerweise Systeme mit einem identischen Schutzbedürfnis zusammengefasst werden. ´

Abbildung 10: Unterteilung der administrativen Sicherheitszonen

Domänen-Controller-Sicherheitszone

Die Zone sollte in einem Active Directory-basierten Netzwerk die am besten geschützte Zone darstellen, da die Domain Controller die Macht besitzen, beliebige Änderungen an jedem Mitgliedssystem vorzunehmen und ein zentrales Accounting für das gesamte Unternehmen bereitstellen. Diese Zone sollte administrativ unbedingt von anderen Systemen abgeschottet werden, so dass Sicherheitsvorfälle in anderen Zonen niemals Auswirkungen auf die Domain Controller-Zone haben können. Des Weiteren sollte beachtet werden, dass alle Domänen-Controller des Active Directory Forest (incl. aller Subdomains) einen identischen Sicherheitsstandard benötigen (siehe hierzu auch „Problem: Privilege Escalation im Windows-Rollenkonzept“).

Management Sicherheitszone

Management-Systeme (Backup, Softwareverteilung, Patchmanagement) und administrative Systeme (Admin PC, Admin Terminal Server) stellen im Netzwerk eine Sonderrolle dar. Von diesen Systemen werden alle anderen Sicherheitszonen incl. der Domain Controller-Zone verwaltet. Daher müssen die Systeme dieser Zone die gleichen Sicherheitskriterien (e.g. physikalische Sicherheit und sicherheitsrelevante Konfiguration) erfüllen, wie das stärkste Glied im gesamten Netzwerk – der Domänen-Controller-Sicherheitszone. Anzumerken bleibt hierbei noch, dass die Administration der Domänen-Controller und der Management Systeme selbst nur von Systemen erfolgen darf, die Mitglieder der Management Sicherheitszone sind. Es sollte zwingend vermieden werden, dass diese Systeme der Management-Sicherheitszone in irgendeiner Weise von Systemen aus niedrigen Sicherheitszonen verwaltet werden können, da in diesem Fall ein sicherheitsrelevanter Vorfall in den niedrigen Sicherheitszonen einen Übergriff auf die höheren Sicherheitszonen ermöglichen kann.

Ressource Server Sicherheitszone

In der Ressource Server-Sicherheitszone befinden sich die traditionellen Mitgliedsserver (e.g. Infrastruktur Server, File und Print, Mail) des Unternehmens. Die Aufgabe dieser Sicherheitszone ist es, eine weitere Abgrenzung zwischen den niedrigen Sicherheitszonen (Clients) und den höheren Sicherheitszonen (Domänen-Controller und Management) zu etablieren, so dass auch hier im Falle eines Sicherheitsvorfalls ein Übergriff zwischen den Systemen nicht möglich wird.

Spezielle Server Sicherheitszone

Unter spezielle Server sind die Server-Systeme in einem Unternehmensnetzwerk gemeint, die unternehmenskritische Dienste ausführen sowie hochsensible Daten verarbeiten (Personalabteilung, Lohnbuchhaltung, etc.) Durch die Etablierung dieser Zone wird sichergestellt, dass die unternehmenskritischen Informationen, die auf diesen Serversystemen gehostet werden, einen zusätzlichen Schutz gegenüber herkömmlichen Servern erhalten, so dass ein Sicherheitsvorfall in der Ressource Server-Sicherheitszone keine Übergriffe auf diese kritischen Systeme möglich macht.

Anzumerken ist hierbei, dass die Client Computer der jeweiligen Anwendungsbetreuer ebenfalls ein Mitglied in dieser Sicherheitszone sein sollten, um wiederum einen Übergriff von anderen Zonen zu vermeiden.

Benutzer-Systeme-Sicherheitszone

In dieser Zone werden alle Systeme verwaltet, die dem Endbenutzer interaktiven, terminalbasierten oder gar physischen Clientzugriff ermöglichen. Systeme dieser Sicherheitszone sollten aus Sicht der Active Directory-Sicherheit „per se“ als nicht vertrauenswürdig eingestuft werden. Auf diesen Systemen sollte deshalb niemals ein Benutzerkonto zur Anwendung kommen, das in den höheren Sicherheitszonen administrative Berechtigungen besitzt. Dieses betrifft sowohl die interaktive Anmeldung mit hochprivilegierten Accounts an diesen Systemen als auch einen Terminal Server-Zugriff von diesen Systemen auf Systeme in höhere Sicherheitszonen.

Zuordnung der Sicherheitszonen auf administrative Benutzerrollen

Bei der Zuordnung, welche Administrationskonten oder welche Administratoren-Gruppen die jeweilige Sicherheitszone administrieren dürfen, gibt es eigentlich nur eine Sache, die zwingend eingehalten werden muss: ein- und dasselbe Benutzerkonto darf niemals zwei unterschiedliche Sicherheitsbereiche zur selben Zeit administrieren, da es ansonsten wieder zu einer Vermischung der Sicherheitszonen kommen könnte und bei einem sicherheitsrelevanten Vorfall ein Sprung von einem Sicherheitsbereich nicht mehr ausgeschlossen werden kann.

Sollte also eine Person gleichzeitig administrative Tätigkeiten in unterschiedlichen Sicherheitsbereichen durchführen müssen, sind unbedingt unterschiedliche Benutzerkonten zu verwenden. Dieses mag zwar im ersten Augenblick für die tägliche Administration ein wenig umständlich wirken, aber man gewöhnt sich sehr schnell daran. Letztendlich bietet die Verwendung von administrativen Sicherheitszonen einen gravierenden Sicherheitsvorteil, der den Umstand in jedem Fall rechtfertigt.

Technische Umsetzung der administrativen Sicherheitszonen

In der Windows-Plattform sind umfangreiche Werkzeuge vorhanden, mit denen ein administratives Sicherheitszonen-Modell umgesetzt werden kann. Die Hauptwerkzeuge sind das „Active Directory Users and Computers“- sowie das „Group Policy Management Console“-Snap-In, mit denen für die jeweiligen Sicherheitsbereiche die entsprechenden Administrationsgruppen berechtigt bzw. mit administrativen Rechten ausgestattet werden können.

Zunächst sollte für die unterschiedlichen Sicherheitszonen jeweils eine neue Administrationsgruppe erstellt werden, über die im späteren Verlauf die einzelnen Administratoren zusammengefasst und die notwendigen Rechten und Berechtigungen zugewiesen werden können. Es empfiehlt sich, ein eindeutiges Namensschema zu etablieren, das ebenfalls in den entsprechenden Administrationskonten (sollte ein Administrator zwei unterschiedliche Konten benötigen) seine Analogien finden sollte.

Administrative Delegation via GPOs

Über den Einsatz von GPOs können zum einen die Sicherheitszonen-Administrationsgruppen zu lokalen Administratoren auf den jeweiligen Systemen befördert und zum anderen der Einsatz dieser Gruppen in anderen Sicherheitsbereichen technisch untersagt werden. Die hierfür benötigten Anpassungen werden über zwei unterschiedliche GPO-Einstellungen vorgenommen.

Lokale Administratoren über Group Policy Preferences zuweisen

Die Group Policy Preferences ermöglichen es an zentraler Stelle, den neu erstellten administrativen Sicherheitsgruppen auf den jeweiligen Systemen ihre administrativen Berechtigungen und Rechte zu erteilen. Die Erteilung geschieht hierbei, in dem die neu erstellten Gruppen in die bereits vorhandenen Administratoren-Gruppen der jeweiligen Systeme verschachtelt werden.

Abbildung 11: Lokale Administratoren Gruppen mit "Group Policy Preferences" verwalten

Lokale Anmeldung über Sicherheitsoptionen einschränken

Die Sicherheitsoptionen „Deny log on locally“, „Deny log on as Batch job“, „Deny log on as a service“ und „Deny log on through Terminal Services“ schränken die Verwendung der administrativen Konten in jeweils unpassende Sicherheitszonen wirkungsvoll ein. Durch diese Einschränkungen kann man bewirken, dass die jeweiligen Administrationskonten sich nicht mehr auf Systemen in anderen Sicherheitsbereichen anmelden können.

Abbildung 12: Logon Einschränkungen über Windows Security Policies verwalten

Active Directory-Delegation via ACLs

Über den “Delegation of Control Wizard” des “Active Directroy Users and Computers”-MMC-Snap-Ins lassen sich die Berechtigungen innerhalb des Active Directory auf einfache Art und Weise verwalten. Mit diesem Wizard können für die jeweiligen administrativen Sicherheitsgruppen bei Bedarf gewisse Zweige in der Active Directory-Struktur delegiert werden.

Abbildung 13: Delegation von Teilbereichen des Active Directory

Nachwort

Ich hoffe ich mit dieser Blogreihe ein wenig Interesse zu der Active Directory super GAU Thematik geweckt zu haben. Für Feedback zu diesem Blog könnt ihr mich gerne via Email kontaktieren (kai.wilke_AT_itacs.de).

Über den Autor

Kai Wilke ist Senior Consultant mit dem Schwerpunkt IT-Security und zeitgleich Chief Security Officer bei der ITaCS GmbH -  einem Microsoft Security Gold Partner aus Berlin. Kai wurde in den letzten 10 Jahren 6-fach mit dem MVP Titel für die Bereiche ISA Server und Windows Security ausgezeichnet. Er hat auf unterschiedlichen Community Portalen Artikel publiziert und ist darüber hinaus Co-Autor des Buches „Windows Sicherheit – Das Praxis Buch“. Gelegentlich sieht man ihn auch auf den heimischen Fachkonferenzen den einen oder anderen Vortrag zu aktuellen Microsoft Sicherheitsthemen halten."