# 31k$ SSRF in Google Cloud Monitoring led to metadata exposure

Google Cloud Monitoring uptime checks allowed SSRF to the GCE metadata server, leaking project metadata and service account tokens via response-validation oracle.

- Payout: $31,337
- Severity: high
- Program: Google
- Credited: David Nechuta
- Disclosed: 2020-11-10
- Write-up quality: 8/10
- Original: https://nechudav.blogspot.com/2020/11/31k-ssrf-in-google-cloud-monitoring.html
- Library page: https://bugbountylibrary.com/r/blog%3Anechudav-blogspot-com-2020-11-31k-ssrf-in-google-cloud-monitoring-html
- Tags: domain:cloud impact:data-leak impact:internal-access kind:bounty platform:blog sev:high tech:gcp technique:blind technique:oob-exfil technique:recon vuln:ssrf

**Target:** Cloud Monitoring uptime check HTTP request feature
**Root cause:** Uptime check requests were sent from Google Cloud VMs and could target 169.254.169.254 with attacker-controlled custom headers (Metadata-Flavor: Google), reaching the metadata server without egress filtering.
**Steps:**
1. Create uptime check: Protocol HTTP, Hostname `169.254.169.254`, Path `/computeMetadata/v1/project/project-id`, Custom Header `Metadata-Flavor: Google`
2. Press Test; observe 200 status and ~2ms response time confirming internal reachability (blind SSRF)
3. Use Response validation feature to test whether response body contains a candidate string
4. Brute-force response body char-by-char by appending/prepending characters and re-testing via the Test endpoint
5. Automate with Python script to extract project metadata (SSH keys, project name)
6. For tokens: use regex binary search `foo[a-n]` vs `foo[^a-n]` to halve search space per request, repeat until unique prefix, ~15 min to full token
**How found:** Noticed Cloud Monitoring runs on GCE VMs, hypothesized metadata endpoint reachable from within instance; most SSRF targets blocked but custom headers allowed satisfying v1 metadata requirement; used response timing (2ms) to confirm internal hit, then response validation to convert blind SSRF into read.
**Exploitation:** Attacker with Cloud Monitoring access creates an uptime check pointed at the metadata server with the required Metadata-Flavor header, then uses the response-validation oracle to exfiltrate metadata and service account access tokens character by character, yielding GCP project credentials.
**Escalation:** Blind SSRF upgraded to full-read via response-validation oracle; token extraction via regex binary search across load-balanced backends.
**Insight:** When a feature lets you set custom headers on server-side requests, the Metadata-Flavor requirement for GCE v1 metadata is no barrier; and any boolean 'response contains X' validator turns blind SSRF into a full-read oracle—use regex character classes to binary-search secrets across load-balanced backends.