GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Η εξουσιοδότηση σε επίπεδο τομέα του Google Workspace επιτρέπει σε ένα αντικείμενο ταυτότητας, είτε μια εξωτερική εφαρμογή από το Google Workspace Marketplace είτε έναν εσωτερικό GCP Service Account, να πρόσβαση σε δεδομένα σε όλο το Workspace εκ μέρους των χρηστών.
Αυτό σημαίνει βασικά ότι οι λογαριασμοί υπηρεσιών μέσα σε έργα GCP μιας οργάνωσης μπορεί να είναι σε θέση να παριστάνουν τους χρήστες του Workspace της ίδιας οργάνωσης (ή ακόμη και από μια διαφορετική).
Για περισσότερες πληροφορίες σχετικά με το πώς λειτουργεί αυτό ακριβώς, ελέγξτε:
GCP - Understanding Domain-Wide DelegationΕάν ένας επιτιθέμενος συμβιβάσει κάποια πρόσβαση μέσω GCP και γνωρίζει μια έγκυρη διεύθυνση email χρήστη του Workspace (κατά προτίμηση super admin) της εταιρείας, θα μπορούσε να καταγράψει όλα τα έργα στα οποία έχει πρόσβαση, να καταγράψει όλους τους SAs των έργων, να ελέγξει σε ποιους λογαριασμούς υπηρεσιών έχει πρόσβαση, και να επαναλάβει όλα αυτά τα βήματα με κάθε SA που μπορεί να παριστάνει. Με μια λίστα όλων των λογαριασμών υπηρεσιών που έχει πρόσβαση και τη λίστα των emails του Workspace, ο επιτιθέμενος θα μπορούσε να προσπαθήσει να παριστάνει τον χρήστη με κάθε λογαριασμό υπηρεσίας.
Σημειώστε ότι κατά τη ρύθμιση της εξουσιοδότησης σε επίπεδο τομέα δεν απαιτείται κανένας χρήστης του Workspace, επομένως αρκεί να γνωρίζετε έναν έγκυρο και απαιτείται για την παριστάνωση. Ωστόσο, οι προνομίες του παριστάμενου χρήστη θα χρησιμοποιηθούν, οπότε αν είναι Super Admin θα μπορείτε να έχετε πρόσβαση σε όλα. Αν δεν έχει καμία πρόσβαση, αυτό θα είναι άχρηστο.
Αυτό το απλό σενάριο θα δημιουργήσει ένα OAuth token ως ο εξουσιοδοτημένος χρήστης που μπορείτε στη συνέχεια να χρησιμοποιήσετε για να αποκτήσετε πρόσβαση σε άλλες Google APIs με ή χωρίς gcloud:
Αυτό είναι ένα εργαλείο που μπορεί να εκτελέσει την επίθεση ακολουθώντας αυτά τα βήματα:
Καταμέτρηση GCP Projects χρησιμοποιώντας το Resource Manager API.
Επαναλάβετε για κάθε πόρο έργου και καταμετρήστε τους πόρους GCP Service account στους οποίους έχει πρόσβαση ο αρχικός IAM χρήστης χρησιμοποιώντας το GetIAMPolicy.
Επαναλάβετε για κάθε ρόλο service account και βρείτε ενσωματωμένους, βασικούς και προσαρμοσμένους ρόλους με άδεια serviceAccountKeys.create στον πόρο του στοχευμένου service account. Θα πρέπει να σημειωθεί ότι ο ρόλος του Editor κατέχει εγγενώς αυτή την άδεια.
Δημιουργήστε ένα νέο KEY_ALG_RSA_2048 ιδιωτικό κλειδί για κάθε πόρο service account που βρέθηκε με σχετική άδεια στην πολιτική IAM.
Επαναλάβετε για κάθε νέο service account και δημιουργήστε ένα JWT αντικείμενο για αυτό που αποτελείται από τα διαπιστευτήρια του ιδιωτικού κλειδιού SA και μια έκταση OAuth. Η διαδικασία δημιουργίας ενός νέου JWT αντικειμένου θα επαναλάβει όλους τους υπάρχοντες συνδυασμούς εκτάσεων OAuth από τη λίστα oauth_scopes.txt, προκειμένου να βρει όλες τις δυνατότητες αντιπροσώπευσης. Η λίστα oauth_scopes.txt ενημερώνεται με όλες τις εκτάσεις OAuth που έχουμε βρει ότι είναι σχετικές για την κατάχρηση ταυτοτήτων Workspace.
Η μέθοδος _make_authorization_grant_assertion αποκαλύπτει την ανάγκη να δηλωθεί ένας στόχος χρήστη workspace, αναφερόμενος ως subject, για τη δημιουργία JWTs υπό DWD. Ενώ αυτό μπορεί να φαίνεται ότι απαιτεί έναν συγκεκριμένο χρήστη, είναι σημαντικό να συνειδητοποιήσουμε ότι η DWD επηρεάζει κάθε ταυτότητα εντός ενός τομέα. Συνεπώς, η δημιουργία ενός JWT για οποιονδήποτε χρήστη τομέα επηρεάζει όλες τις ταυτότητες σε αυτόν τον τομέα, σύμφωνα με τον έλεγχο καταμέτρησης συνδυασμών μας. Απλά, ένας έγκυρος χρήστης Workspace είναι επαρκής για να προχωρήσουμε.
Αυτός ο χρήστης μπορεί να οριστεί στο αρχείο config.yaml του DeleFriend. Εάν δεν είναι ήδη γνωστός ένας στόχος χρήστη workspace, το εργαλείο διευκολύνει την αυτόματη αναγνώριση έγκυρων χρηστών workspace σκανάροντας τους χρήστες τομέα με ρόλους σε έργα GCP. Είναι σημαντικό να σημειωθεί (ξανά) ότι τα JWT είναι συγκεκριμένα για τομέα και δεν δημιουργούνται για κάθε χρήστη. Επομένως, η αυτόματη διαδικασία στοχεύει σε μία μοναδική ταυτότητα ανά τομέα.
Καταμέτρηση και δημιουργία ενός νέου bearer access token για κάθε JWT και επικύρωση του token μέσω του tokeninfo API.
Η Gitlab έχει δημιουργήσει αυτό το Python script που μπορεί να κάνει δύο πράγματα - να καταγράψει τον κατάλογο χρηστών και να δημιουργήσει έναν νέο διοικητικό λογαριασμό ενώ υποδεικνύει ένα json με διαπιστευτήρια SA και τον χρήστη που θα μιμηθεί. Εδώ είναι πώς θα το χρησιμοποιούσατε:
Είναι δυνατόν να ελέγξετε τις Εξουσιοδοτήσεις σε επίπεδο Τομέα στο https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Ένας επιτιθέμενος με την ικανότητα να δημιουργεί λογαριασμούς υπηρεσίας σε ένα έργο GCP και προνομία super admin στο GWS θα μπορούσε να δημιουργήσει μια νέα εξουσιοδότηση που επιτρέπει στους λογαριασμούς υπηρεσίας να προσποιούνται κάποιους χρήστες του GWS:
Δημιουργία Νέου Λογαριασμού Υπηρεσίας και Σχετικού Ζεύγους Κλειδιών: Στο GCP, νέοι πόροι λογαριασμού υπηρεσίας μπορούν να παραχθούν είτε διαδραστικά μέσω της κονσόλας είτε προγραμματισμένα χρησιμοποιώντας άμεσες κλήσεις API και εργαλεία CLI. Αυτό απαιτεί τον ρόλο iam.serviceAccountAdmin ή οποιονδήποτε προσαρμοσμένο ρόλο εξοπλισμένο με την άδεια iam.serviceAccounts.create. Μόλις δημιουργηθεί ο λογαριασμός υπηρεσίας, θα προχωρήσουμε στη δημιουργία ενός σχετικού ζεύγους κλειδιών (άδεια iam.serviceAccountKeys.create).
Δημιουργία νέας εξουσιοδότησης: Είναι σημαντικό να κατανοήσουμε ότι μόνο ο ρόλος Super Admin έχει τη δυνατότητα να ρυθμίσει παγκόσμια εξουσιοδότηση σε επίπεδο Τομέα στο Google Workspace και η εξουσιοδότηση σε επίπεδο Τομέα δεν μπορεί να ρυθμιστεί προγραμματισμένα, μπορεί να δημιουργηθεί και να ρυθμιστεί χειροκίνητα μέσω της κονσόλας Google Workspace.
Η δημιουργία του κανόνα μπορεί να βρεθεί στη σελίδα API controls → Διαχείριση Εξουσιοδότησης σε επίπεδο Τομέα στην κονσόλα διαχείρισης Google Workspace.
Συνημμένα προνόμια OAuth scopes: Κατά τη ρύθμιση μιας νέας εξουσιοδότησης, η Google απαιτεί μόνο 2 παραμέτρους, το Client ID, το οποίο είναι το OAuth ID του πόρου Λογαριασμού Υπηρεσίας GCP, και 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
Δράση εκ μέρους της στοχευμένης ταυτότητας: Σε αυτό το σημείο, έχουμε ένα λειτουργικό εξουσιοδοτημένο αντικείμενο στο GWS. Τώρα, χρησιμοποιώντας το ιδιωτικό κλειδί του Λογαριασμού Υπηρεσίας GCP, μπορούμε να εκτελέσουμε κλήσεις API (στο πεδίο που καθορίζεται στην παράμετρο OAuth scope) για να το ενεργοποιήσουμε και να δράσουμε εκ μέρους οποιασδήποτε ταυτότητας που υπάρχει στο Google Workspace. Όπως μάθαμε, ο λογαριασμός υπηρεσίας θα δημιουργήσει διαπιστευτήρια πρόσβασης ανάλογα με τις ανάγκες του και σύμφωνα με την άδεια που έχει για τις εφαρμογές REST API.
Ελέγξτε την προηγούμενη ενότητα για κάποια εργαλεία για να χρησιμοποιήσετε αυτήν την εξουσιοδότηση.
Το OAuth SA ID είναι παγκόσμιο και μπορεί να χρησιμοποιηθεί για διασυνοριακή εξουσιοδότηση. Δεν έχει εφαρμοστεί καμία περιοριστική πολιτική για να αποτραπεί η διασυνοριακή εξουσιοδότηση. Με απλά λόγια, οι λογαριασμοί υπηρεσίας από διαφορετικούς οργανισμούς GCP μπορούν να χρησιμοποιηθούν για να ρυθμίσουν εξουσιοδότηση σε επίπεδο τομέα σε άλλους οργανισμούς Workspace. Αυτό θα είχε ως αποτέλεσμα να απαιτείται μόνο πρόσβαση Super Admin στο Workspace, και όχι πρόσβαση στον ίδιο λογαριασμό GCP, καθώς ο αντίπαλος μπορεί να δημιουργήσει Λογαριασμούς Υπηρεσίας και ιδιωτικά κλειδιά στον προσωπικά ελεγχόμενο λογαριασμό GCP του.
Κατά προεπιλογή, οι χρήστες του Workspace έχουν την άδεια να δημιουργούν νέα έργα, και όταν δημιουργείται ένα νέο έργο, ο δημιουργός αποκτά τον ρόλο του Ιδιοκτήτη.
Επομένως, ένας χρήστης μπορεί να δημιουργήσει ένα έργο, να ενεργοποιήσει τις API για να καταμετρήσει το Workspace στο νέο του έργο και να προσπαθήσει να καταμετρήσει αυτό.
Για να μπορέσει ένας χρήστης να καταμετρήσει το Workspace, χρειάζεται επίσης αρκετές άδειες Workspace (όχι κάθε χρήστης θα μπορεί να καταμετρήσει τον κατάλογο).
Check περισσότερη αρίθμηση σε:
GCP - IAM, Principals & Org Policies EnumΜπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με τη ροή gcloud για σύνδεση σε:
Όπως εξηγείται εκεί, το gcloud μπορεί να ζητήσει το πεδίο https://www.googleapis.com/auth/drive το οποίο θα επιτρέπει σε έναν χρήστη να έχει πρόσβαση στον δίσκο του χρήστη.
Ως επιτιθέμενος, αν έχετε παραβιάσει φυσικά τον υπολογιστή ενός χρήστη και ο χρήστης είναι ακόμα συνδεδεμένος με τον λογαριασμό του, θα μπορούσατε να συνδεθείτε δημιουργώντας ένα διακριτικό με πρόσβαση στον δίσκο χρησιμοποιώντας:
Αν ένας επιτιθέμενος παραβιάσει τον υπολογιστή ενός χρήστη, θα μπορούσε επίσης να τροποποιήσει το αρχείο google-cloud-sdk/lib/googlecloudsdk/core/config.py και να προσθέσει στο CLOUDSDK_SCOPES την έκταση 'https://www.googleapis.com/auth/drive':
Ως εκ τούτου, την επόμενη φορά που ο χρήστης θα συνδεθεί, θα δημιουργήσει ένα 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 ή ακόμη και σε χρήστες, επομένως η μετάβαση από το GWS στο GCP είναι συνήθως πιο "απλή" απλώς και μόνο επειδή οι χρήστες στο GWS έχουν υψηλά προνόμια στο GCP.
Από προεπιλογή, οι χρήστες μπορούν να ενταχθούν ελεύθερα σε ομάδες Workspace της Οργάνωσης και αυτές οι ομάδες μπορεί να έχουν εκχωρημένα δικαιώματα GCP (ελέγξτε τις ομάδες σας στο https://groups.google.com/).
Εκμεταλλευόμενοι την google groups privesc, μπορεί να είστε σε θέση να κλιμακώσετε σε μια ομάδα με κάποιο είδος προνομιακής πρόσβασης στο GCP.
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
