Gefährliche API-Berechtigungen, die den Mandanten betreffen

Microsoft macht APIs über Anwendungen in Microsoft Entra ID verfügbar, um Drittanbieter-Anwendungen die Ausführung von Aktionen für Microsoft Entra ID selbst, Microsoft 365 (O365), die Azure-Cloud usw. zu erlauben. „API-Berechtigungen“ schützen den Zugriff auf diese APIs, und nur Dienstprinzipale, die die APIs benötigen, können über diese Berechtigungen verfügen. Die Genehmigung der Berechtigungen wird als „Anwendungsrollenzuweisung“ oder „Einwilligungserteilung“ („consent grant“) bezeichnet.

Bestimmte Berechtigungen für einige Microsoft-APIs (siehe unten) können eine ernste Bedrohung für den gesamten Microsoft Entra-Mandanten darstellen, weil ein Dienstprinzipal mit diesen Berechtigungen über sehr viel Macht verfügt, zugleich jedoch diskreter ist als ein Benutzer mit einer umfassenden Administratorrolle wie z. B. „Globaler Administrator“. Ein Missbrauch dieser Situation kann es einem Angreifer ermöglichen, die Multifaktor-Authentifizierung (MFA) zu umgehen sich dem Zurücksetzen von Benutzerpasswörtern zu widersetzen.

Wenn die Berechtigungen legitim sind, vergrößern sie die Angriffsoberfläche für den Mandanten. Wenn sie nicht legitim sind, kann es sich um einen böswilligen Versuch handeln, Rechte oder die Persistenzmethode auszuweiten.

Es gibt zwei Arten von API-Berechtigungen in Microsoft Entra ID, wie in der Microsoft-Dokumentation Einführung in Berechtigungen und Einwilligung beschrieben:

• Anwendungsberechtigungen: Die Einwilligung wird von Administratoren gegeben, und die Berechtigungen gelten mandantenweit.
• Delegierte Berechtigungen: Die Einwilligung wird von Benutzern oder Administratoren im Namen der gesamten Organisation gegeben. Beachten Sie, dass diese Berechtigungen die Fähigkeit der Anwendung einschränken, Aktionen auf Basis der Rechte des angemeldeten Benutzers durchzuführen (d. h. Schnittpunkt der Berechtigung und der Rechteebene des Benutzers). Wie gefährlich diese delegierten Berechtigungen sind, hängt daher von den tatsächlichen Berechtigungen des Anwendungsbenutzers ab, wie im Artikel Entwickeln einer Strategie für delegierte Berechtigungen beschrieben. Beispiel: Wenn ein normaler Benutzer die Berechtigung „Group.ReadWrite.All“ delegiert, erlaubt er damit der Anwendung, nur die Gruppen zu ändern, die der Benutzer bearbeiten kann, und nicht alle Gruppen.

Dieser Indicator of Exposure untersucht beide Arten von Berechtigungen. Er gibt nur Auskunft über Dienstprinzipale, da API-Berechtigungen nur für Dienstprinzipale gelten können, nicht jedoch für Benutzer.

Dieser Indicator of Exposure konzentriert sich außerdem auf Berechtigungen, die Zugriff auf die Microsoft Graph API und die ältere Azure AD Graph API erlauben. Insbesondere die folgenden gefährlichen Berechtigungen können ein Sicherheitsrisiko darstellen:

• RoleManagement.ReadWrite.Directory: Erlaubt es Angreifern, sich selbst auf die Rolle „Globaler Administrator“ hochzustufen.
• AppRoleAssignment.ReadWrite.All: Erlaubt es Angreifern, sich selbst die Berechtigung RoleManagement.ReadWrite.Directory zu erteilen (siehe oben).

Legitime Anwendungen mit diesen gefährlichen Berechtigungen fordern Berechtigungen an, die zu umfassend sein können. Dies kann auch ein Hinweis auf einen als „illegale Einwilligungserteilung“ bezeichneten Phishing-Angriff sein, bei dem Angreifer erfolgreich die Einwilligung eines Administrators einholen.

Ermitteln Sie als Erstes, ob der gemeldete Dienstprinzipal mit der Berechtigung legitim ist. Denken Sie daran, dass es technisch möglich ist, den Anzeigenamen in einem Phishing-Angriff zu spoofen. Wenn der Dienstprinzipal zu einem bekannten Softwareanbieter zu gehören scheint, bitten Sie diesen zu bestätigen, dass die gemeldete Anwendungs-ID wirklich ihm gehört. Wenn der Dienstprinzipal nicht legitim ist und einen bekannten Anwendungsnamen spooft, sollten Sie eine forensische Analyse durchführen.

• Wenn der Dienstprinzipal legitim ist, ermitteln Sie seinen Besitzer und seine Rolle, um festzustellen, ob er diese gefährlichen Berechtigungen tatsächlich benötigt. Im Fall einer internen Anwendung können Sie abhängig von ihren Funktionen die Berechtigungen unter Anwendung der bewährten Methode des Prinzips der geringsten Berechtigungen verringern, wie im Abschnitt „Zustimmung und Autorisierung“ der Dokumentation zur Microsoft Graph API beschrieben, in dem insbesondere die erforderlichen Mindestberechtigungen für die einzelnen APIs erläutert werden. Im Fall einer Drittanbieter-Anwendung fordern Sie den Anbieter auf, die erforderlichen Berechtigungen herabzusetzen oder zumindest zu dokumentieren, warum bestimmte Berechtigungen benötigt werden.
• Standardmäßig können alle Benutzer Berechtigungen an jede beliebige Anwendung delegieren, was bedeutet, dass sie sensible Sicherheitsentscheidungen treffen können. Microsoft Entra ID bietet Optionen, die Sie aktivieren können, um die Benutzereinwilligung zu konfigurieren. Wenn Sie Einschränkungen aktivieren, müssen Microsoft Entra-Administratoren mit bestimmten Rollen die Einwilligung zu Anwendungen verwalten und Einwilligungsanforderungen beurteilen. Informieren Sie sich auch über das Überprüfen von Anforderungen zur Administratoreinwilligung.
• Anwendungsberechtigungen erfordern immer die Einwilligung eines Administrators. Schulen Sie diese Administratoren darin, verdächtige Anwendungen und sensible Berechtigungen, insbesondere mandantenweite Anwendungsberechtigungen, sowie delegierte Berechtigungen von privilegierten oder sensiblen Benutzern zu erkennen. Dies muss im Rahmen einer umfassenden Anwendungs-Governance-Initiative erfolgen.
• Entfernen Sie eine Berechtigung, wenn Sie sie für nicht legitim halten. Tenable empfiehlt, zunächst Beweise zu speichern, wenn Sie eine umfassendere forensische Untersuchung planen. Das Microsoft Entra-Portal bietet eine dedizierte Funktion, um Berechtigungen zu überprüfen, die Unternehmensanwendungen erteilt wurden.

Microsoft hat außerdem zwei Leitfäden veröffentlicht, in denen die Durchführung einer Untersuchung der Zuweisung der App-Einwilligung und die Vorgehensweise zum Erkennen und Korrigieren illegaler Einwilligungserteilungen beschrieben werden.

Name: Gefährliche API-Berechtigungen, die den Mandanten betreffen

Codename: DANGEROUS-API-PERMISSIONS-AFFECTING-THE-TENANT

Schweregrad: High