Ein neuer App-Angriff auf die Einwilligung: Versteckte Einverständniserklärung

Wichtigste Ergebnisse

• Ein Application Consent-Angriff, auch bekannt als Illicit Consent Grant-Angriff, ist eine Art von Phishing-Angriff, bei dem sich ein böswilliger Akteur Zugang zu einer Anwendung verschafft und dann Berechtigungen ausnutzt, die dieser Anwendung gewährt wurden.
• Der Semperis-Forscher Adi Malyanker hat entdeckt, dass ein böswilliger Akteur unter bestimmten Umständen die Berechtigung Directory.ReadWrite.All oder die Berechtigung DelegatedPermissionGrant.ReadWrite.All innerhalb von Microsoft Azure nutzen kann, um seine Privilegien zu erweitern, auf sensible Ressourcen und Daten zuzugreifen, einen Denial of Service (DoS)-Angriff zu starten oder sogar einen Entra ID-Mieter zu übernehmen.
• Jedes Unternehmen, das Anwendungen in Entra ID verwendet, könnte für diesen Angriff anfällig sein, der auch als Hidden Consent Grant-Angriff bezeichnet wird.
• Soweit Semperis weiß, wurde bisher kein solcher Angriff dokumentiert.
• Die Forscher von Semperis stufen diese Sicherheitslücke als potenziell SCHWER ein, da die Möglichkeit besteht, dass ein Entra ID-Mieter übernommen wird.

In Microsoft Azure ist die Berechtigung Directory.ReadWrite.All von großer Bedeutung. Diese Berechtigung ermöglicht eine Vielzahl von Aktionen, einschließlich der Bearbeitung durch den Benutzer und den Zugriff auf alle Daten innerhalb des Verzeichnisses.

Klingt das riskant? Einige haben argumentiert, dass die Berechtigung, wenn sie isoliert verwendet wird, kein inhärentes Risiko darstellt. Meine Nachforschungen haben jedoch ergeben, dass ein Angreifer die Berechtigung Directory.ReadWrite.All (oder DelegatedPermissionGrant.ReadWrite.All ) verwenden könnte, um in einer Microsoft Entra ID (früher bekannt als Azure AD) oder einer hybriden Microsoft Active Directory/Entra ID-Umgebung schweren Schaden anzurichten.

Was sind Anwendungsberechtigungen?

In Entra ID gewähren Anwendungsberechtigungen einer bestimmten Anwendung die Möglichkeit, bestimmte Aktionen durchzuführen oder auf bestimmte Ressourcen innerhalb von Entra ID oder anderen Microsoft-Diensten zuzugreifen. Im Gegensatz zu delegierten Berechtigungen, die Benutzer autorisierten Anwendungen erteilen, werden Anwendungsberechtigungen in der Regel von einem Administrator während der Anwendungsregistrierung erteilt.

Die Anwendung verwendet dann diese Berechtigungen, um Aufgaben im Namen der Organisation oder ihrer Benutzer auszuführen, ohne dass eine individuelle oder fortlaufende Zustimmung der Benutzer erforderlich ist(Abbildung 1).

Anwendungsberechtigungen werden häufig verwendet, wenn die Anwendung auf Ressourcen zugreifen oder Aktionen durchführen muss, die nicht von der Identität oder den Berechtigungen eines bestimmten Benutzers abhängen. Beispiele für Anwendungsberechtigungen sind:

• Benutzerprofile lesen
• Gruppen verwalten
• Zugriff auf Organisationsdaten

Eine sorgfältige Verwaltung und Zuweisung von Anwendungsberechtigungen ist unerlässlich. Unternehmen sollten sicherstellen, dass die Anwendungen über eine angemessene Zugriffsstufe verfügen und gleichzeitig die Sicherheits- und Compliance-Standards innerhalb der Entra ID Umgebung einhalten.

Was ist Directory.ReadWrite.All?

Bei meinen Recherchen über Anwendungsberechtigungen bin ich auf die Berechtigung Directory.ReadWrite.All gestoßen. Laut der Dokumentation von Microsoft:

"Directory.ReadWrite.All" gewährt einen Zugriff, der im Großen und Ganzen dem eines globalen Tenant-Administrators entspricht. Apps, denen Directory.ReadWrite.All gewährt wird, können die gesamte Palette der Verzeichnisressourcen verwalten und sie können die Berechtigung für andere Apps und Benutzer zum Zugriff auf Ressourcen im gesamten Unternehmen verwalten. Dazu gehören Verzeichnisressourcen wie Benutzer, Gruppen, Anwendungen und Geräte sowie nicht-verzeichnisspezifische Ressourcen in Exchange, SharePoint, Teams und anderen Diensten."

Angesichts des Namens dieser Berechtigung, der Assoziation mit der Entra ID und der Verwicklung in die Verzeichnisverwaltung hatte ich den Verdacht, dass diese Berechtigung potenziell gefährlich sein könnte.

Aber nachdem ich die Aktionen untersucht hatte, die Directory.ReadWrite.All zulässt, konnte ich zunächst keine nennenswerten Bedrohungen feststellen. Andere scheinen zu einem ähnlichen Schluss gekommen zu sein. In einem ausgezeichneten Artikel von SpectreOps wird beispielsweise behauptet, dass diese Berechtigung, obwohl sie in Kombination mit anderen Berechtigungen sehr mächtig ist, für sich allein genommen wahrscheinlich kein großes Risiko darstellt.

Trotzdem beschloss ich, mir die Sache genauer anzusehen.

Ich habe getestet, was die Berechtigung Directory.ReadWrite.All auf hoher Ebene bewirken kann. Was könnte ein böswilliger Akteur erreichen, wenn er nur diese Anwendungsberechtigung verwendet?
Die gute Nachricht ist, dass ich die Berechtigung nicht verwenden konnte, um Folgendes zu tun:

• Geheimnisse zu Anwendungen hinzufügen
• Besitzer hinzufügen
• Mitglieder oder Besitzer mit einer Rolle zu einer Sicherheitsgruppe hinzufügen
• Eine App-Rolle zuweisen
• Das Passwort eines Benutzers zurücksetzen

Diese API-Aufrufe liefern eine Antwort wie die in Abbildung 2 gezeigte.

Ich konnte jedoch Directory.ReadWrite.All verwenden, um Folgendes zu tun:

• Hinzufügen eines neuen Mitglieds oder Besitzers ohne zugewiesene Rolle zu einer Sicherheitsgruppe
• Benutzer zum Verzeichnis hinzufügen
• Admin-Zustimmungen bearbeiten
• Begrenzte Bearbeitungen von Verwaltungseinheiten

Hinweis: Mehr als 400 API-Aufrufe beziehen sich auf Teams, Geräte und OneDrive. Diese Aufrufe liegen außerhalb des Rahmens dieser Untersuchung.

Aktionen wie das Hinzufügen neuer Benutzer und Mitglieder, die keine zugewiesene Rolle haben, zu Gruppen könnten für Angreifer, die versuchen, einen ersten Zugriff auf ein Verzeichnis oder Ressourcen zu erhalten, recht nützlich sein. Diese Möglichkeit ist schon beunruhigend genug, aber ich habe mich gefragt, ob noch mehr möglich ist.

Kann ich die Berechtigung Directory.ReadWrite.All verwenden, um mich in einen globalen Administrator zu verwandeln?

Kann Directory.ReadWrite.All zu einem potenziellen Angriffsvektor führen?

Bevor wir zu den lustigen Dingen kommen, ein Hinweis: Das Access Token, mit dem Sie sich bei Azure anmelden, enthält ein spezielles Feld namens scope oder scp. In diesem Feld sind die Berechtigungen vermerkt, die dem Benutzer gewährt werden(Abbildung 3).

Ich habe diesen Wert während meiner Recherche überprüft, um festzustellen, ob meine Versuche, die Berechtigungen zu erhöhen, erfolgreich waren.

Um meinen Verdacht bezüglich Directory.ReadWrite.All zu testen, habe ich eine Microsoft Graph API, oauth2PermissionGrant, gewählt, die eine delegierte Berechtigung für eine Ressource für eine ausgewählte Entität erstellen kann(Abbildung 4).

Um diesen API-Aufruf durchzuführen, musste ich einer Anwendung die Berechtigung Directory.ReadWrite.All erteilen(Abbildung 5). Ich entschied mich für postman-test(Abbildung 6).

Ich habe auch ein schwaches Benutzerkonto, Evil User(Abbildung 7), erstellt, um einen Angreifer zu repräsentieren (der einen böswilligen Benutzer simuliert, der Mitglied des Mandanten und ein legitimer Benutzer ist, der von einem Angreifer erlangt wurde). Ich habe diesem Benutzer keine Rollen oder Berechtigungen zugewiesen(Abbildung 8).

Um die API-Aufrufe aufzurufen, habe ich das Prinzip des postman-test-Dienstes mit Postman verbunden. Schauen wir uns die Eigenschaften und Anforderungen der API an(Abbildung 9):

• clientId identifiziert die Anwendung (in diesem Fall Graph Explorer), die berechtigt ist, im Namen eines angemeldeten Benutzers zu handeln. Der Wert clientId dient als Ersatz für die Identität des Benutzers.
• consentType gibt an, ob die Client-Anwendung berechtigt ist, sich für alle Benutzer oder nur für einen bestimmten Benutzer auszugeben.
• resourceId gibt die Ressource an (in diesem Fall Microsoft Graph), auf die die clientId mit den gewährten Rechten zugreifen kann.
• scope definiert die spezifischen Aktionen (z.B. device.Read.All, Director.ReadWrite.All), die die clientId mit der resourceId durchführen kann.

Um die Beziehungen zwischen diesen Eigenschaften zusammenzufassen: Ein oder mehrere Benutzer gewähren der clientId eine Reihe von Berechtigungen, die durch den Geltungsbereich definiert sind. Die clientId kann dann diese Berechtigungen verwenden, um auf die angegebene resourceId zuzugreifen.

Nun zurück zur Erkundung meines API-Aufrufs. Zunächst brauchte ich die Graph Explorer Objekt-ID. Ich konnte entweder im Apps-Portal in Azure navigieren oder die Graph API(Abbildung 10) verwenden, um diese ID zu erhalten.

Zu Beginn habe ich Graph Explorer als clientId und resourceId verwendet.

Als Evil User habe ich versucht, alle Gruppen im Verzeichnis zu lesen. Wie Sie aus der 403-Antwort in Abbildung 11 ersehen können, wurde diese Aktion aufgrund unzureichender Berechtigungen nicht zugelassen.

Als nächstes habe ich versucht, Graph Explorer eine delegierte Berechtigung - GroupMember.Read.All -für das gesamte Verzeichnis hinzuzufügen(Abbildung 12). Wenn ich Erfolg hatte, sollte jeder Benutzer im Verzeichnis (einschließlich Evil User) diese Berechtigung erhalten.

Ich habe überprüft, ob das Hinzufügen dieser Berechtigung erfolgreich war. Beachten Sie, dass in der App Graph Explorer die Berechtigung für das gesamte Verzeichnis als erteilt angezeigt wurde(Abbildung 13).

Jetzt sollte ich in der Lage sein, den API-Aufruf zu verwenden, um alle Gruppen abzurufen(Abbildung 14).

Seltsam...Graph Explorer hatte die Berechtigung GroupMember.Read.All mit Admin-Zustimmung, aber ich erhalte trotzdem eine 403-Antwort. Warum eigentlich?

Erinnern Sie sich an die Definition von delegierten Rechten? Da Graph Explorer die Berechtigungen des angemeldeten Benutzers verwendete, konnte er Mitglieder nur lesen, wenn der angemeldete Benutzer die richtige Rolle oder Berechtigungsstufe hatte, um diese Berechtigung zu verwenden, was bei Evil User nicht der Fall war. Mein Versuch war eine Sackgasse.

Aber warten Sie. Sind Sie mit dem Angriff auf die unerlaubte Erlaubnis vertraut?

Was ist ein Angriff mit unerlaubter Zustimmung?

Vereinfacht ausgedrückt, handelt es sich um einen Angriff mit unerlaubter Erlaubniserteilung, der auch als Angriff mit Anwendungserlaubnis bezeichnet wird, wenn jemand dazu verleitet wird, einer Drittanbieteranwendung (d.h. einer externen Anwendung) übermäßige Rechte auf seine Daten oder die Konfiguration seiner Office 365-Anwendungen zu gewähren. Abbildung 15 veranschaulicht, wie dieser Angriff funktioniert.

Kurz gesagt, ein Angreifer erstellt eine bei Azure registrierte Anwendung. Dann:

1. Die Anwendung fordert Zugriff auf sensible Daten wie Kontaktinformationen, E-Mails oder Dokumente.
2. Der Endbenutzer erteilt der Anwendung seine Zustimmung. Die Zustimmung kann durch Phishing-Angriffe oder durch Einschleusen von illegalem Code in eine vertrauenswürdige Website erlangt werden.
3. Die App des Angreifers erhält die Zustimmung und ein Zugriffstoken.
4. Die bösartige App - und der Angreifer - haben nun Zugriff auf die Daten des Benutzers auf Kontoebene.

Was würde passieren, wenn ein Angreifer mit einer bösartigen Anwendung, der die Berechtigung Directory.ReadWrite.All erteilt wurde, einen Angriff mit unerlaubter Berechtigungserteilung starten würde? Es war an der Zeit, mein Experiment zu wiederholen.

Treffen Sie den Angriff auf die verborgene Bewilligung

Dieses Mal agierte ich als Angreifer, der versuchte, einen Benutzer im Zielverzeichnis über eine App mit der Berechtigung Directory.ReadWrite.All zu kompromittieren. Die App würde mit niedrigen Rechten starten und dann ihre Berechtigungen erweitern, nachdem sie die Zustimmung des Administrators erhalten hat(Abbildung 16).

Dieser Angriffsablauf wäre auch mit einer App möglich, aber ich habe mich entschieden, zwei Apps zu verwenden, um die Tarnung zu verbessern (indem ich zwischen der App mit der Berechtigung Directory.ReadWrite.All und der App, deren Berechtigungen aktualisiert werden, trenne). Für dieses Experiment:

1. Ich habe ein Konto für einen Benutzer mit eingeschränkten Rechten erstellt: Harmloser Angreifer (harmless_attacker). Bei diesem Experiment wird davon ausgegangen, dass ein Angreifer bereits durch ein früheres Phishing, einen anderen Angriff oder eine Mitgliedschaft im Mandanten Zugang zu diesem Konto erhalten hat.
2. Ich habe ein privilegiertes Benutzerkonto, Privileged User (privileged_user), erstellt, um einen globalen Administrator zu repräsentieren.
3. Ich habe Harmless Attacker verwendet, um eine Anwendung mit der Berechtigung Directory.ReadWrite.All zu erstellen (in diesem Fall postman-test, die ich verwendet habe, um 365stealer delegierte Berechtigungen zu erteilen).
4. Ich habe Harmless Attacker verwendet, um eine weitere App namens 365stealer zu erstellen. Diese App hat die in Abbildung 17 gezeigten Einstellungen. Beachten Sie, dass die Redirect-URI der App zu einem vom Angreifer kontrollierten Endpunkt führt.

Der harmlose Angreifer konnte der 365stealer-App bei der Erstellung keine privilegierten Berechtigungen hinzufügen, so dass die App-Berechtigungen zunächst so aussahen wie in Abbildung 18 gezeigt.

Als nächstes habe ich einen vom Angreifer kontrollierten Endpunkt verwendet, um einen HTTPS-Server einzurichten, der auf Port 443 lauscht(Abbildung 19).

Dann habe ich Harmless Attacker verwendet, um eine Phishing-Seite zu erstellen(Abbildung 20). In einem realen Szenario würde der harmlose Angreifer versuchen, den privilegierten Benutzer dazu zu bringen, diese Seite über eine E-Mail oder eine bösartige Datei aufzurufen.

Die Phishing-Seite enthielt einen Hyperlink zu einer umgeleiteten Microsoft-Anmeldeseite, auf der der privilegierte Benutzer aufgefordert wird, sich bei der bösartigen App(365stealer) anzumelden. Gemäß dem redirect_uri-Teil werden die Token an den HTTPS-Server gesendet, den der Angreifer eingerichtet hat(Abbildung 21).

Nach erfolgreicher Anmeldung wird dem Benutzer eine Einverständniserklärung vorgelegt(Abbildung 22).

Nichts an diesen Berechtigungen oder an der Abfrage der Zustimmung scheint schädlich zu sein (es sind keine sensiblen Berechtigungen erforderlich), also wird der Benutzer die Zustimmung akzeptieren. In unserem Fall wird ihm dann eine Seite wie in Abbildung 23 angezeigt, er schließt seinen Browser und geht seiner Arbeit nach.

Hinweis: Auch wenn die Seite als unsicher gekennzeichnet ist, gibt es Möglichkeiten, dies zu umgehen. Das würde jedoch den Rahmen dieses Artikels sprengen. Sie können auch die nicht verifizierte Notiz in der Zustimmung sehen. Ich werde später in diesem Artikel darauf eingehen, wie Sie dies verbergen können.

In der Zwischenzeit erhält der Angreifer, ohne dass der Benutzer es merkt, das Zugriffstoken und verwendet es, um die /me API aufzurufen(Abbildung 24).

Dieses Zugriffstoken enthält die Berechtigungen, denen der Benutzer in der Zustimmungsanfrage zugestimmt hat. Ein Blick auf das scp-Feld des Tokens bestätigt dies(Abbildung 25).

Jetzt hat der Angreifer also ein Zugriffstoken (und ein Refresh-Token) eines privilegierten Benutzers. Aber dieses Token kann nur mit der App und den delegierten Berechtigungen verwendet werden, die im Bereich aufgeführt sind. Dem Angreifer fehlt immer noch die Berechtigung RoleManagement.ReadWrite.Directory, so dass jeder Versuch, die directoryRoles API (über eine Anfrage an https://graph.microsoft.com/v1.0/directoryRoles) aufzurufen, eine Antwort Access Denied zurückgibt(Abbildung 26).

Auch hier scheint es, dass die Möglichkeiten des Angreifers, Schaden anzurichten, sehr begrenzt sind. Wie könnte ein Angreifer seine Privilegien ausweiten und andere interessante APIs aufrufen?

Hier kommt Directory.ReadWrite.All ins Spiel.

Könnte ich die oauth2PermissionGrant API aus meinem ursprünglichen Experiment nehmen, die nur die Berechtigung Directory.ReadWrite.All erfordert, und sie verwenden, um der 365stealer-App die delegierte Berechtigung RoleManagement.ReadWrite.Directory zu erteilen?

Um das herauszufinden, verwende ich zunächst die oauth2PermissionGrant API, um die für 365stealer verwendete clientId und resourceId aufzuzählen(Abbildung 27).

Als nächstes habe ich den consentType auf "AllPrincipals" gesetzt(Abbildung 28). Damit entfällt das Erfordernis der Zustimmung des Administrators bei der Erteilung der Berechtigungen.

Warten Sie einen Moment. Die Berechtigung RoleManagement.ReadWrite.Directory wurde erteilt, ist aber nicht in der Liste der konfigurierten Berechtigungen enthalten(Abbildung 29).

Aha! Der harmlose Angreifer ist Eigentümer der 365stealer-App . Ich muss nur mit der rechten Maustaste auf RoleManagement.ReadWrite.Directory klicken und zu den konfigurierten Berechtigungen hinzufügen wählen (Abbildung 30). Auch ohne diesen Schritt sollte die Berechtigung für mich verfügbar sein.

Die Berechtigung ist nun konfiguriert(Abbildung 31).

Jetzt rufe ich einfach den Endpunkt /refresh im HTTP-Server auf, um das Zugriffstoken des Privileged User-Kontos zu aktualisieren und seine Berechtigungen zu ändern(Abbildung 32).

Ein Blick auf den Geltungsbereich des Tokens zeigt, dass die Berechtigung RoleManagement.ReadWrite.Directory hinzugefügt wurde(Abbildung 33).

Mit dieser Berechtigung im Zugriffstoken kann ich nun GET https://graph.microsoft.com/v1.0/directoryRoles aufrufen(Abbildung 34).

Und jetzt kann ich POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments aufrufen, um Harmless Attacker die Rolle Global Admin zuzuweisen(Abbildung 35).

Geschafft! Ein Blick auf die aktiven Zuweisungen des Angreiferkontos bestätigt die Ausweitung der Berechtigungen(Abbildung 36). Mein Versuch, eine versteckte Erlaubnis zu erteilen, wie ich es nenne, war erfolgreich.

Versteckte Bewilligung: Jetzt mit zusätzlicher Täuschung!

Erinnern Sie sich an die Frage nach der Zustimmung, die dem Benutzer in der Anfangsphase des Hidden Consent Grant-Angriffs gestellt wurde? Ich habe mich gefragt, ob ich diese Herausforderung verstecken könnte, um den Angriff noch unauffälliger zu machen. Auf diese Weise würde ein ähnlicher Angriffsablauf entstehen, ohne dass der Benutzer etwas tun muss, indem er eine Zustimmungsanfrage stellt, selbst wenn die App erweiterte Berechtigungen anfordert(Abbildung 37).

Ich habe mit denselben Berechtigungen begonnen, die ich im vorherigen Experiment verwendet habe. Allerdings habe ich der 365stealer-App administrative Berechtigungen erteilt(Abbildung 38). Denken Sie daran, dass Directory.ReadWrite.All es dem Angreifer ermöglicht, dies ohne jegliche Benutzerinteraktion zu tun.

Führen Sie nun den Phishing-Fluss aus und stellen Sie fest, ob der privilegierte Benutzer beim Klicken auf den Link auf der Phishing-Seite eine Zustimmungsanfrage erhält. (Spoiler-Alarm: Sie werden nicht gefragt.)

An diesem Punkt habe ich zwei Punkte bewiesen:

• Das Phishing-Opfer wird nicht aufgefordert, seine Zustimmung zu geben, wenn die erforderlichen Berechtigungen bereits vom Administrator genehmigt wurden.
• Selbst nachdem der Administrator die Zustimmungsanfrage zum Hinzufügen der Berechtigungen für die App genehmigt hat, kann der Angreifer weitere Berechtigungen hinzufügen, indem er die Berechtigungen manuell bearbeitet, ohne dass das Opfer davon weiß.

Verbreitung des Hidden Consent Grant

Ich fragte mich, ob ich alle Apps im Verzeichnis dazu bringen könnte, die Phishing-Links zu bedienen. Ich wusste, dass ich jede App, die wir besaßen, in eine Phishing-App verwandeln konnte, indem ich ihre Umleitungs-URL änderte. Aber was ist mit den Apps, die diese Anforderung nicht erfüllen?

In dem seltenen Fall, dass eine App auch über die Berechtigung Application.ReadWrite.All verfügt, kann der Angreifer eine weitere Umleitungs-URL - den Abhörserver des Angreifers - bearbeiten oder der App hinzufügen. Auf diese Weise wird jede App im Verzeichnis in eine bösartige Entität verwandelt(Abbildung 39).

Mit dem in Abbildung 40 gezeigten Graph API-Aufruf können Sie den Redirect-URI der App ändern(Abbildung 41).

Für diesen Angriffsvektor muss der Angreifer immer noch das Geheimnis der App kennen. Zum Glück für den Angreifer kann er mit Application.ReadWrite.All ein neues Geheimnis zur App hinzufügen(Abbildung 42).

Hinweis: Es scheint eine Diskrepanz zwischen der Dokumentation von Microsoft und meinen eigenen Beobachtungen zu geben. Meine Tests haben ergeben, dass, obwohl Directory.ReadWrite.All erwähnt wird, zusätzliche Berechtigungen erforderlich sein könnten.

Für diesen Proof of Concept hat Semperis ein neues Tool, HiddenConsentGrant, entwickelt und veröffentlicht, das hier verfügbar ist. Mit diesem Tool können Sie einen lauschenden Server einrichten, der auf die Antworten auf das Access Token wartet.

Erkennung und Abhilfemaßnahmen

Woran erkennen Sie einen Angriff mit versteckter Einverständniserklärung?

1. Benutzer von Semperis Directory Services Protector ( DSP) oder Purple Knight können den Sicherheitsindikator Entra tenant is susceptible to Hidden Consent Grant Attack verwenden, um die Möglichkeit eines Angriffs auf den Mandanten zu prüfen und zu melden.
2. Suchen Sie nach verdächtigen Dienstprinzipalen mit hohen Privilegien, wie z.B. Rollenmanagement.ReadWrite.Verzeichnis, Anwendung.LesenSchreiben.Alle, und AppRoleAssignment.ReadWrite.All. Sie können den folgenden API-Aufruf verwenden, um diese Berechtigungen aufzuzählen (Abbildung 43):
   GET graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=consentType eq %27AllPrincipals%27
   

   

3. Ermitteln Sie, ob ein Administrator die Berechtigungen genehmigt hat.
4. Überprüfen Sie, ob die Berechtigungen aktiv genutzt werden und erforderlich sind.
5. Entfernen Sie unnötige Privilegien.
6. Suchen Sie in den Audit-Protokollen nach dem Delegierte Erlaubniserteilung hinzufügen Eintrag mit dem initiierten Akteur Anwendung (Abbildung 44).
   

   

   Die Typ Wert sollte sein Anwendung und die Aktivität Typ sein sollte Delegierte Erlaubniserteilung hinzufügen. Sie können Graph API verwenden, um alle Audit-Protokolle zu erhalten, die den Aktivitätstyp Delegierte Erlaubniserteilung hinzufügen:
   https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=activityDisplayName eq 'Add delegated permission grant'

   Sie können dann nach "user" suchen : null, was bedeutet, dass eine Anwendung die delegierte Rechtevergabe aufgerufen hat(Abbildung 45).

   

7. Überwachen und widerrufen Sie alle nicht autorisierten OAuth Zustimmung gewährt. Der folgende API-Aufruf kann Ihnen dabei helfen:
   GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants/
   Dieser Aufruf liefert alle delegierten Berechtigungen, die im Mandanten erteilt wurden, die Art der Zustimmung und die Entität (Abbildung 46).
   

   

8. Und schließlich sollten Sie vermeiden, Anwendungen die Berechtigungen Directory.ReadWrite.All oder DelegatedPermissionGrant.ReadWrite.All zu erteilen. (Die Berechtigung DelegatedPermissionGrant.ReadWrite.All ermöglicht es einem Angreifer, die gleichen Angriffe zu starten, die ich in diesem Artikel beschreibe). Wann immer möglich, konfigurieren Sie spezifischere Berechtigungen für Ihre Anwendungen.

Hidden Consent Grants aufklären

Dieser Artikel veranschaulicht den Nachweis des Konzepts für mehrere Angriffsflüsse, die die Rolle Directory.ReadWrite.All missbrauchen, um potenziell jede Berechtigung zu erhalten, die ein Angreifer haben möchte. Diese Angriffsflüsse könnten in den Händen eines geschickten Angreifers tödlich sein. Überprüfen und verschärfen Sie jetzt Ihre App-Berechtigungen und schließen Sie diese potenzielle Lücke, bevor Bedrohungsakteure sie ausnutzen können.