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

Basiese Inligting:

GCP - Storage Enum

storage.objects.get

Hierdie toestemming laat jou toe om lêers wat in Cloud Storage gestoor is af te laai. Dit sal moontlik jou toelaat om voorregte te verhoog omdat in sommige gevalle sensitiewe inligting daar gestoor word. Boonop stoor sommige GCP-dienste hul inligting in emmers:

• GCP Composer: Wanneer jy 'n Composer Omgewing skep, sal die kode van al die DAGs in 'n emmer gestoor word. Hierdie take kan interessante inligting in hul kode bevat.

• GCR (Container Registry): Die beeld van die houers word in emmer gestoor, wat beteken dat as jy die emmers kan lees, jy die beelde sal kan aflaai en soek na lekke en/of bronkode.

storage.objects.setIamPolicy

Jy kan jou toestemming gee om enige van die vorige scenario's van hierdie afdeling te misbruik.

storage.buckets.setIamPolicy

Vir 'n voorbeeld van hoe om toestemmings met hierdie toestemming te wysig, kyk na hierdie bladsy:

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Cloud Storage se "interoperabiliteit" kenmerk, ontwerp vir kruis-cloud interaksies soos met AWS S3, behels die skepping van HMAC sleutels vir Diensrekeninge en gebruikers. 'n Aanvaller kan dit misbruik deur 'n HMAC-sleutel vir 'n Diensrekening met verhoogde voorregte te genereer, wat dus voorregte binne Cloud Storage verhoog. Terwyl gebruikers-geassosieerde HMAC-sleutels slegs via die webkonsol verkrygbaar is, bly beide die toegang en geheime sleutels perpetueel toeganklik, wat vir potensiële rugsteun toegang tot stoorplek toelaat. Aan die ander kant is HMAC-sleutels wat aan Diensrekeninge gekoppel is API-toeganklik, maar hul toegang en geheime sleutels is nie na skepping verkrygbaar nie, wat 'n laag van kompleksiteit vir voortdurende toegang byvoeg.

# 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

'n Ander exploit-skrip vir hierdie metode kan hier gevind word.

storage.objects.create, storage.objects.delete = Berging Skryf regte

Om 'n nuwe objek binne 'n emmer te skep, benodig jy storage.objects.create en, volgens die dokumentasie, benodig jy ook storage.objects.delete om 'n bestaande objek te wysig.

'n Baie gewone uitbuiting van emmers waar jy in die wolk kan skryf, is in die geval waar die emmer webbediener lêers stoor, jy mag in staat wees om nuwe kode te stoor wat deur die webtoepassing gebruik sal word.

Composer

Composer is Apache Airflow wat binne GCP bestuur word. Dit het verskeie interessante kenmerke:

• Dit loop binne 'n GKE-kluster, so die SA wat die kluster gebruik, is toeganklik deur die kode wat binne Composer loop

• Al die komponente van 'n composer omgewing (kode van DAGs, plugins en data) word binne 'n GCP-emmer gestoor. As die aanvaller lees- en skryfregte daaroor het, kan hy die emmer monitor en wanneer 'n DAG geskep of opgedateer word, 'n backdoored weergawe indien sodat die composer omgewing die backdoored weergawe van die berging sal kry.

Jy kan 'n PoC van hierdie aanval in die repo vind: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

• Cloud Functions kode word in Berging gestoor en wanneer 'n nuwe weergawe geskep word, word die kode na die emmer gestoot en dan word die nuwe houer van hierdie kode gebou. Daarom, om die kode te oorskryf voordat die nuwe weergawe gebou word, is dit moontlik om die wolk funksie te laat uitvoer willekeurige kode.

Jy kan 'n PoC van hierdie aanval in die repo vind: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine weergawes genereer sekere data binne 'n emmer met die formaat naam: staging.<project-id>.appspot.com. Binne hierdie emmer, is dit moontlik om 'n gids genaamd ae te vind wat 'n gids per weergawe van die AppEngine-toepassing sal bevat en binne hierdie gidse sal dit moontlik wees om die manifest.json lêer te vind. Hierdie lêer bevat 'n json met al die lêers wat gebruik moet word om die spesifieke weergawe te skep. Boonop is dit moontlik om die werklike name van die lêers, die URL na hulle binne die GCP-emmer (die lêers binne die emmer het hul naam vir hul sha1-hash verander) en die sha1-hash van elke lêer te vind.

Let daarop dat dit nie moontlik is om hierdie emmer vooraf oor te neem nie, omdat GCP-gebruikers nie gemagtig is om emmers te genereer met die domeinnaam appspot.com nie.

Met lees- en skryftoegang oor hierdie emmer, is dit egter moontlik om regte te eskaleer na die SA wat aan die App Engine weergawe geheg is deur die emmer te monitor en enige tyd wanneer 'n verandering gemaak word (nuwe weergawe), die nuwe weergawe so vinnig as moontlik te wysig. Op hierdie manier sal die houer wat van hierdie kode geskep word, die backdoored kode uitvoer.

Die genoemde aanval kan op baie verskillende maniere uitgevoer word, al hulle begin deur die staging.<project-id>.appspot.com emmer te monitor:

• Laai die volledige nuwe kode van die AppEngine weergawe na 'n ander en beskikbare emmer en berei 'n manifest.json lêer voor met die nuwe emmer naam en sha1 hashes daarvan. Dan, wanneer 'n nuwe weergawe binne die emmer geskep word, moet jy net die manifest.json lêer wysig en die kwaadwillige een op te laai.

• Laai 'n gewysigde requirements.txt weergawe op wat die kwaadwillige afhanklikhede kode sal gebruik en die manifest.json lêer met die nuwe lêernaam, URL en die hash daarvan opdateer.

• Laai 'n gewysigde main.py of app.yaml lêer op wat die kwaadwillige kode sal uitvoer en die manifest.json lêer met die nuwe lêernaam, URL en die hash daarvan opdateer.

Jy kan 'n PoC van hierdie aanval in die repo vind: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

• Google Container Registry stoor die beelde binne emmers, as jy kan daardie emmers skryf, mag jy in staat wees om lateraal te beweeg na waar daardie emmers uitgevoer word.

• Die emmer wat deur GCR gebruik word, sal 'n URL hê wat soortgelyk is aan gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Die topvlak subdomeine is hier gespesifiseer).

Hierdie diens is verouderd, so hierdie aanval is nie meer nuttig nie. Boonop, Artifact Registry, die diens wat hierdie een vervang, stoor nie die beelde in emmers nie.

Verwysings

• https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!

• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @hacktricks_live.

• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.