GCP <–> Workspace Pivoting

Tip

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

Υποστηρίξτε το HackTricks

Από GCP σε GWS

Βασικά της εξουσιοδότησης σε επίπεδο τομέα

Η εξουσιοδότηση σε επίπεδο τομέα του Google Workspace επιτρέπει σε ένα αντικείμενο ταυτότητας, είτε μια εξωτερική εφαρμογή από το Google Workspace Marketplace είτε έναν εσωτερικό GCP Service Account, να πρόσβαση σε δεδομένα σε όλο το Workspace εκ μέρους των χρηστών.

Note

Αυτό σημαίνει βασικά ότι οι service accounts μέσα σε έργα GCP μιας οργάνωσης μπορεί να είναι σε θέση να παριστάνουν τους χρήστες του Workspace της ίδιας οργάνωσης (ή ακόμα και από μια διαφορετική).

Για περισσότερες πληροφορίες σχετικά με το πώς λειτουργεί αυτό ακριβώς, ελέγξτε:

GCP - Understanding Domain-Wide Delegation

Συμβιβασμός υπάρχουσας εξουσιοδότησης

Εάν ένας επιτιθέμενος συμβιβάσει κάποια πρόσβαση μέσω GCP και γνωρίζει μια έγκυρη διεύθυνση email χρήστη του Workspace (κατά προτίμηση super admin) της εταιρείας, θα μπορούσε να καταγράψει όλα τα έργα στα οποία έχει πρόσβαση, να καταγράψει όλους τους SAs των έργων, να ελέγξει σε ποιους service accounts έχει πρόσβαση, και να επαναλάβει όλα αυτά τα βήματα με κάθε SA που μπορεί να παριστάνει.
Με μια λίστα όλων των service accounts που έχει πρόσβαση και τη λίστα με τις διευθύνσεις email του Workspace, ο επιτιθέμενος θα μπορούσε να προσπαθήσει να παριστάνει τον χρήστη με κάθε service account.

Caution

Σημειώστε ότι κατά τη ρύθμιση της εξουσιοδότησης σε επίπεδο τομέα δεν απαιτείται κανένας χρήστης του Workspace, επομένως αρκεί να γνωρίζετε έναν έγκυρο και απαιτείται για την παριστία.
Ωστόσο, οι προνομίες του παριστάμενου χρήστη θα χρησιμοποιηθούν, οπότε αν είναι Super Admin θα μπορείτε να έχετε πρόσβαση σε όλα. Αν δεν έχει καμία πρόσβαση, αυτό θα είναι άχρηστο.

GCP Generate Delegation Token

Αυτό το απλό σενάριο θα δημιουργήσει ένα OAuth token ως ο εξουσιοδοτημένος χρήστης που μπορείτε στη συνέχεια να χρησιμοποιήσετε για να αποκτήσετε πρόσβαση σε άλλες Google APIs με ή χωρίς gcloud:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid"

DelePwn

Βασισμένο στο εργαλείο DeleFriend, αλλά με κάποιες προσθήκες όπως η δυνατότητα να καταμετρά το domain, drive, gmail, calendar και να εκτελεί άλλες λειτουργίες.

DeleFriend

Αυτό είναι ένα εργαλείο που μπορεί να εκτελέσει την επίθεση ακολουθώντας τα παρακάτω βήματα:

  1. Καταμέτρηση GCP Projects χρησιμοποιώντας το Resource Manager API.
  2. Επαναλάβετε για κάθε πόρο έργου, και καταμετρήστε τους πόρους GCP Service account στους οποίους έχει πρόσβαση ο αρχικός IAM χρήστης χρησιμοποιώντας το GetIAMPolicy.
  3. Επαναλάβετε για κάθε ρόλο service account, και βρείτε ενσωματωμένους, βασικούς και προσαρμοσμένους ρόλους με άδεια serviceAccountKeys.create στον πόρο του στόχου service account. Πρέπει να σημειωθεί ότι ο ρόλος Editor κατέχει εγγενώς αυτή την άδεια.
  4. Δημιουργήστε ένα νέο KEY_ALG_RSA_2048 ιδιωτικό κλειδί για κάθε πόρο service account που βρέθηκε με σχετική άδεια στην πολιτική IAM.
  5. Επαναλάβετε για κάθε νέο service account και δημιουργήστε ένα JWT αντικείμενο για αυτό που αποτελείται από τα διαπιστευτήρια του ιδιωτικού κλειδιού SA και μια OAuth έκταση. Η διαδικασία δημιουργίας ενός νέου JWT αντικειμένου θα επαναλάβει όλους τους υπάρχοντες συνδυασμούς OAuth εκτάσεων από τη λίστα oauth_scopes.txt, προκειμένου να βρει όλες τις δυνατότητες αντιπροσώπευσης. Η λίστα oauth_scopes.txt ενημερώνεται με όλες τις OAuth εκτάσεις που έχουμε βρει ότι είναι σχετικές για την κατάχρηση ταυτοτήτων Workspace.
  6. Η μέθοδος _make_authorization_grant_assertion αποκαλύπτει την ανάγκη να δηλωθεί ένας στόχος χρήστη workspace, αναφερόμενος ως subject, για τη δημιουργία JWTs υπό DWD. Ενώ αυτό μπορεί να φαίνεται ότι απαιτεί έναν συγκεκριμένο χρήστη, είναι σημαντικό να συνειδητοποιήσουμε ότι η DWD επηρεάζει κάθε ταυτότητα εντός ενός domain. Συνεπώς, η δημιουργία ενός JWT για οποιονδήποτε χρήστη του domain επηρεάζει όλες τις ταυτότητες σε αυτό το domain, σύμφωνα με τον έλεγχο καταμέτρησης συνδυασμών μας. Απλά, ένας έγκυρος χρήστης Workspace είναι επαρκής για να προχωρήσουμε.
    Αυτός ο χρήστης μπορεί να οριστεί στο αρχείο config.yaml του DeleFriend. Εάν δεν είναι ήδη γνωστός ένας στόχος χρήστη workspace, το εργαλείο διευκολύνει την αυτόματη αναγνώριση έγκυρων χρηστών workspace σκανάροντας τους χρήστες του domain με ρόλους σε GCP projects. Είναι σημαντικό να σημειωθεί (ξανά) ότι τα JWT είναι συγκεκριμένα για το domain και δεν δημιουργούνται για κάθε χρήστη· επομένως, η αυτόματη διαδικασία στοχεύει σε μία μοναδική ταυτότητα ανά domain.
  7. Καταμέτρηση και δημιουργία ενός νέου bearer access token για κάθε JWT και επικύρωση του token μέσω του tokeninfo API.

Gitlab’s Python script

Η Gitlab έχει δημιουργήσει αυτό το Python script που μπορεί να κάνει δύο πράγματα - να καταγράψει τον κατάλογο χρηστών και να δημιουργήσει έναν νέο διαχειριστικό λογαριασμό ενώ υποδεικνύει ένα json με διαπιστευτήρια SA και τον χρήστη που θα μιμηθεί. Εδώ είναι πώς θα το χρησιμοποιούσατε:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Δημιουργία νέας εξουσιοδότησης (Persistence)

Είναι δυνατόν να ελέγξετε τις Domain Wide Delegations στο https://admin.google.com/u/1/ac/owl/domainwidedelegation.

Ένας επιτιθέμενος με την ικανότητα να δημιουργεί λογαριασμούς υπηρεσίας σε ένα έργο GCP και προνόμια super admin στο GWS θα μπορούσε να δημιουργήσει μια νέα εξουσιοδότηση που επιτρέπει στους SAs να προσποιούνται κάποιους χρήστες του GWS:

  1. Δημιουργία Νέου Λογαριασμού Υπηρεσίας και Σχετικού Ζεύγους Κλειδιών: Στο GCP, νέοι πόροι λογαριασμού υπηρεσίας μπορούν να παραχθούν είτε διαδραστικά μέσω της κονσόλας είτε προγραμματισμένα χρησιμοποιώντας άμεσες κλήσεις API και εργαλεία CLI. Αυτό απαιτεί το ρόλο iam.serviceAccountAdmin ή οποιονδήποτε προσαρμοσμένο ρόλο εξοπλισμένο με την άδεια iam.serviceAccounts.create. Μόλις δημιουργηθεί ο λογαριασμός υπηρεσίας, θα προχωρήσουμε στη δημιουργία ενός σχετικού ζεύγους κλειδιών (άδεια iam.serviceAccountKeys.create).
  2. Δημιουργία νέας εξουσιοδότησης: Είναι σημαντικό να κατανοήσουμε ότι μόνο ο ρόλος Super Admin έχει τη δυνατότητα να ρυθμίσει παγκόσμια Domain-Wide εξουσιοδότηση στο Google Workspace και η Domain-Wide εξουσιοδότηση δεν μπορεί να ρυθμιστεί προγραμματισμένα, μπορεί να δημιουργηθεί και να προσαρμοστεί χειροκίνητα μέσω της κονσόλας Google Workspace.
  • Η δημιουργία του κανόνα μπορεί να βρεθεί στη σελίδα API controls → Manage Domain-Wide delegation in Google Workspace Admin console.
  1. Σύνδεση προνομίων OAuth scopes: Κατά τη ρύθμιση μιας νέας εξουσιοδότησης, η Google απαιτεί μόνο 2 παραμέτρους, το Client ID, το οποίο είναι το OAuth ID του πόρου GCP Service Account, και OAuth scopes που καθορίζουν ποιες κλήσεις API απαιτεί η εξουσιοδότηση.
  • Η πλήρης λίστα των OAuth scopes μπορεί να βρεθεί εδώ, αλλά εδώ είναι μια σύσταση: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
  1. Δράση εκ μέρους της στοχευμένης ταυτότητας: Σε αυτό το σημείο, έχουμε ένα λειτουργικό εξουσιοδοτημένο αντικείμενο στο GWS. Τώρα, χρησιμοποιώντας το ιδιωτικό κλειδί του GCP Service Account, μπορούμε να εκτελέσουμε κλήσεις API (στο πεδίο που καθορίζεται στην παράμετρο OAuth scope) για να το ενεργοποιήσουμε και να δράσουμε εκ μέρους οποιασδήποτε ταυτότητας που υπάρχει στο Google Workspace. Όπως μάθαμε, ο λογαριασμός υπηρεσίας θα δημιουργήσει διακριτικά πρόσβασης ανάλογα με τις ανάγκες του και σύμφωνα με την άδεια που έχει για τις εφαρμογές REST API.
  • Ελέγξτε την προηγούμενη ενότητα για κάποια εργαλεία για να χρησιμοποιήσετε αυτή την εξουσιοδότηση.

Διασυνοριακή εξουσιοδότηση

Το OAuth SA ID είναι παγκόσμιο και μπορεί να χρησιμοποιηθεί για διασυνοριακή εξουσιοδότηση. Δεν έχει εφαρμοστεί καμία περιοριστική πολιτική για να αποτραπεί η διασυνοριακή εξουσιοδότηση. Με απλά λόγια, οι λογαριασμοί υπηρεσίας από διαφορετικές οργανώσεις GCP μπορούν να χρησιμοποιηθούν για να ρυθμίσουν την εξουσιοδότηση σε επίπεδο τομέα σε άλλες οργανώσεις Workspace. Αυτό θα είχε ως αποτέλεσμα να απαιτείται μόνο πρόσβαση Super Admin στο Workspace, και όχι πρόσβαση στον ίδιο λογαριασμό GCP, καθώς ο αντίπαλος μπορεί να δημιουργήσει Λογαριασμούς Υπηρεσίας και ιδιωτικά κλειδιά στον προσωπικά ελεγχόμενο λογαριασμό GCP του.

Δημιουργία Έργου για την καταμέτρηση του Workspace

Από προεπιλογή οι χρήστες του Workspace έχουν την άδεια να δημιουργούν νέα έργα, και όταν δημιουργείται ένα νέο έργο, ο δημιουργός αποκτά το ρόλο του Ιδιοκτήτη σε αυτό.

Επομένως, ένας χρήστης μπορεί να δημιουργήσει ένα έργο, να ενεργοποιήσει τις API για να καταμετρήσει το Workspace στο νέο του έργο και να προσπαθήσει να καταμετρήσει αυτό.

Caution

Για να μπορέσει ένας χρήστης να καταμετρήσει το Workspace, χρειάζεται επίσης αρκετές άδειες Workspace (όχι κάθε χρήστης θα μπορεί να καταμετρήσει τον κατάλογο).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Ελέγξτε περισσότερη αρίθμηση σε:

GCP - IAM, Principals & Org Policies Enum

Κατάχρηση διαπιστευτηρίων Gcloud

Μπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με τη ροή gcloud για σύνδεση σε:

GCP - Token Persistence

Όπως εξηγείται εκεί, το gcloud μπορεί να ζητήσει την έκταση https://www.googleapis.com/auth/drive που θα επιτρέπει σε έναν χρήστη να έχει πρόσβαση στον δίσκο του χρήστη.
Ως επιτιθέμενος, εάν έχετε παραβιάσει φυσικά τον υπολογιστή ενός χρήστη και ο χρήστης είναι ακόμα συνδεδεμένος με τον λογαριασμό του, θα μπορούσατε να συνδεθείτε δημιουργώντας ένα διακριτικό με πρόσβαση στον δίσκο χρησιμοποιώντας:

gcloud auth login --enable-gdrive-access

Αν ένας επιτιθέμενος παραβιάσει τον υπολογιστή ενός χρήστη, θα μπορούσε επίσης να τροποποιήσει το αρχείο google-cloud-sdk/lib/googlecloudsdk/core/config.py και να προσθέσει στο CLOUDSDK_SCOPES την έκταση 'https://www.googleapis.com/auth/drive':

Warning

Επομένως, την επόμενη φορά που ο χρήστης θα συνδεθεί, θα δημιουργήσει ένα token με πρόσβαση στο drive που ο επιτιθέμενος θα μπορούσε να εκμεταλλευτεί για να αποκτήσει πρόσβαση στο drive. Προφανώς, ο περιηγητής θα υποδείξει ότι το παραγόμενο token θα έχει πρόσβαση στο drive, αλλά καθώς ο χρήστης θα καλέσει ο ίδιος το gcloud auth login, πιθανότατα δεν θα υποψιαστεί τίποτα.

Για να καταγράψετε τα αρχεία του drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

Από GWS σε GCP

Πρόσβαση σε προνομιούχους χρήστες GCP

Αν ένας επιτιθέμενος έχει πλήρη πρόσβαση στο GWS, θα είναι σε θέση να αποκτήσει πρόσβαση σε ομάδες με προνομιακή πρόσβαση στο GCP ή ακόμη και σε χρήστες, επομένως η μετάβαση από το GWS στο GCP είναι συνήθως πιο “απλή” απλώς και μόνο επειδή οι χρήστες στο GWS έχουν υψηλά προνόμια στο GCP.

Κλιμάκωση προνομίων Google Groups

Από προεπιλογή, οι χρήστες μπορούν να εντάσσονται ελεύθερα σε ομάδες Workspace της Οργάνωσης και αυτές οι ομάδες μπορεί να έχουν εκχωρημένα δικαιώματα GCP (ελέγξτε τις ομάδες σας στο https://groups.google.com/).

Εκμεταλλευόμενοι την κλιμάκωση προνομίων google groups, μπορεί να είστε σε θέση να κλιμακωθείτε σε μια ομάδα με κάποιο είδος προνομιακής πρόσβασης στο GCP.

Αναφορές

Tip

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

Υποστηρίξτε το HackTricks