In this research you’ll discover some of the common attack techniques used in Google Cloud Platform (GCP) to better understand how an attacker exploits this environment to 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 – <PROJECT NUMBER>[email protected]. 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
Dataproc & Dataflow service compromise
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:
| Dataproc | Dataflow |
|---|---|
| Google Cloud Dataproc is a fully managed and highly scalable service for running Apache Spark, Apache Flink, Presto, and 30+ open source tools and frameworks. Dataproc automation helps you create clusters quickly, manage them easily, and save money by turning clusters off when you don’t need them. | Google Cloud Dataflow is a cloud-based data processing service for both batch and real-time data streaming applications. Dataflow enables developers to set up processing pipelines for integrating, preparing and analyzing large data sets, such as those found in Web analytics or big data analytics applications. |
The jobs you run in the services control the services. Here are some new privilege escalation techniques we found that the attacker can use to compromise these services.
Create or update jobs to exploit service account
All the attacker needs in order to compromise the Dataproc and Dataflow services is access to these permissions:
| Dataproc | Dataflow |
|---|---|
| dataproc.clusters.create or existing dataproc cluster dataproc.jobs.update or dataproc.jobs.create iam.serviceAccounts.actAs | dataflow.jobs.create dataflow.jobs.updateContentsiam. serviceAccounts.actAs |
With these permissions, the attacker can create or update jobs and run any code they would 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 uses the same idea. It involves privilege escalation on the Composer service.
About Composer
Cloud Composer is a fully managed workflow orchestration service, enabling you to create, schedule, monitor, and manage workflows that span across clouds and on-premises data centers.
Cloud Composer is built on the popular Apache Airflow open source project and operates using the Python programming language.
Update composer and comprise a service account
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
With permissions to edit objects in storage buckets, in order to edit the code and update the environment, 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. 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 in order to close these security gaps and avoid a breach.
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.
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.
Related Topics
){kind=icon}
){kind=icon}
){kind=icon}
){kind=icon}
){kind=icon}