GCP - AppEngine Privesc

Soutenez HackTricks

App Engine

Pour plus d'informations sur App Engine, consultez :

GCP - App Engine Enum

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

Ce sont les permissions nécessaires pour déployer une App en utilisant gcloud cli. Peut-être que les permissions get et list pourraient être évitées.

Vous pouvez trouver des exemples de code python sur https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine

Par défaut, le nom du service App sera default, et il ne peut y avoir qu'une seule instance avec le même nom. Pour le changer et créer une deuxième App, dans app.yaml, changez la valeur de la clé racine en quelque chose comme service: my-second-app

cd python-docs-samples/appengine/flexible/hello_world
gcloud app deploy #Upload and start application inside the folder

Donnez-lui au moins 10-15 minutes, si cela ne fonctionne pas, appelez deploy another of times et attendez quelques minutes.

Il est possible d'indiquer le Service Account à utiliser mais par défaut, le SA par défaut de App Engine est utilisé.

L'URL de l'application est quelque chose comme https://<proj-name>.oa.r.appspot.com/ ou https://<service_name>-dot-<proj-name>.oa.r.appspot.com

Mettre à jour les permissions équivalentes

Vous pourriez avoir suffisamment de permissions pour mettre à jour un AppEngine mais pas pour en créer un nouveau. Dans ce cas, voici comment vous pourriez mettre à jour l'App Engine actuel :

# 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

Si vous avez déjà compromis un AppEngine et que vous avez la permission appengine.applications.update et actAs sur le compte de service à utiliser, vous pouvez modifier le compte de service utilisé par AppEngine avec :

gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com

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

Avec ces permissions, il est possible de se connecter via ssh dans les instances App Engine de type flexible (pas standard). Certaines des permissions list et get pourraient ne pas être vraiment nécessaires.

gcloud app instances ssh --service <app-name> --version <version-id> <ID>

appengine.applications.update, appengine.operations.get

Je pense que cela change simplement le SA de fond que Google utilisera pour configurer les applications, donc je ne pense pas que vous puissiez abuser de cela pour voler le compte de service.

gcloud app update --service-account=<sa_email>

appengine.versions.getFileContents, appengine.versions.update

Pas sûr de savoir comment utiliser ces permissions ou si elles sont utiles (notez que lorsque vous modifiez le code, une nouvelle version est créée, donc je ne sais pas si vous pouvez simplement mettre à jour le code ou le rôle IAM d'une version, mais je suppose que vous devriez pouvoir le faire, peut-être en changeant le code à l'intérieur du bucket??).

Accès en écriture sur les buckets

Même avec un accès en écriture sur les buckets où le code source est situé il N'ÉTAIT PAS possible d'exécuter du code arbitraire en modifiant le code source et le manifest.json. Peut-être que si vous surveillez le bucket et détectez le moment où une nouvelle version est créée et que le code source et le manifest sont téléchargés, il pourrait être possible de les changer pour que la nouvelle version utilise ceux avec une porte dérobée??

Il semble également que les couches de conteneurs soient stockées dans le bucket, peut-être les changer?

Soutenez HackTricks

Last updated