# GCP - AppEngine Privesc

{{#include ../../../banners/hacktricks-training.md}}

## App Engine

Vir meer inligting oor App Engine, sien:

{{#ref}}
../gcp-services/gcp-app-engine-enum.md
{{#endref}}

### `appengine.applications.get`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.operations.list`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.create`, `appengine.versions.get`, `appengine.versions.list`, `cloudbuild.builds.get`,`iam.serviceAccounts.actAs`, `resourcemanager.projects.get`, `storage.objects.create`, `storage.objects.list`

Dit is die nodige toestemmings om **'n App te ontplooi met die `gcloud` cli**. Miskien kan die **`get`** en **`list`** permissies **vermyd** word.

Jy kan python-codevoorbeelde vind by [https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine)

Standaard sal die naam van die App-diens **`default`** wees, en daar kan net 1 instansie met dieselfde naam wees.\
Om dit te verander en 'n tweede App te skep, in **`app.yaml`**, verander die waarde van die wortelsleutel na iets soos **`service: my-second-app`**

<details>
<summary>Ontplooi App Engine-toepassing</summary>
```bash
cd python-docs-samples/appengine/flexible/hello_world
gcloud app deploy #Upload and start application inside the folder
```
</details>

Gee dit ten minste 10–15 minute; as dit nie werk nie, probeer **deploy weer 'n paar keer** en wag 'n paar minute.

> [!NOTE]
> Dit is **moontlik om die Service Account wat gebruik moet word aan te dui**, maar standaard word die App Engine default SA gebruik.

Die URL van die toepassing is iets soos `https://<proj-name>.oa.r.appspot.com/` of `https://<service_name>-dot-<proj-name>.oa.r.appspot.com`

### Werk ekwivalente toestemmings by

Jy mag genoeg toestemmings hê om 'n AppEngine op te dateer maar nie om 'n nuwe een te skep nie. In daardie geval, so kan jy die huidige App Engine opdateer:

<details>
<summary>Werk bestaande App Engine-toepassing by</summary>
```bash
# Find the code of the App Engine in the buckets
gsutil ls

# Download code
mkdir /tmp/appengine2
cd /tmp/appengine2
## In this case it was found in this custom bucket but you could also use the
## buckets generated when the App Engine is created
gsutil cp gs://appengine-lab-1-gcp-labs-4t04m0i6-3a97003354979ef6/labs_appengine_1_premissions_privesc.zip .
unzip labs_appengine_1_premissions_privesc.zip

## Now modify the code..

## If you don't have an app.yaml, create one like:
cat >> app.yaml <<EOF
runtime: python312

entrypoint: gunicorn -b :\$PORT main:app

env_variables:
A_VARIABLE: "value"
EOF

# Deploy the changes
gcloud app deploy

# Update the SA if you need it (and if you have actas permissions)
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
```
</details>

As jy **alreeds 'n AppEngine gekompromitteer het** en jy het die toestemming **`appengine.applications.update`** en **actAs** oor die service account wat jy gebruik, kan jy die service account wat deur AppEngine gebruik word wysig met:

<details>
<summary>Bywerk App Engine service account</summary>
```bash
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
```
</details>

### `appengine.instances.enableDebug`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.get`, `appengine.versions.list`, `compute.projects.get`

Met hierdie permissies is dit moontlik om **login via ssh in App Engine instances** van die tipe **flexible** (nie **standard** nie). Sommige van die **`list`** en **`get`** permissies **is dalk nie regtig nodig nie**.

<details>
<summary>SSH na App Engine instansie</summary>
```bash
gcloud app instances ssh --service <app-name> --version <version-id> <ID>
```
</details>

### `appengine.applications.update`, `appengine.operations.get`

Ek dink dit verander net die agtergrond-SA wat google sal gebruik om die toepassings op te stel, so ek dink nie jy kan dit misbruik om die service account te steel nie.

<details>
<summary>Werk toepassing se service account by</summary>
```bash
gcloud app update --service-account=<sa_email>
```
</details>

### `appengine.versions.getFileContents`, `appengine.versions.update`

Nie seker hoe om hierdie permissies te gebruik of of hulle nuttig is nie (let daarop dat wanneer jy die kode verander 'n nuwe weergawe geskep word, so ek weet nie of jy net die kode of die IAM-rol van een kan opdateer nie, maar ek raai jy behoort dit te kan, dalk deur die kode binne die bucket te verander??).

### Write Access over the buckets

Soos genoem genereer die appengine versions sekere data binne 'n bucket met die formaatnaam: `staging.<project-id>.appspot.com`. Let daarop dat dit nie moontlik is om hierdie bucket vooraf oor te neem nie omdat GCP gebruikers nie gemagtig is om buckets te skep wat die domeinnaam `appspot.com` gebruik nie.

Ewenwel, met lees- en skryftoegang tot hierdie bucket is dit moontlik om voorregte op te skerp na die SA wat aan die AppEngine version gekoppel is deur die bucket te monitor en elke keer as 'n verandering aangebring word, so gou moontlik die kode te wysig. Op hierdie manier sal die kontainer wat uit hierdie kode geskep word die **kode met 'n agterdeur uitvoer**.

Vir meer inligting en 'n **PoC, kyk die relevante inligting op hierdie bladsy**:

{{#ref}}
gcp-storage-privesc.md
{{#endref}}

### Write Access over the Artifact Registry

Alhoewel App Engine docker images binne Artifact Registry skep, is dit getoets dat **selfs as jy die image binne hierdie diens wysig** en die App Engine instance verwyder (sodat 'n nuwe een ontplooi word) die **uitgevoerde kode nie verander nie**.\
Dit kan moontlik wees dat deur 'n **Race Condition attack soos met die buckets dit moontlik is om die uitgevoerde kode oor te skryf**, maar dit is nie getoets nie.

{{#include ../../../banners/hacktricks-training.md}}
