Google-sudoers Privilege Escalation

  • 13 June 2022
  • 0 replies
Google-sudoers Privilege Escalation

In this series of articles, we will discuss a variety of MITRE ATT&CK techniques for Google Cloud Platform (GCP). The articles will cover techniques such as persistence, privilege escalation, lateral movement, and more. The first technique we will discuss is privilege escalation in GCP through a process called "google-guest-agent".


Google Compute Engine Services

Google Compute Engine (GCE) has some services that are run by the systemd daemon, including "google-guest-agent.service". This service is responsible for executing the binary "google-guest-agent" at boot. As we can see the agent is child of the init process and is running as root.


What is google-guest-agent?

‘Google-guest-agent’ is a daemon that is responsible for handling GCE platform features. The guest agent functionality can be separated into various areas of responsibility. Historically, on Linux these were managed by separate independent processes, but today they are all managed by the guest agent.

The guest agent handles the following features:

  • Account management
  • OS-Login
  • Clock Skew
  • Network
  • Instance Setup

In this article we will discuss the Account management feature when OS-Login is disabled. One of the main goals of the agent is provisioning and deprovisioning user accounts. The agent creates local user accounts and maintains the authorized SSH keys file for each. User account creation is based on adding and removing SSH Keys stored in metadata. The SSH keys are taken from the metadata server.

What is the metadata server?

Every Google virtual machine (VM), also known as Google Compute Engine (GCE), stores its metadata on a metadata server as key:value pairs. The VM has automatic read access to the metadata server API without any additional authorization. The metadata provides information about the GCE instance and the project it belongs to. The internal IP of the metadata is and the domain is

GCP resource hierarchy

Google Cloud resources are organized hierarchically, where the organization node is the root node in the hierarchy, the projects are the children of the organization, and the other resources, such as instances, are descendants of projects. Every instance under a project will inherit by default the SSH keys that exist at the project level. In the screenshot below you can see that the instance inherited the SSH keys from the project level:

Where does privilege escalation come into the picture?

The interesting part is that when OS-Login is disabled, every user that is shown under the metadata SSH keys (instance/project) will be automatically added to the google-sudoers group by the google-guest-agent process.

Users that are part of the google-sudoers group can use sudo and execute commands as root. This is mentioned in the GCP docs.

What is google-sudoers group?

Let's start by explaining what sudo and sudoers file are. The word sudo is an abbreviation of "super user do" and is a Linux command that allows programs to be executed as a super user (root). Users with sudo permission are called sudo users. Management of all these sudo users is done through file called sudoers file.

The "/etc/sudoers" file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands. The sudoers file includes a directory with the name "sudoers.d". The purpose of the directory is to save local changes in case of upgrading the system, and in contrast to the "/etc/sudoers" file, this is under control of the distribution packages manager.

Below, we can see there is a file named "google_sudoers" in the directory. In this file we can see a declaration of a new sudoers group named "google-sudoers", which means that every user under this group will gain sudo privileges.

As we can see in the source code of "google_guest_agent" binary, there is a for loop over the SSH keys values from the metadata, and each user from there is added to google-sudoers group.

Proof of Concept

We will create a weak user to show how to escalate privileges. To escalate our weak (unprivileged) user to a privileged one we need to edit the metadata, whether it is at the instance level or at the project level. To do this we need a service-account with one of the following permissions:

  • compute.instances.setMetadata – instance-level, only the current instance will be affected.
  • compute.projects.setCommonInstanceMetadata – project-level, all the instances under the project will be affected.

Creating a weak user

Let's create a weak user without sudo privileges. As we can see, there are currently only two users in the google-sudoers group. The weak user will not be able to use sudo because he is not in the sudoers file.

Adding SSH keys to the metadata

We are logged in with the default service account of GCE instances, and by default this service account has the editor role. The editor role enables a user to edit metadata for both the instance and the project. Now we will add SSH keys at the instance level for our "weakuser".

After we add the SSH keys, the process "google_guest_agent" will notice the changes and will add the "weakuser” to the "google_users" file that is located at "/var/lib/google/google_users". After our user will be in the "google_users" file he will be added to the google-sudoers group.

Weakuser can now enjoy sudo privileges

Now, our "weakuser" is not weak anymore 😊.

He is now part of the google-sudoers group and can execute commands as sudo!


Firstly, ensure that only service-accounts that you trust have permission to edit the metadata. Editing metadata is a high privilege, especially at the project level. The next mitigation is to enable OS-Login at the instance level by adding "enable-oslogin=TRUE" to the metadata.

What is OS-Login?

Earlier in the article we described the Google Compute Engine platform features that the guest agent is handling, which includes OS-Login. OS-Login is a feature that is used to manage SSH access to instances using IAM without having to create and manage individual SSH keys. OS-Login maintains a consistent Linux user identity across VM instances and is the recommended way to manage many users across multiple instances or projects. When OS-Login is enabled, all the SSH connections will be made by authenticated users from the IAM.

How does enabling OS-Login protect you from attacks?

When OS-Login is enabled, the guest agent will not maintain connections to the instance via SSH keys. It will also deactivate the feature of adding users to google-sudoers group, thereby preventing an attacker from escalating privileges to a compromised instance.

You may ask yourself that if an attacker with project-level access can edit the metadata, why wouldn’t he just disable OS-Login? The attacker may be able to edit metadata to disable OS-Login, but the important thing is at which level he is editing the metadata. If an attacker changes the metadata at the project level, any changes he may make to the metadata can be overridden at the instance level.

As shown in the screenshot below, the value of the enable variable at the project-level will be overridden by the value at the enable variable of the instance-level.

If you want to fully prevent a scenario of an attacker disabling your OS-Login at the instance level, you can use OS-Login organization-policy.

To ensure that all new projects, and the VM instances created in these new projects, have OS-Login enabled, you can set up the following OS-Login constraint in your organization:

“gcloud beta resource-manager org-policies enable-enforce compute.requireOsLogin \ --organization=organization-id”

When this constraint is set up, the following conditions are applied:

  • enable-oslogin=true is included in the project metadata for all new projects.
  • Requests that set enable-oslogin to false in VM or project metadata are rejected for new and existing VMs and projects.

To read the documentation for managing OS-Login, see - Manage OS Login in an organization.

Future plans

In the next article, we will discuss another method of privilege escalation that will lead to Remote Code Execution (RCE) at root privileges and a GCP service named “google-startup-scripts”.

Stay tuned!

0 replies

Be the first to reply!