GCP - Storage Privesc

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

Αποθήκευση

Basic Information:

GCP - Storage Enum

storage.objects.get

Αυτό το δικαίωμα σας επιτρέπει να κατεβάζετε αρχεία αποθηκευμένα στο Cloud Storage. Αυτό ενδέχεται να σας επιτρέψει να αποκτήσετε αυξημένα προνόμια, επειδή σε ορισμένες περιπτώσεις ευαίσθητες πληροφορίες αποθηκεύονται εκεί. Επιπλέον, ορισμένες υπηρεσίες GCP αποθηκεύουν τις πληροφορίες τους σε buckets:

  • GCP Composer: Όταν δημιουργείτε ένα Composer Environment ο κώδικας όλων των DAGs θα αποθηκευτεί μέσα σε ένα bucket. Αυτές οι εργασίες μπορεί να περιέχουν ενδιαφέρουσες πληροφορίες μέσα στον κώδικά τους.
  • GCR (Container Registry): Το image των containers αποθηκεύεται μέσα σε buckets, που σημαίνει ότι αν μπορείτε να διαβάσετε τα buckets θα μπορείτε να κατεβάσετε τα images και να αναζητήσετε leaks και/ή τον πηγαίο κώδικα.

storage.objects.setIamPolicy

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

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

Για παράδειγμα σχετικά με το πώς να τροποποιήσετε permissions με αυτό το permission, δείτε αυτή τη σελίδα:

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Η λειτουργία “interoperability” του Cloud Storage, σχεδιασμένη για cross-cloud interactions όπως το AWS S3, αφορά την δημιουργία HMAC keys για Service Accounts και χρήστες. Ένας επιτιθέμενος μπορεί να το εκμεταλλευτεί δημιουργώντας ένα HMAC key για ένα Service Account με αυξημένα προνόμια, αυξάνοντας έτσι τα προνόμια εντός του Cloud Storage. Ενώ τα HMAC keys που σχετίζονται με χρήστες ανακτώνται μόνο μέσω του web console, τόσο τα access όσο και τα secret keys παραμένουν διαρκώς προσβάσιμα, επιτρέποντας πιθανή αποθήκευση για backup πρόσβασης. Αντίθετα, τα HMAC keys που συνδέονται με Service Accounts είναι προσβάσιμα μέσω API, αλλά τα access και secret keys τους δεν μπορούν να ανακτηθούν μετά τη δημιουργία, προσθέτοντας ένα επίπεδο πολυπλοκότητας για τη διατήρηση συνεχούς πρόσβασης.

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"storage-sa@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

Another exploit script for this method can be found here.

storage.objects.create, storage.objects.delete = Storage Write permissions

Για να create a new object μέσα σε ένα bucket χρειάζεστε το storage.objects.create και, σύμφωνα με the docs, χρειάζεστε επίσης το storage.objects.delete για να modify ένα υπάρχον αντικείμενο.

Μια πολύ common exploitation των buckets όπου μπορείτε να γράψετε στο cloud είναι στην περίπτωση που το bucket αποθηκεύει αρχεία web server, μπορεί να είστε σε θέση να store new code που θα χρησιμοποιηθεί από την web εφαρμογή.

Composer

Composer είναι Apache Airflow managed μέσα στο GCP. Έχει αρκετά ενδιαφέροντα χαρακτηριστικά:

  • Τρέχει μέσα σε ένα GKE cluster, οπότε το SA που χρησιμοποιεί το cluster είναι προσβάσιμο από τον κώδικα που τρέχει μέσα στο Composer
  • Όλα τα components ενός Composer environment (code of DAGs, plugins και data) αποθηκεύονται σε ένα GCP bucket. Αν ο attacker έχει read και write δικαιώματα πάνω σε αυτό, θα μπορούσε να παρακολουθεί το bucket και whenever a DAG is created or updated, submit a backdoored version ώστε το Composer environment να πάρει από το storage την backdoored έκδοση.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Ο κώδικας των Cloud Functions αποθηκεύεται στο Storage και κάθε φορά που δημιουργείται μια νέα έκδοση ο κώδικας ωθείται στο bucket και στη συνέχεια χτίζεται το νέο container από αυτόν τον κώδικα. Συνεπώς, overwriting the code before the new version gets built it’s possible to make the cloud function execute arbitrary code.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

Οι AppEngine versions δημιουργούν κάποια δεδομένα μέσα σε ένα bucket με το format όνομα: staging.<project-id>.appspot.com. Μέσα σε αυτό το bucket, είναι δυνατό να βρείτε έναν φάκελο με όνομα ae που θα περιέχει έναν φάκελο ανά version της AppEngine εφαρμογής και μέσα σε αυτούς τους φακέλους θα είναι δυνατό να βρείτε το αρχείο manifest.json. Αυτό το αρχείο περιέχει ένα json με όλα τα αρχεία που πρέπει να χρησιμοποιηθούν για να δημιουργηθεί η συγκεκριμένη έκδοση. Επιπλέον, είναι δυνατό να βρείτε τα πραγματικά ονόματα των αρχείων, το URL τους μέσα στο GCP bucket (τα αρχεία μέσα στο bucket άλλαξαν το όνομά τους σε sha1 hash) και το sha1 hash κάθε αρχείου.

Note that it’s not possible to pre-takeover this bucket because GCP users aren’t authorized to generate buckets using the domain name appspot.com.

Ωστόσο, με read & write πρόσβαση σε αυτό το bucket, είναι δυνατό να πραγματοποιηθεί escalation privileges προς το SA που είναι attached στην App Engine version παρακολουθώντας το bucket και κάθε φορά που γίνεται μια αλλαγή (νέα έκδοση), να τροποποιήσετε τη νέα έκδοση όσο το δυνατόν πιο γρήγορα. Με αυτόν τον τρόπο, το container που δημιουργείται από αυτόν τον κώδικα θα εκτελέσει τον backdoored κώδικα.

Η αναφερόμενη επίθεση μπορεί να πραγματοποιηθεί με πολλούς διαφορετικούς τρόπους, όλοι ξεκινούν παρακολουθώντας το staging.<project-id>.appspot.com bucket:

  • Upload the complete new code of the AppEngine version to a different and available bucket and prepare a manifest.json file with the new bucket name and sha1 hashes of them. Then, when a new version is created inside the bucket, you just need to modify the manifest.json file and upload the malicious one.
  • Upload a modified requirements.txt version that will use a the malicious dependencies code and update the manifest.json file with the new filename, URL and the hash of it.
  • Upload a modified main.py or app.yaml file that will execute the malicious code and update the manifest.json file with the new filename, URL and the hash of it.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry αποθηκεύει τα images μέσα σε buckets, αν μπορείτε να write those buckets ίσως να μπορέσετε να move laterally to where those buckets are being run.
  • Το bucket που χρησιμοποιεί το GCR θα έχει ένα URL παρόμοιο με gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (The top level subdomains are specified here).

Tip

This service is deprecated so this attack is no longer useful. Moreover, Artifact Registry, the service that substitutes this one, does’t store the images in buckets.

Αναφορές

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