Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03247.jsonl.gz/879

Microsoft Cloud Security
Marius Elmiger
Angreifern mit Attack Path Analysis einen Schritt voraus sein
Aufgrund der Kritikalität von IT-Umgebungen werden Sicherheitsanalysen und Härtungsmassnahmen als obligatorisch angesehen. Es gibt verschiedene Methoden zur Prüfung von IT-Umgebungen, z. B. durch Scannen nach Schwachstellen oder in Form von Sicherheitsempfehlungen. Die Komplexität und die potenziellen Blindspots stellen jedoch ein grosses Problem dar. Sie können zu Attack-Paths führen, die von Angreifern zur Kompromittierung von Systemen missbraucht werden können. In diesem Artikel liegt der Fokus auf identitätsbasierten Attack-Paths. Die Methode der Attack-Paths kann jedoch auch auf andere Szenarien angewandt werden, z. B. auf fehlende Firewall-Regeln oder Softwareschwachstellen.
Angreifer können Attack-Paths verwenden, um sich auf der Grundlage beabsichtigter oder unbeabsichtigter missbräuchlicher IT-Entitätbeziehungen durch eine IT-Umgebung zu bewegen. Ein Attack-Path kann ein Konstrukt aus komplexen oder einfachen Sequenzen von Beziehungen sein. Ein sehr vereinfachtes Beziehungsmuster einer IT-Organisation ist in folgender dargestellt.
Ein Endpunkt (1) wie ein Server, ein Client oder eine DevOps-Pipeline läuft mit einer Identität (2), wie zum Beispiel einem Benutzerkonto, ein Dienstkonto oder ein Azure-Service-Principal. Die Identität ist Mitglied von Rollen oder Gruppen (3), diese können verschiedene Berechtigungen (4) haben. Wobei gewisse das gesamte IT-Environment kontrollieren können (5). Die genannten Entitäten werden normalerweise von Verwaltungssystemen wie zum Beispiel Intune, SCCM, Hypervisors und IAM-Lösungen verwaltet. Die folgende Abbildung stellt diese zusätzlichen Beziehungen dar (6-7).
In der Regel fügen IT-Organisationen weitere Komplexität hinzu, indem sie einen Teil ihrer IT-Umgebung auslagern oder Cloud-Lösungen wie AWS, GCP, Microsoft Cloud, GitLab, GitHub usw. nutzen. Die folgende Abbildung veranschaulicht dieses Argument.
Mit der neu hinzugefügten Umgebung werden neue Beziehungen eingeführt. In der nächsten Abbildung wiederholt sich das allgemeine Muster zum Beispiel. Warum? Weil das Muster auch in der hinzugefügten Umgebung existieren kann, wodurch neue übergreifende Attack-Paths zu Umgebung 1 auftreten können.
Inzwischen wissen wir, dass unsere Umgebung eine Vielzahl von Beziehungen aufweisen kann, die sich vervielfachen, sobald weitere Dienstleister oder neue Lösungen eingeführt werden, die mit unserer IT-Umgebung interagieren. Können wir immer alle Beziehungen kennen? Wahrscheinlich nicht. Ist es wichtig, es zu versuchen? Definitiv. Um Attack-Paths analysieren zu können, sind wir abhängig von zwei Tatsachen. Erstens die gesammelten IT-Daten für die Analyse und zweitens das Wissen über die Beziehungen zwischen den IT-Entitäten in unseren Umgebungen. Die folgende Abbildung zeigt ein stark vereinfachtes Beispiel für bekannte und unbekannte Attack-Paths in einem Attack Graph. Da es schwierig ist alle Attack-Paths zu kennen, sollte es unser Ziel sein so viele wie möglich zu identifizieren und zu eliminieren. Damit wird es für einen Angreifer umso schwieriger einen neuen unbekannten Pfad auszunutzen.
Die bisher verwendeten Beispiele waren eine vereinfachte Abstraktion, um die Beziehung und die Herausforderungen von Attack-Paths in IT-Umgebungen zu veranschaulichen. Die folgende Abbildung zeigt einen Attack-Path, welcher in einem Azure AD Tenant tatsächlich existieren kann.
Die Abbildung enthält die Elemente von zuvor mit zwei Umgebungen. Umgebung 2 ist eine lokale Active Directory Umgebung, und Umgebung 1 ist ein Azure AD Tenant. Ein Azure AD Benutzer ist auf einem Hybrid-Joined-Device aus Umgebung 2 angemeldet. Der Azure AD Benutzer hat Owner Rechte über den Azure Service-Principal. Der Azure Service-Principal ist Mitglied der Global Administrator Rolle und kann daher als mächtigste Rolle in der Microsoft Cloud den Azure AD Tenant vollständig kontrollieren. Das Auffinden und das Eliminieren von solchen missbrauchbaren Berechtigungs-Abfolgen kann die Sicherheitslage einer Umgebung messbar verbessern.
Alles beginnt mit einem Defender’s Mindset, welches eine gewisse Neugier voraussetzt, um zu verstehen, wie die eingesetzten IT-Systeme wie Active Directory, Microsoft Cloud, DevOps, Jump Servers oder andere zusammenhängen und funktionieren. Eine Methode besteht darin, IT-Entitäten und ihre Berechtigungen zu untersuchen und die Frage zu stellen, wie sich diese Berechtigung auf die IT-Umgebung auswirken können. Die Antwort kann trivial oder komplex sein, aber sie hilft dabei, Entitäten nach ihren Prioritäten zu kategorisieren und zuzuordnen. Mit diesem Ansatz hat die Reise zu Knowing your Assets in Bezug auf die Beziehungen der einzelnen Assets begonnen. Die Graph-Theory kann dabei eine effektive Methode sein, welche dabei helfen kann Beziehungen zu visualisieren und messbar zu machen. Es gibt bereits mehrere Tools für die Analyse von Attack-Paths, die sich die Graph-Theory zunutze machen. Tools wie BloodHound, BloodHound Enterprise, adalanche, Stormspotter und andere haben bereits viele gemeinsame IT-Entitätsbeziehungen zu bestimmten IT-Services implementiert und können bei der Durchführung einer ersten Attack-Path-Analysis der eigenen IT-Umgebung als nützlich erweisen.
Das folgende Attack-Path-Beispiel zeigt, wie ein scheinbar unprivilegierter Benutzer ein Global Administrator in einem Azure AD Tenant werden kann, indem er Anmeldeinformationen von Azure DevOps extrahiert und die Azure AD App-Rollenberechtigungen missbraucht. Teil zwei des Attack-Paths wurde von Andy Robbins Research inspiriert, der das Szenario des Azure AD App-Rollenmissbrauchs noch ausführlicher behandelt.
Der in der Abbildung dargestellte Attack-Path ist ein Auszug aus einem Microsoft Cloud Tenant, der mit einer modifizierten Version von AzureHound und BloodHound durchgeführt wurde. Wir planen in der Zukunft weitere Blogbeiträge zu veröffentlichen, wie die Graph-Theroy und Tools wie BloodHound helfen können, Attack-Paths in einer komplexen IT-Umgebung zu finden.
Der Attack-Path zeigt in der oberen linken Ecke einen Benutzer namens Rabban. Es wird davon ausgegangen, dass ein Angreifer den Benutzer kompromittiert hat. Das Ziel des Angreifers ist es, ein Global Administrator zu werden, um die volle Kontrolle über den Azure AD Tenant zu erlangen. Die folgenden sechs Schritte beschreiben den Attack-Path aus der Sicht des Angreifers.
Verschiedene Sicherheitskontrollen wie MFA, Genehmigungsanfragen für Rollen oder Detection-Rules hätten implementiert werden können, um es einem Angreifer zu erschweren, den oben beschriebenen mehrstufigen Attack-Path zu missbrauchen. Aber wäre es nicht besser, mit der Beseitigung der Grundursache zu beginnen? Die Grundursache in diesem Beispiel ist der überpriviligierte Service-Principal, welcher indirekt von einem Standardbenutzer kontrolliert wird. Der gezeigte Attack-Path ist ohne Analyse schwer zu finden und selbst bei aktivierten Sicherheitskontrollen nicht unbedingt zu verhindern.
Die Attack-Path-Analysis-Methode ist geeignet, um direkte und indirekte Attack-Paths zu identifieren und konkrete Präventivmassnahmen zu ergreifen. Wir haben gelernt, dass die Methode die Denkweise eines Verteidigers erfordert, der neugierig sein sollte, wie IT-Systeme funktionieren. Basierend auf diesem Wissen können die notwendigen IT-Daten für die Analyse gesammelt und die Beziehungen zwischen den IT-Entitäten kreiert werden, um eine Attack-Path-Analysis durchzuführen. Es wurden verschiedene Tools wie zum Beispiel BloodHound, BloodHound Enterprise, adalanche oder Stormspotter erwähnt, die es ermöglichen, mit dem Auffinden von Attack-Paths in häufig genutzten IT-Diensten wie Active Directory oder der Microsoft Cloud zu beginnen. Schlussendlich wurde mithilfe eines Beispiels aufgezeigt, wie ein mehrstufige Attack-Path-Abfolge aussehen könnte. Durch die Attack-Path-Analysis-Methode können solche und andere Abflogen erkannt und eliminiert werden. Was uns einen Vorsprung vor Angreifern verschaffen könnte, welche versuchen, bestehende Angriffspfade in IT-Umgebung zu missbrauchen.
Unsere Spezialisten kontaktieren Sie gern!
Marius Elmiger
Marius Elmiger
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv