IBM Security X-Force Red took a deeper look at the Google Cloud Platform (GCP) and found a potential method an attacker could use to persist in GCP via the Google Cloud Shell.
Google Cloud Shell is a service that provides a web-based shell where GCP administrative activities can be performed. A web-based shell is a nice feature because it allows developers and administrators to manage GCP resources without having to install or keep any software locally on their system. From a technical perspective, Google notes that Cloud Shell is an ephemeral Debian Linux Virtual Machine (VM). What users interact with when they use Cloud Shell is actually a Docker container. To use Cloud Shell, you simply log in to the Google Cloud console and click the terminal icon, which starts up a Cloud Shell instance, as can be seen below.
Reading the previous paragraph, you probably saw the word “ephemeral” and wondered how you can persist in an ephemeral environment. The container spun up by Google Cloud Shell is ephemeral, but your home directory (/home) can hold up to 5GB of data and is persistent.
There is previous research showing how to use the .bashrc file to persist in Cloud Shell. That is in this Medium post made by Juan Berner in 2018. Persisting through the .bashrc file is one method to persist, but there is another option.
During our research, we discovered that the Google Cloud Shell has a unique capability at startup to read from a file in the home folder called .customize_environment. This file is not created by default, but once it is added it will run every time the Cloud Shell is started.
From an administrative perspective, this is a great convenience. If there are tools an admin frequently uses, but are not installed by default, they can write a script within the .customize_environment file to install any desired software, change the system’s configuration and more.
If you are a hacker, however, this feature may catch your attention for other reasons.
Bad guys, penetration testers and red teams typically have a similar goal after they initially breach an environment. That goal is to stay inside a compromised network, which means they need to have at least one method to maintain their access. In cybersecurity, we refer to this as persistence.
The .customize_environment file is a solid persistence option after initial access is gained to GCP. There is a lot of capability with this method. A command and control implant could be downloaded and run every time the Cloud Shell is started, or run a script run that steals tokens and posts them to the attacker’s server and so on. Outbound filtering on the Cloud Shell seemed extremely limited during testing. Below we checked for open TCP ports we could connect to outbound, and none were blocked.
Open outbound access means that a reverse shell is possible. In the example below we keep it simple and run a Netcat reverse shell using the following code in the .customize_environment file. This provides us remote access to the compromised Cloud Shell.
The next time Cloud Shell is started up we get a reverse shell.
You can see in the process list that .customize_environment is automatically called with Bash at startup and is still running the reverse shell.
There are downsides to this persistence method, however. For it to be effective, the victim must use Cloud Shell. If they are an infrequent user or don’t use Cloud Shell, this will not be a reliable or effective persistence method.
Another downside is that the first time an action is performed in Cloud Shell that requires authentication, it pops up an authorization window in the user’s browser that must be accepted before the command runs. If an unexpected pop-up comes up, a target could get suspicious and burn the persistence method.
A workaround to limit detection would be monitoring the user’s activity and waiting until they have made an API call before trying to perform activity that requires authentication. Lastly, if a user does not use Cloud Shell regularly the Home directory will be deleted after 120 days of inactivity.
Authorization popup from command using Curl to attempt to access the Metadata server
A key advantage of this persistence method is that the ability to detect or block it is very limited. Google does not currently provide for logging, firewall rules or etc. to apply to Cloud Shell.
The only way to effectively block this persistence method is to disable Cloud Shell for all users. Below are step-by-step instructions a Google admin user can use to disable Cloud Shell:
1. Login to the Google Admin console at https://admin.google.com/
2. Select Additional Google services on the left menu bar.
3. Now select Google Cloud Platform from the menu in the middle of the screen.
4. Click on Cloud Shell settings to open the Cloud Shell options menu.
5. Uncheck the box Allow access to Cloud Shell.
6. Lastly, click the SAVE button to save the configuration.
The Google Cloud Shell is now disabled for the organization.
In the end, using the .customize_environment file for persistence is a method that under the right conditions is a solid persistence option with limited detection capabilities.
If you’d like to schedule a consult with IBM Security X-Force visit: www.ibm.com/security/xforce?schedulerform