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

Vorbemerkung

In den vielzähligen Security Audits und Penetrationstest, die wir in den letzten Jahren bei unseren Kunden durchgeführt haben, sind wir erschreckend oft auf schwerwiegende Sicherheitslücken im Bereich des Microsoft Active Directory gestoßen. Die Sicherheitslücken, die wir hierbei klassifizieren konnten, haben in den meisten Fällen dafür gesorgt, dass wir uns binnen weniger Stunden (meist am ersten Tag) einen administrativen Vollzugriff auf das gesamte Active Directory erschlichen haben und somit auch meistens einen uneingeschränkten Zugriff auf sämtliche  informationstechnologischen Werte des Unternehms. Ein GAU halt…

Das Erstaunliche an den von uns beobachteten Sicherheitsschwachstellen ist, dass es sich hierbei nicht um Softwarefehler im klassischen Sinne (e.g. Bug) oder um mangelnde Funktionalitäten seitens der Windows Plattform handelt (Unsecure by Design), sondern ausschließlich um elementare Sicherheitsgrundsätze, die beim Design einer Active Directory-Infrastruktur und insbesondere in der Verwaltung des Active Directorys verletzt wurden.

In der folgenden Blogreihe „Active Directory Security – den GAU verstehen und verhindern“ möchte ich genauer auf diese Probleme eingehen, die Ursachen erläutern und hierbei Ansätze aufzeigen, wie man die Probleme an der Wurzel beseitigen bzw. entschärfen kann.

Die Blogreihe setzt sich aus den folgenden zwei Teilen zusammen.

Blog Part 1:

1. Die Macht in einem Windows basierten Netzwerk und der 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 GAU schützen?

2. Grundlagen der administrativen Sicherheitszonen

3. Technische Umsetzung der administrativen Sicherheitszonen

Der erste Teil ist bereits publiziert und der zweite Teil wird im Abstand von einer Woche auf unserem Blog ebenfalls zu finden sein.

Wer hat die Macht in einem Windows basierten Netzwerk?

Mir ist aufgefallen, dass die meisten Administratoren, mit denen ich über die Jahre zu tun hatte das Selbstverständnis besitzen, dass ihr Administrator-Benutzerkonto der ultimative Herrscher im Unternehmensnetzwerk ist und da nur sie das Passwort zu diesem Konto besitzen, sie automatisch zu den alleinigen Herrschern auserkoren wurden. Nun ja, auf den ersten Blick scheint dieses vollkommen richtig zu sein, da man so gut wie alles mit diesem Konto bewerkstelligen kann. Wenn man aber genau hinsieht, dann ist das Administrationskonto nicht als „Herrscher“ sondern eher als ein „Berater“ anzusehen, der den Windows-Systemen lediglich Empfehlungen gibt, wie sie sich zu verhalten haben.

Die wahre Macht wird indes von den SYSTEM-Kontexten der jeweiligen Windows-Systeme ausgeübt oder halt in einem Unternehmensnetzwerk zentral von den Active Directory Domänencontrollern vorgegeben. Die jeweiligen Windows-Systeme und die Domänen Controller entscheiden anhand von Gruppenmitgliedschaften, welcher Benutzer sich wo anmelden darf und auf welche Ressourcen alles zugegriffen werden darf. Ist der Domänen Controller der Meinung, dass es „Jemand“ nicht gibt, dann gibt es diesen „Jemand“ halt  nicht. Bestätigt der Domänencontroller einem Benutzer, dass sein Passwort „Richtig“ ist und er Mitglied in den folgenden Gruppen ist, dann glaubt ihm das die gesamte Active Directory basierte Netzwerkinfrastruktur. Ich könnte an dieser Stelle noch weiter auf die Macht des Domänencontrollers in einem Unternehmensnetzwerk eingehen, aber ich denke, dass es bereits ausreichen sollte, um aufzuzeigen, wie mächtig die Domänen Controller in einem Unternehmensnetzwerk sind.

Fernab von der oben angerissenen „Henne–Ei“-Frage zwischen Administratoren und den SYSTEM Kontexten, gibt es dann noch Angreifer, die ebenfalls ein Stück vom „Macht-Kuchen“ abhaben wollen. Und diesen wollen wir uns im Folgenden widmen.

Der GAU in einem Windows basierten Netzwerk?

Möchte ein Angreifer Zugriff auf bestimmte Daten oder Dienste (e.g. SQL, File Service, etc.) erlangen, hat er grundsätzlich mehrere Ansätze, dieses zu erreichen. Zum einen kann er versuchen, Schwachstellen (e.g. Bufferoverflows, SQL-Injection, uvm.) direkt in den Diensten  zu suchen, oder er geht letztendlich den Weg über die Active Director- Domäne und versucht dort sein Glück.

Abbildung 1: Angriffsvektoren in Windows basierten Netzwerken

Der Umweg über das Active Directory ist aufgrund von immer sichereren Anwendungsdiensten (e.g. SourceCode Reviews, Secure by Desing und zeitnahes Patching) sogar eine deutlich erfolgsversprechende Methode, da sie weit weniger Timing Probleme hat (gibt es derzeit überhaupt Sicherheitsschwachstellen in diesem Dienst und sind die bereits gefixt?) und bietet zusätzlich noch den Vorteil, dass nicht nur ein Dienst „gehackt“ wird sondern gleich die gesamte Active Directory-basierte Netzwerkinfrastruktur, da innerhalb dieser Struktur alle Systeme den Domänencontrollern quasi blind vertrauen.

In der IT-Security Community ist dieser Umstand unter der Abkürzung „BORE“ bekannt – welches „Break Once Run Everywhere“ ausgesprochen wird und sich lapidar nach „Breche lediglich den Schlüsselkasten auf, um Zugriff auf alle Geldkassetten zu erhalten“ übersetzen lässt.

Wie „hackt“ man überhaupt eine Active Directory Infrastruktur? – Teil 1: Identity Theft

Einige werden sich sicherlich verwundert fragen, warum der Umweg über das Active Directory erfolgsversprechender ist, als das Angreifen einzelnen Dienste, da doch auch die Active Directory Domänencontroller ähnlich wie die eigentlichen Ressource Server über die Jahre immer sicherer wurden und auch ähnliche Timing-Probleme in Bezug auf publizierte Exploits haben sollten? Zusätzlich werden in etwas größeren Active Directory-Infrastrukturen die Domaincontroller auf dedizierten Servern oder sogar auf Core-Servern ausgeführt, um zusätzlich die Angriffsfläche so gering wie möglich zu halten. 

Nun ja, hierfür gibt es eine einfache Erklärung. Anstelle die Bits und Bytes der Active Directory Domaincontroller anzugreifen, ist es in den meisten Fällen um ein vielfaches einfacher die „Berater“ des Active Directory – also die Administratoren – zu „hacken“, in dem man ihre Fehlkonfigurationen aufspürt und anschließend ausnutzt oder ihnen halt aufgrund ihres sozialen Verhaltens gezielt eine Falle stellt. Für diese Arten der Angriffe existiert ebenfalls eine Vielzahl an Fachbegriffen in der IT-Security Community. Die gebräuchlichsten unter ihnen ist sind „Identity Theft“ (Entwenden des Benutzer Konto/Passwortes), „Privilege Escalation“ (Erhöhung der eigenen Rechte und Berechtigungen), und Social Engineering (das Sozialverhalten eines Menschen ausnutzen).

Im Folgenden möchte ich ein paar einfache Beispiele zu den oben aufgeführten Angriffstechnologien darstellen. Anzumerken bleibt, dass ich diese Beispiele nicht an den Haaren herbei gezogen habe, sondern diese auf realen Sicherheitsschwachstellen beruhen, die wir im Rahmen von Security Audits und Penetrationstest bei mehr als einer Firma identifizieren konnten oder ausgenutzt haben.

Identity Theft Methode

Die Identity Theft Methode umschreibt das Entwenden von Benutzeridentitäten und hat viele unterschiedliche Herangehensweisen. Die klassische Form von Identity Theft ist wohl der gelbe Passwort Zettel, den ein Anwender direkt auf seinen Monitor geklebt hat. Ich bezweifle jedoch, dass ich in meiner weiteren Laufbahn als Penetrationstester jemals ein Administratoren-Passwort über diesen Weg erhalten werde, da dieses Fehlverhalten jedem Administrator einleuchtend ist und er niemals sein Passwort direkt auf den Monitor pinnen würde – und das ist auch gut so.

Problem: Keylogger

Aber es gibt auch Methoden, wie man ohne ein vorheriges Fehlverhalten der Benutzer an ihre Passwörter kommen kann, und das sogar, ohne dass die ausgespähten Benutzer davon etwas mitbekommen. Die bekannteste und auch die am einfachsten für einen Laien durchführbare Methode ist die Verwendung eines USB Keyloggers, der zwischen Tastatur und Computer geschaltet wird. Ein Merkmal dieser USB Keylogger gegenüber softwarebasierten Ansätzen ist, dass Passworteingaben vollkommen transparent für das Betriebssystem abgefangen werden können und somit die Wahrscheinlichkeit, dass der Angreifer beim Mitschneiden erwischt wird, als sehr gering anzusehen ist. Einziges Problem bei der Anwendung dieser Geräte ist wohl die unbemerkte „Installation“ des Keyloggers. Aber hierzu werde ich später noch ein wenig unter dem Punkt Social Engineering eingehen.

Abbildung 2: Bedienungsanleitung eines Keyloggers

Eine weitere offensichtliche Methode, um an Passwörter zu kommen, ist die Protokollierung der Passworteingaben, die im „Klartext“ übers Netzwerk übertragen werden, mittels Netzwerkmonitor. Klartext Passwörter kommen jedoch bei modernen Netzwerkanwendungen nur noch selten zum Einsatz, so dass diese Methode eher von den verwendeten Netzwerkanwendungen des Unternehmens und vom Glück abhängt.

Problem: Passwörter in Scripten

Einen hohen Erfolg haben wir bei unseren Security Audits noch bei der Verwendung von Suchanfragen mittels Windows-Explorer mit den Freitext-Suchbegriffen „Password“ oder „Passwort“ auf Software Installationsshares (dort liegen meist viele Scripte herum, die unter Umständen Passwörter enthalten), Shares von Netzwerkanwendungen (enthalten oftmals Dateien mit priviligierten SQL-Passwörtern) und insbesondere auf OS-Deployment Servern (enthalten lokale Admin-Passwörter der Clients und Passwörter für den Domain-Join). Gerade bei den zuletzt genannten Deployment Servern konnten wir den eindeutigen Trend erkennen, dass viele Unternehmen innerhalb der „unattended Scripte“ unglücklicherweise Benutzerkonten für den Domain-Join verwendet haben, die Domänen-Administratoren-Rechte und -Berechtigungen hatten, oder dass oftmals die lokalen Administratoren-Kennwörter der Client Computer im Klartext vorhanden und identisch mit denen des Domänen-Administrators waren. Anzumerken ist hierbei noch, dass die meisten von uns vorgefundenen Shares allen Domänen-Benutzern einen Lesezugriff gewährten und somit diese Passwörter ohne weiteres von niedrigprivilegierten Benutzer ausgelesen werden konnten.

Abbildung 3: Passwörter in Scripten

Problem: Windows Service Manager

Als weitere Fundgrube für hochprivilegierte Benutzerkonten haben wir in den letzten Jahren den Windows Dienste-Manager identifizieren können. Wir konnten hierbei beobachten, dass das eine oder andere Mal auf Servern und Clients auch Benutzeridentitäten für die Ausführung von Diensten verwendet wurden, die Mitglied der Domänen-Administratoren-Gruppe waren.  Nun ja, was gibt es hierüber zu berichten und was ist so spannend am Dienste-Manager?

Zunächst einmal ist es an dieser Stelle wichtig anzumerken, dass Kennwörter für den Start der Services unter Verwendung von Domänenkonten für das Betriebssystem immer mit einer reversiblen Verschlüsselung gespeichert werden müssen. Reversibel deshalb, weil schließlich das lokale Betriebssystem das Passwort zum entsprechenden Domänen-Servicekonto wissen muss, um eine Anmeldung am Active Directory durchzuführen. Der spannende Punkt dabei ist: wenn das Betriebssystem selbst Zugriff auf diese Passwortinformationen hat, wer kann dann noch alles auf diese Informationen zugreifen?

Da die Passwortinformationen über die LSA Secrets abgesichert werden, kann das Betriebssystem selbst und auch alle lokalen Administratoren, über LSA Debugger alla LSADump.exe oder Tools wie Cain&Abel, diese Informationen abfragen. In diesem Fall könnte ein lokaler Administrator – oder eine Person, die sich auf einem Client PC oder einem Terminal Server etwaige Administrations-Rechte ergattert hat – ebenfalls Zugriff auf die gespeicherten Domänen-Anmeldedaten erhalten.

Abbildung 4: LSA Dump mit Cain&Abel

Wie „hackt“ man überhaupt eine Active Directory Infrastruktur? – Teil 2: Privilege Escalation

Unter Privilege Escalation beschreibt man den Umstand, dass ein niedrig-privilegierter Benutzer oder Dienst – unberechtigter Weise – etwaige Programme oder Scripte unter höher-privilegierten Kontexten ausführt und somit in die Lage versetzt wird, Aktionen durchzuführen, auf die er normalerweise aufgrund seiner eigenen Rechte und Berechtigungen keinen Zugriff hat. Im Grunde genommen sind die Folgen einer Privilege Escalation mit dem der Identity Theft-Methode gleichzusetzen, nur dass halt nicht erst die hoch-privilegierte Benutzerkennung geklaut wird, sich unter dieser angemeldet und dann der Code ausgeführt wird, sondern dass der Code über trickreiches Vorgehen direkt von dem hoch-privilegierten Benutzer oder Dienst zur Ausführung gebracht wird (z.B. Code Injection). Witziger Weise wird bei dieser Methode meist versucht, eine Backdoor zu öffnen (z.B. neues Administratorkonto erstellen oder Telnet Server starten), über die man im folgenden einen Vollzugriff auf das System bekommt, ohne sich jedes Mal verrenken zu müssen.

In der Praxis finden wir immer wieder neue Wege, um eine Privilege Escalation durchzuführen – die meist etwas komplexer im Aufbau sind und für Außenstehende erst einmal nicht wirklich als eine Gefahr wahrgenommen werden.

Problem: Privilege Escalation über schwache NTFS-Berechtigungen

Um die Banalität und die zeitgleiche Komplexität dieser Methode darzustellen, möchte ich an dieser Stelle einen Klassiker erläutern, den wir in unseren Audits sogar mehr als regelmäßig vorfinden. Und zwar die Gefahren von schwachen NTFS Default-Berechtigungen im Zusammenhang mit anderen Faktoren.

Abbildung 5: Windows 2000 NTFS Defaultberechtigungen

Unter Windows 2000 waren die NTFS Default-Berechtigungen für Root-Verzeichnisse immer mit „Jeder = Vollzugriff“ abgesichert, was dazu führte, dass „Jeder“ neue Ordner und Dateien auf der lokalen Festplatte erstellen durfte und auch alle nachträglich erstellten Inhalte beliebig verändern durfte – es sei denn, der Ersteller oder der Administrator hatte entgegen gewirkt und die Berechtigungen entsprechend angepasst, um genau das zu verhindern. Hat jedoch der Ersteller oder der Administrator dieses nicht beachtet, und es wurden in den neu erstellten Ordnern (Klassiker:  C:\Program Files\* anstelle von C:\Programme\*verwendet)  etwaige Programme hinterlegt oder Scripte von hochprivilegierten Benutzerkonten ausgeführt, war das Unheil quasi vorprogrammiert. In diesem Fall war „Jeder“ in der Lage, direkte Änderungen am Program Code vorzunehmen (*.EXE Datei austauschen oder Scripte manipulieren) und  diese Änderungen dann von anderen Benutzern oder den Administratoren, die sich ebenfalls am System anmelden, zur Ausführung zu bringen.

Problem: Privilege Escalation über schwache NTFS-Berechtigungen + SYSTEMVARIABLEN

Unter Windows XP und auch Windows Server 2003 wurden hingegen die NTFS Default-Berechtigungen so abgeändert, so dass „Benutzer“ nur noch neue Ordner erstellen und in Unterordnern nur weitere Unterordner und Dateien hinzufügen dürfen. Bestehende Dateien anpassen oder gar löschen durften in diesem Fall nur noch die „Ersteller-Besitzer“ selbst. Auf den ersten Blick hören sich die neuen NTFS Default-Berechtigungen hervorragend an, Benutzer dürfen beliebige Ordner und Dateien erstellen (Abwärtskompatibilität zu Win9X Programmen) und nur noch die Dateien editieren, die sie selbst erstellt haben.

Abbildung 6: Windows XP/2003 NTFS Defaultberechtigungen

Auf den zweiten Blick kann dieses Konstrukt jedoch unter Umständen ebenfalls sehr gefährlich werden und dem Angreifer eine Tür zur Privilege Escalation öffnen, wie das folgende, zunächst unscheinbare Beispiel aufzeigt.

Abbildung 7: Falsch abgespeicherte Scripte

Im oben dargestellten Beispiel wurde auf einem Terminal Server, auf den Benutzer sowie Administratoren Zugriff haben, unachtsamer Weise das Tool BGInfo im Ordner „Programme“ anstelle des vordefinierten und entsprechend abgesicherten Ordners „Program Files“ gespeichert und via „Autostart“ so eingerichtet, dass jede Person, die sich am System anmeldet, das Script „BG-Start.CMD“ automatisch ausführt. Wie ich zuvor erwähnt hatte, ist es aufgrund der neuen NTFS-Berechtigungen unter Windows XP/2003 nicht mehr möglich, dass normale Benutzer dieses Script editieren dürfen, da nur der „Ersteller“ diese Berechtigungen besitzt. Nun ja, aber ist eine Änderung des *.CMD Scriptes oder der *.EXE-Datei in diesem konkreten Beispiel überhaupt notwendig, um „eigenen Programcode“ über dieses Script zur Ausführung zu bringen? Nein, eigentlich nicht, da man auch über Umwege einen beliebigen Programmcode in dieses Script injizieren kann.

Der Grund, warum in diesem Beispiel keine Änderungen am Script und an der eigentlichen BGInfo.exe Programdatei notwendig ist, findet sich in der Windows-Systemvariablen mit dem Namen „PATHEXT“. Diese Systemvariable ist dafür verantwortlich, in welcher Reihenfolge Dateierweiterungen angehängt werden, wenn in einem CMD-Aufruf keine explizite Dateierweiterung angegeben wurde. Schaut man sich nun das obige Script und die unten dargestellte Auflistung der PATHEXT-Variablen an, so wird man zum einen feststellen, dass im BGInfo Script keine Dateierweiterung angegeben wurde und dass *.EXE-Dateierweiterungen in der PATHEXT-Systemvariablen an zweiter Stelle hinter *.COM- Dateierweiterungen stehen.

Abbildung 8: Windows PATH und PATHEXT Variable

Ein Angreifer könnte diese kleine Unachtsamkeit bemerken und hierdurch den scriptgesteuerten Programmaufruf „bginfo“ mit einer selbst erstellten „bginfo.com“-Datei abfangen. Hierzu müsste er lediglich seinen Schadcode in eine Anwendungsdatei kompilieren und diese unter dem Namen „bginfo.com“ im selben Ordner, in dem auch das Script gespeichert wurde, ablegen. Da in diesem Ordner, wie weiter oben beschrieben, alle „Benutzer“ neue Programdateien erstellen dürfen, sollte das keine Berechtigungsprobleme verursachen. Wenn der Angreifer hierbei geschickt vorgeht, würden die restlichen Benutzer, die sich an diesem System anmelden, noch nicht einmal etwas mitbekommen. Alles, was die selbst erstellte BGINFO.COM-Datei hierfür machen müsste, wäre, im Hintergrund den Schadcode aufzuführen (e.g. enumerieren, ob der ausführende Benutzer ein Administrator ist und wenn ja, einen neuen Administrator als Backdoor erstellen) und anschließend die originale BGINFO.EXE starten und hierbei die ursprünglichen Commandline-Parameter übergeben. 

Problem: Privilege Escalation im Windows-Rollenkonzept

Eine weitere Form der Privilege Escalation ist direkt in dem vordefinierten Rollenkonzept von Windows zu finden. Diesen Umstand möchte ich an dieser Stelle noch in Kürze erläutern, da er ebenfalls in unseren Audits oftmals negativ aufgefallen ist. Und zwar geht es um die Abgrenzung zwischen einem vollwertigen Windows-Administrator und den Windows Service-Administratoren. Unter einem Windows Service-Administrator sind im Allgemeinen die vordefinierten Benutzerrollen gemeint, die in einem Windows-System gewisse Teilbereiche administrieren können (e.g. Print Operator, Backup Operator, Power User, Server Operator).

Das vorgefertigte Rollenkonzept von Windows kann aufgrund von Privilege Escalation eigentlich auf die Rollen „Administrator“ und „Benutzer“ heruntergebrochen werden, da die vordefinierten Service Administrator-Rollen im Grunde genommen bereits vollwertige Administratoren sind. Das Problem dieser Rollen ist, dass die jeweils zugewiesenden Aufgaben bereits so hohe Rechte und Berechtigungen in einem Windows-System besitzen, dass sie quasi nur ein paar Mausklicks davon entfernt sind, sich selbstständig zu einem vollwertigen Administrator zu befördern.

Im Folgenden möchte ich die Rollen aufführen, die von diesem Problem betroffen sind, da diese Rollen ebenfalls oftmals ein Angriffsvektor darstellen, um einen super GAU in einer Active Directory basierten Netzwerkinfrastruktur auszulösen.

Domain Print Operators

Die Active Directory-Benutzerolle „Print Operatoren“ besitzt zum Beispiel das Windows-System-Recht, beliebige Gerätetreiber innerhalb der Domäne zu installieren. Diese Systemtreiber werden nach der Installation im SYSTEM-Kontext ausgeführt und können somit ohne weitere Einschränkungen auf alle lokalen Ressourcen zugreifen. Über eine Treiberinstallation können beliebige Backdoors auf einem Windows System platziert werden, die anschließend im SYSTEM-Kontext den Schadcode unter sehr hohen Berechtigungen und Rechten ausführen. Die Berechtigungen und Rechte, die hierbei zum Einsatz kommen, überschreiten sogar die eines normalen Administrators.

Domain Backup Operators

Ein Backup Operator ist in der Lage, sämtliche NTFS-Berechtigungen über die Systemrechte „Backup file and directories“ und „Restore files and directories“ zu ignorieren. Über diesem Weg ist es ebenfalls möglich, essentielle Betriebssystemdateien auf beliebigen Systemen auszutauschen und somit auch beliebigen Programcode von hoch privilegierten Diensten oder anderen Administratoren zur  Ausführung zu bringen.

Domain Server Operators/Power Users

Server Operatoren und ihr clientseitiges Pendant, die Power User, besitzen ebenfalls in einem Windows-System weitreichende Rechte und Berechtigungen, die es dieser Gruppe erlauben, eigenen Programcode im SYSTEM- Kontext zur Ausführung zu bringen. Mitglieder dieser Gruppen dürfen ebenfalls  jegliche Systemdateien des Betriebssystems über die „Backup file and directories“ und „Restore files and directories“-Rechte manipulieren. Darüber hinaus können die Mitglieder dieser Gruppen beliebige System-Dienste des lokalen Betriebssystems starten, stoppen sowie Anpassungen an den Diensten vornehmen.

Domain-, Enterprise- und Schema-Administrator

Diese Rollen sind in einem Active Directory Forest im Grunde ebenfalls identische Rollen. Innerhalb einer Active Directory-Infrastruktur, die aus einer einzelnen Domäne besteht, können die Domänen-Administratoren sich jederzeit selbst zum Mitglied der Enterprise- und Schem- Administratoren-Gruppe hinzufügen. Ein Enterpris- Administrator kann dieses ebenfalls auf dem umgekehrten Weg machen.

Aus einer Subdomain heraus ist es jedoch ein wenig komplexer, aus einem Domain-Administrator (der Subdomain) einen Enterprise-Administrator (des gesamten Forests) zu machen. Ohne hierbei groß auf die Details dieser Angriffe einzugehen, möchte ich an dieser Stelle darauf hinweisen, dass innerhalb eines Active Directory Forest gewisse Informationen (Global Catalog, Configuration Partition und das Schema) von allen Domain Controllern gleichberechtig verwaltet werden und eine Vielzahl von Funktionen auf blindes Vertrauen (keine erneute Validierung) zwischen den einzelnen Domänen Controllern eines Unternehmens abgewickelt werden. Eine Manipulation dieser Informationen innerhalb einer Sub-Domäne würde hierbei ebenfalls Änderungen im gesamten Active Directory Forest bewirken. Werden nun an gewisser Stelle Informationen hinzugefügt oder verändert (z.B. Startup Scripte in Site-GPOs, SIDs in Windows Token oder zusätzliche sicherheitsrelevante Schema-Attribute abändern,) lassen sich auch Angriffe von Subdomains auf die Rootdomains durchführen.

Wie „hackt“ man überhaupt eine Active Directory Infrastruktur? – Teil 3: Social Engeneering

Kommen wir zur nächsten Methode, mit der man sich unberechtigten Zugriff verschaffen kann: das „Social Engineering“. Da ich die genaue Definition selbst nicht besser formulieren könnte, möchte ich an dieser Stelle die Wikipedia-Definition des Begriffs „Social Engineering“ quoten.

„Social Engineering (engl. eigentlich „angewandte Sozialwissenschaft“, auch „soziale Manipulation“) nennt man zwischenmenschliche Beeinflussungen mit dem Ziel, unberechtigt an Daten oder Dinge zu gelangen. Social Engineers spionieren das persönliche Umfeld ihres Opfers aus, täuschen falsche Identitäten vor oder nutzen Verhaltensweisen wie Autoritätshörigkeit aus, um Dinge wie geheime Informationen oder unbezahlte Dienstleistungen zu erlangen. Meist dient Social Engineering dem Eindringen in ein fremdes Computersystem, um vertrauliche Daten einzusehen; man spricht dann auch von Social Hacking.“

Es gibt sehr viele unterschiedliche Arten des Social Engineering. In Bezug auf das Thema Active Directory ist es über diese Methode durchaus möglich, dem eigenen User-Helpdesk eine gezielte Falle zu stellen. Zum Beispiel könnte durch Social Engineering ein Problem an einem Client PC vorgetäuscht werden, in der Hoffnung, dass sich ein Administrator dem Problem annimmt (dafür wird er ja schließlich bezahlt) und sich zum Troubleshooten mit seinem administrativen Benutzerkonto an dem System anmeldet. Was der Administrator hierbei nicht weiß: der Client PC wurde vorher mit einem USB-Keylogger oder einer Autostart Backdoor präpariert.

Nachwort

Ich hoffe ich konnte mit diesem ersten Blogeintrag ein wenig Interesse zu der Active Directory super GAU Thematik wecken. Die Fortsetzung zu diesem Thema, in der auch Lösungsansätze zu dieser Problematik angesprochen werden, folgt in der nächsten Woche.

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."