New Privilege Escalation Techniques that Might Compromise Your Google Cloud Platform
Written by Idan Strovinsky & Zur Ulianitzky — March 28,2022
In this blog, we’ll describe some common attack techniques that an attacker can use to exploit your Google Cloud Platform (GCP) environment, gain permissions, and steal information.
Auto-create Service Account Backdoor
About service accounts
A GCP service account is a type of Google account whose purpose is to interact with non-human users that require authentication, in order to fetch information over Google APIs.
Auto-create a service account backdoor
There’s one service account that an attacker can leverage, and its permissions let them do everything in your project.
Its name is <PROJECT NUMBER>-compute@developer.gserviceaccount.com. If the attacker can just compromise this service account in its default form, they can wreak havoc in your project.
There are ways for the attacker to create this default service account. When you create a service, but you create it without a specific service account, it’s created with the default. And GCP attaches the Editor role to it.
The GCP Editor role can do everything on your project. It can’t change permissions, but it doesn’t need this because it already has all the permissions it needs.
So the attacker creates a service, and the prize is this powerful default service account. With it, all the attacker needs is enough permissions to compromise a service. Below, we’ll show how the attacker does this using privilege escalation techniques.
Mitigation advice
To mitigate against this technique, don’t leave the default service account with the default permissions. Rather, attach permissions to this default service account that enforce the Principle of Least Privilege.
New Privilege Escalation Techniques
Privilege escalation with Dataproc & Dataflow
Based on the Auto-create Service Account Backdoor technique, what the attacker wants is to compromise a service, and then the attacker can exploit the service account within that service and wreak havoc.
So they’ll be looking for services that they can compromise without too much difficulty. Two such services are Dataproc and Dataflow:
The jobs you run in the Dataproc and Dataflow services control the services. All the attacker needs in order to compromise the services is access to these permissions to create or update jobs:
With these permissions, the attacker can run any code they like. In this way, they can totally compromise your Dataproc and Dataflow accounts.
As an example, the attacker could upload a JAR file to GCP storage:
Mitigation advice
- Whenever you create a new service, ensure that the service account uses the minimum permissions.
- Limit which users or service accounts can create Dataproc and Dataflow jobs.
Privilege escalation with Composer
We just went through two privilege escalation techniques that are very similar to each other. We’ll show you one more that is a little more complex, but it employs the same idea. It involves privilege escalation on the Composer service.
Cloud Composer is a fully managed workflow orchestration service, enabling you to create, schedule, monitor, and manage workflows that span across clouds and on-premise data centers.
Cloud Composer is built on the popular Apache Airflow open-source project, and it operates using the Python programming language.
The attacker that compromises Composer can use the service account linked to it with its permissions.
All the attacker needs to exploit the service account linked to Composer is to access permissions:
- storage.objects.update
- composer.environments.get
If you can edit objects in storage buckets, then you can edit the code and update the environment. Therefore, with permissions to edit these objects, the attacker can compromise the Composer’s service account and permissions and use them as they wish.
As an example, below you see how the code is located within the bucket, in the DAGs folder:
The attacker updates the file by uploading a new version with malicious code. Then the attacker updates the Composer DAG with the new file version, by running this command:
gcloud composer environments storage dags import --environment ENVIRONMENT_NAME --location LOCATION --source LOCAL_FILE
Following this, the attacker updates the code with the malicious version, running commands from the Composer’s service account.
Mitigation advice
- Whenever you create a new service, ensure that the service account uses the minimum permissions.
- Limit which users or service accounts can create Composer jobs.
Summary
In this blog, you saw a few of the techniques used by attackers in order to compromise your GCP environment.
A typical technique flow might be:
- The attacker uses the Auto-create Service Account Backdoor technique to create the powerful default service account.
- The attacker compromises Dataproc, Dataflow, or Composer using the privilege escalation techniques we described, which most people in the industry are less familiar with.
- Armed with the powerful service account, the attacker can wreak their havoc in your GCP projects, not necessarily limited to Dataproc, Dataflow, and Composer.
XM Cyber Attack Path Management continuously and safely models these attack techniques to discover them in your GCP environment. Then it immediately flags the remediation steps needed so you can close these security gaps and avoid a breach.
The XM Cyber arsenal is full of new GCP techniques such as the above. Ready to start an assessment of your GCP environment? Contact us today! You’ll be surprised to discover what security hygiene issues exist in your environment that allow attackers to make their way to your critical assets.
