Hello,
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.
Ex.,
https://parse.com/apps/VICTIM_APP/collaborations/validate?email=test@example.com
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! :)
PS : Sorry for the late writeup! ;p
Join on Twitter : https://twitter.com/shailesh4594
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.
Ex.,
https://parse.com/apps/VICTIM_APP/collaborations/validate?email=test@example.com
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
