Az - OAuth Apps Phishing

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Phishing aplikacji OAuth

Aplikacje Azure są konfigurowane z uprawnieniami, które będą mogły być używane, gdy użytkownik wyrazi zgodę na aplikację (takimi jak enumerowanie katalogu, dostęp do plików lub wykonywanie innych działań). Należy pamiętać, że aplikacja będzie działać w imieniu użytkownika, więc nawet jeśli aplikacja mogłaby prosić o uprawnienia administracyjne, jeśli użytkownik, który wyraża zgodę, nie ma tych uprawnień, aplikacja nie będzie mogła wykonywać działań administracyjnych.

Uprawnienia zgody aplikacji

Domyślnie każdy użytkownik może wyrazić zgodę na aplikacje, chociaż można to skonfigurować tak, aby użytkownicy mogli wyrażać zgodę tylko na aplikacje od zweryfikowanych wydawców dla wybranych uprawnień lub nawet usunąć uprawnienie dla użytkowników do wyrażania zgody na aplikacje.

Jeśli użytkownicy nie mogą wyrażać zgody, administratorzy tacy jak GA, Administrator aplikacji lub Administrator aplikacji w chmurze mogą wyrażać zgodę na aplikacje, z których użytkownicy będą mogli korzystać.

Co więcej, jeśli użytkownicy mogą wyrażać zgodę tylko na aplikacje z użyciem niskiego ryzyka uprawnień, te uprawnienia to domyślnie openid, profil, email, User.Read i offline_access, chociaż możliwe jest dodanie więcej do tej listy.

A jeśli mogą wyrażać zgodę na wszystkie aplikacje, mogą wyrażać zgodę na wszystkie aplikacje.

2 typy ataków

  • Nieautoryzowany: Z zewnętrznego konta utwórz aplikację z niskim ryzykiem uprawnień User.Read i User.ReadBasic.All, na przykład, phishinguj użytkownika, a będziesz mógł uzyskać dostęp do informacji katalogowych.
  • To wymaga, aby phished użytkownik był w stanie zaakceptować aplikacje OAuth z zewnętrznego najemcy.
  • Jeśli phished użytkownik jest jakimś administratorem, który może wyrażać zgodę na każdą aplikację z dowolnymi uprawnieniami, aplikacja może również żądać uprawnień uprzywilejowanych.
  • Autoryzowany: Po skompromitowaniu podmiotu z wystarczającymi uprawnieniami, utwórz aplikację wewnątrz konta i phishinguj jakiegoś uprzywilejowanego użytkownika, który może zaakceptować 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 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).

Użytkownicy mogą wyrażać zgodę

Należy pamiętać, że musisz wykonać to polecenie z konta użytkownika wewnątrz najemcy, nie możesz znaleźć tej konfiguracji najemcy z zewnętrznego. Następujące cli mogą pomóc Ci zrozumieć uprawnienia użytkowników:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
  • Użytkownicy mogą wyrażać zgodę na wszystkie aplikacje: Jeśli w permissionGrantPoliciesAssigned znajdziesz: ManagePermissionGrantsForSelf.microsoft-user-default-legacy, to użytkownicy mogą zaakceptować każdą aplikację.
  • Użytkownicy mogą wyrażać zgodę na aplikacje od zweryfikowanych wydawców lub twojej organizacji, ale tylko na uprawnienia, które wybierzesz: Jeśli w permissionGrantPoliciesAssigned znajdziesz: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team, to użytkownicy mogą zaakceptować każdą aplikację.
  • Wyłącz zgodę użytkownika: Jeśli w permissionGrantPoliciesAssigned znajdziesz tylko: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat i ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team, to użytkownicy nie mogą wyrażać zgody na żadne.

Możliwe jest znalezienie znaczenia każdej z komentowanych polityk w:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"

Administratorzy aplikacji

Sprawdź użytkowników, którzy są uważani za administratorów aplikacji (mogą akceptować nowe aplikacje):

# Get list of roles
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles"

# Get Global Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"

# Get Application Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"

# Get Cloud Applications Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"

Przegląd Przepływu Ataku

Atak składa się z kilku kroków, które mają na celu zaatakowanie ogólnej firmy. Oto jak może się to rozwinąć:

  1. Rejestracja Domeny i Hosting Aplikacji: Atakujący rejestruje domenę przypominającą zaufaną stronę, na przykład “safedomainlogin.com”. Pod tą domeną tworzony jest subdomena (np. “companyname.safedomainlogin.com”), aby hostować aplikację zaprojektowaną do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.
  2. Rejestracja Aplikacji w Azure AD: Atakujący następnie rejestruje aplikację wielo-tenantową w swoim dzierżawcy Azure AD, nadając jej nazwę odpowiadającą docelowej firmie, aby wyglądała na legalną. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.
  3. Ustawienie Uprawnień: Atakujący 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ą atakującemu na wyciąganie wrażliwych informacji w imieniu użytkownika.
  4. Dystrybucja Złośliwych Linków: Atakujący tworzy link zawierający identyfikator klienta złośliwej aplikacji i dzieli się nim z docelowymi użytkownikami, oszukując ich, aby przyznali zgodę.

Przykład Ataku

  1. Zarejestruj nową aplikację. Może być tylko dla bieżącego katalogu, jeśli używasz użytkownika z zaatakowanego katalogu, lub dla dowolnego katalogu, jeśli jest to atak zewnętrzny (jak na poniższym obrazku).
  2. Ustaw również URI przekierowania na oczekiwaną stronę, na której chcesz otrzymać kod do uzyskania tokenów (http://localhost:8000/callback domyślnie).
  1. Następnie utwórz sekret aplikacji:
  1. Wybierz uprawnienia API (np. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)
  1. Wykonaj stronę internetową (azure_oauth_phishing_example), która prosi o uprawnienia:
# From https://github.com/carlospolop/azure_oauth_phishing_example
python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client-id <client-id> --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read"
  1. Wyślij URL do ofiary
  2. W tym przypadku http://localhost:8000
  3. Ofiary muszą zaakceptować komunikat:
  1. Użyj tokena dostępu, aby uzyskać żądane uprawnienia:
export ACCESS_TOKEN=<ACCESS_TOKEN>

# List drive files
curl -X GET \
https://graph.microsoft.com/v1.0/me/drive/root/children \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List eails
curl -X GET \
https://graph.microsoft.com/v1.0/me/messages \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List notes
curl -X GET \
https://graph.microsoft.com/v1.0/me/onenote/notebooks \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

Inne narzędzia

Post-eksploatacja

Phishing po eksploatacji

W zależności od żądanych uprawnień możesz być w stanie uzyskać dostęp do różnych danych najemcy (lista użytkowników, grup… lub nawet modyfikować ustawienia) oraz informacji o użytkowniku (pliki, notatki, e-maile…). Następnie możesz wykorzystać te uprawnienia do wykonania tych działań.

Administrator aplikacji Entra ID

Jeśli udało ci się w jakiś sposób skompromitować główny identyfikator Entra ID, który może zarządzać aplikacjami w Entra ID, a są aplikacje używane przez użytkowników najemcy. Administrator mógłby zmodyfikować uprawnienia, o które prosi aplikacja, i dodać nowy dozwolony adres przekierowania, aby ukraść tokeny.

  • Zauważ, że możliwe jest dodanie URI przekierowania (nie ma potrzeby usuwania prawdziwego) i następnie wysłanie linku HTTP z użyciem URI przekierowania atakującego, aby gdy użytkownik kliknie link, uwierzytelnienie odbywało się automatycznie, a atakujący otrzymuje token.
  • Możliwe jest również zmienienie uprawnień, o które prosi aplikacja, aby uzyskać więcej uprawnień od użytkowników, ale w takim przypadku użytkownik będzie musiał ponownie zaakceptować monit (nawet jeśli był już zalogowany).
  • Aby przeprowadzić ten atak, atakujący NIE MUSI kontrolować kodu aplikacji, ponieważ mógłby po prostu wysłać link do logowania w aplikacji do użytkownika z nowym URL w parametrze redirect_uri.

Aplikacja po eksploatacji

Sprawdź sekcje Aplikacje i Główne Identyfikatory Usług na stronie:

Az - EntraID Privesc

Odniesienia

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks