No IP, No Problem: Exfiltrating Data Behind IAP

No IP, No Problem: Exfiltrating Data Behind IAP

Speakers: Ariel Kalman

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=g-XCNobgvaM

Overview

Ariel Kalman, a senior security researcher at Mitiga, presented a novel data exfiltration technique that abuses Google Cloud Platform's Identity-Aware Proxy (IAP) to smuggle secrets out of restricted environments without sending a single packet directly from the internal attacker to the external attacker. The attack leverages a specific IAP setting called "Allow HTTP OPTIONS" -- designed to support CORS preflight requests -- in combination with App Engine version deployments to embed secrets in the Access-Control-Allow-Origin response header, which is returned to unauthenticated external HTTP OPTIONS requests. The technique was disclosed to GCP, who acknowledged it as expected behavior and updated documentation to highlight the risk but declined to change the service architecture.

Background

▶ Watch: What is Identity-Aware Proxy and how it works (1:30)

Identity-Aware Proxy (IAP) is a GCP service that acts as an identity firewall in front of applications. It intercepts all requests, blocks unauthenticated access by default, and enforces identity-based authorization. When functioning correctly, IAP ensures that only authenticated and authorized users can reach the protected application.

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that prevents websites from accessing other websites' data without permission. CORS relies on the Access-Control-Allow-Origin response header to indicate which origins are permitted. For non-simple requests (POST with custom headers, etc.), browsers send a CORS preflight -- an HTTP OPTIONS request -- before the actual request to ask the server whether the real request is allowed. Critically, these OPTIONS requests are unauthenticated by design, as the preflight process is meant to be lightweight.

This creates a conflict with IAP: since IAP blocks unauthenticated requests and CORS preflight requests are inherently unauthenticated, applications behind IAP cannot work with CORS unless GCP provides an exception. That exception is the "Allow HTTP OPTIONS" setting, which permits only HTTP OPTIONS requests to bypass IAP without a token.

Key Findings

▶ Watch: CORS deep dive: preflight requests are unauthenticated by design (5:45)

The core finding is that when "Allow HTTP OPTIONS" is enabled on IAP, an attacker with code execution inside the restricted environment and the App Engine Deployer role can exfiltrate data to an external attacker who has no credentials or network access to the environment.

The attack works because:

1. The internal attacker can deploy new App Engine versions containing arbitrary values in the Access-Control-Allow-Origin header within the application's YAML configuration
2. HTTP OPTIONS requests from the external attacker bypass IAP and reach the application due to the enabled setting
3. The application responds with the Access-Control-Allow-Origin header -- containing the embedded secret -- to the unauthenticated external requester
4. The response is the only part of the exchange visible to the external attacker, and this header is the only header visible from outside IAP

Kalman automated the process and achieved an exfiltration rate of approximately 15 megabytes per day, constrained by three factors: the Access-Control-Allow-Origin header is limited to 256 bytes per GCP and 8 kilobytes by protocol, App Engine allows up to 10,000 version deployments per day, and each deployment takes approximately 20-25 seconds. While 15 MB/day is modest, it is sufficient for exfiltrating secrets, tokens, certificates, and credentials that could be used to expand the attack surface.

GCP was notified. They classified the issue as low severity and expected behavior, updated documentation to highlight the risk, but declined to modify the service architecture. Kalman proposed that GCP validate the Access-Control-Allow-Origin header value as an actual domain, but GCP determined that reliably validating domain formats without false positives was too complex.

Technical Deep Dive

▶ Watch: Attack prerequisites and exfiltration diagram (11:30)

Prerequisites for the attack:

1. An application protected by IAP with the "Allow HTTP OPTIONS" setting enabled
2. An internal attacker with code execution inside the environment (VM, Cloud Run, Lambda, any compute)
3. The internal attacker has the App Engine Deployer IAM role (a common role granted to developers)
4. A firewall blocks direct outbound/inbound traffic between the internal and external attacker

Exfiltration process:

• Step 1: The internal attacker deploys a new App Engine version with a YAML configuration containing the secret (base64-encoded or otherwise character-encoded) in the Access-Control-Allow-Origin header field
• Step 2: The external attacker sends an HTTP OPTIONS request to the application's endpoint, bypassing IAP
• Step 3: The application responds with the header containing the secret

This process can be automated in a loop: the internal attacker deploys a new version with a new secret chunk, the external attacker polls and retrieves it.

Detection:

The attack is detectable but only through one log source. The HTTP OPTIONS requests are not logged anywhere -- only the App Engine version creation events appear in GCP logs. Detection involves filtering for the appengine.versions.create event, aggregating by time window, and alerting on anomalous deployment frequency (e.g., more than 10 deployments per 30 minutes). The pattern of a developer deploying a new version every 30 seconds is obviously anomalous and easily flagged.

Two additional IAP misconfigurations were also presented:

1. Overly broad IAM grants: Adding allUsers or allAuthenticatedUsers to the IAP access list effectively disables IAP. The GCP Cloud Console shows a warning, but the gcloud CLI provides no warning.
2. Exposed bypass paths: If an application has multiple endpoints and IAP is not enabled for all of them, unauthenticated access is possible through unprotected endpoints.

Demo / Proof of Concept

▶ Watch: Step-by-step exfiltration: deploying secrets in Access-Control-Allow-Origin h... (13:00)

The attack was demonstrated through screenshots showing the end-to-end exfiltration process: the YAML configuration with the embedded secret, the HTTP OPTIONS request bypassing IAP, and the response containing the secret visible to the external attacker. The automated exfiltration process achieving 15 MB/day throughput was described.

Defensive Implications

▶ Watch: Detection: OPTIONS requests are not logged -- only version creation events (16:00)

Organizations using GCP IAP should audit whether the "Allow HTTP OPTIONS" setting is enabled on any IAP-protected applications and evaluate whether it is truly necessary. If it must be enabled, implement detection for anomalous App Engine version deployment frequency as described in the talk. The App Engine Deployer role should be reviewed in the context of least privilege -- consider whether developers truly need deployment capability in production environments.

More broadly, the two IAP misconfiguration patterns (overly broad IAM grants and unprotected endpoints) should be checked across all IAP-protected applications. Defenders should be aware that the gcloud CLI does not warn when adding allUsers to IAP access lists, unlike the Cloud Console.

Key Takeaways

• GCP's IAP "Allow HTTP OPTIONS" setting creates a covert data exfiltration channel through the Access-Control-Allow-Origin response header
• An internal attacker with the App Engine Deployer role can embed secrets in App Engine version deployments and an external attacker can retrieve them via unauthenticated HTTP OPTIONS requests
• Exfiltration throughput is approximately 15 MB/day -- modest but sufficient for secrets, tokens, and certificates
• HTTP OPTIONS requests bypassing IAP are not logged; detection relies solely on monitoring App Engine version creation frequency
• GCP classified this as low severity and expected behavior and declined to change the architecture
• Adding allUsers to IAP via gcloud CLI produces no warning, unlike the Cloud Console

About the Speaker(s)

Ariel Kalman is a senior security researcher at Mitiga, based in Tel Aviv, Israel. His research focuses on cloud security and data exfiltration techniques. He responsibly disclosed the IAP exfiltration technique to GCP before presenting it publicly.