Die Herausforderung, IT-Umgebungen vor Angreifern sicherzumachen, hat eine neue Komplexitätsstufe erreicht, da immer mehr Unternehmen Cloud-Lösungen zusätzlich zu ihrer bestehenden Umgebung einsetzen. Dieser Trend erhöht die Wahrscheinlichkeit, gefährliche Attack Paths (dt. Angriffspfad) in der eigenen IT-Infrastruktur zu übersehen.

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.

Was sind Attack Paths?

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.

Warum sollte aktiv nach Attack Paths gesucht werden?

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.

Grossartig, aber wie finden wir solche Attack Paths?

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.

Technisches Attack Path Beispiel

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.

Von einem Azure DevOps User zu Global Administrator Rechten

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.

1. Der Angreifer aktiviert die Zugriffsgruppe mit dem Namen “DevOpsRole-Build Administrators” im Azure PIM GUI für den Benutzer Rabban.
   
2. Die Gruppe “DevOpsRole-Build Administrators” mit ihren Mitgliedern wird mit Azure DevOps synchronisiert, wie in der Abbildung dargestellt. Azure DevOps ist eine SaaS Applikation von Microsoft, die eine End-to-End-DevOps-Toolchain für die Entwicklung und Bereitstellung von Ressourcen bereitstellt. Die Gruppe “DevOpsRole-Build Administrators” ist ein direktes Mitglied von drei Azure DevOps-Rollen. Laut der Beschreibung der Microsoft-Dokumentation sollen die Mitgliedschaften dem Benutzer Rabban erlauben, Pipelines zu erstellen und zu verändern. In Azure DevOps werden Pipelines im Allgemeinen für Bereitstellungen von Ressourcen verwendet. Die Deployments verwenden Service-Principals oder andere Arten von Schlüsselmaterial, um sich bei einem Zielsystem zu authentifizieren und autorisieren. Dies macht die Azure DevOps-Plattform für Angreifer interessant.
   
3. Der Angreifer stellt beim Öffnen der Pipeline-Konfiguration fest, dass ein Service-Principal verwendet wird, um Ressourcen für den anvisierten Azure AD Tenant bereitzustellen. Dies ist auch an der Beziehung RunsAs in der Attack Path Abbildung zu erkennen. Der Angreifer beschliesst, das Kennwort des Service-Principal auszulesen, indem er die Pipeline so modifiziert, dass das Kennwort auf dem Terminal ausgegeben wird. Azure DevOps verhindert standardmässig die Ausgabe von Anmeldeinformationen im Klartext. Durch die Konvertierung der Anmeldeinformationen in Hexadezimalzeichen werden diese Schutzmassnahmen umgangen, und die Anmeldeinformationen können abgerufen werden.
   
4. Die folgenden drei Schritte verwendet das PowerShell Script AttackPathDevOps-Sp-AppRole-GA.ps1, das den zweiten Teil des Angriffs automatisiert. Der gewonnene Service-Principal Schlüssel wird umgewandelt, mit welchem sich der Angreifer nun am Azure AD authentifiziert.
   
5. Die Abbildung zeigt, dass dem Service-Principal die App-Rolle AppRoleAssignment.ReadWrite.All zugewiesen ist. Diese Rolle erlaubt es dem Service-Principal, eine neue App-Rolle namens RoleManagement.ReadWrite.Directory anzufordern. Gemäss der Dokumentation von Microsoft kann mit der RoleManagement.ReadWrite.Directory App Rolle alle Azure AD-Rollenmitgliedschaften verwaltet werden.
   
6. Im letzten Schritt wird ein neues Token, das die neue App-Rolle enthält, für den Service-Principal angefordert. Der Angreifer beschliesst, dem Benutzer Rabban die Rolle Global Administrator zuzuweisen, und erreicht damit das Ziel der Tenant-Übernahme.
   

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.

Fazit

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.

Über den Autor

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://bloodhoundenterprise.io
• https://docs.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops&tabs=preview-page
• https://docs.microsoft.com/en-us/graph/permissions-reference
• https://gist.github.com/m8r1us/5babd1d63c25c0199520a0a2f8e4f2e4
• https://github.com/Azure/Stormspotter
• https://github.com/BloodHoundAD/AzureHound
• https://github.com/BloodHoundAD/BloodHound
• https://github.com/lkarlslund/adalanche
• https://go.neo4j.com/rs/710-RRC-335/images/Knowledge-Graphs-Data-in-context-responsive.pdf
• https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48