GCP - Storage Privesc
Berging
Basiese Inligting:
GCP - Storage Enumstorage.objects.get
storage.objects.get
Hierdie toestemming laat jou toe om lêers wat binne Cloud Storage gestoor is af te laai. Dit kan potensieel lei tot die eskalasie van voorregte omdat in sommige gevalle sensitiewe inligting daar gestoor word. Verder stoor sommige GCP-diens hul inligting in emmers:
GCP Composer: Wanneer jy 'n Composer-omgewing skep, sal die kode van al die DAGs binne 'n emmer gestoor word. Hierdie take mag interessante inligting binne hul kode bevat.
GCR (Container Registry): Die beeld van die houers word binne emmers gestoor, wat beteken as jy die emmers kan lees, sal jy die beelde kan aflaai en soek na lekke en/of bronkode.
storage.objects.setIamPolicy
storage.objects.setIamPolicy
Jy kan jou toestemming gee om enige van die vorige scenarios van hierdie afdeling te misbruik.
storage.buckets.setIamPolicy
storage.buckets.setIamPolicy
Vir 'n voorbeeld oor hoe om toestemmings met hierdie toestemming te wysig, kyk na hierdie bladsy:
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
storage.hmacKeys.create
Cloud Storage se "interoperabiliteit" funksie, ontwerp vir kruiswolk interaksies soos met AWS S3, behels die skepping van HMAC-sleutels vir Diensrekeninge en gebruikers. 'n Aanvaller kan dit uitbuit deur 'n HMAC-sleutel vir 'n Diensrekening met verhoogde voorregte te genereer, en sodoende voorregte binne Cloud Storage te eskaleer. Terwyl gebruiker-geassosieerde HMAC-sleutels slegs ophaalbaar is via die webkonsol, bly beide die toegangs- en geheimsleutels permanente toeganklik, wat potensiële rugsteun toegang tot berging bied. Daarteenoor is Diensrekening-gekoppelde HMAC-sleutels API-toeganklik, maar hul toegangs- en geheimsleutels is nie na skepping ophaalbaar nie, wat 'n laag van kompleksiteit vir voortdurende toegang toevoeg.
'n Ander uitbuitingskrip vir hierdie metode kan hier gevind word.
storage.objects.create
, storage.objects.delete
= Skryfregte vir Berging
storage.objects.create
, storage.objects.delete
= Skryfregte vir BergingOm 'n nuwe voorwerp binne 'n emmer te skep, benodig jy storage.objects.create
en, volgens die dokumente, benodig jy ook storage.objects.delete
om 'n bestaande voorwerp te verander.
'n Baie gewone uitbuiting van emmers waarin jy in die wolk kan skryf, is in die geval waar die emmer webbedienerlêers stoor, jy mag dalk nuwe kode stoor wat deur die webtoepassing gebruik sal word.
Komponis
Komponis is Apache Airflow wat binne GCP bestuur word. Dit het verskeie interessante kenmerke:
Dit hardloop binne 'n GKE-kluster, dus die SA wat deur die kluster gebruik word, is toeganklik deur die kode wat binne Komponis hardloop.
Dit stoor die kode in 'n emmer, daarom sal enigiemand met skryftoegang tot daardie emmer in staat wees om 'n DGA-kode te verander/toe te voeg (die kode wat Apache Airflow sal uitvoer) Dan, as jy skryftoegang tot die emmer het wat Komponis gebruik om die kode te stoor, kan jy privesc na die SA wat in die GKE-kluster hardloop.
Wolksfunksies
Wolksfunksiekode word gestoor in Berging, dus deur dit te oorwryf, is dit moontlik om willekeurige kode uit te voer.
Toepassingmotor
Toepassingmotorkode word gestoor in emmers, deur die kode te oorskryf, kan dit moontlik wees om willekeurige kode uit te voer. DIT IS NIE MOONTLIK NIE
Dit lyk asof houerlae in die emmer gestoor word, dalk dit verander?
GCR
Google Container Registry stoor die beelde binne emmers, as jy daardie emmers kan skryf, mag jy in staat wees om sydelings te beweeg na waar daardie emmers uitgevoer word.
Die emmer wat deur GCR gebruik word, sal 'n URL hê soortgelyk aan
gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
(Die boonste vlak subdomeine word gespesifiseer hier).
Verwysings
Last updated