- Netzwerkverteidigung beginnt damit, Assets aufzulisten und zu priorisieren, doch die tatsächliche Angriffsfläche entsteht als Graph von Sicherheitsabhängigkeiten zwischen Assets
- Angreifer greifen selten das stärkste Asset frontal an, sondern suchen entlang schwach geschützter Workstations oder Administrationspfade nach Umwegen zu hochwertigen Assets
- In Windows-Netzwerken können Faktoren wie Anmeldeart, Zugangsdaten, Kerberos-TGTs, NTLM-Hashes, gemeinsame lokale Administratorpasswörter und Anmeldeskripte allesamt Kanten im Graphen bilden
- Verteidiger sollten Asset-Listen in Graphen umwandeln und die Konnektivität durch Infrastruktursegmentierung, Credential-Silos, Least Privilege, Zwei-Faktor-Authentifizierung und Credential-Rotation verringern
- Angreifer lernen die reale Infrastruktur Stück für Stück, nicht anhand veralteter Diagramme; Verteidiger können nur im Vorteil sein, wenn sie die Verbindungen im aktuellen Netzwerk genauer verstehen
Was Verteidigung in Listen übersieht
- Viele Ansätze der Netzwerkverteidigung laufen schon schief, bevor es zum Kontakt mit Angreifern kommt, weil sie das Schlachtfeld falsch verstehen
- Verteidiger konzentrieren sich darauf, Assets zu schützen, Prioritäten zu setzen und sie nach Workloads und Geschäftsfunktionen zu ordnen
- Systemverwaltungsdienste, Asset-Inventardatenbanken und BCDR-Tabellen sind voll von Asset-Listen
- Tatsächlich müssen Verteidiger jedoch nicht einzelne Asset-Listen handhaben, sondern einen Graphen, in dem Assets durch Sicherheitsbeziehungen verbunden sind
- Angreifer landen mit Techniken wie Spearphishing an irgendeinem Punkt dieses Graphen und bewegen sich dann im Netzwerk weiter, um anfällige Systeme zu finden
- Dieser Graph ist nicht von außen vorgegeben; er wird von den Verteidigern selbst geschaffen, die das Netzwerk entwerfen und betreiben
Was der Graph im Netzwerk bedeutet
- Der Graph eines Netzwerks ist die Menge von Sicherheitsabhängigkeiten, die zwischen Assets Äquivalenzklassen bilden
- Vier große Faktoren beeinflussen den Graphen
- Netzwerkdesign
- Art der Netzwerkverwaltung
- Im Netzwerk eingesetzte Software und Dienste
- Verhalten der Nutzer
- Im Beispiel eines Domain Controllers senkt ein einzelner schwacher Administrationspfad das Sicherheitsniveau des gesamten hochwertigen Assets
- Bob verwaltet den Domain Controller von seiner Workstation aus
- Wenn diese Workstation nicht so gut geschützt ist wie der Domain Controller, kann auch der Domain Controller kompromittiert werden
- Andere Konten mit Administratorrechten auf Bobs Workstation können ebenfalls Bob und den Domain Controller kompromittieren
- Diese Administratoren melden sich berufsbedingt auf mindestens einer weiteren Maschine an
- Kompromittiert ein Angreifer eine davon, entsteht ein Pfad zum Domain Controller
Six Degrees of Mallory: laterale Bewegung entlang des Graphen
- Angreifer können auf einer kompromittierten Maschine abwarten und mit Passwort-Dumpern wie mimikatz darauf warten, dass sich ein hochwertiges Konto anmeldet
- Der linke Cluster im Beispielgraphen ist ein einzelner Terminal Server, der von Hunderten Nutzern verwendet wird
- Kompromittiert ein Angreifer diese Maschine, kann er im Laufe der Zeit die Zugangsdaten vieler Nutzer dumpen
- Eine Graphsuche legt mehrere Pfade zu einem High Value Asset offen
- Durch die Kompromittierung des Terminal Servers werden auch User46 und User128 kompromittierbar
- User46 ist Administrator von Machine2821, User128 ist Administrator von Machine115
- Werden diese Workstations kompromittiert, können User1 und User34 kompromittiert werden
- User1 und User34 sind beide Administratoren des High Value Asset
- Um ein High Value Asset zu schützen, müssen alle Elemente, von denen es abhängt, ebenso gründlich geschützt werden wie das High Value Asset selbst; zusammen bilden sie eine Äquivalenzklasse
Beziehungen, die Sicherheitsabhängigkeiten schaffen
- Wenn ein Nutzer in einem Windows-Netzwerk bestimmte Anmeldearten wie Interactive oder Terminal Server verwendet, sind seine Zugangsdaten bei einer Kompromittierung des zugrunde liegenden Hosts dem Diebstahl ausgesetzt
- Betroffen sind nicht nur Zugangsdaten, sondern auch Single-Sign-on-Äquivalente wie Kerberos-TGTs und NTLM-Hashes
- Sicherheitsabhängigkeiten entstehen auch durch alltägliche Verwaltungsbeziehungen
- Lokale Administratorkonten mit gemeinsamem Passwort: Nach dem Dump eines lokalen Administratorpassworts auf einem System kann dasselbe Passwort auf anderen Hosts verwendet werden
- Fileserver und Software-Update-Server, die Anmeldeskripte enthalten, die für viele Nutzer ausgeführt werden
- Printserver, die bei der Nutzung Druckertreiber an Client-Maschinen ausliefern
- Zertifizierungsstellen, die für Smartcard-Anmeldungen gültige Zertifikate ausstellen
- Datenbankadministratoren, die Code im Kontext eines Datenbankservers ausführen können, der als privilegierter Nutzer läuft
- Auch indirekte Beziehungen werden Teil des Graphen
- Wird eine verwundbare Maschine kompromittiert, kann der Angreifer neue Kanten im Graphen schaffen
- Wenn ein Nutzer Konten mit demselben Passwort in zwei Domains ohne Vertrauensbeziehung hat, entsteht eine verborgene Kante zwischen den Domains
Verteidigungsmethoden, die den Graphen verkleinern
- Der erste Schritt für Verteidiger besteht darin, Asset-Listen in einen Graphen umzuwandeln und das Netzwerk zu visualisieren
- Danach müssen unerwünschte Kanten gefunden und beschnitten werden, die große Konnektivitätsexplosionen verursachen
- Infrastruktursegmentierung und Credential-Silos implementieren
- Die Zahl der Administratoren reduzieren und Berechtigungen mit Just-In-Time- / Just-Enough-Techniken minimieren
- Zwei-Faktor-Authentifizierung einsetzen, um Bewegungen über bestimmte Kanten abzumildern
- Ein robustes Verfahren zur Credential-Rotation einsetzen, um auf Kompromittierungen von Nutzerkonten vorbereitet zu sein
- Forest-Trust-Beziehungen erneut prüfen
Ein besseres Realitätsmodell als die Angreifer entwickeln
- Verteidiger sollten Angreifern beim Visualisieren des Schlachtfelds keinen Vorteil überlassen
- Verteidiger können über vollständige Informationen zu ihrem Netzwerk verfügen, während Angreifer das Netzwerk Stück für Stück lernen müssen
- Angreifer untersuchen nicht ungenaue mentale Modelle, unvollständige Asset-Inventarsysteme oder veraltete Netzwerkdiagramme, sondern die aktuell vorhandene Infrastruktur
- Auch Verteidiger müssen ihr Netzwerk an der Realität ausrichten, um der Denkweise vorbereiteter Verteidiger näherzukommen
Weiterführende Lektüre
- Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph: J. Dunagan, D. Simon, A. Zheng
- Two Formal Analyses of Attack Graphs: S. Jha, O. Sheyner, J. Wing
- Using Model Checking to Analyze Network Vulnerabilities: P. Ammann, R. Ritchey
- A Graph-Based System for Network-Vulnerability Analysis: C. Phillips, L. Swiler
- Automated Generation and Analysis of Attack Graphs: J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
- Modern Intrusion Practices: Gerardo Richarte
- Attack Planning in the Real World: Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute
1 Kommentare
Meinungen auf Hacker News
Angreifer haben in der Regel eine bestimmte Mission, etwa den Abfluss wichtiger Daten, die Destabilisierung eines Ziels oder Ransomware, und können so tief wie nötig vordringen, bis sie diese Mission erfüllt haben.
Verteidiger hingegen müssen gleichzeitig viele Signale und Bedrohungsvektoren verfolgen, weshalb sie zwangsläufig in Listen denken, und wegen regulatorischer Vorgaben müssen sie sogar die Punkte priorisieren, zu denen sie Maßnahmen ergreifen müssen.
Wenn Verteidiger nicht beliebig über den Graphen verteilt werden, um interessante Aktivitäten zu finden, sehe ich nicht, wie Verteidiger in Graphen denken können. Auch das, was der Autor vorschlägt, wird am Ende nur zu Signalen in einer Liste, die Verteidiger abgleichen müssen.
Als die Verteidiger diese Methode übernahmen, konnten sie potenzielle Angriffe identifizieren, bevor das Red Team sie ausführte. Kluge Teams würden zum Beispiel sofort Red-Team-Techniken übernehmen, bei denen AWS als Graph gecrawlt wird, um Pfade von Konten mit geringem Wert zu Konten mit hohem Wert zu finden.
Es ist keine Frage von Nullsummenlogik oder eines großen Umbruchs, aber Verteidiger können stärker wie Angreifer denken und Angreifer-Tools häufiger für die Verteidigung nutzen.
Dann muss man die Pfade zu diesem Ziel schützen, unabhängig davon, wie diese Pfade aussehen oder ob sie auf Software beschränkt sind.
Ein Angreifer könnte zwar eine CVE ausnutzen, um das Entertainment-System in einen Denial-of-Service-Zustand zu versetzen, aber es ist fraglich, wie wichtig so etwas in der Praxis wirklich ist.
Die große Mehrheit realer Angriffe läuft eher nach dem Muster „schauen wir uns um, was wir finden können, und überlegen später, wie wir es nutzen“. Viele Angriffsaktivitäten wie Informationsbeschaffung, Einflussoperationen und Propaganda funktionieren genauso.
Verteidiger verwenden Listen, weil sie Hunderte oder Tausende von Assets gleichzeitig verwalten müssen. Wenn man vieles verwalten muss, erstellt man Listen, geht sie durch und wendet Checklisten an.
Natürlich sollten Verteidiger auch Abhängigkeitsgraphen erstellen, aber zuerst müssen sie Listen anlegen und prüfen, ob diese aktuell sind, ob sie von begrenztem Vertrauen ausgehen und ob Ressourcen isoliert sind; danach erstellt man Abhängigkeitsgraphen.
Verteidiger müssen sowohl in Listen als auch in Graphen denken und eine enorme Zahl von Einträgen verwalten, während Angreifer nur auf wenige Dinge achten müssen.
Ohne die Einsicht, Listen in Graphen zu überführen, bleibt man am Ende nur mit einer Liste der kritischen Assets zurück und stopft im Whac-a-Mole-Stil Zehntausende Zugangswege, die man nicht bedacht hat.
Dieser Artikel wirkt, als ginge er zu sehr in die Tiefe. Oder die Begründung stimmt, aber die Ursache ist falsch. Die Aufgabe von Verteidigern ist nicht die Verteidigung an sich.
Cybersicherheit ist kein Sportspiel mit klaren, gleichwertigen Zielen und abwechselnden Positionen, sondern eher ein Nebenprogramm und eine Ablenkung neben dem eigentlichen Geschäft, dem Verteidiger nachgehen wollen.
Umgekehrt besteht die gesamte Aufgabe von Angreifern darin, Systeme anzugreifen. Es gibt keinen anderen Zweck, keinen nachrangigen Auftraggeber und keine sonstigen Überlegungen, die den Angriff abschwächen würden.
Der Grund, warum Angreifer gewinnen, ist derselbe, aus dem Microsoft besser als Cisco darin ist, Betriebssysteme herauszubringen. Für Cisco ist ein Betriebssystem ein Mittel zum Zweck, für Microsoft ist es der Zweck.
Es erklärt auch, warum Unternehmen für Datenlecks am Markt kaum bestraft werden.
Cyberangriffe haben klare Ziele wie Datendiebstahl oder die Störung von Diensten. Das mag auf unreife Akteure zutreffen, die einfach etwas kaputtmachen und Chaos stiften wollen, aber wenn man staatliche Akteure oder finanziell motivierte Kriminelle betrachtet, geht diese Sicht völlig am Ziel vorbei.
Dieser Artikel wirkt eher so, als ginge er nicht tief genug :-)
Eine „Liste“ ist eine Kurzform für Komponenten, ein „Graph“ eine Kurzform für Interoperabilität. Die Komponentenperspektive ist Analyse; für die Interaktionsperspektive gibt es noch kein gutes Wort, aber wie der Artikel sagt, wird sie oft zur Angriffsfläche.
Komplexe adaptive Systeme haben Komponenten und einen Message Bus, und entscheidend ist, dass dieser Bus den Komponenten Möglichkeiten zur Interoperation bietet. Man kann Ameisen einzeln fangen, aber wenn man sie wirklich aufhalten will, muss man ihnen die Fähigkeit nehmen, Pheromonspuren zu hinterlassen.
Es wäre schön, wenn es auch für das Verstehen von Interoperabilitätsweisen ein Wort wie „Analyse“ gäbe. Gestaltysis vielleicht?
Ich habe einmal kurz bei einem Cybersicherheitsunternehmen gearbeitet und konnte damals nicht in Worte fassen, warum ich dieses Produkt nicht mochte und warum sich der Ansatz dieses Unternehmens und eines großen Teils der Branche letztlich wie Schein wirkte.
Jetzt weiß ich es. Wir bauten ein Tool, das die nutzloseste Praxis in der Cybersicherheit unterstützte: Checklisten auf Organisationsebene.
Im Zentrum jeder Aktivität stehen Listen und wiederkehrende Termine. Man muss regelmäßig auftauchen und die Dinge tun, die zu tun sind.
Natürlich stimme ich zu, dass es bei diesem Schritt „was zu tun ist“ einen tieferen und besseren Ansatz braucht.
Um sagen zu können: „Wir haben alle Checklisten befolgt, und die Sicherheitssoftware hat es nicht erkannt, also ist es nicht unsere Schuld.“
Wenn einem Unternehmen Sicherheit wirklich wichtig wäre, würde es ein Red Team beauftragen, statt für nutzlose Scanner zu zahlen, deren Signal-Rausch-Verhältnis unter 1 % liegt.
Schaut man auf die Luftfahrt, leben Piloten von Checklisten. Das garantiert nicht, dass während eines Flugs nie Probleme auftreten, aber eine Checkliste nicht zu befolgen oder sie leichtfertig zu behandeln, ist ein Rezept für eine Katastrophe. Solche Checklisten entstehen auf Grundlage jahrelanger, teurer Erfahrung.
Eine Checkliste, die nur existiert, damit man sagen kann „wir haben eine Checkliste“, oder die nicht regelmäßig anhand realer Bedingungen überprüft und aktualisiert wird, ist dagegen bedeutungslos.
Viele Unternehmen verstehen das falsch. Sie halten die Checkliste selbst für Sicherheit, tatsächlich ist sie aber nur ein Werkzeug, das einen daran erinnert, Dinge weiter aufrechtzuerhalten, die man früher richtig gemacht hat. Sobald man die Checkliste wie ein Ziel behandelt, ist man vom Weg abgekommen.
Aus Sicht eines Penetration Testers denken Angreifer auch nicht unbedingt in Graphen.
Abgesehen von BloodHound fällt mir kaum ein Tool ein, das Graphen nutzt.
Auch in der Web-Sicherheit fällt mir nichts ein, worauf „Graph-Denken“ zutrifft. Stattdessen gibt es eine sehr große Liste von Angriffen, die man testen kann: https://portswigger.net/web-security/all-topics
Und was am Ende in einem Penetrationstestbericht steht, ist kein Graph, sondern eine To-do-Liste. Zum Beispiel SMB-Signierung, nicht für die Verwaltung aller Maschinen ein Domain-Admin-Konto verwenden, und so weiter.
Der Hauptgrund, warum diese Formulierung beliebt ist, ist, dass sie das Ego der Hacker-Community anspricht. Nach dem Motto: „Wir sind die Schlauen, und die Verteidiger hantieren nur mit Excel-Tabellen.“
Ein Körnchen Wahrheit steckt allerdings darin. Verteidiger können ziemlich viel Zeit mit Dingen verbringen, die nicht besonders wichtig sind. Während man auf allen Servern CIS-Benchmarks von Hand umsetzt, übersieht man die tief hängenden Früchte, die eine starke Sicherheitslage schaffen würden.
In vielen Unternehmen sind Verteidiger einfach Systemadministratoren, die nicht wissen, worauf sie sich konzentrieren sollten.
Ein Beispiel, das mir sofort einfällt, sind Bug Chains. Wenn man mehrere Schwachstellen auf CVSS-4-bis-7-Niveau verknüpft, kann daraus ein Ergebnis der Klasse 9,8 werden, etwa vollständige Remote Code Execution. Solche Bug-Verknüpfungen sind im Kern eine Graph-Traversierung über Kompromittierungselemente.
BloodHound ist hervorragend und ein gutes visuelles Werkzeug, um Angriffsgraphen zu konzeptualisieren, aber es ist nur ein Teil davon, eine Zieldomain aus Angreifersicht zu verstehen.
Der Grund, warum es für Web-Penetrationstests kein so sauberes Tool wie BloodHound gibt, ist, dass sich Kompromittierungsketten schwer einfach in Tool-Form reduzieren lassen. Bei AD sind Sicherheitsgrenzen bis zu einem gewissen Grad verstanden und kodifiziert, aber Chains in Web-Apps sind oft stärker an die jeweilige Anwendung gebunden als an das zugrunde liegende Framework.
Dass in Penetrationstestberichten Punkte wie SMB-Signierung oder „nicht alles mit DA-Konten verwalten“ auftauchen, liegt daran, dass sie sehr frühe, hell leuchtende Knoten in der Kompromittierungskette sind. In der Praxis werden Umgebungen oft genau so geknackt.
Es ist weniger so, dass Penetration Tester Graph-Denken nicht verstehen, sondern eher so, dass der erste Knoten im Graphen praktisch schon vollständige Kompromittierung bedeutet und es daher keinen Grund gibt, weiter zu traversieren.
Das ist im Grunde nur eine schickere Formulierung dafür, dass Verteidiger alle Einstiegspunkte schützen müssen, während Angreifer nur eine Schwachstelle finden müssen.
Denkbar wäre zum Beispiel, Honeypots zu nutzen, um Zero-Day-Exploits auf die Ausrüstung der Angreifer zurückzuspielen. Vielleicht ist so etwas in Produkten von Google, Microsoft und anderen sogar absichtlich eingebaut.
Man ginge gewissermaßen mit plausibler Abstreitbarkeit komplett Black-Hat vor und füttert Ransomware-Angreifer mit Ransomware.
Beim Schreiben klingt das wie ein böses, allmächtiges Unternehmen aus der Science-Fiction, wobei solche Unternehmen normalerweise sogar Feinde ermorden.
Ich habe Incident Response gemacht und auch Erfahrung mit Penetrationstests und Red Teams. Es ist zwar eine verkürzte Formulierung, aber bis zu einem gewissen Grad stimmt sie, und sie muss nicht so negativ sein, wie der Text es darstellt.
Verteidigung besteht aus vielen Elementen. Dazu gehören zum Beispiel die Entwicklung wirksamer Kontrollen, die Risiko und Auswirkungen von Sicherheitsvorfällen verringern, das Erkennen von Angriffen und Kompromittierungen sowie Incident Response. Listen mit Standards und Reaktionsmaßnahmen funktionieren gut.
Zur Verteidigung gehören auch Architekturentscheidungen, bei denen man in Netzwerkgraphen denken muss, um solche Kontrollen zu entwerfen. Der Verteidigungsbereich ist ebenfalls vielfältig: Architektur/Engineering, Risikomanagement, Incident Response, Anwendungssicherheit, Schulung, Threat Intelligence und mehr.
Interessant ist auch, dass der Autor impliziert, es sei ein Problem, Verteidigung in Listen zu denken, und dann selbst eine Liste von Punkten vorlegt, die man zur Verbesserung der Verteidigung berücksichtigen sollte.
Angreifer gewinnen, weil sie nach dem Finden einer Schwachstelle nur einmal erfolgreich sein müssen. Verteidiger müssen alles gleichzeitig schützen.
Es scheint, als bräuchte jedes Netzwerk mindestens einen Honeypot, um Eindringlinge zu fassen. Dazu gehören Dinge wie gefälschte Krypto-Zugangsdaten oder gefälschte Passwortspeicher.