Fremde Workloadidentitäten: Ein Security Boundary Risiko?

Fremde Workloadidentitäten

Ein Security Boundary Risiko?

Marius Elmiger
von Marius Elmiger
am 04. April 2024
Lesezeit: 16 Minuten

Keypoints

Die potenziellen Risiken, die von fremden Workloadidentitäten ausgehen

  • Security Boundaries sollten IT-Umgebungen voneinander abtrennen
  • Die Security Boundary ist der Forest in Active Directory und der Tenant in Entra ID
  • Durch die Einführung von Abhängigkeiten von anderen IT-Lösungen kann die Security Boundary erweitert werden
  • Es ist wichtig, die Security Boundary einer bestimmten Lösung zu verstehen
  • Fremde Entra Workload-Identitäten können je nach den gewährten Berechtigungen Risiken darstellen
  • Workload-Identitäten und ihre Fähigkeiten werden oft nicht vollständig verstanden

Security Boundaries sollten IT-Umgebungen oder -Lösungen voneinander trennen. Oft sind Security Boundaries jedoch nicht statisch. Sie können gewollt oder ungewollt erweitert werden. Unbeabsichtigte Erweiterungen können zu Schwachstellen führen, die möglicherweise sensible Daten oder Systeme gefährden. Daher erfordert das Management dieser Sicherheitsgrenzen einen dynamischen Ansatz, der eine kontinuierliche Überwachung und Anpassung erfordert, um ein akzeptables Sicherheitsniveau zu gewährleisten.

In diesem Artikel wird ein Beispiel präsentiert, wie Microsoft Entra Workload-Identitäten versehentlich die Sicherheitsgrenze eines Entra-Tenants auf einen fremden Tenant ausweiten können.

Was ist eine Security Boundary?

Eine Security Boundary ist die Definition einer logischen oder physischen Grenze, die IT-Umgebungen oder -Lösungen voneinander trennen soll. Bei einer neuen Active Directory Installation ist die Security Boundary der Forest. Für Entra ID wäre es der Tenant. Die Security Boundary kann absichtlich oder unabsichtlich erweitert werden, indem Beziehungen zu anderen IT-Lösungen hergestellt werden, die nicht Teil der ursprünglichen Implementierung sind. Regelmässige Audits, robuste Protokolle und Sicherheitstools können helfen, die Integrität dieser Grenzen zu wahren. Letztendlich geht es darum, ein Gleichgewicht zwischen Zugänglichkeit und Sicherheit zu finden und sicherzustellen, dass die richtige Entität zur richtigen Zeit den richtigen Zugriff hat. Weitere Beispiele für Beziehungen, die die Security Boundary erweitern können, sind im Artikel Attack Path Analysis beschrieben.

Was sind Entra Workload-Identitäten?

Workload-Identitäten in der Microsoft Cloud beschreiben nicht persönliche Konten, die einem Workload wie einer Anwendung, einem Dienst, einer virtuellen Maschine, einem Skript oder einem Container zugeordnet sind, um sich zu authentifizieren und auf andere Dienste und Ressourcen zuzugreifen. Microsoft beschreibt drei Arten von Workload-Identitäten im Artikel Workload-Identitäten.

Entra Service Principal Zugangsmanagement

Der Zugriff für Service Principals auf Ressourcen kann mit Delegations- oder Application-API-Berechtigungen zugewiesen werden und erfordert die Zustimmung des Administrators oder des Benutzers.

Entra API Berechtigungen

API-Berechtigungen ermöglichen den Service Principal der Anwendung, andere öffentliche APIs aufzurufen, wenn die Benutzer oder Administratoren dem zugestimmt haben. API-Berechtigungen werden oft im Resource.Operation.Constraint scope format angegeben. Zum Beispiel bedeutet Directory.Read.All, dass der Service Principal, dem diese Berechtigung erteilt wurde, Daten im Tenant lesen kann, z. B. Benutzer, Gruppen und Apps.

Entra App Rollen

App-Rollen definieren Zugriffsdefinitionen für die Anwendung. Eine Rolle kann mehrere Berechtigungen beinhalten. Für Microsoft Graph existieren zum Beispiel mehrere Anwendungsrollen. Directory.Read.All ist eine von ihnen. Der einfachste Weg, die detaillierten API-Berechtigungen zu überprüfen, die zum Beispiel von der Anwendungsrolle Directory.Read.All gewährt werden, ist der Besuch der Website Microsoft Graph Permission Explorer von Merill Fernando.

Beispiel einer Security Boundary Verletzung

Nach einer kurzen Einführung, was Security Boundaries, Entra Applications und Entra Service Principals sind, wird im nächsten Kapitel anhand eines sehr praktischen Beispiels gezeigt, wie eine multi-tenant Anwendung eine Security Boundary Erweiterung zur Folge haben kann. Falls die obigen Erklärungen zu kurz waren, erklärt der Artikel von Thomas Naunheim Entra Workload Identities im Detail. Andy Robbins von SpecterOps hat ausserdem einen Artikel über den jüngsten Microsoft-Entra-Breach Was ist passiert? What should Azure Admins do? veröffentlicht, in dem er sehr detailliert erklärt, wie externe multi-tenant Anwendungen während des Angriffs genutzt wurden. Beide Artikel sind sehr lesenswert.

Das Szenario

Der Tenant-Administrator von mytenant.onmicrosoft.com registriert eine multi-tenant Anwendung vom Tenant foreigntenant.onmicrosoft.com. Die Anwendung verspricht ein reibungsloses Entra-Rollenmanagement. Nachdem der globale Administrator die Anwendung mit den Geltungsbereichen RoleManagement.ReadWrite.Directory und Directory.Read.All akzeptiert hat, wird im mytenant.onmicrosoft.com Tenant automatisch ein Service Principal als lokale Repräsentation der Anwendung erstellt. Durch diese Aktion wurde die Security Boundary versehentlich auf den nicht vertrauenswürdigen Tenant foreigntenant.onmicrosoft.com ausgeweitet.

Wie schnell eine multi-tenant Anwendung versehentlich eine Security Boundary überschreiten kann

Der folgende Schritt-für-Schritt-POC untersucht die in der obigen Abbildung dargestellten Auswirkungen im Detail.

Voraussetzungen

Schritt 0 (Foreign Tenant): Erstellung einer Anwendung im Portal

Nachdem Schritt 0 abgeschlossen ist, kann die foreignApp Anwendung im mytenant.onmicrosoft.com Tenant registriert werden. Die gesamte Einrichtung könnte noch verbessert werden, indem eine Webanwendung erstellt und eine Antwortadresse konfiguriert wird. Für den POC ist dies jedoch optional.

Schritt 1 (My Tenant): Registrierung der foreignApp Anwendung

Ok, das Szenario ist vorbereitet, jetzt kommt der interessante Teil.

Schritt 2 (Foreign Tenant): Anmelden mit dem Service Principal

Die nächsten Schritte werden per Skript ausgeführt, da dies die einzige Möglichkeit ist, sich mit einem Service Principal anzumelden. Das Skript heisst consentIsTheMindkiller.ps1 und ist im Gist-Repository zu finden.

$myTenantId = "cdfdd915-..." # Der Tenant, der die Anwendung nutzen möchte (Source: My Tenant)
$foreignTenantId = "d2a16643-37f9-..." # Der Tenant, welcher die Anwendung betreibt (Source: Foreign Tenant)
$spPassword = "1N98Q~qo7oKGhA3L~t~OgQKVDPL.iasdas32" # Das client secret von der Anwendung (Source: Foreign Tenant)
$appName = "foreignApp" # Der Anwendungsname (Source: Foreign Tenant)

$foreignApp = Get-MgServicePrincipal -All -Filter $appFilter

$spPwd= ConvertTo-SecureString $spPassword -AsPlainText -Force
$psCred = New-Object System.Management.Automation.PSCredential($foreignApp.AppId, $spPwd)
Connect-MgGraph -TenantId $myTenantId -ClientSecretCredential $psCred -NoWelcome

Erfolgreiche Anmeldung mit den Anmeldeinformationen vom foreigntenant beim mytenant mit dem Service Principal

$globalAdmin = Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdmin.Id -BodyParameter @{"@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$($foreignsp.id)"}

Service Principal erfolgreich zur Rolle des Global Administrator hinzugefügt

Bei der Genehmigung von Rechten zu fremden Applikationen, kann die Security Boundary auf den Tenant der fremden Applikation ausgeweitet werden. Schliesslich funktioniert SaaS auf diese Weise. Jedoch haben wir keine Möglichkeit gefunden, auf dem fremden Tenant über das Azure-Portal oder die Graph-API abzufragen wer die multi-tenant Anwendung nun schlussendlich verwendet. Das wäre aber natürlich möglich, wenn der fremde Tenant eine Website hosten würde, die den Administrator zur Registrierung und schliesslich zur Nutzung der Anwendung leitet. Aber wenn man in einem Tenant landen und viele multi-tenant Apps findet, wäre es momentan nicht trivial, einen Ziel-Tenant zu evaluieren, um das oben beschriebene Szenario zu missbrauchen. Es sei denn, es handelt sich um eine bekannte Anwendung.

Was kann dagegen gemacht werden? Zunächst einmal ist es wichtig, jede fremde SaaS-Anwendung zu überprüfen, bevor Anwendungsberechtigungen oder Delegationen erteilt werden. Danach sollte der folgende Schritt 3 dabei helfen, bestehende foreign Service Principals in einem Tenant zu überprüfen.

Schritt 3 (My Tenant): Finde foreign Service Principals mit Anwendungsberechtigungen

In diesem Schritt sind wir der Administrator des Tenants mytenant.onmicrosoft.com, der zuvor die Anwendungsberechtigungen akzeptiert hat.

$foreignsp = Get-MgServicePrincipal -All | Where-Object { $_.AppOwnerOrganizationId -ne $myTenantId -and $_.AppOwnerOrganizationId -ne $null }

Foreign Service Principal Resultat

In einem produktiven Tenant ist Schritt 3 eine wichtige Prüfungsaufgabe, um die Berechtigungen der Foreign Service Principals zu überprüfen. Schritt 3 ist auch als separates Skript verfügbar. Das Skript heisst checkForForeignServicePrincipals.ps1 und ist im Gist-Repository zu finden.

Fazit

Eine der vielen Herausforderungen in jeder IT-Umgebung und insbesondere in der Cloud besteht darin, die Security Boundary nicht versehentlich auf eine unbekannte, nicht vertrauenswürdige Entität auszuweiten. In einem Microsoft-Cloud-Tenant gibt es verschiedene Möglichkeiten, dies zu tun, z. B. über Azure Lighthouse, granulare delegierte Administratorrechte (GDAP), multi-tenant Anwendungen, Lösungen von Drittanbietern, die nur Cloud-Konten unterstützen, Agenten von Drittanbietern für IaaS-Workloads und DevOps-Lösungen. In einer Active Directory-Umgebung existieren ähnliche Herausforderungen, obwohl die Cloud eine gefährlichere Angriffsfläche bietet. Wie das obige Beispiel zeigt, genügt ein einziger Klick eines privilegierten Administrators, um die Security Boundary zu einem fremden Tenant zu erweitern. Umso wichtiger ist es, die Security Boundary eines Tenants zu kennen und neue Funktionen in einem nicht produktiven Tenant zu testen. IT-Administratoren sollten ausreichend geschult sein, um über das Wissen zum Betrieb einer Cloud-Umgebung zu verfügen. Bei unseren Prüfungen stellen wir oft fest, dass Workload Identities und ihre Möglichkeiten nicht vollständig verstanden werden, weshalb sie in unseren Top 10 Riskiest Cloud Configurations aufgeführt sind. Microsoft macht es ausserdem nicht einfach, Workload Identities und ihre Berechtigungen zu verwalten und zu überprüfen. Tools wie ROADTools, BloodHound, Skripte wie Export-MsIdAppConsentGrantReport oder die automatische Überwachung von Workload Identities-Berechtigungen und -Änderungen, wie zum Beispiel in Hunting Service Principals with Microsoft Sentinal beschrieben, können helfen, Workload Identities unter Kontrolle zu bekommen.

Über den Autor

Marius Elmiger

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

Sie wollen die Awareness Ihrer Benutzer prüfen?

Lassen Sie durch uns einen Social Engineering Test durchführen!

×
Microsoft Cloud Access Tokens

Microsoft Cloud Access Tokens

Marius Elmiger

Credential Tiering

Credential Tiering

Marius Elmiger

Credential Tiering

Credential Tiering

Marius Elmiger

Hardware-Keylogger

Hardware-Keylogger

Marius Elmiger

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv