Bringing Out of Scope, In Scope
By: Saurabh Tiwari
Tags: Bug Bounty

We are all aware of the CSRF on Login form being out of scope in almost all of the bug bounty programs. This post is about chaining this out of scope vulnerability with another vulnerability to show the impact.

CSRF on linking your social media account

While hunting on this program, let’s call it redacted.com (for obvious reasons), I found a feature that was used to link your social media account (e.g. Gmail, Facebook etc.) with your account on redacted.com. It followed the normal OAuth flow i.e. clicking the connect your Gmail button, which leads to your Gmail and asks for your verification and then it verifies your Gmail account by sending the code with client id.

After verifying my Gmail account and linking it to redacted.com, I looked up in the burp history to see the requests that were made throughout this whole process and to my surprise the first request that was made (which is when you click connect your Gmail ) didn’t have CSRF token to verify the session. Interesting!

But then I realised that the session was being checked when you click on verify on the Gmail page when you are redirected to it. So even if the connect your Gmail doesn’t have CSRF protection, the very next step has. So are we done? It’s not a vulnerability, then? Nope. Let’s try again.

So I disconnected my Gmail account and reconnected it to the same redacted.com account and this time it didn’t redirect me to any verification on Gmail page. This is a known behavior in OAuth flow. When you verify the same social media account with the same client the second time, it won’t lead you to the verification page and simply verify you as long as you are logged in to the account in the same browser. It doesn’t matter if the client account is different.

What we have now?

So, what can be done with the information we have right now? Let’s see:

We have CSRF on connect your Gmail The verification page doesn’t show up if the social media account has been linked before.

Attack Scenario

If the attacker can somehow login to their social media account on the victim’s browser and trick the victim to click on the url that leads to the account linking (the url behind connect your Gmail ), then the attacker can link their social media account with victim’s account. Now if the attacker logs in to the redacted.com page using login with google , they will be logged into the victim’s account.

But wait! How would the attacker login to his own social media account on victim’s browser? Social media like Gmail and Facebook don’t have CSRF on their login page. Social engineering? That won’t seem plausible in this pandemic.

So this attack scenario has failed, we can’t hack into someone else’s account using this scenario.

But our old friend that had been out of scope for too long comes into the game. CSRF on login on redacted.com.

New Attack Scenario

The attacker unlinks the Gmail account that the victim account has been linked to, then they’ll log the victim out of redacted.com, login using their own credentials (notice that there is no CSRF implemented here) and send a request to linking the social media account (belonging to victim) to the attacker’s account and then log out from victim’s browser. All of this can be done by hosting a page on a server and sending the url to this page to the victim.

Now when the attacker logs into their own account they can impersonate the victim.

This is how you can chain an out of scope vulnerability with another vulnerability to show an impact. There are other out of scope (in general) vulnerabilities like self XSS that can be chained with similar types of vulnerabilities to create an impact from nothing. But all of that depends on the functioning of the webpage and your creativity.

Thanks for reading!