GCP - AppEngine Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
For more information about App Engine check:
GCP - App Engine Enumappengine.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.listThose are the needed permissions to deploy an App using gcloud cli. Maybe the get and list ones could be avoided.
You can find python code examples in https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine
By default, the name of the App service is going to be default, and there can be only 1 instance with the same name.
To change it and create a second App, in app.yaml, change the value of the root key to something like service: my-second-app
Give it at least 10-15min, if it doesn't work call deploy another of times and wait some minutes.
It's possible to indicate the Service Account to use but by default, the App Engine default SA is used.
The URL of the application is something like https://<proj-name>.oa.r.appspot.com/ or https://<service_name>-dot-<proj-name>.oa.r.appspot.com
You might have enough permissions to update an AppEngine but not to create a new one. In that case this is how you could update the current App Engine:
If you have already compromised a AppEngine and you have the permission appengine.applications.update and actAs over the service account to use you could modify the service account used by AppEngine with:
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.getWith these permissions, it's possible to login via ssh in App Engine instances of type flexible (not standard). Some of the list and get permissions could not be really needed.
appengine.applications.update, appengine.operations.getI think this just change the background SA google will use to setup the applications, so I don't think you can abuse this to steal the service account.
appengine.versions.getFileContents, appengine.versions.updateNot sure how to use these permissions or if they are useful (note that when you change the code a new version is created so I don't know if you can just update the code or the IAM role of one, but I guess you should be able to, maybe changing the code inside the bucket??).
As mentioned the appengine versions generate some data inside a bucket with the format name: staging.<project-id>.appspot.com. Note that it's not possible to pre-takeover this bucket because GCP users aren't authorized to generate buckets using the domain name appspot.com.
However, with read & write access over this bucket, it's possible to escalate privileges to the SA attached to the AppEngine version by monitoring the bucket and any time a change is performed, modify as fast as possible the code. This way, the container that gets created from this code will execute the backdoored code.
For more information and a PoC check the relevant information from this page:
GCP - Storage PrivescEven though App Engine creates docker images inside Artifact Registry. It was tested that even if you modify the image inside this service and removes the App Engine instance (so a new one is deployed) the code executed doesn't change. It might be possible that performing a Race Condition attack like with the buckets it might be possible to overwrite the executed code, but this wasn't tested.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
