Account Takeover for Google SSO Users

2 weeks ago 19
BOOK THIS SPACE FOR AD
ARTICLE AD

Mahmoud Hamed

Hi all, In this blog post, I will walk through finding an ATO for Google SSO Users through collaborative work with my friend Refaat.

This ATO was a chain of several bugs, let’s go into the details of each one

DOM XSS

The DOM XSS was in a tricky place. creating the full exploit was challenging due to an aggressive WAF.

Getting CSRF Token

After finding the XSS, We knew that any chain would require the CSRF token to be on the request. Getting the CSRF token was easy since it was in a meta tag on the profile page https://taget.com/profile , To get the CSRF token of any user and send it with any request, we can use the following script:

var xhr = new XMLHttpRequest();
theUrl = 'https://target.com/profile'
token = ''
xhr.open("GET", theUrl, false);
xhr.onload = async () => {
const parser = new DOMParser();
const data = parser.parseFromString(xhr.response, 'text/html')
token = data.getElementsByName('csrf-token')[0].content

Unlink Google Account

At this point, We were able to send any authenticated request using the XSS since We had the CSRF token. However, making it an ATO required a request that could change the password or email. Unfortunately, all the requests We found that could potentially lead to changing the password or email were secure and had no bypass.

After some time, We found something very interesting. We discovered that users could sign up using Google SSO. When logged in with Google SSO, users have the option to unlink Google from their account. This allows them to log in with an email and password instead of Google SSO.

Unlinking Google from Account

When they click on Continue, an OTP (Six-digit code) is sent to their email address.

Upon entering the OTP (Six-digit code), they can set a new password directly.

Here, We found the bug: the OTP code was brute-forceable because there was no rate limiting.

Using the XSS, We could take over any account logged in using Google SSO by sending the request to "Unlinking Google from Account," and then brute-forcing the OTP. Once the correct OTP was found, We could send the request to set a new password with the correct OTP. This would all be done with the leaked CSRF token.

Note: We didn’t report the 2FA bypass as part of the chain; instead, We demonstrated org takeover on another function. We reported the 2FA bypass in a seperate report because the ATO, with or without the 2FA bypass, will be the same severity (High).

That was all for this write-up! If you have any questions or feedback, please don’t hesitate to DM me on LinkedIn or Twitter. See you in the next write-up!

Read Entire Article