mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
Translator
@@ -58,9 +58,9 @@ Entra ID è un servizio di **gestione dell'identità e degli accessi basato su c
|
||||
|
||||
### Servizi di Dominio Entra (precedentemente Azure AD DS)
|
||||
|
||||
I Servizi di Dominio Entra estendono le capacità di Entra ID offrendo **servizi di dominio gestiti compatibili con ambienti tradizionali di Windows Active Directory**. Supporta protocolli legacy come LDAP, Kerberos e NTLM, consentendo alle organizzazioni di migrare o eseguire applicazioni più vecchie nel cloud senza dover distribuire controller di dominio on-premises. Questo servizio supporta anche le Group Policy per la gestione centralizzata, rendendolo adatto a scenari in cui carichi di lavoro legacy o basati su AD devono coesistere con ambienti cloud moderni.
|
||||
I Servizi di Dominio Entra estendono le capacità di Entra ID offrendo **servizi di dominio gestiti compatibili con ambienti tradizionali di Windows Active Directory**. Supporta protocolli legacy come LDAP, Kerberos e NTLM, consentendo alle organizzazioni di migrare o eseguire applicazioni più vecchie nel cloud senza dover implementare controller di dominio on-premises. Questo servizio supporta anche le Group Policy per la gestione centralizzata, rendendolo adatto a scenari in cui carichi di lavoro legacy o basati su AD devono coesistere con ambienti cloud moderni.
|
||||
|
||||
## Principali Entra ID
|
||||
## Principali di Entra ID
|
||||
|
||||
### Utenti
|
||||
|
||||
@@ -96,7 +96,7 @@ Puoi controllarli in [https://learn.microsoft.com/en-us/entra/fundamentals/users
|
||||
- Registrare Applicazioni: Predefinito **Sì**
|
||||
- Limitare gli utenti non amministratori dalla creazione di tenant: Predefinito **No**
|
||||
- Creare gruppi di sicurezza: Predefinito **Sì**
|
||||
- Limitare l'accesso al portale di amministrazione di Microsoft Entra: Predefinito **No**
|
||||
- Limitare l'accesso al portale di amministrazione Microsoft Entra: Predefinito **No**
|
||||
- Questo non limita l'accesso API al portale (solo web)
|
||||
- Consentire agli utenti di collegare l'account di lavoro o scolastico con LinkedIn: Predefinito **Sì**
|
||||
- Mostra mantenere l'utente connesso: Predefinito **Sì**
|
||||
@@ -108,11 +108,11 @@ Puoi controllarli in [https://learn.microsoft.com/en-us/entra/fundamentals/users
|
||||
- **Gli utenti ospiti hanno accesso limitato alle proprietà e alle appartenenze degli oggetti di directory (predefinito)**. Questo limita l'accesso degli ospiti solo al proprio profilo utente per impostazione predefinita. L'accesso ad altre informazioni sugli utenti e sui gruppi non è più consentito.
|
||||
- **L'accesso degli utenti ospiti è limitato alle proprietà e alle appartenenze dei propri oggetti di directory** è la più restrittiva.
|
||||
- **Opzioni di invito per gli ospiti**:
|
||||
- **Chiunque nell'organizzazione può invitare utenti ospiti, compresi ospiti e non amministratori (la più inclusiva) - Predefinito**
|
||||
- **Gli utenti membri e gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti, compresi gli ospiti con permessi di membro**
|
||||
- **Chiunque nell'organizzazione può invitare utenti ospiti, inclusi ospiti e non amministratori (la più inclusiva) - Predefinito**
|
||||
- **Gli utenti membri e gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti, inclusi ospiti con permessi di membro**
|
||||
- **Solo gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti**
|
||||
- **Nessuno nell'organizzazione può invitare utenti ospiti, compresi gli amministratori (la più restrittiva)**
|
||||
- **Uscita di utenti esterni**: Predefinito **Vero**
|
||||
- **Nessuno nell'organizzazione può invitare utenti ospiti, inclusi gli amministratori (la più restrittiva)**
|
||||
- **Uscita degli utenti esterni**: Predefinito **Vero**
|
||||
- Consentire agli utenti esterni di lasciare l'organizzazione
|
||||
|
||||
> [!TIP]
|
||||
@@ -149,7 +149,7 @@ Una **Registrazione App** è una configurazione che consente a un'applicazione d
|
||||
1. **ID Applicazione (Client ID):** Un identificatore unico per la tua app in Azure AD.
|
||||
2. **URI di Reindirizzamento:** URL dove Azure AD invia le risposte di autenticazione.
|
||||
3. **Certificati, Segreti e Credenziali Federate:** È possibile generare un segreto o un certificato per accedere come il principio di servizio dell'applicazione, o per concedere accesso federato ad essa (ad es. Github Actions).
|
||||
1. Se viene generato un **certificato** o un **segreto**, è possibile per una persona **accedere come il principio di servizio** con strumenti CLI conoscendo l'**ID dell'applicazione**, il **segreto** o il **certificato** e il **tenant** (dominio o ID).
|
||||
1. Se viene generato un **certificato** o un **segreto**, è possibile che una persona **acceda come il principio di servizio** con strumenti CLI conoscendo l'**ID applicazione**, il **segreto** o il **certificato** e il **tenant** (dominio o ID).
|
||||
4. **Permessi API:** Specifica quali risorse o API l'app può accedere.
|
||||
5. **Impostazioni di Autenticazione:** Definisce i flussi di autenticazione supportati dall'app (ad es., OAuth2, OpenID Connect).
|
||||
6. **Principio di Servizio**: Un principio di servizio viene creato quando viene creata un'App (se fatto dalla console web) o quando viene installata in un nuovo tenant.
|
||||
@@ -161,21 +161,21 @@ Una **Registrazione App** è una configurazione che consente a un'applicazione d
|
||||
|
||||
- **Non consentire il consenso dell'utente**
|
||||
- Sarà richiesto un amministratore per tutte le app.
|
||||
- **Consentire il consenso dell'utente per le app di editori verificati, per permessi selezionati (Consigliato)**
|
||||
- Tutti gli utenti possono dare consenso per permessi classificati come "basso impatto", per app di editori verificati o app registrate in questa organizzazione.
|
||||
- **Consentire il consenso dell'utente per app di editori verificati, app interne e app che richiedono solo permessi selezionati (Consigliato)**
|
||||
- Tutti gli utenti possono consentire app che richiedono solo permessi classificati come "basso impatto", app di editori verificati e app registrate nel tenant.
|
||||
- **Permessi a basso impatto predefiniti** (anche se è necessario accettare per aggiungerli come bassi):
|
||||
- User.Read - accedi e leggi il profilo utente
|
||||
- offline_access - mantieni l'accesso ai dati a cui gli utenti hanno dato accesso
|
||||
- openid - accedi gli utenti
|
||||
- profile - visualizza il profilo di base dell'utente
|
||||
- email - visualizza l'indirizzo email dell'utente
|
||||
- **Consentire il consenso dell'utente per le app (Predefinito)**
|
||||
- Tutti gli utenti possono dare consenso per qualsiasi app per accedere ai dati dell'organizzazione.
|
||||
- **Consentire il consenso dell'utente per app (Predefinito)**
|
||||
- Tutti gli utenti possono consentire a qualsiasi app di accedere ai dati dell'organizzazione.
|
||||
|
||||
**Richieste di consenso dell'amministratore**: Predefinito **No**
|
||||
|
||||
- Gli utenti possono richiedere il consenso dell'amministratore per app a cui non possono dare consenso
|
||||
- Se **Sì**: È possibile indicare Utenti, Gruppi e Ruoli che possono dare consenso alle richieste
|
||||
- Gli utenti possono richiedere il consenso dell'amministratore per app a cui non possono consentire
|
||||
- Se **Sì**: È possibile indicare Utenti, Gruppi e Ruoli che possono consentire richieste
|
||||
- Configura anche se gli utenti riceveranno notifiche via email e promemoria di scadenza
|
||||
|
||||
### **Identità Gestite (Metadati)**
|
||||
@@ -184,16 +184,16 @@ Le identità gestite in Azure Active Directory offrono una soluzione per **gesti
|
||||
|
||||
Ci sono due tipi di identità gestite:
|
||||
|
||||
- **Assegnate al sistema**. Alcuni servizi Azure consentono di **abilitare un'identità gestita direttamente su un'istanza di servizio**. Quando abiliti un'identità gestita assegnata al sistema, viene creato un **principio di servizio** nel tenant Entra ID fidato dalla sottoscrizione in cui si trova la risorsa. Quando la **risorsa** viene **eliminata**, Azure elimina automaticamente **l'identità** per te.
|
||||
- **Assegnate al sistema**. Alcuni servizi Azure ti consentono di **abilitare un'identità gestita direttamente su un'istanza di servizio**. Quando abiliti un'identità gestita assegnata al sistema, viene creato un **principio di servizio** nel tenant Entra ID fidato dalla sottoscrizione in cui si trova la risorsa. Quando la **risorsa** viene **eliminata**, Azure elimina automaticamente **l'identità** per te.
|
||||
- **Assegnate dall'utente**. È anche possibile per gli utenti generare identità gestite. Queste vengono create all'interno di un gruppo di risorse all'interno di una sottoscrizione e verrà creato un principio di servizio nel tenant EntraID fidato dalla sottoscrizione. Poi, puoi assegnare l'identità gestita a una o **più istanze** di un servizio Azure (risorse multiple). Per le identità gestite assegnate dall'utente, **l'identità è gestita separatamente dalle risorse che la utilizzano**.
|
||||
|
||||
Le identità gestite **non generano credenziali eterne** (come password o certificati) per accedere come il principio di servizio ad esse collegato.
|
||||
Le Identità Gestite **non generano credenziali eterne** (come password o certificati) per accedere come il principio di servizio ad essa associato.
|
||||
|
||||
### Applicazioni Aziendali
|
||||
|
||||
È solo un **tabella in Azure per filtrare i principi di servizio** e controllare le applicazioni che sono state assegnate.
|
||||
È solo una **tabella in Azure per filtrare i principi di servizio** e controllare le applicazioni che sono state assegnate.
|
||||
|
||||
**Non è un altro tipo di “applicazione”,** non c'è alcun oggetto in Azure che sia un “Applicazione Aziendale”, è solo un'astrazione per controllare i Principi di servizio, le Registrazioni App e le identità gestite.
|
||||
**Non è un altro tipo di “applicazione”**, non c'è alcun oggetto in Azure che sia un “Applicazione Aziendale”, è solo un'astrazione per controllare i Principi di servizio, le Registrazioni App e le identità gestite.
|
||||
|
||||
### Unità Amministrative
|
||||
|
||||
@@ -212,18 +212,18 @@ Esempio:
|
||||
- Concedi il ruolo di "Amministratore Utente" al personale IT regionale, limitato all'AU della loro regione.
|
||||
- Risultato: Gli amministratori IT regionali possono gestire gli account utente all'interno della loro regione senza influenzare altre regioni.
|
||||
|
||||
### Ruoli e Permessi Entra ID
|
||||
### Ruoli e Permessi di Entra ID
|
||||
|
||||
- Per gestire Entra ID ci sono alcuni **ruoli predefiniti** che possono essere assegnati ai principi Entra ID per gestire Entra ID
|
||||
- Per gestire Entra ID ci sono alcuni **ruoli predefiniti** che possono essere assegnati ai principi di Entra ID per gestire Entra ID
|
||||
- Controlla i ruoli in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
|
||||
- I ruoli contrassegnati come **`PRIVILEGIATI`** da EntraID dovrebbero essere assegnati con cautela perché, come spiega Microsoft [nei documenti](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): Le assegnazioni di ruolo privilegiato possono portare a un'elevazione dei privilegi se non utilizzate in modo sicuro e previsto.
|
||||
- Il ruolo più privilegiato è **Amministratore Globale**
|
||||
- I ruoli raggruppano **permessi granulari** e possono essere trovati nelle loro descrizioni.
|
||||
- È possibile **creare ruoli personalizzati** con i permessi desiderati. Anche se per qualche motivo non tutti i permessi granulari sono disponibili per gli amministratori per creare ruoli personalizzati.
|
||||
- I ruoli in Entra ID sono completamente **indipendenti** dai ruoli in Azure. L'unica relazione è che i principi con il ruolo di **Amministratore Globale** in Entra ID possono elevare al ruolo di **Amministratore Accesso Utente** in Azure.
|
||||
- Non è **possibile utilizzare caratteri jolly** nei ruoli Entra ID.
|
||||
- I ruoli in Entra ID sono completamente **indipendenti** dai ruoli in Azure. L'unica relazione è che i principi con il ruolo **Amministratore Globale** in Entra ID possono elevare al ruolo di **Amministratore Accesso Utente** in Azure.
|
||||
- Non è **possibile utilizzare caratteri jolly** nei ruoli di Entra ID.
|
||||
|
||||
## Ruoli e Permessi Azure
|
||||
## Ruoli e Permessi di Azure
|
||||
|
||||
- **Ruoli** sono **assegnati** ai **principi** su un **ambito**: `principle -[HAS ROLE]->(scope)`
|
||||
- **Ruoli** assegnati a **gruppi** sono **ereditati** da tutti i **membri** del gruppo.
|
||||
@@ -310,13 +310,13 @@ Secondo **[la documentazione](https://learn.microsoft.com/en-us/azure/role-based
|
||||
|
||||
### Assegnazioni di Negazione
|
||||
|
||||
Proprio come le assegnazioni di ruolo, le **assegnazioni di negazione** vengono utilizzate per **controllare l'accesso alle risorse di Azure**. Tuttavia, le **assegnazioni di negazione** vengono utilizzate per **negare esplicitamente l'accesso** a una risorsa, anche se a un utente è stato concesso l'accesso tramite un'assegnazione di ruolo. Le **assegnazioni di negazione** hanno la precedenza sulle **assegnazioni di ruolo**, il che significa che se a un utente è concesso l'accesso tramite un'assegnazione di ruolo ma gli viene anche negato esplicitamente l'accesso tramite un'assegnazione di negazione, l'assegnazione di negazione avrà la precedenza.
|
||||
Proprio come le assegnazioni di ruolo, le **assegnazioni di negazione** sono utilizzate per **controllare l'accesso alle risorse di Azure**. Tuttavia, le **assegnazioni di negazione** sono utilizzate per **negare esplicitamente l'accesso** a una risorsa, anche se a un utente è stato concesso l'accesso tramite un'assegnazione di ruolo. Le **assegnazioni di negazione** hanno la precedenza sulle **assegnazioni di ruolo**, il che significa che se a un utente è concesso l'accesso tramite un'assegnazione di ruolo ma viene anche esplicitamente negato l'accesso tramite un'assegnazione di negazione, l'assegnazione di negazione avrà la precedenza.
|
||||
|
||||
Proprio come le assegnazioni di ruolo, le **assegnazioni di negazione** vengono applicate su un certo ambito che indica i principali interessati e i permessi che vengono negati. Inoltre, nel caso delle assegnazioni di negazione, è possibile **prevenire che la negazione venga ereditata** dalle risorse figlie.
|
||||
|
||||
### Politiche di Azure
|
||||
|
||||
Le **Politiche di Azure** sono regole che aiutano le organizzazioni a garantire che le loro risorse soddisfino standard specifici e requisiti di conformità. Consentono di **applicare o auditare impostazioni sulle risorse in Azure**. Ad esempio, puoi impedire la creazione di macchine virtuali in una regione non autorizzata o garantire che tutte le risorse abbiano tag specifici per il tracciamento.
|
||||
Le **Politiche di Azure** sono regole che aiutano le organizzazioni a garantire che le loro risorse soddisfino standard specifici e requisiti di conformità. Consentono di **applicare o auditare le impostazioni sulle risorse in Azure**. Ad esempio, puoi impedire la creazione di macchine virtuali in una regione non autorizzata o garantire che tutte le risorse abbiano tag specifici per il tracciamento.
|
||||
|
||||
Le Politiche di Azure sono **proattive**: possono impedire la creazione o la modifica di risorse non conformi. Sono anche **reattive**, consentendo di trovare e correggere risorse non conformi esistenti.
|
||||
|
||||
@@ -325,7 +325,7 @@ Le Politiche di Azure sono **proattive**: possono impedire la creazione o la mod
|
||||
1. **Definizione della Politica**: Una regola, scritta in JSON, che specifica cosa è consentito o richiesto.
|
||||
2. **Assegnazione della Politica**: L'applicazione di una politica a un ambito specifico (ad es., sottoscrizione, gruppo di risorse).
|
||||
3. **Iniziative**: Una raccolta di politiche raggruppate per un'applicazione più ampia.
|
||||
4. **Effetto**: Specifica cosa succede quando la politica viene attivata (ad es., "Negare", "Audit" o "Aggiungere").
|
||||
4. **Effetto**: Specifica cosa succede quando la politica viene attivata (ad es., "Negare", "Audit", o "Aggiungere").
|
||||
|
||||
**Alcuni esempi:**
|
||||
|
||||
@@ -338,7 +338,7 @@ Le Politiche di Azure sono **proattive**: possono impedire la creazione o la mod
|
||||
|
||||
Nota che le Politiche di Azure possono essere collegate a qualsiasi livello della gerarchia di Azure, ma sono **comunemente utilizzate nel gruppo di gestione radice** o in altri gruppi di gestione.
|
||||
|
||||
Esempio di json della politica di Azure:
|
||||
Esempio di json di politica di Azure:
|
||||
```json
|
||||
{
|
||||
"policyRule": {
|
||||
@@ -356,7 +356,7 @@ Esempio di json della politica di Azure:
|
||||
"mode": "All"
|
||||
}
|
||||
```
|
||||
### Ereditarietà dei Permessi
|
||||
### Ereditarietà dei permessi
|
||||
|
||||
In Azure **i permessi possono essere assegnati a qualsiasi parte della gerarchia**. Questo include gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse individuali. I permessi sono **ereditati** dalle **risorse** contenute nell'entità a cui sono stati assegnati.
|
||||
|
||||
@@ -366,10 +366,10 @@ Questa struttura gerarchica consente una gestione efficiente e scalabile dei per
|
||||
|
||||
### Azure RBAC vs ABAC
|
||||
|
||||
**RBAC** (controllo accessi basato su ruoli) è ciò che abbiamo già visto nelle sezioni precedenti: **Assegnare un ruolo a un principale per concedergli accesso** a una risorsa.\
|
||||
**RBAC** (controllo degli accessi basato sui ruoli) è ciò che abbiamo già visto nelle sezioni precedenti: **Assegnare un ruolo a un principale per concedergli accesso** a una risorsa.\
|
||||
Tuttavia, in alcuni casi potresti voler fornire una **gestione degli accessi più dettagliata** o **semplificare** la gestione di **centinaia** di **assegnazioni** di ruolo.
|
||||
|
||||
Azure **ABAC** (controllo accessi basato su attributi) si basa su Azure RBAC aggiungendo **condizioni di assegnazione del ruolo basate su attributi** nel contesto di azioni specifiche. Una _condizione di assegnazione del ruolo_ è un **controllo aggiuntivo che puoi opzionalmente aggiungere alla tua assegnazione di ruolo** per fornire un controllo degli accessi più dettagliato. Una condizione filtra i permessi concessi come parte della definizione del ruolo e dell'assegnazione del ruolo. Ad esempio, puoi **aggiungere una condizione che richiede a un oggetto di avere un tag specifico per leggere l'oggetto**.\
|
||||
Azure **ABAC** (controllo degli accessi basato sugli attributi) si basa su Azure RBAC aggiungendo **condizioni di assegnazione del ruolo basate su attributi** nel contesto di azioni specifiche. Una _condizione di assegnazione del ruolo_ è un **controllo aggiuntivo che puoi opzionalmente aggiungere alla tua assegnazione di ruolo** per fornire un controllo degli accessi più dettagliato. Una condizione filtra i permessi concessi come parte della definizione del ruolo e dell'assegnazione del ruolo. Ad esempio, puoi **aggiungere una condizione che richiede a un oggetto di avere un tag specifico per leggere l'oggetto**.\
|
||||
Non **puoi** esplicitamente **negare** **l'accesso** a risorse specifiche **utilizzando condizioni**.
|
||||
|
||||
## Riferimenti
|
||||
|
||||
@@ -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