---
title: "Exposed GCP Bucket"
canonical: "https://kb.cynergy.app/space/MD/899416238/Exposed%20GCP%20Bucket"
format: markdown
---
**Description **

GCP Buckets (Blobs) are used to store data in GCP. An organization’s cloud storage is a prime target for attackers looking to identify sensitive information for exfiltration. Depending on the settings set on GCP Storage accounts, companies could be unknowingly exposing their containers/buckets to the internet for direct access. 

**Hacker's View**

As a hacker, I can run scanners to detect open and misconfigured Azure Blobs using tools like [GCPBucketBrute](https://github.com/RhinoSecurityLabs/GCPBucketBrute), [Red-Bucket-GCP](https://github.com/lightspin-tech/red-bucket-gcp), or [Cloud Hunter](https://github.com/belane/CloudHunter) to identify open GCP buckets and their permissions or use platforms like [Grayhatwarfare](https://buckets.grayhatwarfare.com/). once I have identified a Bucket that is accessible and which contains interesting/sensitive information. Then I would try to escalate privileges if the bucket policy allowed either “allUsers” or “allAuthenticatedUsers” to write to their bucket policy (the **storage.buckets.setIamPolicy** permission)**,** then anyone can modify the bucket policy and grant himself full access.

There are 2 ways to check the permissions over a bucket. The first one is to ask for them by making a request to `https://www.googleapis.com/storage/v1/b/BUCKET_NAME/iam` or running `gsutil iam get gs://BUCKET_NAME`.

The other option which will always work is to use the testPermissions endpoint of the bucket to figure out if you have the specified permission, for example accessing: `https://www.googleapis.com/storage/v1/b/BUCKET_NAME/iam/testPermissions?permissions=storage.buckets.delete&permissions=storage.buckets.get&permissions=storage.buckets.getIamPolicy&permissions=storage.buckets.setIamPolicy&permissions=storage.buckets.update&permissions=storage.objects.create&permissions=storage.objects.delete&permissions=storage.objects.get&permissions=storage.objects.list&permissions=storage.objects.update`

I would then escalate my privileges With the “gsutil” Google Storage CLI program, we can run the following command to grant “allAuthenticatedUsers” access to the “Storage Admin” role, thus escalating the privileges we were granted to the bucket:

```
gsutil iam ch group:allAuthenticatedUsers:admin gs://BUCKET_NAME
```

download the information and try extorting the organization. If the information contains secret keys or other information that may help me to get even stronger access to the organization’s assets. 

**Mitigation**

Change the GCP bucket access policy based on the below references per the GCP recommendation. 

- Locate the sensitive data in your cloud storage using tools included in [Google Cloud Platform](https://cloud.google.com/) (GCP) and [Cloud Data Loss Prevention (DLP) API](https://cloud.google.com/dlp/)
- Check for appropriate permissions on the bucket and make sure they are not set to public.
- Make the public buckets or objects private
- Restrict access to the bucket (see [Using IAM](https://cloud.google.com/storage/docs/access-control/using-iam-permissions))
- [Remove](https://cloud.google.com/storage/docs/object-basics#delete) the sensitive file or object from the bucket
- Use the Cloud DLP API to [redact](https://cloud.google.com/dlp/docs/redacting-sensitive-data) sensitive content

#### GCP Console

To change the policy using the GCP Console, follow these steps:

1. Log in to the GCP Console at <u>[https://console.cloud.google.com](https://console.cloud.google.com/)</u>.
2. Navigate to <u>[Storage](https://console.cloud.google.com/storage/browser)</u>.
3. Navigate to **Bucket** details page, select *bucket name*.
4. Click **Permissions** tab.
5. To remove a specific role assignment, to the front of **allUsers** and **allAuthenticatedUsers**, click **Delete**.

#### CLI Command

To remove access to **allUsers** and **allAuthenticatedUsers**, use the following commands:  
`gsutil iam ch -d allUsers gs://BUCKET_NAME`  
`gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME`

#### Buildtime

##### Terraform

- **Resource**: google_storage_bucket_iam_member
- **Argument**: member
- **Resource**: google_storage_bucket_iam_binding
- **Field**: members

##### Go

```
//Option 1
resource "google_storage_bucket_iam_member" "member" {
  bucket = google_storage_bucket.default.name
  role = "roles/storage.admin"
-  member = "allUsers"
-  member = "allAuthenticatedUsers"
}

//Option 2
resource "google_storage_bucket_iam_binding" "binding" {
  bucket = google_storage_bucket.default.name
  role = "roles/storage.admin"
  members = [
-    "allAuthenticatedUsers",
-    "allUsers"
  ]
}
```


**Cynergy’s View**

Cynergy detects the publicly exposed buckets and notifies the client regarding the exposure. In addition, Cynergy identifies all the exposed files in the specific bucket and contextualizes the exposure. differentiating between different file types and exposed content. 

Cynergy is constantly comparing your environment to a baseline of appropriate configurations and behavior, looking for deviation. The moment a deviation is detected, such as a public-facing GCP Bucket, Cynergy would flag the issue.

A few things to note: a lot of vendors today provide Cloud Security Posture Management (CSPM) solutions including this monitoring and detection, but next-generation platforms such as Cynergy take things a step further. Let’s say there is a misconfiguration, like a lack of authentication needed to access the content of a Blob, and your CSPM tool detects it and issues a ticket to your security team. This ticket will sit at the back of a queue of other security concerns, or the alert can get lost in a sea of notifications the security team receives. Or maybe there’s a specific team responsible for tackling the issue, but this alert goes to a general queue. What if it’s Friday evening and your employees are signing off for the weekend?

In this case, your organization needs an efficient way for the correct team responsible to receive the alert, and it needs context in order to recognize that this specific alert, among so many others, is a pressing concern deserving immediate attention. Even a step further, it needs a way to remediate the concern without manual action.

This is why Cynergy aims to automate the process from detection via contextualization and remediation of the exposure. 

**Reference**

Google official recommendation- [https://cloud.google.com/blog/products/gcp/4-steps-for-hardening-your-cloud-storage-buckets-taking-charge-of-your-security](https://cloud.google.com/blog/products/gcp/4-steps-for-hardening-your-cloud-storage-buckets-taking-charge-of-your-security) 

Hacktricks- [https://book.hacktricks.xyz/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation](https://book.hacktricks.xyz/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation)  

Comparitech - [https://www.comparitech.com/blog/information-security/google-cloud-buckets-unauthorized-access-report/](https://www.comparitech.com/blog/information-security/google-cloud-buckets-unauthorized-access-report/)