No IP, No Problem: Exfiltrating Data Behind IAP

No IP, No Problem: Exfiltrating Data Behind IAP

Speakers: Ariel Kalman, Security Researcher, Mitiga

Conference: Cloud Village

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

Overview

In a compelling presentation at Cloud Village, Ariel Kalman, a Security Researcher at Mitiga, unveiled a novel data exfiltration technique targeting Google Cloud Platform's (GCP) Identity-Aware Proxy (IAP). Titled "No IP, No Problem: Exfiltrating Data Behind IAP," the talk demonstrated how specific misconfigurations and an often-misunderstood security setting within IAP can be abused to bypass stringent network controls and extract sensitive information from otherwise isolated environments. This research is particularly significant for organizations heavily relying on IAP to secure their applications, as it exposes a stealthy channel for data egress that circumvents traditional firewall rules and access management.

Kalman's research highlights a critical intersection of identity management, web security protocols, and cloud infrastructure. By dissecting the inner workings of IAP and its interaction with Cross-Origin Resource Sharing (CORS) preflight requests, the talk revealed how an internal attacker with a common developer role can collude with an external adversary to exfiltrate secrets. The implications are profound, as the attack leverages legitimate functionalities in an unintended manner, making it difficult to detect with conventional monitoring tools and underscoring the necessity of a deep understanding of cloud service configurations beyond their intended use.

The talk not only detailed the technical mechanics of the attack but also provided crucial insights into common IAP misconfigurations observed in the wild. It served as a stark reminder that even robust security services, when improperly configured, can introduce unforeseen vulnerabilities. For security practitioners and cloud architects, understanding this attack vector is paramount to fortifying their GCP environments against sophisticated threats that exploit the nuances of cloud security mechanisms.

Background

▶ Watch: Talk Introduction and Agenda (0:00)

To appreciate the intricacies of the data exfiltration technique, it's essential to first understand the core components involved: Google Cloud's Identity-Aware Proxy, common misconfigurations, and the web security protocols Same-Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS).

Identity-Aware Proxy (IAP) is a fundamental security service in GCP designed to act as an identity firewall for applications. It intercepts all incoming requests to an application, controlling access based on user identity rather than network location. By default, IAP blocks any unauthenticated requests, redirecting users to a Google sign-in page. Upon successful authentication, IAP then performs authorization checks to ensure the user has sufficient roles to access the application. If both authentication and authorization succeed, IAP injects authentication headers into the request and forwards it to the application, allowing the user to interact seamlessly. This mechanism effectively removes the need for traditional VPNs or firewall rules for access control, relying instead on a centralized identity-based approach.

However, IAP's effectiveness can be undermined by common misconfigurations, two of which were highlighted in the talk:

1. Overly Broad IAM Grants: IAP requires explicit specification of which users can access an application. A critical mistake is granting access to special member types like allUsers or allAuthenticatedUsers.

• allUsers: Grants access to anyone on the internet, authenticated or not, effectively making the resource public and completely disabling IAP's protection. While the Cloud Console issues a warning for this, using the gcloud CLI for the same operation yields no such warning, making it easy to overlook.
• allAuthenticatedUsers: Grants access to any user authenticated with a Google account, regardless of whether that account belongs to the organization. This still bypasses the intended organizational identity control.

1. Exposing a Bypass Path: Applications often have multiple endpoints. IAP protection must be explicitly configured for each endpoint. If an administrator mistakenly forgets to protect even a single endpoint, an attacker can access the application's data through that unprotected path, completely bypassing IAP.

The second critical background component is Cross-Origin Resource Sharing (CORS), a mechanism that allows web servers to indicate any other origins (domain, scheme, or port) apart from its own from which a browser should permit loading resources. CORS is a relaxation of the Same-Origin Policy (SOP), a fundamental web security feature embedded in modern browsers. SOP prevents a malicious script on one website from accessing data from another website without explicit permission.

To prevent certain types of cross-origin requests, particularly those that could cause state changes (like POST requests), SOP introduces CORS preflight requests. Before sending the actual request, the browser sends an HTTP OPTIONS request to the server. This preflight request asks the server if the subsequent "real" request is allowed. If the server responds affirmatively, the browser proceeds with the original request; otherwise, it drops it. A crucial design aspect of HTTP OPTIONS requests, especially in the context of preflights, is that they are unauthenticated. They are intended to be lightweight, simple communications between the browser and server to negotiate access, without requiring user credentials. This unauthenticated nature of HTTP OPTIONS requests becomes the linchpin of the described exfiltration technique when combined with a specific IAP setting.

Key Findings

▶ Watch: IAP Misconfiguration: Overly Broad IAM Grants (2:09)

The central finding of Ariel Kalman's talk is the identification and exploitation of the allow HTTP options setting within GCP's Identity-Aware Proxy. When enabled, this setting creates an unauthenticated data exfiltration channel, even in environments with strict network and identity controls.

Specifically, the key findings are:

1. IAP's Default Behavior and CORS Conflict: By default, IAP blocks all unauthenticated requests. Since CORS preflight requests (which use the HTTP OPTIONS method) are inherently unauthenticated, IAP would block them. This default behavior prevents applications protected by IAP from properly interacting with CORS, hindering legitimate cross-origin functionality.
2. The allow HTTP options Setting: To resolve the CORS conflict, GCP introduced the allow HTTP options setting in IAP. When enabled, this setting explicitly permits HTTP OPTIONS requests to bypass IAP's authentication checks and reach the protected application. Crucially, this bypass applies only to OPTIONS requests; other unauthenticated requests like GET or POST are still blocked.
3. Abuse for Data Exfiltration: The core vulnerability lies in combining the allow HTTP options setting with an internal attacker's ability to modify application configuration. An internal attacker, with a role like app engine deployer, can deploy a new version of the application where a sensitive secret is embedded within the Access-Control-Allow-Origin header of the application's response to an OPTIONS request.
4. Circumventing Network Restrictions: This method allows an external attacker to retrieve the secret by sending an unauthenticated HTTP OPTIONS request to the IAP-protected application. This bypasses both IAP's authentication (due to the enabled setting) and any outbound firewall rules that would typically prevent the internal attacker from directly sending data to an external server. The application itself, under the control of the internal attacker, becomes the unwitting exfiltration conduit.
5. Stealth and Persistence: The attack can be automated, allowing for continuous, low-volume data exfiltration (e.g., 15 MB in one day). Detection is challenging because the critical OPTIONS requests and the exfiltrated data are not logged by cloud-native logging services. Only the internal attacker's deployment actions are logged, which, while anomalous, do not reveal the payload.

In essence, the research demonstrates how a seemingly innocuous configuration setting, designed to enable legitimate web functionality, can be weaponized to create an unauthenticated, egress-bypassing channel for data theft when an attacker gains an initial foothold and can manipulate application responses.

Technical Deep Dive

▶ Watch: IAP Misconfiguration: Exposing Bypass Paths (4:00)

The technical foundation of this exfiltration technique rests on a clever exploitation of how GCP's Identity-Aware Proxy (IAP) interacts with Cross-Origin Resource Sharing (CORS) preflight requests, specifically HTTP OPTIONS requests.

IAP's primary function is to enforce identity-based access control by intercepting all requests to a protected application. By default, IAP blocks any request that is not authenticated and authorized. However, HTTP OPTIONS requests, which are fundamental to CORS preflight, are designed to be unauthenticated. This creates a conflict: if IAP blocks OPTIONS requests, applications behind it cannot properly support CORS, breaking legitimate web functionality.

To address this, GCP introduced the allow HTTP options setting within IAP. When this setting is enabled, IAP makes an explicit exception: HTTP OPTIONS requests are allowed to bypass the authentication and authorization checks and reach the underlying application directly. It's crucial to understand that this bypass only applies to OPTIONS requests; any other unauthenticated request method (like GET or POST) will still be blocked by IAP.

The attack leverages this specific bypass. The prerequisites for this attack are:

1. Vulnerable IAP Configuration: An application (e.g., an App Engine instance) protected by IAP, with the allow HTTP options setting explicitly enabled.
2. Internal Foothold: An attacker must have an initial foothold within the GCP environment, allowing for code execution. This could be a compromised Virtual Machine (VM), a Cloud Run service, or any other compute resource.
3. App Engine Deployer Role: The internal attacker's identity must possess the app engine deployer IAM role. This role is commonly granted to developers to manage and deploy new versions of their applications. This privilege is critical as it allows the attacker to modify the application's configuration.
4. External Attacker: A separate VM or server on the internet, controlled by the attacker, which will serve as the data collection point.
5. Network Restrictions: The environment must have typical enterprise-grade network security:

• Outbound Firewall: Blocks direct outbound connections from the internal attacker's compute resource to arbitrary external IP addresses, preventing direct data exfiltration.
• IAP Protection: The application is behind IAP, meaning the external attacker cannot access it directly without authentication (which they don't have).

The attack proceeds in three orchestrated steps:

Step 1: Internal Attacker Crafts and Deploys a Malicious Application Version

The internal attacker, having the app engine deployer role, creates a new version of the App Engine application. This new version includes a subtly malicious configuration within its app.yaml file (or equivalent). The core of this malicious configuration is the abuse of the Access-Control-Allow-Origin HTTP header. This header is legitimately used by web servers to specify which origins are permitted to access resources via CORS. However, the attacker embeds the secret they wish to exfiltrate directly into the value of this header. For example, instead of Access-Control-Allow-Origin: https://example.com, it becomes Access-Control-Allow-Origin: <secret_data>. Any type of secret that can be encoded into a string format can be used here. The internal attacker then deploys this modified version to the App Engine application.

Step 2: External Attacker Initiates the Exfiltration Request

The external attacker, situated on a VM on the internet, sends an HTTP OPTIONS request to the IAP-protected App Engine application. This request is deliberately unauthenticated.

Step 3: IAP Bypass and Secret Exfiltration

Because the allow HTTP options setting is enabled on the IAP instance protecting the App Engine application, IAP permits the unauthenticated OPTIONS request to pass through directly to the application. The App Engine application, now running the version deployed by the internal attacker, receives the OPTIONS request. As configured by the internal attacker in Step 1, the application responds to this OPTIONS request with the crafted Access-Control-Allow-Origin header, which contains the embedded secret. The external attacker receives this response, effectively exfiltrating the secret.

This three-step process can be automated. The speaker demonstrated that by repeatedly deploying new versions with different chunks of secrets and fetching them, it was possible to exfiltrate approximately 15 megabytes of data in a single day. While this might not seem like a massive volume, it is more than sufficient to exfiltrate critical secrets such as tokens, certificates, or small configuration files, which can then be used by the external attacker to expand their foothold and further compromise the environment.

The elegance of this attack lies in its ability to operate within the legitimate framework of IAP and CORS, turning a necessary security exception into an exfiltration channel, all while bypassing traditional network egress controls.

Demo / Proof of Concept

▶ Watch: How Same-Origin Policy Prevents Cross-Origin Attacks (6:00)

Ariel Kalman provided a clear demonstration of the exfiltration technique, illustrating each step and showing how the attack manifests within GCP's logging mechanisms. The proof of concept confirmed the feasibility and stealthy nature of the attack.

The demonstration involved setting up an App Engine application protected by IAP, with the crucial allow HTTP options setting enabled. An internal attacker, simulated with appropriate permissions (specifically the app engine deployer role), deployed a new version of the application. The key modification in this deployment was embedding a "secret" (represented as "shrug" in the example) into the Access-Control-Allow-Origin header within the application's configuration.

The external attacker then sent an unauthenticated HTTP OPTIONS request to the IAP-protected App Engine application's public endpoint. As anticipated, due to the allow HTTP options setting, IAP allowed this unauthenticated request to reach the application. The application responded with the custom Access-Control-Allow-Origin header, which now contained the "shrug" secret. The external attacker successfully received this response, demonstrating the exfiltration channel.

Crucially, the talk also showed how this activity appears (or rather, doesn't appear fully) in GCP logs. A screenshot from the GCP logs revealed a significant spike in operations during the attack period. Upon closer inspection, the logs displayed repeated create version on app engine events, occurring approximately every 30 seconds. This high frequency of deployments by a single user is highly anomalous for typical development workflows. However, the logs for these create version events do not contain the actual YAML file content that was deployed, meaning the specific malicious configuration or the exfiltrated secret itself is not visible in the default logs. Furthermore, the subsequent steps of the attack—the external attacker sending the HTTP OPTIONS request and the application's response—are not logged by cloud-native logging services. This limited logging makes direct detection of the exfiltration extremely challenging, forcing defenders to rely on detecting the anomalous deployment activity as an indicator of compromise.

The demo effectively showcased that the attack is practical, effective, and leaves minimal direct forensic evidence of the data egress itself, underscoring the need for proactive detection of the initial deployment phase.

Defensive Implications

▶ Watch: The Challenge with Cross-Origin POST Requests (7:45)

The "No IP, No Problem" attack highlights critical areas where defenders need to strengthen their posture in GCP environments. Preventing and detecting this sophisticated exfiltration technique requires a multi-faceted approach focusing on configuration best practices, least privilege, and robust monitoring.

Prevention Strategies:

1. Strict IAP Configuration Review:

• Disable allow HTTP options unless absolutely necessary: This is the most critical preventive measure. Organizations should meticulously review all IAP configurations and disable the allow HTTP options setting if the application behind IAP does not require CORS preflight requests from unauthenticated origins. If CORS is required, thoroughly assess the risks and consider alternative architectures or stricter controls.
• Avoid Overly Broad IAM Grants: Never grant allUsers or allAuthenticatedUsers access to IAP-protected resources. Ensure that only specific, named identities or groups with appropriate roles are authorized. Regularly audit IAM policies for IAP-protected services.
• Comprehensive Endpoint Protection: When protecting an application with IAP, ensure all relevant endpoints are explicitly configured for IAP protection. Conduct thorough application mapping and penetration testing to identify any forgotten or overlooked bypass paths.

1. Implement Least Privilege for Application Deployment Roles:

• Restrict app engine deployer (and similar roles): The app engine deployer role, while common for developers, effectively allows modification of the application's runtime behavior, including its HTTP response headers. Implement least privilege for such roles. Developers should only have permissions strictly necessary for their tasks. Consider using more granular custom roles or conditional IAM policies where possible.
• Separation of Duties: Implement separation of duties for deploying code to production. Require multiple approvals or automated CI/CD pipelines that validate configurations before deployment, especially for sensitive production environments.

1. Secure Application Development Lifecycle:

• Secure Coding Practices: Encourage developers to understand the implications of application configuration files and how headers like Access-Control-Allow-Origin function. Conduct security reviews of application code and configurations before deployment.
• Supply Chain Security: Ensure the integrity of deployment artifacts. If an attacker can inject malicious configuration into the deployment pipeline, the attack can still succeed.

Detection Strategies:

1. Monitor for Anomalous Deployment Activity:

• Focus on create version on app engine events: This is the primary log event that provides an indicator of the attack setup. Create monitoring rules to detect an unusually high frequency of create version on app engine operations by a single user or service account within a short timeframe (e.g., multiple deployments within minutes or seconds, as demonstrated by the 30-second interval).
• Baseline Normal Deployment Patterns: Establish a baseline for normal deployment frequency for each application and team. Deviations from this baseline should trigger alerts.
• Contextual Analysis: When an alert is triggered, investigate the user or service account responsible, the application being deployed, and the time of day. Correlate this with other activities from the same identity.

1. Limitations of Cloud-Native Logging:

• It's crucial to acknowledge that GCP's native logs currently do not capture the content of the deployed YAML file (which would reveal the injected secret) nor do they log the unauthenticated HTTP OPTIONS requests or the application's response containing the exfiltrated data. This means direct detection of the exfiltration payload or channel activity is not feasible with standard logging. Defenders must rely on detecting the preparatory actions (i.e., the rapid deployments).

1. Network-Level Monitoring (if applicable):

• While the attack bypasses traditional egress firewalls for the internal attacker, if there are network monitoring tools before the IAP (e.g., WAFs or load balancer logs that can capture OPTIONS requests), these might offer additional detection points. However, this depends heavily on the specific network architecture and logging capabilities.

By rigorously applying these preventive and detective measures, organizations can significantly reduce their exposure to this type of sophisticated data exfiltration attack behind IAP.

Key Takeaways

• IAP Misconfigurations are Critical: Seemingly minor misconfigurations in Identity-Aware Proxy, such as overly broad IAM grants (allUsers, allAuthenticatedUsers) or unprotected endpoints, can completely nullify its security benefits.
• The allow HTTP options Setting is a High-Risk Vector: While intended to enable legitimate CORS functionality, enabling allow HTTP options on IAP creates an unauthenticated bypass for HTTP OPTIONS requests, which can be exploited for data exfiltration.
• CORS Preflight Requests are Unauthenticated by Design: Understanding the unauthenticated nature of HTTP OPTIONS requests (CORS preflights) is crucial, as this fundamental web protocol design choice is central to the attack's success.
• Data Exfiltration Bypasses Network Controls: This technique demonstrates how data can be exfiltrated from sensitive, firewall-restricted environments by leveraging legitimate cloud service configurations in an abusive manner, even when direct outbound connections are blocked.
• Least Privilege is Paramount: An internal attacker with a common developer role like app engine deployer can become a critical pivot point for this attack. Implementing strict least privilege and continuous IAM auditing is essential.
• Detection Relies on Anomalous Activity: Direct logging of the exfiltrated data or the OPTIONS requests themselves is often absent. Defenders must focus on detecting anomalous patterns of application deployment (e.g., frequent create version on app engine events) as an indicator of compromise.

About the Speaker(s)

Ariel Kalman is a Security Researcher at Mitiga, a cloud security company. He delivered this insightful talk at the Cloud Village conference, traveling all the way from Tel Aviv, Israel. Ariel specializes in uncovering novel attack vectors and misconfigurations within cloud environments. A fun fact about Ariel, as shared during his presentation, is that he prefers dogs over humans.