This is the write up of my last Facebook Report, How I was able to bypass the permissions approvals system in the 2.x Facebook API Versions in 2 different ways.
FIRST Flow :
+++Flow discussion:
Here the attack is done on two main steps:
(1) The victim visits normal login with Facebook page for the unapproved page and the app can’t ask for more than public information.
This step main target is to get the app scoped id for the current user.
(2) Adding the user to the roles as admin/developer at the back-end of the script.
(3) Auto Redirecting him to the normal login with Facebook page asking for more permissions as a FB approved app!
* Of course all of this takes seconds at the backend of the attacker’s server *
Here the attack is done but I’ve found some other vulnerabilities that making this attack even more professional.
– Blocking the victim between the step (1) and (2) mentioned above will prevent the invite from reaching him and if it reached him he will be unable to define it’s source (by whom it was sent).
– you can add a user to application roles using his (app scoped ID) not his real ID and it will work when of course, only the real ID should work.
+++What’s the main and critical vulnerability in this flow?
between step 6 and 5 in the flow you will notice the Facebook condition this condition checks if application is authorized to request this permission and in our case of course the application isn’t, then Facebook starts another query checking if user is one of this application roles here is the problem, the structure of the app roles table should be (or I guess it’s already like this) the following :
-ID
-app_id ( the application ID )
-user_id ( The user ID )
-role (ADMIN/DEVELOPER/TESTER/..)
-status(1,0)( Approved the invitation,Didn’t approve it )
The Facebook Query here is something like the following
( SELECT COUNT(*)/some fields FROM `table` WHERE `app_id`=’the_app_id’ AND `user_id`=’the_user_id’ )
So it’s not even checking if the user approved the invitation that’s why this query will return results even if user didn’t approve the invitation and the authentication page will appear and work with the user, and that’s what is actually happening in this flow..
+++FIXES
– Fix should be by adding ( `status`=1 ) or whatever approved value should be.
Facebook uses hacklang so I guess all you need to know is this (http://docs.hhvm.com/manual/en/hack.async.mysql.examples.php) to fix this dangerous issue.
– Also preventing the app owner from adding users to roles with the app scoped ID and only allow what’s mentioned in the add form (To add someone you aren’t friends with on Facebook, use their fbid or username.)
– Also when the app owner blocks the user who received an invitation, the invitation sender name should appear even though he blocked the user.
IF YOU FIXED THE FIRST FLOW MENTIONED ABOVE THIS ONE WILL BYPASS THE FIX WHY?
Because you can add testers to the app without even sending them a request!!
SECOND Flow :
( MORE IMPACT )
+++Flow discussion:
Here the attack is also done on two main steps:
(1) The victim visits normal login with facebook page for the unapproved page and the app can’t ask for more than public information.
This step main target is to get the app scoped id for the current user.
(2) Adding the user to the roles as TESTER at the back-end of the script ( he will be successfully added not pending, and system won’t wait for his approve because there is no invitation ) .
(3) Auto Redirecting him to the normal login with facebook page asking for more permissions as a fb approved app!
* Of course all of this takes seconds at the backend of the attacker’s server *
+++What’s the main and critical vulnerability in this flow?
here adding the user as a tester from ( https://developers.facebook.com/apps/app_id/roles/ ) directly activates him as a tester and allows the app owner to ask for any permissions from him!
+++FIXES
Here the fix will be by inserting the user to database as inactive (Status=0,didn’t accept invitation yet) and send him an invite, means use the same adding scenario as adding an admin/developer to the app.
NOTICE: Adding the user as tester from the api (https://developers.facebook.com/docs/graph-api/reference/v2.5/app/roles) will send him a request before he is truly added that’s how fix should look like.
We got 500$ for this vulnerability because Facebook had no fast fix for it at that time and they asked me to keep all the details private.
Hey!
Building a website? Or already built a one? Think twice before going public and let us protect your business!
Previous Next