Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID to platforma zarządzania tożsamością i dostępem (IAM) w chmurze firmy Microsoft, stanowiąca podstawowy system uwierzytelniania i autoryzacji dla usług takich jak Microsoft 365 i Azure Resource Manager. Azure AD wdraża ramy autoryzacji OAuth 2.0 oraz protokół uwierzytelniania OpenID Connect (OIDC) do zarządzania dostępem do zasobów.
Kluczowi Uczestnicy w OAuth 2.0:
Serwer Zasobów (RS): Chroni zasoby należące do właściciela zasobów.
Właściciel Zasobów (RO): Zazwyczaj użytkownik końcowy, który posiada chronione zasoby.
Aplikacja Klienta (CA): Aplikacja starająca się o dostęp do zasobów w imieniu właściciela zasobów.
Serwer Autoryzacji (AS): Wydaje tokeny dostępu aplikacjom klienckim po ich uwierzytelnieniu i autoryzacji.
Zakresy i Zgoda:
Zakresy: Granularne uprawnienia zdefiniowane na serwerze zasobów, które określają poziomy dostępu.
Zgoda: Proces, w którym właściciel zasobów przyznaje aplikacji klienckiej pozwolenie na dostęp do zasobów z określonymi zakresami.
Integracja z Microsoft 365:
Microsoft 365 wykorzystuje Azure AD do IAM i składa się z wielu aplikacji OAuth "pierwszej strony".
Aplikacje te są głęboko zintegrowane i często mają wzajemne relacje serwisowe.
Aby uprościć doświadczenia użytkowników i utrzymać funkcjonalność, Microsoft przyznaje "domyślną zgodę" lub "wstępną zgodę" tym aplikacjom pierwszej strony.
Domyślna Zgoda: Niektóre aplikacje są automatycznie przyznawane dostęp do określonych zakresów bez wyraźnej zgody użytkownika lub administratora.
Te wstępnie wyrażone zgody są zazwyczaj ukryte zarówno przed użytkownikami, jak i administratorami, co sprawia, że są mniej widoczne w standardowych interfejsach zarządzania.
Typy Aplikacji Klientów:
Poufne Klienty:
Posiadają własne poświadczenia (np. hasła lub certyfikaty).
Mogą bezpiecznie uwierzytelniać się na serwerze autoryzacji.
Publiczne Klienty:
Nie mają unikalnych poświadczeń.
Nie mogą bezpiecznie uwierzytelniać się na serwerze autoryzacji.
Implikacja Bezpieczeństwa: Atakujący może podszyć się pod publiczną aplikację kliencką podczas żądania tokenów, ponieważ nie ma mechanizmu, który pozwalałby serwerowi autoryzacji zweryfikować legalność aplikacji.
Istnieją trzy typy tokenów używanych w OIDC:
Tokeny Dostępu: Klient przedstawia ten token serwerowi zasobów, aby uzyskać dostęp do zasobów. Może być używany tylko dla określonej kombinacji użytkownika, klienta i zasobu i nie może być unieważniony do momentu wygaśnięcia - co wynosi domyślnie 1 godzinę.
Tokeny ID: Klient otrzymuje ten token od serwera autoryzacji. Zawiera podstawowe informacje o użytkowniku. Jest powiązany z określoną kombinacją użytkownika i klienta.
Tokeny Odświeżające: Przyznawane klientowi wraz z tokenem dostępu. Używane do uzyskiwania nowych tokenów dostępu i ID. Jest powiązany z określoną kombinacją użytkownika i klienta i może być unieważniony. Domyślne wygaśnięcie wynosi 90 dni dla nieaktywnych tokenów odświeżających i brak wygaśnięcia dla aktywnych tokenów (z tokena odświeżającego można uzyskać nowe tokeny odświeżające).
Token odświeżający powinien być powiązany z aud, z pewnymi zakresami i z dzierżawcą i powinien być w stanie generować tokeny dostępu tylko dla tego aud, zakresów (i nic więcej) oraz dzierżawcy. Jednak nie jest to prawdą w przypadku tokenów aplikacji FOCI.
Token odświeżający jest szyfrowany i tylko Microsoft może go odszyfrować.
Uzyskanie nowego tokena odświeżającego nie unieważnia poprzedniego tokena odświeżającego.
Informacje o dostępie warunkowym są przechowywane wewnątrz JWT. Jeśli więc zażądacie tokena z dozwolonego adresu IP, ten IP zostanie przechowany w tokenie, a następnie możecie użyć tego tokena z niedozwolonego IP, aby uzyskać dostęp do zasobów.
Pole wskazane w polu "aud" to serwer zasobów (aplikacja) używany do przeprowadzenia logowania.
Polecenie az account get-access-token --resource-type [...] obsługuje następujące typy, a każdy z nich doda określone "aud" w wynikowym tokenie dostępu:
Zauważ, że poniższe to tylko API obsługiwane przez az account get-access-token, ale jest ich więcej.
Zakres tokena dostępu jest przechowywany wewnątrz klucza scp w tokenie dostępu JWT. Te zakresy definiują, do czego token dostępu ma dostęp.
Jeśli JWT ma prawo kontaktować się z określonym API, ale nie ma zakresu do wykonania żądanej akcji, nie będzie w stanie wykonać tej akcji z tym JWT.
Wcześniej wspomniano, że tokeny odświeżające powinny być powiązane z zakresami, z którymi zostały wygenerowane, z aplikacją i dzierżawą, do której zostały wygenerowane. Jeśli jakakolwiek z tych granic zostanie naruszona, możliwe jest eskalowanie uprawnień, ponieważ będzie można generować tokeny dostępu do innych zasobów i dzierżaw, do których użytkownik ma dostęp, oraz z większymi zakresami, niż pierwotnie zamierzano.
Co więcej, jest to możliwe z wszystkimi tokenami odświeżającymi w Microsoft identity platform (konta Microsoft Entra, konta osobiste Microsoft oraz konta społecznościowe, takie jak Facebook i Google), ponieważ jak wspominają dokumenty: "Tokeny odświeżające są powiązane z kombinacją użytkownika i klienta, ale nie są powiązane z zasobem ani dzierżawą. Klient może użyć tokena odświeżającego do uzyskania tokenów dostępu w dowolnej kombinacji zasobów i dzierżaw, do których ma pozwolenie. Tokeny odświeżające są szyfrowane i tylko platforma tożsamości Microsoft może je odczytać."
Ponadto, należy zauważyć, że aplikacje FOCI są aplikacjami publicznymi, więc nie jest wymagany żaden sekret do uwierzytelnienia na serwerze.
Znane klientów FOCI zgłoszone w oryginalnych badaniach można znaleźć tutaj.
Kontynuując poprzedni przykład kodu, w tym kodzie żądany jest nowy token dla innego zakresu:
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
