Summary
I found a way to disclose any user’s email address through a CORS misconfiguration in Identity-Aware Proxy (IAP) by opening a malicious domain. I implemented two different attack scenarios to read the email addresses of both authenticated and unauthenticated users.
Introduction to IAP
First, it’s important to understand what the Identity-Aware Proxy (IAP) is and how it works. IAP is a service offered by Google Cloud Platform that helps control access to applications deployed on the cloud, allowing requests only from authorized users.
With IAP, you can enforce access control policies for your applications and various resources. For more information about this service, you can refer to the official documentation.
IAP Workflow
When IAP is enabled, users are redirected to the Google Account sign-in page. If the credentials are valid, IAP checks whether the user is authorized to access the requested resource.
If the user has the appropriate permissions, the request is forwarded to the protected resource. Conversely, if the user is unauthorized, they receive a message stating, “You don’t have access,” which is returned to them. This error page contains the email addresses of both the logged-in user (which is not public) and the owner of the application.
Attack Scenarios
I wondered whether it would be possible to read the email addresses of other users. After conducting some reconnaissance, I identified several domains protected by IAP. The following attack scenarios were on my mind:
- Exploiting a CORS vulnerability in IAP to read the email address by opening a malicious domain.
- Finding an insecure postMessage channel to disclose the email address.
The second scenario was unsuccessful, so I focused on the first. Many servers read the Origin header from the client and reflect it in the Access-Control-Allow-Origin header, thereby granting access to all domains, including malicious ones.
To test for this vulnerability, I sent an HTTP request with an arbitrary origin to check if both the “ACAC: true” and “ACAO” headers were reflected. To my delight, the IAP was indeed vulnerable to a CORS misconfiguration. This misconfiguration allowed arbitrary origins to request credentials, effectively circumventing the Same-Origin Policy (SOP) and enabling a malicious domain to issue authenticated requests to the IAP:
The Exploitation
Authenticated User
Creating a proof-of-concept exploit to steal a user’s email was straightforward. We only needed to send a malicious CORS request to read the email address.
Unauthenticated User
For an unauthenticated user, the process is more complex, as we need to send the request alongside the user’s credentials. Therefore, I had to devise another attack scenario.
The first idea that came to mind was to force the victim to log into the app via Google SSO and then send repeated XHR (XMLHttpRequest) requests to steal the email address. But how could I force the victim to log into the app?
I attempted to frame the Google Account sign-in page within my domain, but this failed due to protective measures in place. I then tried using window.open, which worked perfectly! The opened window allows users to choose between different accounts for signing in:
An attacker could configure a malicious domain and host the above script. How does this exploit work? It first redirects the user to the Google Login page, then sends XHR requests to IAP every second. After a successful login by the user, we can access their email address.
Timeline
May 3, 2022: Report Sent
May 6, 2022: Report Accepted & Nice catch!
May 31, 2022: The VRP panel has decided to issue a reward of 1337$
May 31, 2022: The VRP panel has decided to issue a bonus of 1000$.
“We’re issuing a $1000 bonus for highlighting the systemic pattern of this bug. Thanks!”
The issue has been fixed by Google in July 2022.