Identity-Aware Proxy Misconfiguration- Google Cloud Vulnerability

1 year ago 78

BOOK THIS SPACE FOR AD

ARTICLE AD

Summary

I found a way to disclose any user email address via CORS misconfiguration in IAP by opening a malicious domain. I implemented two different attack scenarios to read the email address of an authenticated or unauthenticated user.

Introduction to IAP

First, we need to know what Identity-Aware Proxy (IAP) is and how it works. IAP is a Google Cloud Platform service which helps to control access to apps deployed on cloud and only lets the requests through if they come from a user you authorize.

With IAP, you can enforce access control policies for applications and different resources. You can also get more information about this service from here.

IAP Workflow

https://codelabs.developers.google.com/codelabs/user-auth-with-iap

If IAP is enabled, the user is redirected to the Google Account Sign-In page. If the credentials are valid, IAP checks if the user is authorized to access the resource.

At step 4, the user has appropriate permissions, the request is forwarded to the protected resource (4.2).
For an unauthorized user, it results in “You don’t have access” and sends it back to the user. The error page includes both the email addresses of the logged-in user (which is not public) and the owner of the application (4.1).

The Attack Scenarios

I thought maybe I could read the email address of other users. After some recon, I found different domains which were protected by IAP. I had the following attack scenarios in my mind:

Finding a CORS vulnerability in IAP to read the email address by opening a malicious domainFinding an Insecure postMessage channel to disclose the email address

The second scenario did not work for me so I tried the first one. Many servers read the Origin header from the client and write it to the Access-Control-Allow-Origin header, thus giving access to all domains, including malicious ones.

I sent an HTTP request with an arbitrary origin to check if both headers ”ACAC: true” and “ACAO” are reflected and bingo! The IAP was vulnerable to CORS misconfiguration. Allowing arbitrary origins with the ability to request credentials effectively disables the SOP and allows a malicious domain to issue authenticated requests to the IAP:

The Exploitation

Authenticated User

It was easy to make a proof of concept exploit to steal a user’s email. We only need to send a malicious CORS request to read the email address.

How about an unauthenticated user? We know that it doesn’t work because we need to send the request along with the user’s credentials. We need another attack scenario.

Unauthenticated User

The first idea which came to my mind was to force the victim to login into the app via the Google SSO and then send XHR requests repeatedly to steal the email address. How to force the victim to login into the app?

I tried to frame the Google Account Sign-In page in my domain but it didn’t work because of the protection. How about “window.open”? It worked fine! The opened window allows us to choose between different accounts:

POC

The Attack Scenario

An attacker could configure a malicious domain and host the above script. How does the above exploit work? It first redirects the user to Google Login. Then it sends XHR requests to IAP every second. After a successful login from the user, we access the email address.

I used different approaches to find vulnerable domains which were protected by IAP. Here’s a simple workflow of my recon phase: