Pre-Account Takeover using OAuth Misconfiguration

Hello guys,

Today I am going to share one of my interesting findings on the private program of Bugcrowd. Since this is on a private program so I will be using target.com as the website name.

Let’s get started. Only 2 subdomains of the private program is in scope. I picked one of the subdomain a.target.com and there is a registration page to create a new account. There is an option that you can also signup using OAuth. So, I created one account using Google OAuth. After that, I explored the website a bit and look for functionality. I thought let’s try for some OAuth Misconfiguration related issues and testing for OAuth related bug is my favorite one. So I started looking for some OAuth Misconfig. I tried CSRF on linking/unlinking Google OAuth, unvalidated redirect after signup with OAuth, and some more known issues. There is a state parameter all over so csrf is not possible, I tried to bypass it but no luck.

I was thinking of what more can be done using OAuth. There is a change email functionality on the profile setting. So, I changed my OAuth email let’s say abc@gmail.com to def@gmail.com. It says if I change email, I am not able to login using Google OAuth.

I proceed with the Unlink option and the email changed successfully without verification of the new email. This time, I logged in again in my account using the email-password method. After a bit of thinking, I tried to log in using old Google OAuth(Already Unlinked) and I am successfully logged in to my old account. It’s like I Unlinked my login with Google OAuth but still able to log in using the OAuth method even after unlinking. So, here I got that there is Misconfiguration on OAuth. Since there is no verification of email after email change so I can use any other people’s email. To show an impact to the company there is an attack scenario :

1. Attacker creates an account on a.target.com using OAuth.
2. Attacker changed his/her email to victim email.
3. When the victim try to create an account on a.target.com, it says the email already exists. Now the victim will reset his/her password and logged in using email-password method.
4. Attacker also able to logged in the victim account using OAuth.

That’s all about the bug.

This bug is not having so much severity but still, some companies paid well.

Some companies paid nothing.

I hope you learned something new from this blog. I will write more of my findings soon so, stay tuned for my next write-up.

Twitter: 7he_unlucky_guy