Links

GCP - App Engine Enum

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:

Basic Information

Google Cloud Platform's (GCP) App Engine is a robust, serverless platform tailored for the development and hosting of web applications on a large scale. The design of this platform focuses on streamlining the development process and enhancing the manageability of applications. The key features and benefits of GCP's App Engine include:
  1. 1.
    Serverless Architecture: App Engine automatically handles the infrastructure, including server provisioning, configuration, and scaling. This allows developers to focus on writing code without worrying about the underlying hardware.
  2. 2.
    Automatic Scaling: App Engine can automatically scale your application in response to the amount of traffic it receives. It scales up to handle increased traffic and scales down when traffic decreases, helping optimize cost and performance.
  3. 3.
    Language and Runtime Support: It supports popular programming languages such as Java, Python, Node.js, Go, Ruby, PHP, and .NET. You can run your applications in a standard or a flexible environment. The standard environment is more restrictive but highly optimized for specific languages, while the flexible environment allows for more customization.
  4. 4.
    Integrated Services: App Engine integrates with many other GCP services, like Cloud SQL, Cloud Storage, Cloud Datastore, and more. This integration simplifies the architecture of cloud-based applications.
  5. 5.
    Versioning and Traffic Splitting: You can easily deploy multiple versions of your application and then split traffic among them for A/B testing or gradual rollouts.
  6. 6.
    Application Insights: App Engine provides built-in services such as logging, user authentication, and a suite of developer tools for monitoring and managing applications.
  7. 7.
    Security: It offers built-in security features like application versioning, SSL/TLS certificates for secure connections, and identity and access management.

Firewall

A simple firewall can be configured for the instances running the Apps with the following options:

SA

The default service account used by these Apps is <proj-name>@appspot.gserviceaccount.com which have Editor role over the project and the SAs inside APP Engine instance runs with cloud-platform scope (among others).

Storage

The source code and metadata is automatically stored in buckets with names such as <proj-id>.appspot.com and staging.<proj-id>.appspot.com and <country>.<proj-id>.appspot.com
Every file of the App is stored with the sha1 of the content as filename:
Inside the ae folder from staging.<proj-id>.appspot.com, one folder per version exist with the source code files and manifest.json file that describes the components of the App:
{"requirements.txt":{"sourceUrl":"https://storage.googleapis.com/staging.onboarding-host-98efbf97812843.appspot.com/a270eedcbe2672c841251022b7105d340129d108","sha1Sum":"a270eedc_be2672c8_41251022_b7105d34_0129d108"},"main_test.py":{"sourceUrl":"https://storage.googleapis.com/staging.onboarding-host-98efbf97812843.appspot.com/0ca32fd70c953af94d02d8a36679153881943f32","sha1Sum":"0ca32fd7_0c953af9_4d02d8a ...

Containers

The web app will ultimately be executed inside a container and Code Build is used to build the container.

URLs & Regions

The default web page will be exposed in the URL <project-uniq-name>.appspot.com although the URL of older versions will be slightly different, like https://20240117t001540-dot-<project-uniq-name>.uc.r.appspot.com (note the initial timestamp).
It might look like it's only possible to deploy 1 app engine web application per region, but it's possible to indicate service: <servicename> in the app.yml and create a new service (a new web). The format of the URL for this new web will be <servicename>-dot-<project-uniq-name>.appspot.com.

Enumeration

Every time you uploads a new code to the App, a new version is created. All versions are stored and they even have an URL to access them. So modifying the code of an old version could be a great persistence technique.
As with Cloud Functions, there is a chance that the application will rely on secrets that are accessed at run-time via environment variables. These variables are stored in an app.yaml file which can be accessed as follows:
# List the apps
gcloud app services list
gcloud app services describe <app-name>
# Access via browser to the specified app
gcloud app services browse <app-name>
# Get App versions
gcloud app versions list
# Get all the info of the app and version, included specific verion URL and the env
gcloud app versions describe -s <app-name> <version-id>
# Logs
gcloud app logs tail -s <app-name>
# Instances
## This is only valid if a flexible environment is used and not a standard one
gcloud app instances list
gcloud app instances describe -s <app-name> --version <version-id> <ID>
## Connect to the instance via ssh
gcloud app instances ssh --service <app-name> --version <version-id> <ID>
# Firewalls
gcloud app firewall-rules list
gcloud app firewall-rules describe <num_fw>
# Get domains
gcloud app domain-mappings list
gcloud app domain-mappings describe <name>
# SSl certificates
gcloud app ssl-certificates list
gcloud app ssl-certificates describe <name>

Privilege Escalation

Unauthenticated Enum

Post Exploitation

Persistence

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks: