mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-07 19:00:49 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
## 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**.
|
||||
**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
|
||||
|
||||
@@ -12,7 +12,7 @@ Per impostazione predefinita, qualsiasi **utente può dare consenso alle app**,
|
||||
|
||||
<figure><img src="../../../images/image.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Se gli utenti non possono acconsentire, gli **amministratori** come `GA`, `Application Administrator` o `Cloud Application` `Administrator` possono **consentire le applicazioni** che gli utenti potranno utilizzare.
|
||||
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.
|
||||
|
||||
@@ -20,12 +20,12 @@ 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 del phishing sia **in grado di accettare app OAuth da tenant esterni**.
|
||||
- Se l'utente vittima del phishing è un amministratore che può **consentire qualsiasi app con qualsiasi permesso**, l'applicazione potrebbe anche **richiedere permessi privilegiati**.
|
||||
- **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 amministratore per concederli**, perché un utente normale non può dare alcun permesso alle app OAuth, ecco perché devi **phishing solo quegli utenti** (magari più avanti parleremo di quali ruoli/permessi concedono questo privilegio).
|
||||
- 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
|
||||
|
||||
@@ -34,7 +34,7 @@ Nota che devi eseguire questo comando da un utente all'interno del tenant, non p
|
||||
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 alle 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.
|
||||
- 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:
|
||||
@@ -61,7 +61,7 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d60
|
||||
|
||||
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 i codici di autorizzazione e richiedere i token di accesso.
|
||||
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.
|
||||
@@ -73,7 +73,7 @@ L'attacco coinvolge diversi passaggi mirati a una azienda generica. Ecco come po
|
||||
|
||||
<figure><img src="../../../images/image (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
2. Quindi creare un segreto per l'applicazione:
|
||||
2. Quindi creare un segreto dell'applicazione:
|
||||
|
||||
<figure><img src="../../../images/image (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -86,8 +86,8 @@ L'attacco coinvolge diversi passaggi mirati a una azienda generica. Ecco come po
|
||||
# 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**
|
||||
1. In questo caso `http://localhost:8000`
|
||||
5. **Invia l'URL alla vittima**
|
||||
1. In questo caso `http://localhost:8000`
|
||||
6. **Le vittime** devono **accettare il prompt:**
|
||||
|
||||
<figure><img src="../../../images/image (4).png" alt=""><figcaption></figcaption></figure>
|
||||
@@ -123,7 +123,14 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \
|
||||
|
||||
### 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 queste azioni.
|
||||
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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user