How i Hacked Scopely using “Sign in with Google”

Hi guys,

so i’m here again to share you a new knowledge and amazing writes up with other interesting vulnerability i found in the program on HackerOne .

it’s been a year since my last writes up and doing Bug Bounty Hunting since i already have work im busy doing with my Jobs, Thanks to Bug bounty i got stable job with a young age, and it helps me to fully understand the flow of the system and how things works.

So let’s start…

as i mentioned im busy with my work and not doing hunting for a long time but on Oct 30, 2021 it’s Saturday so basically i don’t have work on that day, but i miss doing something… so im scrolling on the social media platform and i see a post about bug bounty so it cross to my mind why i will try to do bug bounty again?

so i start visiting hackerone website again after a long time and finding a target so as bug bounty hunter my instinct work like spider-man so i chose the correct tartget for my testing, i only chose one program and that is Scopely so after that i read the Policy & Scopes so my spider-man instinct are activated and i picked the domain scope that i want to penetrate, it not like penetration in your on mid its “Web pentesting”.

Note: Choosing the correct target is important, its not about bugs it’s about the target… the bug is only a bonus…

so first i test the authentecation flow of the system, thats part of my methology i don’t skip authentecation flow when im doing pentesting…

The system have no registration its only a Login, but the system use Google oauth2

so i try to to login “Sign in with Google”

and its look normal, like other website so i tried to logout my account and its also normal.

So i started reviewing the source code…, btw I’m Web Developer so it’s easy to me to read a code. So Lets do this!!

So when i look on the soure code, There’s have a 2 file gets my attention, the [AuthService.js, TeamworkApi.js]

First i look on the AuthService.js and i found something interesting here,
The loginWithGoogle function is use only window.location to get the google access token.

so again my spider-man instinct are activated again i felt something went wrong on the loginWithGoogle, so lets analyze it.

The login function generate a universal unique identifier (UUIDv4) as preregId, its use basically as ID of users.

But what their doing on loginWithGoogle function and also use to finishLogin function?

btw, What finishLogin function do? so the finishLogin is getting preregId and returning AuthToken? i felt very special here…

Let’s read more code.

Wait…. What!?? they are getting authToken from “/user/fullfilledAuthToken/{prepregId}”. ???

so what’s the problem here?

The problem here, is the auth Flow is f*ck!! the preregId is client side generated not back-end/server-side, when you look at AuthService.js on line 32. where preregId are generated on the client Side…

Means, You can generate your own custom preregId to get your authToken on that endpoint and they can’t validate the preregId they can only validate the format of UUIDv4 (if they impliment it), They can only validate the UUIDv4 if it already existing on the database but in this case this is client-side generated !!!

SO when you send a request to “/user/preregister” endpoint you can get your authToken in “/user/fullfilledAuthToken/{prepregId}”

Example:

you can get your authToken in this endpoint:

Response:

Now, How can we identify who is the user behind the preregId (xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx) if this only client side generated? and there’s no credentials?

Let’s deep dive more here…

Ok.. Now we know the flow of the login so ok let’s focus on that how can you exploit that.. let’s start using burp suite to capture all request 1 by 1

So confirm!!! you can enter our own custom UUIDv4 so the UUIDv4 is now already exist on their database so whats next?

So after you registered the custom UUIDv4 as preregId they passing it to Google oauth2 end point.

in the response it will redirecting to:

So this is how they identify who is the users who owned the preregId,
This is how they verified the UUIDv4 that we insert in preregistration and how they identified which user is attempting to login using code from google..

The code returning from google is also a access_token, so it should be your access token of your account’s

so basically in the state they are returning xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx (preregId) and code parammeter (access_token)

as you can see they returning preregId in the scope and also returning the code from google.

so the proccess is when you login with xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx (preregId) using your gmail account so means when you go to the “/user/fullfilledAuthToken/xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx” endpoint the authToken you get from that response is from the gmail account that you login.

When we look at code snips of the loginWithGoogle, we can see that they are passing fromPath & preregId.

so we can hacked the victim by sending a link like this:

so if the victim click the link, if he have already account and their gmail account is loged-in in the thier browser, You can force the victim to login-in their account’s via visiting the link.

Let’s make more research about this.

So i test the open redirect from fromPath.

‘fromPath’ is a path where user’s redirect after they successfully login.

Note: when the preregId is already used you can’t use it again, so i make a lot of test on this.

So after i test open redirect i check my burp collaborator client and i’m surprise in the result.

we can leaked the access token from gmail account in the Referer headers!!!

So means we can hack the google account that used to sign-in to the scopely

We are one more step to make more impact and automate on this…

Another vulnerable confirm again, Let’s combine all vulnerability we found on this to make huge impact!!

so i created simple script: