Skip to content

Latest commit

 

History

History
273 lines (191 loc) · 13 KB

README.md

File metadata and controls

273 lines (191 loc) · 13 KB
Raw

GCP Pentesting

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Basic Information

Before start pentesting a GCP environment, there are a few basics things you need to know about how it works to help you understand what you need to do, how to find misconfigurations and how to exploit them.

Concepts such as organization hierarchy, permissions and other basic concepts are explained in:

{% content-ref url="gcp-basic-information/" %} gcp-basic-information {% endcontent-ref %}

Labs to learn

GCP Pentester/Red Team Methodology

In order to audit a GCP environment it's very important to know: which services are being used, what is being exposed, who has access to what, and how are internal GCP services an external services connected.

From a Red Team point of view, the first step to compromise a GCP environment is to manage to obtain some credentials. Here you have some ideas on how to do that:

  • Leaks in github (or similar) - OSINT
  • Social Engineering (Check the page Workspace Security)
  • Password reuse (password leaks)
  • Vulnerabilities in GCP-Hosted Applications
    • Server Side Request Forgery with access to metadata endpoint
    • Local File Read
      • /home/USERNAME/.config/gcloud/*
      • C:\Users\USERNAME\.config\gcloud\*
  • 3rd parties breached
  • Internal Employee

Or by compromising an unauthenticated service exposed:

{% content-ref url="gcp-unauthenticated-enum-and-access/" %} gcp-unauthenticated-enum-and-access {% endcontent-ref %}

Or if you are doing a review you could just ask for credentials with these roles:

{% content-ref url="gcp-permissions-for-a-pentest.md" %} gcp-permissions-for-a-pentest.md {% endcontent-ref %}

{% hint style="info" %} After you have managed to obtain credentials, you need to know to who do those creds belong, and what they have access to, so you need to perform some basic enumeration: {% endhint %}

Basic Enumeration

SSRF

For more information about how to enumerate GCP metadata check the following hacktricks page:

{% embed url="https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#6440" %}

Whoami

In GCP you can try several options to try to guess who you are:

{% code overflow="wrap" %}

#If you are inside a compromise machine
gcloud auth list
curl -H "Content-Type: application/x-www-form-urlencoded" -d "access_token=$(gcloud auth print-access-token)" https://www.googleapis.com/oauth2/v1/tokeninfo
gcloud auth print-identity-token #Get info from the token

#If you compromised a metadata token or somehow found an OAuth token
curl -H "Content-Type: application/x-www-form-urlencoded" -d "access_token=<token>" https://www.googleapis.com/oauth2/v1/tokeninfo

{% endcode %}

You can also use the API endpoint /userinfo to get more info about the user:

{% code overflow="wrap" %}

curl -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: OAuth $(gcloud auth print-access-token)" https://www.googleapis.com/oauth2/v1/userinfo

curl -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: OAuth <access_token>" https://www.googleapis.com/oauth2/v1/userinfo

{% endcode %}

Org Enumeration

# Get organizations
gcloud organizations list #The DIRECTORY_CUSTOMER_ID is the Workspace ID
gcloud resource-manager folders list --organization <org_number> # Get folders
gcloud projects list # Get projects

Principals & IAM Enumeration

If you have enough permissions, checking the privileges of each entity inside the GCP account will help you understand what you and other identities can do and how to escalate privileges.

If you don't have enough permissions to enumerate IAM, you can steal brute-force them to figure them out.
Check how to do the numeration and brute-forcing in:

{% content-ref url="gcp-services/gcp-iam-and-org-policies-enum.md" %} gcp-iam-and-org-policies-enum.md {% endcontent-ref %}

{% hint style="info" %} Now that you have some information about your credentials (and if you are a red team hopefully you haven't been detected). It's time to figure out which services are being used in the environment.
In the following section you can check some ways to enumerate some common services. {% endhint %}

Services Enumeration

GCP has an astonishing amount of services, in the following page you will find basic information, enumeration cheatsheets, how to avoid detection, obtain persistence, and other post-exploitation tricks about some of them:

{% content-ref url="gcp-services/" %} gcp-services {% endcontent-ref %}

Note that you don't need to perform all the work manually, below in this post you can find a section about automatic tools.

Moreover, in this stage you might discovered more services exposed to unauthenticated users, you might be able to exploit them:

{% content-ref url="gcp-unauthenticated-enum-and-access/" %} gcp-unauthenticated-enum-and-access {% endcontent-ref %}

Privilege Escalation, Post Exploitation & Persistence

The most common way once you have obtained some cloud credentials or have compromised some service running inside a cloud is to abuse misconfigured privileges the compromised account may have. So, the first thing you should do is to enumerate your privileges.

Moreover, during this enumeration, remember that permissions can be set at the highest level of "Organization" as well.

{% content-ref url="gcp-privilege-escalation/" %} gcp-privilege-escalation {% endcontent-ref %}

{% content-ref url="gcp-post-exploitation/" %} gcp-post-exploitation {% endcontent-ref %}

{% content-ref url="gcp-persistence/" %} gcp-persistence {% endcontent-ref %}

Publicly Exposed Services

While enumerating GCP services you might have found some of them exposing elements to the Internet (VM/Containers ports, databases or queue services, snapshots or buckets...).
As pentester/red teamer you should always check if you can find sensitive information / vulnerabilities on them as they might provide you further access into the AWS account.

In this book you should find information about how to find exposed GCP services and how to check them. About how to find vulnerabilities in exposed network services I would recommend you to search for the specific service in:

{% embed url="https://book.hacktricks.xyz/" %}

GCP <--> Workspace Pivoting

Compromising principals in one platform might allow an attacker to compromise the other one, check it in:

{% content-ref url="gcp-to-workspace-pivoting/" %} gcp-to-workspace-pivoting {% endcontent-ref %}

Automatic Tools

# Install
git clone https://github.com/google/gcp_scanner.git
cd gcp_scanner
virtualenv -p python3 venv
source venv/bin/activate
pip install -r requirements.txt
# Execute with gcloud creds
python3 __main__.py -o /tmp/output/ -g "$HOME/.config/gcloud"
  • gcp_enum: Bash script to enumerate a GCP environment using gcloud cli and saving the results in a file.
  • GCP-IAM-Privilege-Escalation: Scripts to enumerate high IAM privileges and to escalate privileges in GCP abusing them (I couldn’t make run the enumerate script).
  • BF My GCP Permissions: Script to bruteforce your permissions.

gcloud config & debug

# Login so gcloud can use your credentials
gcloud auth login
gcloud config set project security-devbox
gcloud auth print-access-token

# Login so SDKs can use your user credentials
gcloud auth application-default login
gcloud auth application-default set-quota-project security-devbox
gcloud auth application-default print-access-token

# Update gcloud
gcloud components update

Capture gcloud, gsutil... network

Remember that you can use the parameter --log-http with the gcloud cli to print the requests the tool is performing. If you don't want the logs to redact the token value use gcloud config set log_http_redact_token false

Moreover, to intercept the communication:

gcloud config set proxy/address 127.0.0.1
gcloud config set proxy/port 8080
gcloud config set proxy/type http
gcloud config set auth/disable_ssl_validation True

# If you don't want to completely disable ssl_validation use:
gcloud config set core/custom_ca_certs_file cert.pem

# Back to normal
gcloud config unset proxy/address
gcloud config unset proxy/port
gcloud config unset proxy/type
gcloud config unset auth/disable_ssl_validation
gcloud config unset core/custom_ca_certs_file

OAuth token configure in gcloud

In order to use an exfiltrated service account OAuth token from the metadata endpoint you can just do:

# Via env vars
export CLOUDSDK_AUTH_ACCESS_TOKEN=<token>
gcloud projects list

# Via setup
echo "<token>" > /some/path/to/token
gcloud config set auth/access_token_file /some/path/to/token
gcloud projects list
gcloud config unset auth/access_token_file

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}