Az - Tokens & Public Applications

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

Το Entra ID είναι η πλατφόρμα διαχείρισης ταυτότητας και πρόσβασης (IAM) της Microsoft που βασίζεται στο cloud, λειτουργώντας ως το θεμελιώδες σύστημα αυθεντικοποίησης και εξουσιοδότησης για υπηρεσίες όπως το Microsoft 365 και το Azure Resource Manager. Το Azure AD εφαρμόζει το πλαίσιο εξουσιοδότησης OAuth 2.0 και το πρωτόκολλο αυθεντικοποίησης OpenID Connect (OIDC) για τη διαχείριση πρόσβασης σε πόρους.

OAuth

Κύριοι Συμμετέχοντες στο OAuth 2.0:

1. Server Πόρων (RS): Προστατεύει πόρους που ανήκουν στον κάτοχο των πόρων.

2. Κάτοχος Πόρων (RO): Συνήθως είναι ο τελικός χρήστης που κατέχει τους προστατευόμενους πόρους.

3. Εφαρμογή Πελάτη (CA): Μια εφαρμογή που ζητά πρόσβαση σε πόρους εκ μέρους του κατόχου των πόρων.

4. Server Εξουσιοδότησης (AS): Εκδίδει διαπιστευτήρια πρόσβασης σε εφαρμογές πελατών μετά την αυθεντικοποίηση και εξουσιοδότησή τους.

Εύρος και Συγκατάθεση:

• Εύρος: Λεπτομερείς άδειες που ορίζονται στον server πόρων που καθορίζουν τα επίπεδα πρόσβασης.

• Συγκατάθεση: Η διαδικασία με την οποία ο κάτοχος πόρων παραχωρεί σε μια εφαρμογή πελάτη άδεια πρόσβασης σε πόρους με συγκεκριμένα εύρη.

Ενσωμάτωση Microsoft 365:

• Το Microsoft 365 χρησιμοποιεί το Azure AD για IAM και αποτελείται από πολλές "πρώτης κατηγορίας" εφαρμογές OAuth.

• Αυτές οι εφαρμογές είναι βαθιά ενσωματωμένες και συχνά έχουν αλληλεξαρτώμενες σχέσεις υπηρεσιών.

• Για να απλοποιήσει την εμπειρία του χρήστη και να διατηρήσει τη λειτουργικότητα, η Microsoft παραχωρεί "υπονοούμενη συγκατάθεση" ή "προ-συγκατάθεση" σε αυτές τις πρώτης κατηγορίας εφαρμογές.

• Υπονοούμενη Συγκατάθεση: Ορισμένες εφαρμογές αποκτούν αυτόματα πρόσβαση σε συγκεκριμένα εύρη χωρίς ρητή έγκριση από τον χρήστη ή τον διαχειριστή.

• Αυτά τα προ-συμφωνημένα εύρη είναι συνήθως κρυμμένα τόσο από τους χρήστες όσο και από τους διαχειριστές, καθιστώντας τα λιγότερο ορατά σε τυπικές διεπαφές διαχείρισης.

Τύποι Εφαρμογών Πελατών:

1. Εμπιστευτικοί Πελάτες:

• Διαθέτουν τα δικά τους διαπιστευτήρια (π.χ., κωδικούς πρόσβασης ή πιστοποιητικά).

• Μπορούν να αυθεντικοποιηθούν με ασφάλεια στον server εξουσιοδότησης.

1. Δημόσιοι Πελάτες:

• Δεν έχουν μοναδικά διαπιστευτήρια.

• Δεν μπορούν να αυθεντικοποιηθούν με ασφάλεια στον server εξουσιοδότησης.

• Σημασία Ασφαλείας: Ένας επιτιθέμενος μπορεί να προσποιηθεί μια δημόσια εφαρμογή πελάτη κατά την αίτηση διαπιστευτηρίων, καθώς δεν υπάρχει μηχανισμός για τον server εξουσιοδότησης να επαληθεύσει τη νομιμότητα της εφαρμογής.

Authentication Tokens

Υπάρχουν τρία είδη διαπιστευτηρίων που χρησιμοποιούνται στο OIDC:

• Access Tokens: Ο πελάτης παρουσιάζει αυτό το διαπιστευτήριο στον server πόρων για να πρόσβαση σε πόρους. Μπορεί να χρησιμοποιηθεί μόνο για μια συγκεκριμένη συνδυασμένη χρήση χρήστη, πελάτη και πόρου και δεν μπορεί να ανακληθεί μέχρι την λήξη του - δηλαδή 1 ώρα από προεπιλογή.

• ID Tokens: Ο πελάτης λαμβάνει αυτό το διαπιστευτήριο από τον server εξουσιοδότησης. Περιέχει βασικές πληροφορίες σχετικά με τον χρήστη. Είναι δεσμευμένο σε μια συγκεκριμένη συνδυασμένη χρήση χρήστη και πελάτη.

• Refresh Tokens: Παρέχονται στον πελάτη με το access token. Χρησιμοποιούνται για να λάβουν νέα access και ID tokens. Είναι δεσμευμένο σε μια συγκεκριμένη συνδυασμένη χρήση χρήστη και πελάτη και μπορεί να ανακληθεί. Η προεπιλεγμένη λήξη είναι 90 ημέρες για ανενεργά refresh tokens και χωρίς λήξη για ενεργά tokens (είναι δυνατή η λήψη νέων refresh tokens από ένα refresh token).

• Ένα refresh token θα πρέπει να συνδέεται με ένα aud, με κάποια εύρη, και με έναν tenant και θα πρέπει να μπορεί να δημιουργεί μόνο access tokens για αυτό το aud, τα εύρη (και όχι περισσότερα) και τον tenant. Ωστόσο, αυτό δεν ισχύει για τα FOCI applications tokens.

• Ένα refresh token είναι κρυπτογραφημένο και μόνο η Microsoft μπορεί να το αποκρυπτογραφήσει.

• Η λήψη ενός νέου refresh token δεν ανακαλεί το προηγούμενο refresh token.

Πληροφορίες για conditional access είναι αποθηκευμένες μέσα στο JWT. Έτσι, αν ζητήσετε το token από μια επιτρεπόμενη διεύθυνση IP, αυτή η IP θα είναι αποθηκευμένη στο token και στη συνέχεια μπορείτε να χρησιμοποιήσετε αυτό το token από μια μη επιτρεπόμενη IP για να αποκτήσετε πρόσβαση στους πόρους.

Access Tokens "aud"

Το πεδίο που υποδεικνύεται στο πεδίο "aud" είναι ο server πόρων (η εφαρμογή) που χρησιμοποιείται για την εκτέλεση της σύνδεσης.

Η εντολή az account get-access-token --resource-type [...] υποστηρίζει τους παρακάτω τύπους και καθένας από αυτούς θα προσθέσει ένα συγκεκριμένο "aud" στο αποτέλεσμα του access token:

Σημειώστε ότι τα παρακάτω είναι μόνο οι APIs που υποστηρίζονται από το az account get-access-token, αλλά υπάρχουν περισσότερα.

aud examples

• aad-graph (Azure Active Directory Graph API): Χρησιμοποιείται για την πρόσβαση στο παλιό Azure AD Graph API (καταργημένο), το οποίο επιτρέπει στις εφαρμογές να διαβάζουν και να γράφουν δεδομένα καταλόγου στο Azure Active Directory (Azure AD).

• https://graph.windows.net/

• arm (Azure Resource Manager): Χρησιμοποιείται για τη διαχείριση πόρων Azure μέσω του API Azure Resource Manager. Αυτό περιλαμβάνει λειτουργίες όπως η δημιουργία, η ενημέρωση και η διαγραφή πόρων όπως εικονικές μηχανές, λογαριασμοί αποθήκευσης και άλλα.

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

• batch (Azure Batch Services): Χρησιμοποιείται για την πρόσβαση στο Azure Batch, μια υπηρεσία που επιτρέπει την αποτελεσματική εκτέλεση εφαρμογών υπολογισμού μεγάλης κλίμακας και υψηλής απόδοσης στο cloud.

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

• data-lake (Azure Data Lake Storage): Χρησιμοποιείται για την αλληλεπίδραση με το Azure Data Lake Storage Gen1, το οποίο είναι μια κλιμακωτή υπηρεσία αποθήκευσης και ανάλυσης δεδομένων.

• https://datalake.azure.net/

• media (Azure Media Services): Χρησιμοποιείται για την πρόσβαση στις υπηρεσίες Azure Media, οι οποίες παρέχουν υπηρεσίες επεξεργασίας και παράδοσης πολυμέσων στο cloud για περιεχόμενο βίντεο και ήχου.

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

• ms-graph (Microsoft Graph API): Χρησιμοποιείται για την πρόσβαση στο Microsoft Graph API, την ενοποιημένη διεπαφή για τα δεδομένα υπηρεσιών Microsoft 365. Επιτρέπει την πρόσβαση σε δεδομένα και πληροφορίες από υπηρεσίες όπως το Azure AD, το Office 365, την Επιχειρηματική Κινητικότητα και τις Υπηρεσίες Ασφαλείας.

• https://graph.microsoft.com

• oss-rdbms (Azure Open Source Relational Databases): Χρησιμοποιείται για την πρόσβαση στις υπηρεσίες βάσεων δεδομένων Azure για ανοιχτού κώδικα μηχανές σχεσιακών βάσεων δεδομένων όπως MySQL, PostgreSQL και MariaDB.

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

Access Tokens Scopes "scp"

Το εύρος ενός access token αποθηκεύεται μέσα στο κλειδί scp μέσα στο JWT του access token. Αυτά τα εύρη καθορίζουν σε τι έχει πρόσβαση το access token.

Αν ένα JWT επιτρέπεται να επικοινωνήσει με μια συγκεκριμένη API αλλά δεν έχει το εύρος για να εκτελέσει την ζητούμενη ενέργεια, δεν θα μπορεί να εκτελέσει την ενέργεια με αυτό το 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(
"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

Προηγουμένως αναφέρθηκε ότι τα refresh tokens θα πρέπει να συνδέονται με τα scopes με τα οποία δημιουργήθηκαν, με την εφαρμογή και τον tenant για τον οποίο δημιουργήθηκαν. Εάν οποιοδήποτε από αυτά τα όρια παραβιαστεί, είναι δυνατόν να γίνει κλιμάκωση προνομίων καθώς θα είναι δυνατή η δημιουργία access tokens για άλλους πόρους και tenants στους οποίους έχει πρόσβαση ο χρήστης και με περισσότερα scopes από ό,τι είχε αρχικά προγραμματιστεί.

Επιπλέον, αυτό είναι δυνατό με όλα τα refresh tokens στην Microsoft identity platform (λογαριασμοί Microsoft Entra, προσωπικοί λογαριασμοί Microsoft και κοινωνικοί λογαριασμοί όπως το Facebook και το Google) επειδή όπως αναφέρουν οι docs: "Τα refresh tokens είναι δεσμευμένα σε έναν συνδυασμό χρήστη και πελάτη, αλλά δεν είναι δεσμευμένα σε πόρο ή tenant. Ένας πελάτης μπορεί να χρησιμοποιήσει ένα refresh token για να αποκτήσει access tokens σε οποιονδήποτε συνδυασμό πόρου και tenant όπου έχει άδεια να το κάνει. Τα refresh tokens είναι κρυπτογραφημένα και μόνο η Microsoft identity platform μπορεί να τα διαβάσει."

Επιπλέον, σημειώστε ότι οι εφαρμογές FOCI είναι δημόσιες εφαρμογές, οπότε δεν απαιτείται μυστικό για την αυθεντικοποίηση στον διακομιστή.

Στη συνέχεια, οι γνωστοί πελάτες FOCI που αναφέρθηκαν στην αρχική έρευνα μπορούν να βρεθούν εδώ.

Get different scope

Ακολουθώντας το προηγούμενο παράδειγμα κώδικα, σε αυτόν τον κώδικα ζητείται ένα νέο token για ένα διαφορετικό 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)

Λάβετε διαφορετικούς πελάτες και πεδία εφαρμογής

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

Αναφορές

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

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Υποστήριξη HackTricks

• Ελέγξτε τα σχέδια συνδρομής!

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.

• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.