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.

• Application: Ist eine globale Objektdarstellung einer Anwendung. Sie kann für den Single-Tenant- oder Multi-Tenant-Einsatz konfiguriert werden und ermöglicht den Zugriff auf eine Anwendung von ausserhalb einer Organisation. Letzteres wird für SaaS-Szenarien wie Exchange Online, Teams, Sharepoint Online usw. verwendet. Anwendungen werden über das App-Registrierungs-Menü verwaltet.
• Service Principal: Ist die lokale Darstellung eines globalen Anwendungsobjekts in einem bestimmten Tenant. Das Service Principal Objekt definiert, was die Anwendung in einem bestimmten Tenant tatsächlich tun kann, wer auf die Anwendung zugreift, und auf welche Ressourcen die Anwendung selbst zugreifen kann. Ein neu erstellter Entra-Tenant verfügt über etwa 400 vorkonfigurierte Service Principals, die Anwendungen wie Microsoft Teams, Sharepoint Online, Exchange Online oder Microsoft Graph entsprechen. Wenn eine benutzerdefinierte Anwendung im Entra-Portal oder über die API erstellt wird, werden zwei Entitäten erstellt: eine Application und ein Service Principal.
• Managed Identity: Ein spezieller Typ von einem Service Principal, der die Verwaltung von Anmeldeinformationen überflüssig macht. Es gibt zwei Untertypen. Die vom System zugewiesene verwaltete Identität, die einer bestimmten, von Azure verwalteten Ressource zugewiesen wird und an den Lebenszyklus dieses Objekts gebunden ist. Der zweite Typ ist die benutzerzugewiesene Identität, die als eigenständige Identität von mehreren Ressourcen genutzt werden kann.
• Service Accounts: Eine weitere von Microsoft nicht erwähnte Art von Workload-Identität ist ein Dienstkonto in Form eines reinen Cloud- oder hybriden Benutzerkontos. Es wird oft für Anwendungen von Drittanbietern verwendet, um mit Cloud-Anwendungen zu interagieren, die entweder die Service-Prinzipien nicht vollständig unterstützen, oder für Migrationszwecke.

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.

• Delegated API Permissions: Ermöglicht es der Anwendung, im Namen des angemeldeten Benutzers Zugriff zu erhalten. Dies wird am häufigsten für interaktive Sitzungen verwendet und ist auf den Bereich des jeweiligen Nutzers beschränkt.
• Application API Berechtigungen: Ermöglicht es der Anwendung, auf eine Ressource zuzugreifen, ohne dass ein Benutzer angemeldet ist, und wird normalerweise für Hintergrund- oder automatisierte Arbeitsabläufe verwendet.

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.

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

Voraussetzungen

• Zwei Entra ID Tenants (In diesem Beispiel mytenant.onmicrosoft.com und foreigntenant.onmicrosoft.com)
• Globale Administratorenrolle in beiden Tenants

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

• Anmeldung als Global Administrator bei foreigntenant.onmicrosoft.com unter https://portal.azure.com.
• Öffnen von Microsoft Entra ID
• Navigieren zu App-Registrierungen
• Klicken auf Neue Registrierung
  • Name: foreignApp
  • Support account types: Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant)
    
• Die Anwendung, einschliesslich eines Service Principals, sollte mit einer eindeutigen Objekt- und Client-ID erstellt worden sein
  
• Navigieren von der foreignApp page zu Quickstart
  • Auswahl von Daemon application
  • Auswahl einer Plattformen, zum Beispiel die Node.js console
    
  • Kopieren der generierten Zustimmungs-URL unter standard user. Die URL wird später für Schritt 1 benötigt
    
• Auf der foreignApp Seite zu Certificates & secrets navigieren
  • Erstellen eines client secret und für später aufbewahren
• Auf der foreignApp Seite nach API permissions navigieren
  • Klick auf Add a permission
  • Microsoft Graph auswählen
  • Application permissions auswählen
  • Suchen nach RoleManagement.ReadWrite.Directory und Directory.Read.All
  • Add permissions auswählen für beide App roles
  • Der API-Berechtigungen für diesen Tenant muss nicht zugestimmt werden
    

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

• Anmelden als Global Administrator zum mytenant.onmicrosoft.com Tenant über https://porta.azure.com
• Aufruf von der vorhin generierten Zustimmungs-URL zum Beispiel: https://login.microsoftonline.com/organizations/adminconsent?client_id=e037294a-d64a-4242-977a-3868012d69a5
• Nach der Anmeldung erscheint ein Popup-Fenster, in dem man aufgefordert wird, die foreign application zu prüfen und zu akzeptieren. Ein erstes beunruhigendes Indiz ist, dass die Anwendung nicht verifiziert wurde. Mit ein wenig Mühe kann dies jedoch durch Befolgen der Schritte unter Publisher Verification in verifiziert geändert werden. Das zweite Zeichen ist der in rot markierte Text. Diese Anwendung fragt nach Anwendungsberechtigungen. Das ist nicht wirklich offensichtlich und erfordert das Öffnen der geschlossenen Detailansicht. Der grün hervorgehobene Text verrät, dass es sich um eine Benutzerdelegation handelt. Delegationen sind weniger mächtig als Anwendungsberechtigungen, aber auch nicht harmlos. Zu diesem Thema ist der Artikel OAuth 2.0 Token-Phishing mit bösartigen Anwendungen von nyxgeek (TrustedSec) sehr empfehlenswert.
  
• Nach dem Klicken auf Akzeptieren wurde der Tenant mytenant.onmicrosoft.com erfolgreich an die Organisation foreignapp.onmicrosoft.com übergeben. Wer auch immer das ist (?) Einige öffentlich zugängliche Informationen können mit dem praktischen OSINT-Tool für Tenant-Informationen von DrAzureAD überprüft werden. Aber was ist eigentlich im Hintergrund passiert? Übrigens, der Fehler: Keine Antwortadresse für die Anwendung registriert kann ignoriert werden, da alles auch ohne Antwortadresse funktioniert hat.
• Mit dem Global Admin von mytenant.onmicrosoft.com nun im Azure-Portal zu Enterprise Applications wechseln. Ein Service Principal mit dem Namen foreignApp wurde erfolgreich erstellt, um die multi-tenant Anwendung zu repräsentieren. Die Application ID kann mit der Application (Client) ID aus Schritt 0 verglichen werden. Diese sind identisch.
  
• Öffnen des Service Principals foreignApp und zu Permissions navigieren. Nun kann man die zuvor genehmigten Berechtigungen einschliesslich des Genehmigungsstatus des Administrators sehen.
  

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.

• Zuerst müssen einige Variablen gesetzt werden. Die Kommentare im Skript zeigen den Weg

$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)

• Bevor wir uns mit dem Service Principal anmelden können, verwenden wir unseren Global Administrator aus dem Tenant foreignapp.onmicrosoft.com, um die Anwendungs-ID abzufragen.

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

• Jetzt verwendet das Skript die Application ID und Tenant ID des Tenants mytenant.onmicrosoft.com, um sich mit den Anmeldedaten von foreignapp.onmicrosoft.com beim Tenant mytenant.onmicrosoft.com anzumelden.

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

• Mit der in Schritt 1 zugewiesenen Anwendungsrolle RoleManagement.ReadWrite.Directory fügt das Skript den Service Principal der foreignapp der Rolle Global Administrator hinzu.

$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)"}

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.

• Das Skript fordert dazu auf, sich mit dem Tenant-Administrator von mytenant.onmicrosoft.com anzumelden, der berechtigt ist, Service Principal Informationen zu lesen.
• Das Skript fragt alle Service Principals ab, die eine andere Tenant ID als mytenant.onmicrosoft.com haben, und zwar über das Attribut AppOwnerOrganisationId. Das Ergebnis wird in der Befehlszeile und in der PowerShell-Grid-Ansicht angezeigt.

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

• Die approleValue und appDisplayname sind die App-Rollen, die der resourceDisplayName zugewiesen wurden.

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 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://aadinternals.com/osint/
• https://cyberdom.blog/2023/01/13/hunting-service-principal-with-microsoft-sentinel/
• https://gist.github.com/m8r1us/2b97604b6dd42809a52ca31315a4998a
• https://gist.github.com/m8r1us/86434d2fb7b9e31a71ba4295d6cb2a3a
• https://github.com/AzureAD/MSIdentityTools/wiki/Export-MsIdAppConsentGrantReport
• https://github.com/SpecterOps/BloodHound
• https://github.com/dirkjanm/ROADtools
• https://graphpermissions.merill.net/permission/Directory.Read.All#graph-methods
• https://learn.microsoft.com/en-us/entra/identity-platform/developer-glossary#scopes
• https://learn.microsoft.com/en-us/entra/identity-platform/publisher-verification-overview
• https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
• https://posts.specterops.io/microsoft-breach-what-happened-what-should-azure-admins-do-da2b7e674ebc
• https://www.cloud-architekt.net/entra-workload-id-introduction-and-delegation/
• https://www.trustedsec.com/blog/creating-a-malicious-azure-ad-oauth2-application