It’s the third bug of the year for Facebook bounty hunter Laxman Muthiyah.
At the start of 2015 he noticed that if you could view a photo album on Facebook, you could probably delete it as well, with or without permission.
Simply put, as long as you were authenticated by Facebook to delete some photos, you could in theory delete any photos, as long those photos were already public.
Photo Sync problems
His next bounty-bagging bug involved Facebook’s Photo Sync feature, which automatically uploads photos from your phone to Facebook’s cloud as a kind of instant backup.
In theory, those autouploaded photos were private by default, and were only supposed to be accessible via your Facebook account.
But Laxman found that any other app on your phone that was authorised to read photos stored locally could also read your Photo Sync from the cloud – even if those photos had originally been taken on another device.
So, screenshots taken on your work iPad (screenshots count as photos) could unexpectedly and incorrectly turn up in, say, the screen saver gallery on your personal iPhone.
Page control
Laxman’s latest bug could have cost you control over your personal Facebook pages.
Here’s why.
Third-party Facebook apps can do things like posting status updates, so a malicious or ill-behaved Facebook app can certainly get you into trouble.
However, an app isn’t supposed to be able to get you into permanent trouble by taking over as an administrator of your pages and locking you out.
In theory, then, even if an app goes rogue, you can always wrest control back from it and reverse the unwanted changes.
Except for so-called “business pages” – Facebook pages that aren’t specific to an individual account, but instead represent a business and are typically managed by a number of people.
Third-party apps can request a special access permission called manage_pages for business content, so you can assign different administration roles to different people in the organisation.
Clearly, you want to be very conservative about which apps you allow to manage_pages…
…but you aren’t supposed to worry about your personal pages, because they aren’t, in theory, covered by this privilege.
In other words, even rogue manage_pages apps shouldn’t be able to do anything permanent to your personal pages.
Page administration
Laxman found that a manage_pages request to make user X into a MANAGER (administrator) of page PGID belonging to business B looked something like this:
POST /PGID/userpermissions HTTP/1.1 Host: graph.facebook.com Content-Length: 245 role=MANAGER&user=X&business=B&access_token=AAAA...
If a rogue app were to replay the same request with PGID set to one of your personal pages, and X set to the rogue apps’s developer, the request would fail, because userpermissions requests aren’t supposed to work against personal pages.
You have to use the official Facebook interface to make such changes.
But Laxman claims that by the absurdly simple expedient of leaving out the &business=B parameter above, and changing the PGID, he could trick Facebook into accepting the request, and thereby give X administrator rights over one of your personal pages.
Once X is an administrator of your pages, he can then lock you out of them and thus effectively take them over.
That’s not supposed to be possible.
What happened next?
This is not an earth-shattering bug, because you’d have to trust an app enough to give it manage_pages rights up front.
But it’s a security bypass bug nevertheless, and a reminder that it’s often very hard to try every possible combination of potentially risky inputs during testing.
Which is one reason why companies like Facebook run bug bounty programs.
Laxman received $2500; Facebook closed the hole quickly, before anyone else found it and used it to do harm.
