Over-Privileged Service Accounts Create Escalation of Privileges and Lateral Movement in Google Cloud

Introduction

In this blog, we’ve analyzed data from Netskope customers that include security settings of over 1 million entities in 156,737 Google Cloud (GCP) projects across hundreds of organizations (see Dataset and Methodology for more details on the dataset). 

We will specifically look at the configuration of service accounts, see what’s commonly occurring in the real world, and analyze how multiple security misconfigurations can lead to escalation of privileges and lateral movement. In this Netskope dataset, we observed:

1. Service Accounts with user-managed keys: Over 38% (4,160) of service accounts use user-managed keys, which are often not needed, require work to keep secure (e.g. key rotation), and create a larger attack surface for compromised credentials. Service accounts with user-managed keys are common, existing in 82% of the customers in this dataset.

2. Service Accounts with old user-managed keys: Of the 4,160 service accounts with user-managed keys, 89% of the service accounts have keys older than 90 days, and over 71% have keys older than a year with the oldest key at 8 years, 1 month. All of this shows the challenges in keeping up with best practices when self-managing keys, which then poses an even greater risk of compromised credentials attacks.

3. Over-privileged services accounts with old, user-managed keys: Of the 4,160 service accounts with user-managed keys, 26% (1,102) not only have old keys but are also over-privileged with project-level administrator privileges, such as the project owner/editor roles. This greatly increases the impact after compromise, as it allows wider lateral movement and escalation of privileges.

4. Over-privileged services accounts with old, user-managed keys and access to multiple projects: Of these 1,102 high-risk service accounts that are over-privileged with old user-managed keys, 10% (110) have access privileges to multiple projects, providing more opportunities for lateral movement.

5. Service account access risk from users: Access to over-privileged service accounts (item #3) can be gained not just from service account key compromise (items #1 and #2), but also from compromise of user accounts. 92 (1.3%) users have the iam.serviceAccountUser or iam.serviceAccountTokenCreator roles at the project level, allowing them to access or impersonate ALL service accounts within a project. 

As we can see, there is a cumulative, interrelated risk from the above misconfigurations around service accounts. We’ll be looking closer at:

• Service account design in GCP
• The interdependencies of these four controls
• How misconfigurations in the four controls can be chained by attackers to gain broader access to your GCP environment

Service Accounts

Before we dive into the data and risk analysis, we need to be clear on what service accounts are and how they’re used within GCP. Service accounts are security principals, but created for use by user scripts, applications, or Google services such as virtual machines—the service accounts have roles/permissions that govern the access of the scripts/applications/services using them. Services such as virtual machines can have service accounts attached to them so they run as that particular service account. They differ from user accounts in that:

• They do not have passwords
• Instead, they use RSA public/private key pairs which are used for authentication for Google API access
• Users can impersonate or “run as” a service account
• Finally, they are resources so user access to service accounts can be protected by IAM policies

Types

There are two