# $5k Service dependencies

Hidden usage.dependsOnServices field in Google Service Management let attackers enable arbitrary services, including private internal Google APIs, without the servicemanagement.services.bind permission.

- Payout: $5,000
- Severity: high
- Program: Google VRP
- Credited: Ezequiel Pereira
- Disclosed: 2018-03-31
- Write-up quality: 8/10
- Original: https://www.ezequiel.tech/p/5k-service-dependencies.html
- Library page: https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-5k-service-dependencies-html
- Tags: domain:api domain:cloud impact:internal-access impact:privesc kind:bounty platform:blog sev:high tech:gcp technique:source-review vuln:access-control vuln:auth-bypass vuln:misconfiguration

**Target:** Google Service Management API (servicemanagement.clients6.google.com) service config
**Root cause:** When enabling a service, the dependsOnServices usage setting auto-enables each listed dependency without checking whether the caller holds servicemanagement.services.bind on those services.
**Steps:**
1. Craft a Service object with `usage.dependsOnServices` listing target services (e.g. private/internal APIs).
2. POST it to `/v1/services/<SERVICE NAME>/configs?key=...` on servicemanagement.clients6.google.com with SAPISIDHASH auth and X-Origin console.cloud.google.com.
3. Roll out the config, then enable the service on a project.
4. Observe the listed dependency services get enabled without bind permission.
5. Alternative vector: set the field via the submit configuration method's file, bypassing per-client field visibility.
**How found:** While reading usage settings of the Service Management API, spotted an undocumented hidden field dependsOnServices described as internal-only; tested it via the Cloud Console client and observed dependency services auto-enabled without authorization checks.
**Exploitation:** Attacker with any Google account crafts a service config containing dependsOnServices pointing at private/internal Google APIs, rolls it out, and enables their service on their own project; the dependencies are auto-enabled, granting access to internal APIs not subject to public security standards.
**Escalation:** Chained enabling of private/internal Google APIs (staging, test, trusted-tester-only) to reach potentially vulnerable internal endpoints.
**Insight:** Hidden/internal-only fields in config APIs are prime targets: enumerate undocumented schema fields and test whether server-side side effects (auto-enabling dependencies) skip the per-object authorization check that the primary action enforces.