Chaining Misconfigurations to Full Cloud Compromise: A Case Study in GCP Exploitation

Executive Summary

During a routine security monitoring exercise, our research team identified a chain of vulnerabilities in a major SaaS integration platform that culminated in complete compromise of its Google Cloud Platform (GCP) environment.

The weaknesses, discovered in a publicly accessible API endpoint, allowed us to:

• Smuggle arbitrary HTTP methods through the backend

• Perform Server-Side Request Forgery (SSRF) to internal GCP resources

• Extract valid service account access tokens

• Access sensitive Google Cloud Storage buckets containing cleartext credentials, database dumps, source code, and build artifacts

This case study demonstrates how seemingly minor flaws — when combined — can escalate into a full breach of a cloud perimeter.

---

Discovery Context

Our team at ReactiveZero continuously monitors exposed internet-facing assets for security risks, following a methodology that prioritizes manual testing over automated scanning. This ensures that subtle, high-impact vulnerabilities are not overlooked.

In this instance, the issues were found in an API endpoint used for testing HTTP client configurations. While its purpose appeared benign, its lack of input sanitization and access control provided the perfect starting point for deeper exploitation.

---

Vulnerability Chain

1. HTTP Method Smuggling

Vulnerable Endpoint:

POST /api/v1/di/configurations/http-client/test

Issue:
The endpoint accepted a JSON payload that included a method parameter — intended to specify the HTTP method used in outbound requests. The backend directly trusted this value without sanitization or whitelisting.

By supplying non-standard methods such as PUT, TRACE, or even arbitrary strings, we confirmed that the backend executed outbound requests with those methods intact.

Security Implications:

• Allows bypass of application-level filtering that only expects GET or POST

• Facilitates backend method smuggling for services with method-based access control

• Serves as a foundation for SSRF attacks, enabling more complex payload delivery

---

2. SSRF to GCP Metadata Service

Leveraging method smuggling was only the first step. By manipulating the uri parameter in the same endpoint, we achieved Server-Side Request Forgery (SSRF).

Targeted Internal Resource:

http://169.254.169.254/computeMetadata/v1/

This is the GCP metadata service, accessible only from within GCP virtual machines. With SSRF, we bypassed the cloud provider’s perimeter protections and interacted with this service directly.

What We Retrieved:

• Project ID of the environment

• Active service account identity:
  572120218656-compute@developer.gserviceaccount.com

• Host and disk metadata

• Scheduling configurations

• Cryptographic identity materials (mds-client-certificate), including:

  • encrypted_credentials

  • key_import_blob (with encrypted_seed)

  • public_area data

Why this is serious:
Even without immediate decryption, access to such materials threatens the trust model of confidential compute workloads and mTLS-based identity federation in zero-trust architectures.

---

3. Access Token Extraction and Abuse

From the metadata service, we extracted a valid OAuth2 access token bound to the instance’s service account.

With this token, we:

• Authenticated to the Google Cloud Storage API

• Enumerated all accessible buckets

• Inferred production, staging, and development environment separation

• Identified buckets belonging to third-party clients

Example bucket names (redacted where necessary):

• acc-****** (client environment)

• dev-****** (development data)

• default-webserver

• gcf-sources-* (cloud function source code)

• stamped-io-build-storage (build artifacts)

• staging.******.appspot.com (staging data)

  

---

4. Unauthorized GCS Bucket Access

Bucket enumeration was only the beginning. The obtained token allowed object listing and downloading from multiple buckets — with no additional authentication challenge.

High-Risk Example:

• stamped-io-build-storage/fixtures/db.sql — a 15MB SQL database dump containing:

  • User account tables

  • Cleartext administrator passwords

  • Internal application data

  • Potentially GDPR-regulated personal information

• Other Exposed Assets:

• .tar.gz archives of build artifacts

• Function source code packages (function-source.zip)

• Region and policy metadata revealing operational geography (e.g., EUROPE-WEST4 )

  

---

Root Causes

Our analysis identified three primary causes enabling this chain of exploitation:

1. No HTTP method validation in the configuration testing endpoint

2. Lack of SSRF protection, allowing direct interaction with internal cloud services

3. Overly broad service account permissions and absence of bucket-level IAM restrictions

---

Potential Impact

An attacker exploiting these flaws could:

• Exfiltrate sensitive databases, including customer PII and authentication credentials

• Steal proprietary code and build pipelines

• Compromise third-party client environments

• Perform privilege escalation within GCP

• Bypass network perimeter protections

The GDPR implications alone — given the exposure of personal data — could result in significant regulatory fines.

---

Recommended Mitigations

We recommend the affected organization:

1. Implement strict input validation for HTTP methods, enforcing an allowlist (GET, POST)

2. Deploy SSRF protection using request sanitization and metadata service access restrictions (GCP’s --no-allow-metadata-server-access)

3. Reduce service account scopes to follow the principle of least privilege

4. Apply bucket-level IAM deny-by-default policies for sensitive assets

5. Rotate and revoke exposed credentials immediately

---

Conclusion

This incident reinforces a critical truth in cloud security: minor misconfigurations can combine into devastating exploits when left unchecked. A harmless-looking “HTTP client test” feature became the entry point for complete cloud compromise.

ReactiveZero disclosed all findings under responsible disclosure guidelines. The affected organization has acknowledged the report and is in the process of remediation.

---

About ReactiveZero
ReactiveZero specializes in precision penetration testing, delivering in-depth manual assessments of cloud, application, and network security. We help organizations uncover vulnerabilities before adversaries do.

📧 info@reactivezero.com
📞 +31 6 2908 4840