Compromised Endpoint to Compromised GCP : Gone in 60 Seconds
In this article, we will discuss how you can take over google cloud accounts, if you have compromised an endpoint. Once you get a hang of it, it will take you less than 60 seconds to do this.
A gcloud story
If you are familiar with google cloud, you might be familiar with gcloud as well. It is a very powerful command line tool that pretty much lets you do everything. gcloud ( and gsutil in some cases ) to google cloud is like powershell to windows.
If you use powershell to query AD, it will use your credentials stored in lsass to authenticate and if successful , it will return the result of your query based on your privileges.
In this same manner, gcloud stores credentials but not in memory, on disk, IN CLEAR TEXT, under folder named gcloud. ( You see where I am going with this …!!?? )
Depending on the operating system, this folder is located at different places.
MacOS : /Users/<username>/.config/gcloud/
Linux : /home/<username>/.config/gcloud/
Windows : C:\Users\<username>\AppData\Roaming\gcloud\The files that store this credentials are called access_tokens.db and credentials.db. These are SQLite databases which can be accessed using following commands.
$ cd /home/<username>/.config/gcloud$ sqlite3 access_tokens.db
> select * from access_tokens;> select account_id, access_token, token_expiry from access_tokens WHERE account_id=redteam-operator-1@redteam.com;$ sqlite3 credentials.db
> select * from credentials;> select account_id, value from credentials WHERE account_id=redteam-operator-1@redteam.com;
The access tokens database stores account id , access token value as well as token expiry. All these values are very useful for the next steps.
The credentials database stores account id and as well as values of cliend_id , client_secret etc. which will come in handy as well.
The Proof of Concept
Now that we have learned some basics, let’s see how we can (ab)use this to our advantage.
Spin up two docker containers. One of them will be your attacker and the other one will be your victim. Make sure you have installed gcloud on them. You can follow this article to install gcloud.
Victim
We will authenticate using victim container. Then we will transfer these databases from victim to attacker to simulate exfil.
# root@<victim-container>:/# gcloud auth login --no-launch-browser# root@<victim-container>:/# gcloud projects list
Attacker
Once successfully authenticated in victim container , copy access_tokens.db and credentials.db into attacker container.
On the ATTACKER container, make sure you overwrite existing databases under /root/.config/gcloud/ directory. The path may change based on OS and user.
# root@<attacker-container>:/# gcloud auth list# root@<attacker-container>:/# gcloud config set account redteam-operator-1@redteam.com# root@<attacker-container>:/# gcloud projects list
Now sit back and enjoy the account takeover.
Consideration During Red Team Op
If you run into user who has multiple account_ids in the database, you would want to pick the account for which access token has not expired. You can use SQLite queries shown below to find out account token that has not expired.
One other thing you would want to consider is putting persistence in Google Cloud since you will loose access once token expires. There are many different methods you can use which will be covered in a separate article.
Obviously one of the methods is the what we did in Proof of Concept. Sit on the endpoint , Wait for user to authenticate , Exfil the Databases , Take over the account.
Responsible Disclosure
This issue was reported to google and they were asked to at least encrypt databases on disk as a solution to put more obstacles in the path of the attacker. But they have decided to not pursue it as a security bug.
In Conclusion
This is a very dangerous technique that can cause some heavy damage. There is no prevention currently available that can stop this. Our best bet is to detect this.
You can think of this as “pass-the-hash” for google cloud but you can do it from anywhere. You don’t need to be inside the network once you exfil those databases. Based on the privilege of the compromised account(s), you can pretty much reach to all the components such as compute, storage, IAM, network, KMS, secret management. Thank you, Zero Trust ..!!
The attackers will have access until token expires and can rinse and repeat until they get persistent access to Google Cloud.
In order to detect this, you can use anomaly detection. Look for unusual processes accessing those databases as well as look for unusual IP addresses interacting with your GCP.
