Account Take Over Vulnerability in Google acquisition [Famebit]

Greetings,

Myself is Hassan Khan Yusufzai and today i will share my recent finding in Google acquisition, Which is “Famebit”. I was able to take over victim account by bypassing the CSRF protection in email change functionality.

What is Cross site scripting forgery?

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated”.

I hope you all will be aware of the basics of csrf, lets not discuss about the basics, But if you want to learn you can check at Owasp.

Lets move forward ^^

So basically, one of my friend gave me famebit site and asked me to test it. As i like to do pen-testing only in Bug crowd Private programs. One day i was so board so i thought lets Hunt famebit instead.

Whenever I start testing a Web Application i usually start it from the /settings page, Because that page contains basic functionality of the application. So, When i looked for the Email change functionality, i noticed that there is no “Current Password Protection”. No current password protection in sensitive action considered as p4 vulnerability in “bugcrowd” platform. So, reporting it to Google is no worthy.

I checked the POST request to perform CSRF Attack but there was X-Famebit-Token header in the headers & my first response was “It would not be possible to bypass because its Google acquisition site. Lol?” But i though lets give it a try.

Request & Response with Anti CSRF Headers

Request & Response without Anti CSRF Headers

WDF same Response :D

So, there was no server side validation of X-Famebit-Token. Which means CSRF is possible. I made CSRF POC With burp suite and it didn’t work , response was 404 :/. I was like! dude why this didn’t work.???????????????

First thing that came in my mind may be its a referr based CSRF protection that why, but later i find out its not referr based.

So, it was like when we make JSON CSRF poc its appends extra data at the end of the POST data & in my post request it was like

{“email”:”attacker@Hacker.com”}=

I also made a mistake and thought its server side protection some how :P but later on, i understand that its not any server side protection its just extra data that automatically appends in Json Csrf! Right? (if not correct me)

How i dealt with “=” it ? quite simple, i used one extra parameter in my post data that is ignore. Ignore simply takes “=” and ignores it :)

Final Exploit:

<html> 
 <form action=”https://famebit.com/auth/changeEmail" method=”POST” /> 
<input type=”hidden” name=”&#123;&quot;email&quot;&#58;&quot;Attacker@hacker.com&quot;&#44;&quot;ignore&quot;&#58;&quot;” value=”&quot;&#125;” />
<input type=”submit” value=”Submit Request”>
 </form> 
 </html>

POST Data:

{“email”:”attacker@hacker.com”,”ignore”:”=”}

So, Now with the CSRF it was possible to change vicitim’s email and then attacker can change the password also. Account Take Over :D

POC:

Thats it, Google security team fixed it in a day :). I hope you guys learned something new :-)

#Hack_To_Live#

Regards,
Hassan Khan Yusufzai
Security Researcher