GitBook: [master] 2 pages and one asset modified

SUMMARY.md

@@ -488,7 +488,7 @@
 
 ## Cloud Security
 
-* [Cloud security review](cloud-security/cloud-security-review.md)
+* [Cloud Security Review](cloud-security/cloud-security-review.md)
 * [AWS Security](cloud-security/aws-security.md)
 
 ## Physical attacks

cloud-security/cloud-security-review.md

@@ -1,6 +1,6 @@
-# Cloud security review
+# Cloud Security Review
 
-**Check for nice cloud hacking tricks in** [**https://hackingthe.cloud/aws/general-knowledge/connection-tracking/**](https://hackingthe.cloud/aws/general-knowledge/connection-tracking/)\*\*\*\*
+**Check for nice cloud hacking tricks in** [**https://hackingthe.cloud/aws/general-knowledge/connection-tracking/**](https://hackingthe.cloud/aws/general-knowledge/connection-tracking/)
 
 ## Generic tools
 
@@ -107,3 +107,86 @@ You need **Global Admin** or at least **Global Admin Reader** \(but note that Gl
 
 Get objects in graph: [https://github.com/FSecureLABS/awspx](https://github.com/FSecureLABS/awspx)
 
+## GPC
+
+If you find a **SSRF** in an application running in [**GPC checkout this information**](../pentesting-web/ssrf-server-side-request-forgery.md#6440)**.**  
+If a **SQL database** \(like MySQL\) is used in a GPC machine, users may misconfigure it and open it to the Internet. Try to connect. \([**MySQL**](../pentesting/pentesting-mysql.md), [**PostgreSQL**](../pentesting/pentesting-postgresql.md)\)  
+**Google Cloud Storage publicly exposed**: Sometimes a bucket can be miss-configured and left accessible by everyone. If miss-configured, accessing via HTTP you will find a list of the files stored there:
+
+![](../.gitbook/assets/image%20%28616%29.png)
+
+```bash
+# Use leaked service account
+gcloud auth activate-service-account --key-file=service-key.json
+
+# List images
+gcloud container images list
+
+## Download and run locally an image
+docker run  --rm  -ti  gcr.io/<project-name>/secret:v1 sh
+```
+
+**Service accounts**
+
+Virtual machine instances are usually assigned a service account. Every GCP project has a [default service account](https://cloud.google.com/compute/docs/access/service-accounts#default_service_account), and this will be assigned to new Compute Instances unless otherwise specified. Administrators can choose to use either a custom account or no account at all. This service account can be used by any user or application on the machine to communicate with the Google APIs. You can run the following command to see what accounts are available to you:
+
+```text
+gcloud auth list
+```
+
+Default service accounts will look like one of the following:
+
+```text
+PROJECT_NUMBER-compute@developer.gserviceaccount.com
+PROJECT_ID@appspot.gserviceaccount.com
+```
+
+More savvy administrators will have configured a custom service account to use with the instance. This allows them to be more granular with permissions.
+
+A custom service account will look like this:
+
+```text
+SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com
+```
+
+If `gcloud auth list` returns multiple accounts available, something interesting is going on. You should generally see only the service account. If there is more than one, you can cycle through each using `gcloud config set account [ACCOUNT]` while trying the various tasks in this blog.
+
+**Access scopes**
+
+The service account on a GCP Compute Instance will use OAuth to communicate with the Google Cloud APIs. When [access scopes](https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam) are used, the OAuth token that is generated for the instance will have a [scope](https://oauth.net/2/scope/) limitation included. This defines what API endpoints it can authenticate to. It does NOT define the actual permissions.
+
+When using a custom service account, Google [recommends](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) that access scopes are not used and to rely totally on IAM. The web management portal actually enforces this, but access scopes can still be applied to instances using custom service accounts programatically.
+
+There are three options when setting an access scope on a VM instance:
+
+* Allow default access
+* All full access to all cloud APIs
+* Set access for each API
+
+You can see what scopes are assigned by querying the metadata URL. Here is an example from a VM with "default" access assigned:
+
+```text
+$ curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes \
+    -H 'Metadata-Flavor:Google'
+
+https://www.googleapis.com/auth/devstorage.read_only
+https://www.googleapis.com/auth/logging.write
+https://www.googleapis.com/auth/monitoring.write
+https://www.googleapis.com/auth/servicecontrol
+https://www.googleapis.com/auth/service.management.readonly
+https://www.googleapis.com/auth/trace.append
+```
+
+The most interesting thing in the default scope is `devstorage.read_only`. This grants read access to all storage buckets in the project. This can be devastating, which of course is great for us as an attacker.
+
+Here is what you'll see from an instance with no scope limitations:
+
+```text
+$ curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes -H 'Metadata-Flavor:Google'
+https://www.googleapis.com/auth/cloud-platform
+```
+
+This `cloud-platform` scope is what we are really hoping for, as it will allow us to authenticate to any API function and leverage the full power of our assigned IAM permissions. It is also Google's recommendation as it forces administrators to choose only necessary permissions, and not to rely on access scopes as a barrier to an API endpoint.
+
+It is possible to encounter some conflicts when using both IAM and access scopes. For example, your service account may have the IAM role of `compute.instanceAdmin` but the instance you've breached has been crippled with the scope limitation of `https://www.googleapis.com/auth/compute.readonly`. This would prevent you from making any changes using the OAuth token that's automatically assigned to your instance.
+