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

• Δείτε τα subscription plans!
• Εγγραφείτε στο 💬 Discord group ή την telegram group ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
• Μοιραστείτε τα hacking tricks υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.

Ιεραρχία Πόρων

Το Google Cloud χρησιμοποιεί μια Ιεραρχία Πόρων που είναι παρόμοια, εννοιολογικά, με αυτή ενός παραδοσιακού συστήματος αρχείων. Αυτό παρέχει μια λογική ροή εργασίας γονέα/παιδιού με συγκεκριμένα σημεία προσάρτησης για πολιτικές και δικαιώματα.

Σε υψηλό επίπεδο, φαίνεται έτσι:

Organization
--> Folders
--> Projects
--> Resources

Ένα εικονικό μηχάνημα (που ονομάζεται Compute Instance) είναι ένας πόρος. Ένας πόρος βρίσκεται σε ένα έργο, πιθανώς μαζί με άλλες Compute Instances, αποθηκευτικούς κάδους κ.λπ.

Μεταφορά Έργων

Είναι δυνατόν να μεταφέρετε ένα έργο χωρίς καμία οργάνωση σε μια οργάνωση με τις άδειες roles/resourcemanager.projectCreator και roles/resourcemanager.projectMover. Εάν το έργο βρίσκεται μέσα σε άλλη οργάνωση, είναι απαραίτητο να επικοινωνήσετε με την υποστήριξη GCP για να τα μεταφέρετε εκτός της οργάνωσης πρώτα. Για περισσότερες πληροφορίες δείτε αυτό.

Πολιτικές Οργάνωσης

Επιτρέπουν την κεντρική διαχείριση των πόρων cloud της οργάνωσής σας:

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

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

Για να ορίσετε μια πολιτική οργάνωσης, επιλέγετε έναν περιορισμό, ο οποίος είναι ένας συγκεκριμένος τύπος περιορισμού κατά ενός υπηρεσίας Google Cloud ή μιας ομάδας υπηρεσιών Google Cloud. Ρυθμίζετε αυτόν τον περιορισμό με τους επιθυμητούς περιορισμούς σας.

Κοινές περιπτώσεις χρήσης

• Περιορισμός της κοινής χρήσης πόρων με βάση το domain.
• Περιορισμός της χρήσης λογαριασμών υπηρεσιών Identity and Access Management.
• Περιορισμός της φυσικής τοποθεσίας των νεοδημιουργηθέντων πόρων.
• Απενεργοποίηση της δημιουργίας λογαριασμών υπηρεσιών.

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

Προεπιλεγμένες Πολιτικές Οργάνωσης

Ρόλοι IAM

Αυτοί είναι σαν τις πολιτικές IAM στο AWS καθώς κάθε ρόλος περιέχει ένα σύνολο αδειών.

Ωστόσο, σε αντίθεση με το AWS, δεν υπάρχει κεντρικό αποθετήριο ρόλων. Αντί αυτού, οι πόροι δίνουν X ρόλους πρόσβασης σε Y κύριους, και ο μόνος τρόπος για να μάθετε ποιος έχει πρόσβαση σε έναν πόρο είναι να χρησιμοποιήσετε τη μέθοδο get-iam-policy πάνω σε αυτόν τον πόρο.
Αυτό θα μπορούσε να είναι πρόβλημα γιατί αυτό σημαίνει ότι ο μόνος τρόπος για να μάθετε ποιες άδειες έχει ένας κύριος είναι να ρωτήσετε κάθε πόρο σε ποιον δίνει άδειες, και ένας χρήστης μπορεί να μην έχει άδειες για να αποκτήσει άδειες από όλους τους πόρους.

Υπάρχουν τρεις τύποι ρόλων στο IAM:

• Βασικοί/Πρωτότυποι ρόλοι, οι οποίοι περιλαμβάνουν τους ρόλους Ιδιοκτήτη, Επεξεργαστή και Θεατή που υπήρχαν πριν από την εισαγωγή του IAM.
• Προκαθορισμένοι ρόλοι, οι οποίοι παρέχουν λεπτομερή πρόσβαση για μια συγκεκριμένη υπηρεσία και διαχειρίζονται από την Google Cloud. Υπάρχουν πολλοί προκαθορισμένοι ρόλοι, μπορείτε να δείτε όλους αυτούς με τα προνόμια που έχουν εδώ.
• Προσαρμοσμένοι ρόλοι, οι οποίοι παρέχουν λεπτομερή πρόσβαση σύμφωνα με μια λίστα αδειών που καθορίζεται από τον χρήστη.

Υπάρχουν χιλιάδες άδειες στο GCP. Για να ελέγξετε αν ένας ρόλος έχει άδεια μπορείτε να αναζητήσετε την άδεια εδώ και να δείτε ποιους ρόλους έχει.

Μπορείτε επίσης να αναζητήσετε εδώ προκαθορισμένους ρόλους που προσφέρονται από κάθε προϊόν. Σημειώστε ότι μερικοί ρόλοι δεν μπορούν να προσαρτηθούν σε χρήστες και μόνο σε SAs λόγω ορισμένων αδειών που περιέχουν.
Επιπλέον, σημειώστε ότι οι άδειες θα ισχύουν μόνο εάν είναι συνδεδεμένες με την αντίστοιχη υπηρεσία.

Ή ελέγξτε αν ένας προσαρμοσμένος ρόλος μπορεί να χρησιμοποιήσει μια συγκεκριμένη άδεια εδώ.

GCP - IAM, Principals & Org Policies Enum

Χρήστες

Στην κονσόλα GCP δεν υπάρχει καμία διαχείριση Χρηστών ή Ομάδων, αυτό γίνεται στο Google Workspace. Αν και μπορείτε να συγχρονίσετε έναν διαφορετικό πάροχο ταυτότητας στο Google Workspace.

Μπορείτε να αποκτήσετε πρόσβαση στους χρήστες και τις ομάδες του Workspaces στο https://admin.google.com.

MFA μπορεί να επιβληθεί στους χρήστες Workspaces, ωστόσο, ένας επιτιθέμενος θα μπορούσε να χρησιμοποιήσει ένα token για να αποκτήσει πρόσβαση στο GCP μέσω cli που δεν θα προστατεύεται από MFA (θα προστατεύεται από MFA μόνο όταν ο χρήστης συνδεθεί για να το δημιουργήσει: gcloud auth login).

Ομάδες

Όταν δημιουργείται μια οργάνωση, προτείνεται έντονα να δημιουργηθούν αρκετές ομάδες. Εάν διαχειρίζεστε οποιαδήποτε από αυτές, μπορεί να έχετε συμβιβάσει όλη ή ένα σημαντικό μέρος της οργάνωσης:

Προεπιλεγμένη Πολιτική Κωδικών Πρόσβασης

• Επιβολή ισχυρών κωδικών πρόσβασης
• Μεταξύ 8 και 100 χαρακτήρων
• Καμία επαναχρησιμοποίηση
• Καμία λήξη
• Εάν οι άνθρωποι αποκτούν πρόσβαση στο Workspace μέσω τρίτου παρόχου, αυτές οι απαιτήσεις δεν εφαρμόζονται.

Λογαριασμοί Υπηρεσιών

Αυτοί είναι οι κύριοι που οι πόροι μπορούν να έχουν συνδεδεμένους και πρόσβαση για να αλληλεπιδρούν εύκολα με το GCP. Για παράδειγμα, είναι δυνατόν να αποκτήσετε πρόσβαση στο auth token ενός Λογαριασμού Υπηρεσίας συνδεδεμένου σε ένα VM στα μεταδεδομένα.
Είναι δυνατόν να συναντήσετε κάποιες συγκρούσεις όταν χρησιμοποιείτε τόσο IAM όσο και πεδία πρόσβασης. Για παράδειγμα, ο λογαριασμός υπηρεσίας σας μπορεί να έχει τον ρόλο IAM του compute.instanceAdmin, αλλά η περίπτωση που έχετε παραβιάσει έχει περιοριστεί με τον περιορισμό πεδίου του https://www.googleapis.com/auth/compute.readonly. Αυτό θα σας εμπόδιζε να κάνετε οποιεσδήποτε αλλαγές χρησιμοποιώντας το OAuth token που έχει ανατεθεί αυτόματα στην περίπτωση σας.

Είναι παρόμοιο με τους ρόλους IAM από το AWS. Αλλά όχι όπως στο AWS, οποιοσδήποτε λογαριασμός υπηρεσίας μπορεί να είναι συνδεδεμένος σε οποιαδήποτε υπηρεσία (δεν χρειάζεται να το επιτρέπει μέσω πολιτικής).

Πολλοί από τους λογαριασμούς υπηρεσιών που θα βρείτε είναι στην πραγματικότητα αυτόματα δημιουργημένοι από το GCP όταν αρχίσετε να χρησιμοποιείτε μια υπηρεσία, όπως:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Ωστόσο, είναι επίσης δυνατό να δημιουργήσετε και να συνδέσετε πόρους custom service accounts, οι οποίοι θα μοιάζουν έτσι:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Κλειδιά & Tokens

Υπάρχουν 2 κύριοι τρόποι πρόσβασης στο GCP ως λογαριασμός υπηρεσίας:

• Μέσω OAuth tokens: Αυτά είναι tokens που θα λάβετε από μέρη όπως τα metadata endpoints ή κλέβοντας http requests και περιορίζονται από τους access scopes.
• Κλειδιά: Αυτά είναι ζεύγη δημόσιων και ιδιωτικών κλειδιών που θα σας επιτρέψουν να υπογράφετε αιτήματα ως λογαριασμός υπηρεσίας και ακόμη και να δημιουργείτε OAuth tokens για να εκτελείτε ενέργειες ως λογαριασμός υπηρεσίας. Αυτά τα κλειδιά είναι επικίνδυνα επειδή είναι πιο περίπλοκα να περιοριστούν και να ελεγχθούν, γι’ αυτό το GCP συνιστά να μην τα δημιουργείτε.
• Σημειώστε ότι κάθε φορά που δημιουργείται ένας SA, το GCP δημιουργεί ένα κλειδί για τον λογαριασμό υπηρεσίας που ο χρήστης δεν μπορεί να έχει πρόσβαση (και δεν θα αναφέρεται στην εφαρμογή ιστού). Σύμφωνα με αυτή τη συζήτηση, αυτό το κλειδί είναι χρησιμοποιούμενο εσωτερικά από το GCP για να δώσει πρόσβαση στα metadata endpoints για να δημιουργήσουν τα προσβάσιμα OAuth tokens.

Access scopes

Οι access scopes είναι συνδεδεμένες με τα παραγόμενα OAuth tokens για να αποκτήσουν πρόσβαση στα API endpoints του GCP. Αυτές περιορίζουν τις άδειες του OAuth token.
Αυτό σημαίνει ότι αν ένα token ανήκει σε έναν Ιδιοκτήτη ενός πόρου αλλά δεν έχει την κατάλληλη πρόσβαση στο scope του token για να αποκτήσει πρόσβαση σε αυτόν τον πόρο, το token δεν μπορεί να χρησιμοποιηθεί για (κακή) εκμετάλλευση αυτών των προνομίων.

Η Google στην πραγματικότητα συνιστά ότι οι access scopes να μην χρησιμοποιούνται και να βασίζεστε εντελώς στο IAM. Το διαδικτυακό διαχειριστικό portal επιβάλλει στην πραγματικότητα αυτό, αλλά οι access scopes μπορούν ακόμα να εφαρμοστούν σε περιπτώσεις χρησιμοποιώντας προσαρμοσμένους λογαριασμούς υπηρεσίας προγραμματισμένα.

Μπορείτε να δείτε ποιες scopes είναι καθορισμένες με ερώτημα:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Οι προηγούμενοι σκοποί είναι αυτοί που δημιουργούνται από προεπιλογή χρησιμοποιώντας gcloud για να αποκτήσετε πρόσβαση σε δεδομένα. Αυτό συμβαίνει επειδή όταν χρησιμοποιείτε gcloud πρώτα δημιουργείτε ένα OAuth token και στη συνέχεια το χρησιμοποιείτε για να επικοινωνήσετε με τα endpoints.

Ο πιο σημαντικός σκοπός από αυτούς είναι cloud-platform, που σημαίνει βασικά ότι είναι δυνατό να έχετε πρόσβαση σε οποιαδήποτε υπηρεσία στο GCP.

Μπορείτε να βρείτε μια λίστα με όλους τους πιθανούς σκοπούς εδώ.

Αν έχετε credentials του gcloud για τον περιηγητή, είναι δυνατό να αποκτήσετε ένα token με άλλους σκοπούς, κάνοντας κάτι όπως:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM Πολιτικές, Δεσμεύσεις και Μέλη

Όπως ορίζεται από το terraform στο https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, χρησιμοποιώντας το terraform με το GCP υπάρχουν διάφοροι τρόποι για να παραχωρήσετε σε έναν κύριο πρόσβαση σε έναν πόρο:

• Μέλη: Ορίζετε τους κύριους ως μέλη ρόλων χωρίς περιορισμούς πάνω στον ρόλο ή στους κύριους. Μπορείτε να βάλετε έναν χρήστη ως μέλος ενός ρόλου και στη συνέχεια να βάλετε μια ομάδα ως μέλος του ίδιου ρόλου και επίσης να ορίσετε αυτούς τους κύριους (χρήστης και ομάδα) ως μέλη άλλων ρόλων.
• Δεσμεύσεις: Πολλοί κύριοι μπορούν να δεσμευτούν σε έναν ρόλο. Αυτοί οι κύριοι μπορούν ακόμα να δεσμευτούν ή να είναι μέλη άλλων ρόλων. Ωστόσο, αν ένας κύριος που δεν είναι δεσμευμένος στον ρόλο οριστεί ως μέλος μιας δεσμευμένης ρόλου, την επόμενη φορά που η δέσμευση θα εφαρμοστεί, η ιδιότητα μέλους θα εξαφανιστεί.
• Πολιτικές: Μια πολιτική είναι αυθεντική, υποδεικνύει ρόλους και κύριους και στη συνέχεια, αυτοί οι κύριοι δεν μπορούν να έχουν περισσότερους ρόλους και αυτοί οι ρόλοι δεν μπορούν να έχουν περισσότερους κύριους εκτός αν αυτή η πολιτική τροποποιηθεί (ούτε καν σε άλλες πολιτικές, δεσμεύσεις ή μέλη). Επομένως, όταν ένας ρόλος ή κύριος καθορίζεται σε πολιτική, όλα τα προνόμια του είναι περιορισμένα από αυτή την πολιτική. Προφανώς, αυτό μπορεί να παρακαμφθεί σε περίπτωση που ο κύριος έχει τη δυνατότητα να τροποποιήσει την πολιτική ή άδειες κλιμάκωσης προνομίων (όπως η δημιουργία ενός νέου κύριου και η δέσμευσή του σε έναν νέο ρόλο).

Αναφορές

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

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

• Δείτε τα subscription plans!
• Εγγραφείτε στο 💬 Discord group ή την telegram group ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
• Μοιραστείτε τα hacking tricks υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.