Sunday, 13 December 2015

[Responsible disclosure] How I could have removed all your Facebook notes

Note: This is being published with the permission of Facebook under the responsible disclosure policy. The vulnerability is now fixed.

Summary:

This blog post is about an Insecure direct object reference vulnerability in Facebook Notes using which attacker could have removed all your notes just by replacing his Note id with yours in note editing request. 


About Facebook Notes:

Facebook Notes are ways of writing entries about your life, your thoughts, or your all-time favorite songs and then sharing them with your Facebook friends. The beauty of Notes lies in the ability to blog without needing to distribute a web address to friends so that they can go check out your blog. Instead, your friends are connected to your Profile. Therefore, when you publish a Note, it appears in your News Feed.


Vulnerability description: 

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example database records or files.
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

Reference:  https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References


Vulnerable request:

POST /a/note.php?note_id=[victim’s note id]&publish&gfid=[attacker’s token]
Host: touch.facebook.com

fb_dtsg=[attacker’s token]&charset_test=&title=&body=&privacy=&=Publish&_dyn=&__user=[attacker’s userID]

Replacing note_id in the above request led to successful removal of note from victim's account. Note id can be seen by visiting victim's note and copying the id from the URL.



Video POC:







Impact:

Note deletion from victim's account



Disclosure Timeline:

June 15, 2015 : Report sent to Facebook Security team
June 16, 2015 : Bug acknowledged by Facebook Security team
June 16, 2015 : Vulnerability Fixed
June 22, 2015  : Bounty of $2500 awarded by Facebook






Thursday, 4 June 2015

[Responsible disclosure] How I could have hacked 62.5 million Zomato Users


Note: This is being published with the permission of Zomato Team. The vulnerability is now fixed. 

Zomato is an online restaurant search and discovery service providing information on home delivery, dining-out, caf├ęs and nightlife for various cities of India and 21 other countries. It has 62.5 million registered users.
While creating an account, a user can store his phone number, addresses, date of birth, link Instagram account etc. In one of the API call, they were reflecting the user data based on the "browser_id" parameter in the API request. Interestingly, changing the "browser_id" sequentially resulted in data leakage of other Zomato users. The data leaked also had Instagram access token which could be used to see private photos on Instagram of respective Zomato users.

Below are the technical details of the vulnerability:

Description:

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example database records or files. 
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

Vulnerable endpoint:

POST /v2/userdetails.json/XXXXX?&browser_id=XXXXX&type=journey&lang=en&uuid=pgh1evyBWvL+sp9/JpwUpItnk8Q=&app_version=6.5.0.1 HTTP/1.1
Accept: */*
Content-Length: 214
Accept-Encoding: gzip, deflate
X-Zomato-API-Key: XXXXXXX
Content-Type: application/x-www-form-urlencoded
User-Agent: Zomato/5.0
Host: 1api.zomato.com
Connection: Keep-Alive
Cache-Control: no-cache

lang=en&uuid=pgh1evyBWvL%2Bsp9%2FJpwUpItnk8Q%3D&client_id=Zomato_WindowsPhone8_v2&app_version=6.5.0.1&device_manufacturer=NOKIA&device_name=NOKIA%2520Lumia%25201020&access_token=xyz

Replacing the XXXXX with victim's user id in the above request led to information disclosure.

Ease of exploitability:

You can easily get userid of any zomato user by visting their profile. They are public and appended to your profile url.
Proof of concept video:



This bug was responsibly disclosed to Zomato and was fixed within few minutes by the engineering team.  

Disclosure Timeline:
June 1, 2015  09:29 PM : Report sent to Deepinder Goyal, CEO 
June 2, 2015  12:54 PM :  Added Gunjan Patidar, CTO and Shrey Sinha to the mail thread
June 2, 2015   1:04 PM  : Bug acknowledged by Gunjan Patidar 
June 2, 2015  2:01 PM   : Confirmation of vulnerability fix from Gunjan Patidar.