Hinweis: Dieser Artikel wurde erstmals in der Juli-Ausgabe 2021 des monatlichen Newsletters Network Security veröffentlicht und erscheinterscheint hier mit der Genehmigung des Herausgebers.
Die Uhr 21 Jahre zurückzudrehen, bis zur Jahrtausendwende, wäre angesichts der Welt, in der wir heute leben, eine
seltsame Erfahrung. Selbst wenn man die Pandemie Covid-19
und ihre noch nicht absehbaren Folgen beiseite lässt, hat sich das Leben in den letzten zwei Jahrzehnten enorm
verändert.
Im Jahr 2000 gab es Spotify, Facebook, Instagram und Uber noch nicht, während Netflix (erinnern Sie sich an den DVD- und CD-Verleih auf Abonnementbasis?) und Amazon brandneu waren. Das Internet war noch ziemlich neu und das iPhone würde erst in sieben Jahren auf den Markt kommen. Die Liste ließe sich fortsetzen, aber der Punkt ist, dass sich die technologische Entwicklung in der Welt der IT in den letzten 20 Jahren exponentiell beschleunigt hat.
Trotz dieser Entwicklung hat sich eine grundlegende Innovation in dieser Zeit weitgehend unverändert durchgesetzt.
Verwandte Lektüre
Schmerzpunkt
In den 1990er Jahren waren Verzeichnisse ein großer administrativer IT-Problembereich für Unternehmen. Die Arbeitswelt wurde durch eine Reihe kleiner Verzeichnisse unterstützt, die die gemeinsame Nutzung wichtiger Daten und Dateien zu einer schwierigen und mühsamen Aufgabe machten. Um auf gemeinsam genutzte Dateien zuzugreifen, mussten sich die Benutzer bei jedem einzelnen Dateisystem anmelden, wofür verschiedene Anmeldedaten, Software und Anwendungen erforderlich waren.
Mit der Einführung von Windows NT Mitte der 1990er Jahre hat Microsoft bereits vielen Unternehmen geholfen, das "Domänen"-Konzept zu übernehmen, das es ermöglicht, mehrere Systeme in einem Vertrauenskreis zusammenzuschließen und so die Segmentierung der Benutzeridentitäten in separate Verzeichnisse effektiv zu reduzieren. Mit Windows NT konnte Microsoft zwar erfolgreich in die Rechenzentren von Unternehmen eindringen, aber die inhärenten Skalierungsbeschränkungen von Windows NT-Domänen bedeuteten, dass mehrere Domänenverzeichnisse in verschiedenen Regionen aufgebaut und verwaltet werden mussten, mit Vertrauensstellungen zwischen ihnen, um den Zugang für die verschiedenen Benutzer eines Unternehmens gemeinsam zu nutzen. Dies wurde zunehmend schwieriger, da nicht nur die Unternehmen, sondern auch ihre IT-Systeme auf den Zug der Globalisierung aufsprangen.
Mit Microsoft Active Directory (AD) kam eine damals revolutionäre Technologie auf den Markt, die ursprünglich mit dem Serverbetriebssystem Windows 2000 eingeführt wurde und die auch heute noch einen Großteil der hypervernetzten Arbeitswelt unterstützt.
Das war in vielerlei Hinsicht bahnbrechend. Globale Unternehmen konnten ihre Verzeichnisse skalieren und mussten sich nicht mehr auf viele kleine und schwer zu verwaltende Domains verlassen. In der Tat gab es andere Verzeichnisse, die darum kämpften, die gleichen Vorteile für Unternehmen zu bieten. Novell eDirectory zum Beispiel war weit verbreitet. Doch Microsoft AD setzte sich vor allem aus einem Grund durch - es war offen.
Offen oder sicher?
"Offen" bedeutet im Falle von Verzeichnisdiensten "für jedermann lesbar", was auch heute noch die Standardeinstellung in jeder AD-Konfiguration ist, zumindest für den authentifizierten Benutzer, d.h. jeden Benutzer, der mit seinem AD-Konto an einem Computer angemeldet ist. Novell hat sich bei eDirectory für den sichereren Weg entschieden und verlangt von den Administratoren, dass sie für jeden Bereich, der für Benutzer und Anwendungen erforderlich ist, spezielle Leserechte erteilen, was eine zusätzliche betriebliche Hürde für die Einführung und Integration neuer Anwendungen darstellt.
Diese Offenheit, die vor 21 Jahren die größte Stärke von Microsoft Active Directory war, hat sich inzwischen jedoch zu seiner größten Schwäche entwickelt.
Bei seiner Einführung wurde es hoch gelobt, weil es sich leicht in Anwendungen integrieren lässt und eine einmalige Anmeldung in der gesamten Unternehmensumgebung ermöglicht, wodurch sich der Aufwand für die Verwaltung von Passwörtern und Verzeichnissen durch eine weitreichende Authentifizierung verringert. Aufgrund dieser Offenheit und der einfachen Integration ist AD nach wie vor ein wesentlicher Bestandteil der Infrastruktur von 90% der Unternehmen. Es wird sogar in so großem Umfang eingesetzt, dass die meisten Geschäftsanwendungen heute nicht einmal über ein eigenes Verzeichnis verfügen, sondern sich darauf verlassen, dass der Benutzer über Windows authentifiziert wird.
Doch diese Offenheit hat auch Schwachstellen geschaffen.
Uneingeschränkte Delegation
Nehmen Sie zum Beispiel die speziellen Kerberos-Funktionen. Kerberos ist ein Authentifizierungsprotokoll für Computernetzwerke, das auf einer Ticketing-Struktur basiert und es Knoten, die über Unternehmensnetzwerke kommunizieren, ermöglicht, einander ihre Identität auf sichere Weise mitzuteilen. Für seine Zeit war es ein äußerst sicheres Protokoll, was die Bedeutung seines Namens unterstreicht: In der griechischen Mythologie ist Kerberos ein dreiköpfiger Hund, der die Tore der Unterwelt bewacht, um die Toten am Verlassen zu hindern.
Eine besondere Fähigkeit, die Kerberos bot, war die Delegation, mit der sichergestellt wurde, dass ein Benutzer, der auf eine Anwendung auf einem System zugreift, nur auf bestimmte gemeinsam genutzte Informationen (oft eine Datei oder bestimmte Daten in einer Datenbank) mit dieser Anwendung auf einem anderen System zugreifen kann, während der Zugriff auf andere Daten verhindert wird. Technisch gesehen wurde dies dadurch erreicht, dass der Benutzer von der Anwendung verkörpert wurde, während diese im Namen des Benutzers auf den anderen Dienst zugriff. Die Anwendung - oder vielmehr der Server, der die Anwendung hostet - wurde "delegiert", um die Kerberos-Authentifizierung eines anderen Benutzers zu verwenden, d.h. es wurde ihr das Recht eingeräumt, das Kerberos-Ticket des Benutzers an ein anderes System weiterzuleiten, als ob der Benutzer direkt auf dieses andere System zugreifen würde. Mit der Einführung von AD im Jahr 2000 war es möglich, die Kerberos-Delegation nur "uneingeschränkt" zu konfigurieren, d.h. die Anwendung konnte das Kerberos-Ticket des Benutzers an jedes andere System weiterleiten.
Heute ist dies durch viel sicherere und nahtlosere Möglichkeiten der gemeinsamen Nutzung von Daten überflüssig geworden. Dennoch sind uneingeschränkte Delegationseinstellungen auf einer beträchtlichen Anzahl von Systemen immer noch weit verbreitet, oft weil die Betreiber von AD oder die Eigentümer des spezifischen Serverobjekts, das auf diese Weise konfiguriert wurde, die möglichen Auswirkungen nicht verstehen. Heutige Hacker können dies nutzen, um sich als ein beliebiger AD-Benutzer auf einem beliebigen anderen Rechner auszugeben. Kombinieren Sie dies mit dem Wissen, dass ein Hacker über ein beliebiges unprivilegiertes AD-Konto fast alle Attribute und Objekte in AD lesen kann, einschließlich ihrer Berechtigungen, so dass er Computerkonten in jeder Domäne eines AD-Forests finden kann, die mit uneingeschränkter Delegation konfiguriert sind, und Sie bekommen eine Vorstellung davon, warum die standardmäßige Offenheit von AD zu einer Schwachstelle geworden ist.
Im schlimmsten Fall könnte sich der Eindringling Zugang zu einem solchen System verschaffen und darüber hinaus feststellen, dass auf Ihren Domänencontrollern noch der Druckerdienst (Spooler) läuft. Der Druckerdienst ist standardmäßig auf allen Windows-Servern aktiviert. Ersollte von IT-Administratoren auf allen Servern, die ihn nicht benötigen,deaktiviert werden, aber viele tun dies nicht. In unserem Szenario kann ein Hacker dann einen Domänencontroller aufrufen, um sich bei dem Computer mit der uneingeschränkten Delegation zu authentifizieren und den so genannten Drucker-Bug nutzen, um eine Authentifizierungsanfrage vom Domänencontroller an den gekaperten Computer zu stellen. Obwohl es nichts zu drucken gibt, kann sich ein Bedrohungsakteur durch diesen Prozess das Kerberos-Ticket eines Domänencontrollers sichern und so Ihre AD-Domäne und -Forst kompromittieren.
Die eingeschränkte Delegation ist etwas sicherer, aber sie ist immer noch angreifbar.
Gelegenheit für Bedrohungsakteure
Es gibt noch mehr Beispiele dafür, dass der dreiköpfige Hund im Laufe der Zeit etwas von seiner Schutzkraft verloren hat. Immer mehr Angriffsvektoren gegen AD wurden gefunden und öffentlich dokumentiert, so dass Cyberkriminelle sie auf ihrem Angriffspfad gegen AD nutzen können.
Ein weiteres gutes Beispiel sind die Service Principal Names (SPN), mit denen ein Kerberos-Client eine Instanz eines Dienstes für einen bestimmten Kerberos-Zielcomputer (z.B. eine SQL-Datenbank) eindeutig identifiziert und das zugehörige Dienstkonto (z.B. das SQL-Dienstkonto) ausfindig machen kann, das vom Dienst selbst zur Authentifizierung gegenüber AD verwendet wird.
Dieser Mechanismus ermöglicht es Benutzern, Kerberos für die Authentifizierung bei einer SQL-Datenbank zu nutzen, anstatt sich mit dem weniger sicheren NTLM-Protokoll zu authentifizieren, und ist in den meisten Unternehmen zum Standard für die Integration der AD-Authentifizierung für SQL-Implementierungen geworden. Der Nachteil ist, dass Sicherheitsforscher herausgefunden haben, dass SPNs selbst durch Informationen, die sie während der Kerberos-Authentifizierung an den Dienst weitergeben - nämlich den Hash des Kennworts des Dienstkontos selbst - leicht angreifbar sind, selbst wenn der Anfragende sich nicht bei dem Dienst authentifiziert.
Dieser Hash ist nun Gegenstand von Offline-Knackversuchen, bei denen eine Reihe von öffentlich verfügbaren Tools wie John the Ripper gerne behilflich sind.
Aufgrund der Offenheit von AD ist ein Eindringling leicht in der Lage, privilegierte SPNs in der Umgebung zu finden (denken Sie an einen SPN, der mit einem Domänenadministratorkonto verknüpft ist) und so einen weiteren einfachen Angriffsvektor zu schaffen, der so manipuliert werden kann, dass er hohe Privilegien und volle Sichtbarkeit bietet. Diese Kombination aus Kontrolle und Sichtbarkeit kann unglaublich gefährlich sein. Wenn Sie die höchsten Berechtigungen haben, haben Sie die volle Kontrolle und können ein Unternehmen lahmlegen und Lösegeld fordern.
Aber Sie können es auch schon vorher zur Aufklärung nutzen. "Was sind die privilegierten Konten? Was sind die Schwachstellen, die ich ausnutzen kann? Für Bedrohungsakteure ist Active Directory wie eine Karte, die Schwachstellen in der Umgebung aufzeigt. Sobald ein Hacker in Ihr Netzwerk eingedrungen ist, wird er AD nutzen, um Ihre wichtigen Daten aufzuspüren, sie zu extrahieren, zu verschlüsseln und Lösegeld von Ihnen zu verlangen. Und viele Unternehmen sind einfach nicht auf eine solche Eventualität vorbereitet. Das schafft einen Konflikt. Haben Sie geeignete Backups, um Ihr gesamtes Unternehmen - einschließlich Ihres Active Directory - schnell wiederherzustellen, ohne ein Lösegeld zu zahlen?
Für viele ist die Antwort nein - sie sind gezwungen, das Lösegeld zu zahlen, und die Hacker ziehen weiter zu einem anderen, ähnlich unvorbereiteten Ziel, wodurch ein Teufelskreis entsteht.
Das SolarWinds Beispiel
Wie oft wird AD auf diese Weise von Bedrohungsakteuren ausgenutzt? Der Einbruch bei SolarWinds, auch bekannt als Solorigate, ist eines der berüchtigtsten Beispiele aus jüngster Zeit, bei dem AD eine wichtige Rolle bei einem groß angelegten Angriff auf die Lieferkette spielte, von dem Zehntausende hochrangiger Organisationen betroffen waren, darunter auch US-Regierungsstellen. SolarWinds selbst ist ein weltweit führender Anbieter von IT-Lösungen, dessen Netzwerkmanagement-Tool Orion eine führende Software ist, die diese Organisationen zur Sicherung, Aufrechterhaltung und zum Schutz ihrer eigenen Netzwerke verwendeten. Bei dem Angriff auf SolarWinds gelang es den Hackern, einen Trojaner in die Orion-Software einzuschleusen, der dann über einen regelmäßigen Download-Mechanismus verbreitet wurde, den die Kunden des Unternehmens installiert hatten. Dieser staatlich gesponserte Angriff, der bereits im März 2020 begann, und der Trojaner wurden erst im Dezember desselben Jahres entdeckt.
Es war ein hochgradig bösartiger Angriff, der zahllose Fortune-500-Unternehmen und lebenswichtige Regierungsstellen in den USA betraf. Aber wie konnte es zu einem so starken Angriff auf die Lieferkette kommen? Hier kommen AD und Lecks vor Ort ins Spiel.
SolarWinds hatte einen Verbunddienst zwischen seinen eigenen Verzeichnisdiensten vor Ort und der Cloud eingerichtet, in der es seinen Orion-Softwarecode verwaltet. Bei einer solchen Einrichtung vertraut die Cloud voll und ganz darauf, dass der Verbunddienst die Identität eines Benutzers korrekt nachweisen kann, so dass Sie sich mit Ihrer lokalen Identität anmelden können, oft in Verbindung mit einer Multifaktor-Authentifizierungslösung (MFA) eines Drittanbieters.
Wenn Sie sich auf diese Weise anmelden und ein ordnungsgemäß signiertes Föderations-Token erhalten, vertraut Ihr Cloud-Anbieter Ihnen bei der Authentifizierung und autorisiert dann authentifizierte Benutzer, indem er ihnen Zugriff auf die angeforderten Cloud-Ressourcen gewährt.
Im Fall des SolarWinds-Angriffs konnten die Eindringlinge diese Föderation zu ihrem Vorteil nutzen, um sich heimlich Zugang zum Orion-Quellcode zu verschaffen, der in der Cloud gehostet wird, indem sie das Token-Signaturzertifikat stahlen. Es war der erste bekannte Angriff dieser Art, bei dem ein SAML-Angriff (Golden Secure Access Markup Language) verwendet wurde. Die Föderation erfolgt über Protokolle wie SAML, mit denen ein Sicherheits-Token an die vertrauende Partei weitergegeben wird. Aber wie ist der Angreifer an dieses Token-Signaturzertifikat gekommen?
Kommen wir zurück zu dem Punkt, an dem die Sicherheitsverletzung stattfand: Das Token-Signaturzertifikat war durch das Dienstkonto für AD-Föderationsdienste gesichert, das wie jedes andere Konto im lokalen AD gehostet wird. Sobald sich die Bedrohungsakteure Zugriff auf das lokale AD und das ADFS-Servicekonto verschafft hatten, konnten sie das Zertifikat lesen und damit ihr eigenes SAML-Token erstellen, um Zugriff auf die Cloud-Ressourcen von SolarWinds zu erhalten. Die Kette von Ereignissen zeigt, dass die Active Directory-Sicherheit eine der Hauptschwachstellen auf dem Angriffspfad dieses großen Einbruchs war.
Dies ist ein Paradebeispiel dafür, dass ein Unternehmen glaubte, seine Cloud-Systeme seien sicher, obwohl sie es aufgrund von AD und seiner Abhängigkeit von den lokalen Systemen nicht waren. Die Cloud war zwar getrennt, aber das Vertrauen zwischen den anfälligen lokalen Systemen und der Cloud ermöglichte den Zugriff auf das Netzwerk und schuf eine Brücke, die die Bedrohungsakteure nutzen konnten, um in die Cloud-Ressourcen des Unternehmens einzudringen.
Bewältigung der Herausforderungen
Aus der Perspektive der Sicherheit ist AD die Quelle vieler Kopfschmerzen. Microsoft hat es versäumt, seit 2016 in ein sicherheitsrelevantes Update für AD zu investieren, obwohl dieses zentrale Identitätssystem heute noch von 90 % der Unternehmen genutzt wird.
Die einfachste Lösung wäre, AD abzuschaffen, aber das wird einfach nicht passieren. Es handelt sich um eine veraltete Lösung, die aber nicht so bald verschwinden wird, da so viele Unternehmen und Hunderttausende von Geschäftsanwendungen noch immer auf diese Technologie angewiesen sind. Dennoch ist es kein hoffnungsloser Fall und es gibt Schritte, die Unternehmen unternehmen können, um sich zu schützen.
In der Tat ist dies ein Prozess - die Implementierung geeigneter Schutzprotokolle, beginnend mit dem Erkennen und Verstehen potenzieller Schwachstellen. Führen Sie ein Brainstorming durch und fragen Sie sich: "Was würde passieren, wenn kritische Systeme ausfallen würden?"
Unternehmen können sich gegen Ausfälle wappnen, indem sie mit zwei Rechenzentren oder einer hybriden Lösung aus Rechenzentrum und Cloud arbeiten. Sie müssen jedoch noch weiter gehen und überlegen, was passieren könnte, wenn ein kritisches System wie das Identitätsmanagement gefährdet ist. Nehmen Sie sich die Zeit, die Abhängigkeiten zu allen Ihren Geschäftsanwendungen zu verstehen. Und untersuchen Sie die Abhängigkeiten zwischen Ihrem Authentifizierungsprozess und der Cloud. Mit einem föderationsbasierten Authentifizierungssystem könnten Sie sehr schnell in heißes Wasser geraten.
Sobald Sie diese Abhängigkeiten verstanden haben, können Sie damit beginnen, die zu behebenden Schwachstellen zu identifizieren, zu verstehen und nach Prioritäten zu ordnen. Es muss ein ganzheitlicher Prozess sein, bei dem nichts unversucht gelassen wird, um die volle Einsatzbereitschaft zu erreichen. Wenn ein Boot ein Leck hat und Sie nicht über die nötige Ausrüstung verfügen, um das Leck zu reparieren, dann wird das Boot sinken. Und auch wenn Sie nur eines von mehreren undichten Löchern entdecken, wird das Boot sinken.
Es ist von entscheidender Bedeutung, dass ein Unternehmen alle potenziellen Schwachstellen umfassend versteht, um sie zu beseitigen und sich entsprechend vorzubereiten. Der Angriff von SolarWinds dient als wichtige Lernkurve, die zeigt, welche katastrophalen Auswirkungen ein AD-basierter Angriff haben kann. Angesichts der wachsenden und zunehmend komplexen Bedrohungslage war es noch nie so wichtig wie heute, sich mit AD-basierten Schwachstellen zu befassen.
