Long time no see, guys. And during that long time I've been finally able to make my first valid bug bounty report to Facebook, my first valid report everrrr (Yay). So here I'm going to explain the details on how I was able to find the bug.

Well, on a boring day (as usual), I was unintentionally debugging Facebook mobile app's API just too see if I can wagger any useful new data from the Facebook API. Their current mobile API was kinda boring so I decided to take a look at their very very old API system: FQL.

I think the hard part of this is that FQL has been deprecated for a few years and much of their docs are removed. Long time ago the only way I was able to see the docs is to put the old docs link onto Wayback Machine, but it seems unstable, some of the records are even dead and I don't know why the page would randomly refresh, causes annoying to me. I stayed with FBDevWiki since I found the site, there are still some of the fields missing here but would be enough for basic FQL researching.

For me, to successfully report such a valid bug on FQL, I must find something that successfully allow me to either read or modify something that normally I shouldn't be able to. Since I think FQL is strictly used to query data more than modifying them, I decide that I would go on the journey finding some hidden data fields that developers forgot to hide while developing the app.

To further extend my ability to find new data fields, I left the FBDevWiki page and go find my own piece of old Facebook app's source code which would still use FQL. After a few searches on Github (which I couldn't remember what search query I used anymore), I found this.

A good ol' repository of decompiled Facebook source code from 7 years ago, perfectttt

Upon analyzing the repository for a while I found the folder contains many Java source files responsible for querying/modifying data from the server. And they rely much on FQL queries!

Then while analyzing data from those source files, I found this:

Actually I found lots, lots of fields than this, so I had to test a lot to see what work and what doesn't, but within the purpose of a writeup, I will go straight to the point.

So, I crafted a *redacted* FQL query for this strange mobile_app_data to see which data would it obtains from the server.

And here is what I got:

Let me explain, there a 3 fields of data which are leaked:

  • is_installed: Determine which app the user got on their mobile (Facebook for Android, Facebook for iOS,...). The attacker could see which kind of devices a targeted user have.
  • last_used: Determine the last time user have their app used
  • has_push: Determine if the user has push notification enabled on the device or not.

Inside those fields, instead of app name, the returned data contains an object with the key as the app's id and the boolean/number value. To get the app name from their id. We could use this graph API query:

https://graph.facebook.com/<app_id>?fields=name&access_token=<access_token>

After further investigation I realized that I could only affect users in my friend list. But since it still caused information leaks, I decided to submit a report.

Report timeline:

  • 18 Jun, 2019: Report submitted
  • 20 Jun, 2019: Reply from Facebook, saying that they are able to reproduce the report
  • 21 Jun, 2019: Reply from Facebook, saying that they are sending it to the appropriate product team for further investigation
  • 20 Jul, 2019: Reply from me asking for updates upon investigation
  • 24 Jul, 2019: Reply from Facebook, saying that they have looked into this issue and believe that the vulnerability has been patched and ask for my confirmation
  • 24 Jul, 2019: Reply from me, patch confirmed
  • 26 Jul, 2019: Reply from Facebook with a bounty of $750