From Zero to Hero
Nowadays, more and more organizations are migrating their on-premises environments to the cloud. Cloud platforms are more secure on certain levels, but IT and security teams must understand the weak points. One notable weak point is misconfigured identities, especially service accounts in the Google Cloud Platform (GCP).
Basic Privilege Escalation Techniques
The first challenge a threat actor faces when attacking a Google Cloud environment is gaining the valid access token of a GCP user. This token may be obtained by server-side request forgery, phishing, or accessing a developer’s local file system.
After bypassing this challenge however, the real test for an attacker begins — abusing a user’s permissions to compromise the GCP environment. With luck, the compromised user will be able to escalate privileges by one or more of the commonly used techniques, for example:
iam.roles.update — allows you to edit the permissions of your given custom IAM role, and basically grant yourself higher privileges.
iam.serviceAccounts.getAccessToken — allows you to request an access token for a service account, which may be more privileged than you.
Nowadays, blue teams invest lots of effort to prevent these risks by implementing the least privilege principal. Consequently, it makes it very difficult for attackers to escalate privileges from their regular user.
Least Privilege Principal in Google Cloud
The principle of least privilege states that a cloud resource should only have access to the exact resources it needs in order to function.
For example, if an IT user is the owner of a specific database, then the permissions should be restricted to “owner” permissions on exactly one database, i.e., “owner” permissions at the resource level.
During my latest GCP assessments, I have noticed that blue teams have a high awareness of the least privilege principal among users, but sometimes they do not pay enough attention to other identities, such as service accounts.
What is a Service Account?
A service account is a special kind of GCP account identified by its email address, which is unique to the given project. Service accounts are used by services such as Google Kubernetes Engine (GKE), Cloud Functions, and Compute Engine virtual machine (VM) instances. Resources use service accounts to make authorized API calls.
Threat actors might abuse the fact that some service accounts have excessive privileges in order to move laterally and escalate privileges in the GCP environment.
Abusing Google Compute Engine Default Service Accounts
One common example is the Compute Engine default service accounts.
New projects that have enabled the Compute Engine API will have a Compute Engine default service account. This service account is created with the IAM basic “Editor” role, which is highly privileged in the project.
The Compute Engine service account is attached by default to all instances created by the Google Cloud CLI and the Google Cloud console, unless a different service account, or no service account at all, is specified during the instance creation.
In addition, the default scope of this account is: “https://www.googleapis.com/auth/cloud-platform.” This scope enables the service account to have full access to the enabled GCP APIs. Thus, if one Compute Engine instance gets compromised, the attacker can move laterally across the other instances in the project. In addition, the attacker can take over other GCP services by abusing the “Editor” role and the default API access scope.
Therefore, it is highly recommended to pay attention to the default service accounts to increase your cloud environment’s security. However, it’s not enough…
Abusing Misconfigured Custom Service Accounts
These examples are not just hypothetical. In one of my latest cloud assessments, I could tell that the organization was highly mature and followed the Least Privilege Principle in an exceptional way.
Yet, despite all their efforts, I managed to take over the cloud environment by exploiting one custom service account that did not follow the principle precisely.
My adventure began as a regular developer user in a GCP environment. After a quick and brief scout, I noticed that my user did not have any permissions, which allowed me to escalate my privileges using the classic techniques. One thing in particular that caught my attention, however, was the Kubernetes cluster that I had access to.
While wandering around, I found a GCP service account’s access key, which was stored as a Kubernetes secret. Happy and hopeful, I logged in to the environment with the obtained access key.
But unfortunately, the service user did not seem to be so helpful — the strongest permissions only granted the ability to read and write storage buckets.
At this point, I was at a major crossroads. I had an extremely interesting find, as I was able to retrieve a valid key which was stored as a cleartext secret, but at the same time, I had nothing that was worth immediate reporting. After thinking of what my next step could be, I decided to pool all of my resources together and get to the content of all the storage buckets to try and find something useful. Through this, I managed to find several certificates and cleartext credentials for third-party services. And while this was nice, I still wanted to achieve my “knockout.”
Not giving up hope, I continued with my search through the buckets and, sooner than expected, I found my “knockout.”
I discovered that one of the storage buckets contained Terraform configuration files. After a quick conversation with the environment owners, I understood that these files are used by Terraform to control several services in the cloud environment. By altering these files, I could fundamentally affect the confidentiality, integrity, and availability of all these services — including the Compute Engine disks, VPC networks, GKE clusters, Redis instances, Google Storage objects, and IP addresses, to name a few.
Mitigation and Suggestions
Now that you understand how the service account misconfiguration can be used to compromise the Google cloud environment, I recommend taking these actions as soon as possible:
- GCP predefined roles (Owner, Editor, Viewer) include thousands of permissions across all Google Cloud services. Avoid granting basic roles unless there is no alternative. Instead, grant the most limited predefined roles or custom roles that meet your needs.
- Follow the principle of least privilege and revoke the “Editor” role from the default Compute Engine service account.
- After revoking the editor role, add as many specific roles as possible to the modified default service account.
- If possible, try not to use the default service account. Create custom service accounts for Compute Engine instances.
- Rotate service account keys on a regular basis.
- Don’t check in service account keys into source codes or configurations.
- Use logs from Cloud Audit Logs to regularly audit access to service account keys.
Shani Peled successfully completed her Cyber Shield Course within the Israeli Defense Forces, where she also served in an underground unit and as a team leader. Shani currently works as a Red Team Expert at CYE, and as an esteemed all-rounder, specializes in all matters related to the cyber security field.
