No IP, No Problem: Exfiltrating Data Behind IAP

No IP, No Problem: Exfiltrating Data Behind IAP

Speakers: Ariel Kalman, Security Researcher, Mitiga (introduced as Ariel Coleman in host banter; speaker states “Ariel Kalman”)

Conference: BSides Las Vegas

YouTube: https://www.youtube.com/watch?v=tH5olbwAJoU

Overview

Ariel Kalman presents an attack path against Google Cloud Platform’s Identity-Aware Proxy (IAP), framed as an identity firewall that intercepts requests to protected applications, enforces authentication and authorization, and injects authentication headers for successful sessions. The talk’s headline scenario is data exfiltration without direct outbound connectivity from a restricted internal environment: an internal actor with deployment rights manipulates CORS response headers, while an external collaborator issues unauthenticated HTTP OPTIONS requests that IAP allows through when a specific setting—Allow HTTP options (described as controlling CORS preflight)—is enabled. The speaker states GCP acknowledged the behavior, updated IAP documentation to highlight risk, and chose not to change the mechanism at that time (per the talk; future change left open).

Background

▶ Watch: IAP defined as identity firewall: authn, authz, header injection on success. (2:00)

IAP sits in front of an application and, by default, blocks unauthenticated access, redirecting users to Google sign-in. After authentication, authorization checks (sufficient IAM roles) must pass before IAP forwards traffic and injects headers the backend trusts. The session contrasts this ideal with two misconfigurations observed “in the wild”: overly broad IAM bindings and unprotected alternate endpoints that bypass IAP while reaching the same application data.

The first misconfiguration involves special member types in GCP IAM: allUsers (everyone on the internet, authenticated or not) and allAuthenticatedUsers (any Google account). Adding either to an IAP access list effectively disables IAP’s protection because authorization becomes universally satisfiable. The speaker notes the Cloud Console warns that allUsers makes a resource public, while gcloud CLI may perform the same binding without a warning—emphasizing operational foot-guns.

The second misconfiguration is partial IAP coverage: multi-endpoint applications require IAP enabled per endpoint; a forgotten route can allow attackers to reach the same data without IAP enforcement.

Key Findings

▶ Watch: CORS and same-origin policy explained; Access-Control-Allow-Origin as gate. (8:00)

The central technical pivot is Cross-Origin Resource Sharing (CORS) and preflight. Browsers enforce the same-origin policy to block malicious sites from reading cross-origin responses unless a server returns Access-Control-Allow-Origin (and related headers) permitting the requesting origin. For non-“simple” requests, browsers send an HTTP OPTIONS preflight before the real request. Preflights are unauthenticated by design—a constraint the speaker stresses as non-negotiable in browser behavior.

When IAP’s Allow HTTP options setting is disabled, unauthenticated OPTIONS requests are blocked like other unauthenticated traffic—breaking CORS for apps behind IAP. When enabled, IAP allows only OPTIONS through without authentication while still blocking GET/POST and other methods until users authenticate. That design choice enables standards-compliant CORS behind IAP but creates an attacker-controlled channel if the application reflects attacker-influenced Access-Control-Allow-Origin values in OPTIONS responses.

The attack requires: IAP protecting an app with Allow HTTP options enabled; an internal foothold with code execution (examples given: VM, Cloud Run, Lambda—the last is non-GCP terminology in the transcript but illustrates the class); an identity possessing appengine.deployer (described as common for developers); and an external machine to issue requests. The internal actor deploys an App Engine configuration YAML that sets Access-Control-Allow-Origin to embed a secret (any encodable string—token, certificate material, etc.). The external attacker sends OPTIONS; IAP permits it; App Engine responds including the header; the secret is read by the external party without a direct packet path from internal to external. The speaker reports automating the loop and exfiltrating 15 megabytes in one day as a curiosity metric—enough for secrets and follow-on expansion, though not bulk data theft.

Detection focuses on the logged step: repeated createVersion (or similar App Engine version creation) events on a short interval (example pattern: every 30 seconds). The speaker argues OPTIONS traffic itself is not the durable log signal; deployment churn is.

Technical Deep Dive

▶ Watch: Attack prerequisites: IAP+CORS setting, internal foothold, appengine.deployer... (12:00)

The talk explains CORS as a browser-enforced contract: the server’s Access-Control-Allow-Origin must match the requesting origin for the browser to expose response data to JavaScript. Preflight exists because dangerous methods might execute server-side effects before a browser can block reading the response—so the browser asks permission first with OPTIONS.

IAP’s Allow HTTP options is analyzed as a deliberate exception carved into an otherwise default-deny identity gate. The consequence is that any unauthenticated actor who can reach the IAP front door can trigger OPTIONS handling on the backend, and if the backend’s CORS headers are attacker-controlled via deployment, those headers become a covert channel.

The App Engine deployment path is presented as the practical lever for header injection at scale and speed suitable for automation. The speaker’s detection rule sketch is three-part: filter relevant App Engine admin events, aggregate counts over a time window, threshold suspicious frequency.

In Q&A, the speaker clarifies the threat model: the attacker does not need permission to toggle IAP’s Allow HTTP options—the scenario assumes admins already enabled it; the malicious actor only needs appengine.deployer (or equivalent deployment rights described in the talk) to change application config. The speaker contrasts that with flipping IAP to allUsers, which is a separate misconfiguration.

Why this matters beyond App Engine

Even though the speaker’s worked example centers on App Engine configuration files, the underlying lesson is portable: any stack behind IAP that (a) can be redeployed by insiders to emit dynamic CORS headers and (b) honors OPTIONS for preflight is candidates for the same header-mediated exfiltration channel when Allow HTTP options is on. The talk does not enumerate every GCP runtime variant; defenders should map the pattern to their own load balancer + app topology rather than treating it as a single-product bug.

Limitations and honest boundaries

The attack still requires browser-visible semantics only in the sense that OPTIONS responses return to the external caller; the speaker frames the external party as a VM on the internet, not necessarily a browser tab. That distinction matters for defenders calibrating detections: your WAF may log OPTIONS differently than interactive GET traffic, and some observability stacks discard preflight bodies/headers as noise.

The 15 megabytes per day figure is a single experiment from the speaker’s automation and should not be read as a universal throughput bound. It is useful as an order-of-magnitude intuition: slow compared to raw TCP exfiltration, but fast enough for key material and token caches.

Related defensive controls (grounded in the talk’s themes)

The first half’s IAM binding mistakes and partial IAP coverage are “old” misconfigurations, but the speaker’s point is they remain prevalent—so exfiltration via OPTIONS is less likely to be your first failure mode than public data via allUsers. A practical remediation sequence is: eliminate broad bindings, close bypass endpoints, then revisit CORS + IAP interaction if applications legitimately require Allow HTTP options.

Demo / Proof of Concept

▶ Watch: YAML deploy embedding secret in Allow-Origin; OPTIONS exfiltration walkthrough. (14:00)

The session describes a step-by-step exfiltration chain with diagrammatic narration rather than a full live capture in the transcript provided: internal deploy of YAML with secret embedded in Access-Control-Allow-Origin, external OPTIONS request, response inspection showing exfiltrated content, and iterative redeployments to stream additional data. The 15 MB/day figure is offered as an empirical automation benchmark from the speaker’s testing.

Defensive Implications

▶ Watch: Q&A: appengine.deployer vs IAP admin permissions; threat model clarified. (20:00)

• IAM hygiene: avoid allUsers / allAuthenticatedUsers on IAP-protected resources; treat CLI operations as high risk without console guardrails.
• Coverage: validate every endpoint sits behind IAP (or equivalent controls); hunt shadow URLs and legacy hostnames.
• CORS behind IAP: treat Allow HTTP options as a security-relevant configuration; understand it exposes unauthenticated OPTIONS to application logic.
• Separation of duties: appengine.deployer is widely granted; pair technical controls (approval workflows, deployment locks) with detections for version churn.
• Detection engineering: monitor createVersion spikes and anomalous deploy cadence; correlate with new Access-Control-Allow-Origin patterns if observable in your telemetry stack (speaker emphasizes deploy logs as primary).
• Vendor reliance: documentation updates without product change means risk acceptance stays with the customer—update architecture reviews and threat models accordingly.

Key Takeaways

• IAP is powerful but can be nullified by IAM misbindings or partial enablement across endpoints.
• CORS preflight is unauthenticated; IAP’s Allow HTTP options intentionally permits OPTIONS through, which matters when apps echo dynamic CORS headers.
• A deployer-level insider (or compromised developer identity) can encode secrets into CORS headers and retrieve them externally via OPTIONS despite restrictive network paths.
• High-frequency App Engine deployments are a practical detection anchor for this abuse pattern.
• GCP reportedly documented the risk after disclosure; organizations must operationalize understanding—do not assume the platform will block this class of abuse if configuration allows it.

Cross-team, the talk also argues for tighter collaboration between AppSec (CORS correctness), platform engineering (IAP rollout completeness), and IAM governance (allUsers / allAuthenticatedUsers hygiene)—the headline exfiltration chain is the last mile once those pillars slip.

Finally, the session is a reminder that zero-trust networking and strong identity front doors do not automatically sanitize application-layer output channels; HTTP semantics and browser security models can create narrow exceptions that remain policy-sensitive.

About the Speaker(s)

Ariel Kalman introduces himself as a security researcher at Mitiga, based in Tel Aviv, Israel. The host briefly uses the name “Ariel Coleman”; the speaker’s stated name is Ariel Kalman. A personal aside mentions preferring dogs over humans. Organizational titles beyond “security researcher” are not expanded in the transcript.