Tuesday, 6 December 2016

Bruteforce to disable a feature in parse.com


Shailesh here!

Endpoint : Checking existence of a particular user(by email address) before adding him as a collaborator! (https://parse.com/apps/{APP_NAME}/collaborations/validate?email=test@example.com)
Vulnerable parameter : email 
Vulnerable URI portion : APP_NAME

Normal brute force :  An attacker could fire a simple bruteforce of 200 requests and a payload for email parameter on mentioned endpoint for victim's app to make this feature of adding users disable for victim. 

There was no ACLs on this endpoint so an attacker could use victim's app name at this endpoint. And parse had a bruteforce protection which was based on app name instead of IP address. So because of these two weakness, an attacker could disable this particular feature for a long while by repeating bruteforce attack!  In result, victim was not able to add any more collaborator in his app.

CSRF : there was no CSRF protection on this endpoint. In case of existence of ACLs, An attacker could disable the feature using CSRF as well. ;)

In short, there was following 4 issues at this endpoint :

1) Disabling feature remotely  : Lack of ACLs and proper rate limiting.

2) Disabling feature via CSRF  : Lack of verification of anti-csrf token.
3) Session issue                   : No authentication was required. (Perhaps, Excluded)
4) User/Email enumeration      : Guessing existed email addresses. (Excluded)

Parse has fixed these issues by adding ACLs, anti-csrf token and session verification so now, an attacker can't use victim's app at this endpoint.

Thanks to Facebook security team for fixing this one and rewarding me

Thank you for reading! :)

Report Timeline:


6 August 2015     - Report Sent as User enumeration
7 August 2015     - Added for information about disabling a feature
8 August 2015     - Asked for more information by Facebook (About testing of disabling feature)

8 August 2015     - More clear information sent + Informed about CSRF issue

12 August 2015   - Escalation by Facebook  
6 January 2016    - Finally, Fix Deployed by Facebook :D
9 January 2016    - A Bounty Awarded of $1500 USD by Facebook :)

PS : Sorry for the late writeup! ;p  

Join on Twitter : https://twitter.com/shailesh4594

Wednesday, 29 June 2016

5 IDORs in translate.google.com


Shailesh here!

There is a module named "Translation Toolkit" in https://translate.google.com and i found that a sub-module named "Translation Memories" was fully vulnerable to IDOR vulnerabilities!

I found 5 IDORs in Translation Memories.
1. IDOR to change name of victim's Translation Memory :
An attacker was able to change name of victim's translation memory because there was lack of proper ACLs at this endpoint.

HTTP Request :
POST /toolkit/utmname?hl=en HTTP/1.1
Host: translate.google.com



2. IDOR to search from victim's Translation Memory :

An attacker was able to search from victim's translation memory because there was lack of proper ACLs at this endpoint too.

HTTP Request :
POST /toolkit/gettm HTTP/1.1
Host: translate.google.com


3. IDOR to replace or add .tmx file into victim's Translation Memory : 

You may find something about .tmx file from Here. I used such .tmx file to add some data into victim's Translation Memory. I was able to replace or combine .tmx data into victim's translation memory because of lack of proper ACLs on uploading .tmx file into a Translation Memory.

HTTP Request :
POST /toolkit/tmappend?hl=en HTTP/1.1
Host: translate.google.com

Content-Disposition: form-data; name="security_token"

Content-Disposition: form-data; name="tmid"

Content-Disposition: form-data; name="tloc"; filename="my_memory (1).tmx"
Content-Type: application/octet-stream

4. IDOR to delete victim's Translation Memory :

Yeah!!  Also, There was no
ACLs at this endpoint. So an attacker was able to delete victim's translation memory using a simple IDOR mechanism.

HTTP Request :
POST /toolkit/deletetm HTTP/1.1
Host: translate.google.com

5. IDOR to takeover victim's Translation Memory :

There was no ACLs on sharing a Translation Memory with an user. So an attacker was able to share victim's Translation Memory with himself to be an owner of that particular Translation Memory.

HTTP Request :
POST /toolkit/utminfo HTTP/1.1
Host: translate.google.com
Connection: keep-alive
Content-Length: 396


In short, i was able to modify victim's Translation Memory.
For all requests, tmid(s) was a vulnerable parameter!

That's all ;)

Due to low-sensitive data leakage, i received a combined bounty of $3133.7 from Google.

Thank you for reading!  :-)

-Shailesh Suthar

Monday, 1 February 2016

Information Disclosure in Facebook - PoC by Shailesh Suthar


I found a vulnerability in which i was able to disclose following information of Facebook users.

> Full name of User
> Mobile number or Email Address
> Profile Pic

Endpoint :

POST /login/async/known_user_block/?login_id=[MOBILE_NUMBER or EMAIL_ADDRESS] HTTP/1.1
Host: www.facebook.com
Content-Length: 44


This endpoint was not rate limited!

It was not a normal user enumeration because full name and profile pic were disclosed and also, mobile numbers/email addresses with "only me" privacy were disclosed via this endpoint!

That's all ;)

Actually, Mentioned endpoint was available to just a very small subset of users (only a very small subset of users could use the endpoint) so impact was very low otherwise this might be called a perfect privacy leakage issue!

Because of very limited impact, i got a minimum reward from Facebook.
Thanks to Facebook security team for fixing this one!

Due to this one and one more, I am listed in Facebook Hall of Fame - 2016!

Update : On 10th Feb'16, I got an email from Facebook security team on this ticket that "After further review of this issue, we have decided to increase the reward to $1500 USD total."

I am very thankful to The Facebook Security Team for taking another look of this issue without my request! :-) It's impressive!

Thanks for reading!
Twitter : https://twitter.com/shailesh4594

Report Timeline:
5 December 2015    - Report Sent
8 December 2015    - Asked for more information by Facebook (Due to abnormal endpoint)
8 December 2015    - More information sent
18 December 2015  - Escalation by Facebook
29 December 2015  - Bounty Awarded of $500 USD by Facebook :) (First Bounty)
8 January 2016       - Fix Deployed by Facebook
10 February 2016    - Bounty Awarded of $1000 USD by Facebook :) (Second Bounty)

Wednesday, 29 April 2015

Privacy leakage vulnerability in facebook - PoC by Shailesh Suthar

Privacy Leakage : Counts of actions of a blocked user can be viewed.

Hello , I am Shailesh Suthar, an independent security researcher. I found a vulnerability using that i was able to view counts of recent updates of a blocked user. Also It was possible to view counts of updates regarding status, photos, games, comments-likes , music-videos and other activities separately!

When we create a new friend list , following POST request is generated :

POST /friends/edit/ajax/save_list/ HTTP/1.1
Host: www.facebook.com

Then I modified two parameters as below :


Received below response:

for (;;);{"__ar":1,"payload":null,"onload":["goURI(\"\\\/lists\\\/ID_OF__FRIEND_LIST\");"],"bootloadable":{},"ixData":{},"lid":"0"}

Blocked person was added into new friend list name “Dummy”.
And just blocked user was existed in this List.

Even adding a blocked person in a friend list is not a security vulnerability (Still allowed). So I checked page of Friend lists (https://www.facebook.com/bookmarks/lists)

A counting number was shown for friend list as pointed in below image!

I reported this to Facebook security team. And it got fixed!
Thanks to Facebook security team for fixing this one.

Report Timeline:
Dec 28, 2014 8:38pm   - Report Sent
Jan 3, 2015 3:01am      - Escalation by Facebook
Jan 15, 2015 2:08am    - Fix Deployed by Facebook

Mar 6, 2015 11:11pm   - Bounty Awarded of  $1000 USD by Facebook :)