# Bypassing Identity-Aware Proxy - Google Cloud Vulnerability

Sharing OAuth clients plus query-param routing let an attacker capture a victim's IAP redirect_token and mint valid session cookies for a targeted IAP-secured app.

- Payout: $5,000
- Severity: high
- Program: Google
- Credited: SebLu
- Disclosed: 2021-12-30
- Write-up quality: 9/10
- Original: https://www.seblu.de/2021/12/iap-bypass.html
- Library page: https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html
- Tags: domain:cloud impact:ato impact:internal-access kind:bounty platform:blog sev:high tech:gcp tech:oauth technique:chained technique:source-review vuln:account-takeover vuln:auth-bypass

**Target:** GCP Identity-Aware Proxy / External HTTPS Load Balancer
**Root cause:** IAP backend services accept a shared OAuth client ID with an arbitrary secret across orgs, and issue IAAP_AUTH_TOKEN cookies even when the redirect_token's target_uri does not match the requested hostname.
**Steps:**
1. Extract target OAuth client ID from the IAP redirect to accounts.google.com
2. Create attacker HTTPS LB with two backend services to same VM; enable IAP on first with target client ID and random secret via `gcloud compute backend-services update ... --iap=enabled,oauth2-client-id=<target>,oauth2-client-secret=1234567890`
3. Add URL map routing `?gcp-iap-mode=AUTHENTICATING&redirect_token` to the second non-IAP backend
4. Lure victim (already signed in) to attacker URL; capture redirect_token on backend
5. Send `curl 'https://victim.app/?gcp-iap-mode=AUTHENTICATING&redirect_token=${REDIRECT_TOKEN}'` to obtain GCP_IAAP_AUTH_TOKEN and GCP_IAP_UID cookies
6. Set cookies in browser and access victim.app
**How found:** After failing to bypass IAP without credentials, pivoted to credential theft; noticed the 'Sharing OAuth Clients' convenience feature and hypothesized creating an attacker IAP app with the victim's client ID. Discovered the secret wasn't validated, then noticed Error Code 11 fired only after the LB forwarded the request, implying the redirect_token reached attacker infrastructure first.
**Exploitation:** Attacker reuses victim's OAuth client ID on their own IAP-enabled LB with a bogus secret, routes the AUTHENTICATING redirect to a non-IAP backend to capture the redirect_token, then replays it against the real app to receive valid session cookies, achieving session hijack with no victim interaction beyond a click.
**Escalation:** Chained three individually minor flaws (cross-org OAuth client sharing, query-param routing interception, hostname-mismatch cookie issuance) into full IAP bypass.
**Insight:** When a security component offers a 'convenience' reuse feature (shared OAuth clients, shared keys), try configuring your own instance with the victim's public identifier and a bogus secret; also check whether intermediate tokens are validated against the requesting hostname or only at a later stage.