Wie so oft bei Active Directory werden einige der schlimmsten Sicherheitslücken durch Fehlkonfigurationen verursacht, die potenziellen Cyber-Bedrohungen Tür und Tor öffnen. Eine häufige Einstellung, die von Cyberkriminellen gerne ausgenutzt wird, ist die uneingeschränkte Delegation.
Was ist uneingeschränkte Delegation und warum ist uneingeschränkte Delegation ein Sicherheitsrisiko? Bei der Delegierung wird einem Computer gestattet, die Kerberos-Authentifizierungstickets eines Benutzers zu speichern und dann diese Tickets zu verwenden, um sich als der Benutzer auszugeben und im Namen des Benutzers zu handeln. Uneingeschränkte Delegation ist eine Konfigurationseinstellung, die viele mehrstufige Webanwendungen benötigen, um zu funktionieren. Diese Einstellung hat jedoch Auswirkungen auf die Sicherheit, da ein Computer, der die Kerberos-Ticket-Informationen für eine Reihe von Benutzern speichert, ein offensichtliches Ziel für Angreifer darstellt. Wenn die Angreifer diese Tickets erbeuten können, können sie mit der Identität und den Rechten dieser Benutzer agieren.
Wenn diese Einstellung so riskant ist, warum konfigurieren Administratoren dann Server mit uneingeschränkter Delegation anstelle der traditionellen eingeschränkten Delegation? Wahrscheinlich, weil dies in frühen Versionen der Active Directory-Umgebung die einzige Form der Delegation war, die unterstützt wurde, und weil sie auch am einfachsten zu konfigurieren ist und nur ein einziges Kontrollkästchen erfordert. Und wenn die Konfiguration der uneingeschränkten Delegation die Anwendung zum Laufen bringt, ist doch alles gut, oder? Aber es gibt in der Tat einen guten Grund, diese Einstellung zu überdenken. Durch das Entfernen der uneingeschränkten Delegation wird ein schwaches Glied in der Kette der vertrauenswürdigen Authentifizierung beseitigt, das bei Missbrauch erheblichen Schaden anrichten kann.
Verwandte Lektüre
Wurzeln der uneingeschränkten Delegation
Die Wurzeln dieses potenziellen Sicherheitsrisikos lassen sich 20 Jahre zurückverfolgen. Microsoft führte die uneingeschränkte Kerberos-Delegierung in Windows Server 2000 ein, um es Diensten zu ermöglichen, im Namen eines authentifizierten Benutzers auf andere Dienste zuzugreifen, ohne dass dieser sich erneut authentifizieren muss. Wenn sich ein Benutzer beispielsweise bei einem Webserver authentifiziert hat, kann dieser Webserver den Benutzer verkörpern und auf Backend-Datenbanken zugreifen, ohne dass der Benutzer seine Anmeldedaten erneut eingeben muss. Wenn die uneingeschränkte Delegation für ein Konto aktiviert ist, kann es den Benutzer für jeden Dienst in derselben Domäne ausgeben.
Diese Funktion erleichterte zwar das Leben der Benutzer (und Administratoren), stellte aber auch ein offensichtliches Risiko dar. Wenn ein Server, auf dem die uneingeschränkte Delegation aktiviert ist, unter der Kontrolle von Bedrohungsakteuren steht, könnten diese dieses Vertrauen missbrauchen, um sich in der gesamten Umgebung Zugang zu verschaffen. Microsoft versuchte, dieses Risiko durch die Einführung der eingeschränkten Delegation in Windows Server 2003 zu mindern, mit der Domänenadministratoren einschränken konnten, auf welche Dienste ein bestimmter Server zugreifen konnte.
Mit der Veröffentlichung von Windows Server 2012 gab Microsoft den Dienstadministratoren die Möglichkeit zu entscheiden, ob Front-End-Dienste auf Back-End-Ressourcen zugreifen können. Vor dieser Änderung konnte nur ein Domänenadministrator die Delegationsprivilegien kontrollieren, so dass Dienstadministratoren keine einfache Möglichkeit hatten, herauszufinden, welche Front-End-Dienste auf die ihnen gehörende Ressource zugreifen konnten und welche potenziellen Angriffswege sich dadurch boten. Dieser als ressourcenbasierte eingeschränkte Delegation (Resource Based Constrained Delegation, RBCD) bekannte Ansatz der Active Directory-Delegierung ist am schwersten zu missbrauchen.
Im Vergleich dazu ist die uneingeschränkte Delegierung am wenigsten sicher. Wenn Angreifer eine unsichere Kerberos-Delegierung missbrauchen können, sind sie in der Lage, alle Arten böswilliger Aktivitäten zu verschleiern, indem sie sich als legitimer Benutzer ausgeben. Ein Angreifer mit Zugriff auf einen Webserver mit dieser Konfiguration könnte das „Ticket Granting Ticket“ (TGT) des Benutzers stehlen, das im Speicher des Servers abgelegt ist, und es nutzen, um sich als dieser Benutzer auszugeben und dessen Zugriffsrechte auszunutzen oder den Zugriff durch eine Rechteausweitung zu erweitern. Diese Tatsache macht die uneingeschränkte Delegierung zu einem idealen Mechanismus für die laterale Bewegung innerhalb der gesamten Umgebung. Ein TGT, das einem Domänenadministrator gehört, könnte dem Angreifer beispielsweise Zugriff auf jeden beliebigen Dienst seiner Wahl verschaffen – oder ihm potenziell den Zugriff auf ein KRBTGT-Konto ermöglichen und den Start eines „Golden-Ticket“-Angriffs ermöglichen.
Ein Angreifer kann das Cmdlet „Get-ADComputer“ des Active Directory-PowerShell-Moduls nutzen, um Computer zu identifizieren, bei denen diese Einstellung aktiviert ist, und anschließend seine Attacke starten. Er kann beispielsweise Mimikatz einsetzen, um alle Service-Tickets aus dem Systemspeicher zu extrahieren. Die negativen Folgen davon liegen auf der Hand.
Verbessern Sie die AD-Sicherheit durch Deaktivieren der uneingeschränkten Delegation
Die gute Nachricht ist, dass Sie die durch uneingeschränkte Delegierung entstandene Sicherheitslücke schließen können, indem Sie diese Einstellung einfach deaktivieren. Damit die uneingeschränkte Delegierung wirksam wird, müssen Domänenadministratoren sie für Konten aktivieren, indem sie unter der Registerkarte „Delegierung“ in der ADUC-Verwaltungskonsole das Kontrollkästchen „Diesem Computer für die Delegierung an beliebige Dienste vertrauen (nur Kerberos)“ aktivieren.
Angesichts der hohen Risiken, die mit der Aktivierung dieser Einstellung verbunden sind, können Unternehmen ihre Sicherheitslage verbessern, indem sie alle Server identifizieren, auf denen die uneingeschränkte Delegierung aktiviert ist, diese Einstellung deaktivieren und sie bei Servern, die dies erfordern, durch die eingeschränkte Delegierung ersetzen. Administratorkonten sollten auf „Konto ist sensibel und kann nicht delegiert werden“ gesetzt werden, und Konten mit hohen Berechtigungen sollten der Sicherheitsgruppe „Geschützte Benutzer“ zugeordnet werden. Administratoren können mithilfe der PowerShell-Skripte nach Forests mit eingehenden Vertrauensbeziehungen suchen, die eine TGT-Delegierung zulassen, sowie nach Sicherheitsprinzipalen, die eine uneingeschränkte Delegierung ermöglichen. Sie können eine uneingeschränkte Delegierung auch durch die Überprüfung von Windows-Ereignissen erkennen. Wenn ein Kerberos-Ticket ausgestellt wird, protokolliert ein Active Directory- domain controller Sicherheitsereignisse, die Informationen über die Zieldomäne enthalten. Sie können diese Ereignisse untersuchen, um festzustellen, ob über eingehende Vertrauensbeziehungen hinweg eine uneingeschränkte Delegierung verwendet wird. Oder Sie können Purple Knight, ein kostenloses Tool zur Sicherheitsbewertung, das von AD-Experten bei Semperis entwickelt wurde und Ihre AD-Umgebung auf über 80 Sicherheitsindikatoren überprüft, darunter auch die uneingeschränkte Delegierung.
Die Deaktivierung der uneingeschränkten Delegation kann zu Kompatibilitätsproblemen bei einigen Anwendungen führen, die auf diese Funktion angewiesen sind. Das bedeutet, dass Sie diese Anwendungen neu konfigurieren müssen, um die eingeschränkte Delegation oder RBCD zu verwenden. Wie immer müssen Unternehmen bedenken, dass AD-Sicherheit mehr umfasst als nur das Patchen von Code-Schwachstellen. Die Verhinderung von Angriffen bedeutet auch, dass Sie Maßnahmen ergreifen müssen, um die Angriffsfläche zu verringern und Probleme proaktiv zu verhindern, bevor sie entstehen.
