# Server-Side Request Forgery using Javascript allows to exfill data from Google Metadata

Snapchat's media import fetched attacker URLs in headless Chrome; DNS rebinding to 169.254.169.254 leaked GCP metadata, SSH keys and service-account tokens.

- Payout: hidden
- Severity: critical
- Program: Snapchat
- Found by: nahamsec
- Disclosed: 2020-11-30
- Write-up quality: 8/10
- Original: https://hackerone.com/reports/530974
- Library page: https://bugbountylibrary.com/r/h1%3A530974
- Tags: area:web3 domain:web impact:data-leak impact:internal-access impact:privesc kind:bounty platform:hackerone sev:critical tech:gcp technique:chained technique:oob-exfil vuln:ssrf

**Target:** business.snapchat.com creative media import endpoint /api/v1/media/import (headless Chrome fetcher)
**Root cause:** The media import endpoint fetches arbitrary user-supplied URLs server-side without validating the resolved IP, and the fetcher follows DNS changes between validation and fetch, allowing rebinding to internal/link-local addresses.
**Steps:**
1. Login to business.snapchat.com, open Creative Library -> New Creative -> Topsnap Media -> Create, load a template.
2. Click an image -> Replace -> Import; this calls `/api/v1/media/import` with a URL parameter.
3. Host an HTML page on attacker domain that issues XHRs to `http://<attacker>/computeMetadata/v1beta1/...` with header `X-Google-Metadata-Request: True`, plus timing loops to keep the page alive.
4. Submit `http://demon.attacker/ssrf.html` to `/api/v1/media/import`.
5. Immediately rebind DNS for the attacker domain to `169.254.169.254` and wait ~3 minutes; the headless Chrome re-resolves and hits the metadata service.
6. Exfiltrate results back to attacker log server via XHR.
**How found:** While reviewing the ads site with @daeken, noticed the creative import function fetched remote images; hypothesized the fetcher runs server-side in a browser and could be redirected via DNS rebinding to internal metadata endpoints.
**Exploitation:** Attacker-controlled page is loaded by Snapchat's headless Chrome; after DNS rebinding to 169.254.169.254, the page's XHRs hit the GCP metadata service with the metadata header, reading SSH keys, service-account list, and hostname, then exfiltrating them to the attacker's logging endpoint.
**Escalation:** Metadata service-account tokens allowed minting tokens for the instance's service account, escalating from SSRF to GCP credential compromise.
**Insight:** When a server-side fetcher renders attacker HTML in a real browser, DNS rebinding defeats one-time IP validation: keep the page alive with timing loops so the browser re-resolves the hostname to 169.254.169.254 after the initial check, and add the `X-Google-Metadata-Request: True` header to reach GCP metadata.