Initially this is a different way to recreate the bug found by Mohamed A. Baset around March 2014 https://www.youtube.com/watch?v=zepq4U-ahoU https://twitter.com/symbiansymoh/status/441364355448176640. The final decision however was that behavior does not pose a significant privacy/security risk to qualify for a payout. Nevertheless I decided it was a good idea to share to possibility of recreating old bugs.

In summary he was able to use the mobile (m.facebook.com) endpoint to change a status object to a added_photos object without changing the edit history.

The risk that was associated with this I believe, was that any user who commented/liked the owner’s post will not be notified of this change and from the current timeframe be seen to be associated with interacting with a photo they didn’t initially see.

The fix in place that I’ve seen is that using the link

https://m.facebook.com/photos/upload/?story_id=POST_ID&upload_source=timeline_story

Will result in the post showing the edit history.

Using an API endpoint I can recreate this bug leaving no edit history.

Proof of Concept

Given a whitehat account

Two posts were created

A “I love this life.” https://www.facebook.com/permalink.php?story_fbid=1379036662420184&id=100009415895135

B “I hate this life.” https://www.facebook.com/permalink.php?story_fbid=1379036692420181&id=100009415895135

Patched Method using A

a. Using the patched bug link for post ID 1379036662420184

https://m.facebook.com/photos/upload/?story_id=1379036662420184&upload_source=timeline_story

b. Choose a file and click upload.

The photo will be uploaded and the user will be redirected to

https://m.facebook.com/story.php?story_fbid=1379036662420184&id=100009415895135&_rdr

And the edit history is logged https://m.facebook.com/edits/?cid=1379036662420184

Graph API Method using B

a. Obtain a Facebook Native App user access_token for the user

This could have also been done by decompiling a Facebook app, getting the client and creating signature. I prefer the API login method.

b. Upload the photo via the /me/photos endpoint unpublished (published=false)

https://graph.facebook.com/me/photos?method=post&published=false&url=http%3A%2F%2F36.media.tumblr.com%2Fd0ab3ea70a8f7a1b705afcf265ee9c5a%2Ftumblr_n78ql57fcO1sk9t7ko1_500.jpg&access_token=...

c. Grab the ID from the response

{
"id": "1379039205753263"
}

d. Target the POST ID 1379036692420181 as 100009415895135_1379036692420181 (B) via publishing (published=1) the unpublished photo ID

https://graph.facebook.com/1379039205753263?method=post&target_post=100009415895135_1379036692420181&published=1&access_token=...

The response is true

e. Check the edits https://m.facebook.com/edits/?cid=1379036692420181

None are shown

f. Check the activity log

Notice that the timestamp isn’t set for when the photo was added but when the user initially created the post

Thus, I believe I have successfully found a workaround to the patch placed in m.facebook.com for the bug reported in March 2014.

The fix here will be the same as the original report, ensure that edit history is shown when any new object is added.

Timeline

Mar 22, 2015 8:21pm – Report Sent
Mar 24, 2015 5:42pm – Escalation by Facebook
May 19, 2015 8:37pm – Patched by Facebook
May 22, 2015 5:53pm – Facebook made the decision that this behavior does not pose a significant privacy/security risk to qualify for a payout.

When using Facebook Messenger, it is possible to enable synced contacts from a user’s phone.

These operations are normally restricted to Facebook native whitelisted applications.

However there seems to be a check missing in one of the edges, specifically, an HTTP POST /me/contacts when using a third application.

Also, no additional permissions are needed other than public_profile to add a contact. So any 3rd application can in fact use this bug to the session user’s contact list.

HTTP POST https://graph.facebook.com/me/contacts?profile_id=13608786

The expected behaviour will be that

  • Third applications shouldn’t be allowed to execute this call
  • If they are, it shouldn’t be possible with just basic public_profile permissions

Timeline

May 17, 2015 4:15pm – Report Sent
May 19, 2015 6:37pm – Escalation by Facebook
May 21, 2015 11:50pm – Patched by Facebook
May 22, 2015 5:47pm – Bounty Awarded of $500 by Facebook

In Facebook 2.0, user_friends (me/friends) has only been limited to those friends who are using the application.

In addition finding a user’s friends who is not related to session user should not be possible. Finally given that two users’ friend lists are set to “Only me” privacy it should be possible for a third user to see whether these users are friends.

Using a Graph API call it is possible to do all of the above bypassing the privacy settings set here.

Full link

https://graph.facebook.com/v2.0/13608786/friends/friend_id

Response

{
"data": [

],
"debug": {
"messages": [
{
"link": "https://developers.facebook.com/docs/apps/changelog#v2_0",
"message": "Only friends who installed this app are returned in API v2.0 and higher. total_count in summary represents the total number of friends, including those who haven't installed the app.",
"type": "info"
}
]
}
}

The data is empty however the debug error message gives a sign that these two users are friends.

Trying for two users who are not friends

https://graph.facebook.com/v2.0/13608786/friends/not_friend_id

{
"data": [

]
}

So, one has solid indicator to determine if any two users are friends under any of the following

  • non-app users
  • non-mutual friends
  • no user_friends permission

The correct behaviour should be to set the debug error message for both success and failure of two users being friends.

Timeline

May 18, 2015 4:25pm – Report Sent
May 20, 2015 4:06pm – Escalation by Facebook
May 21, 2015 11:26pm – Patched by Facebook
May 22, 2015 5:47pm – Bounty Awarded of $1250 by Facebook

This used to be a bug that qualified for Facebook Bounty. However they no longer award these bugs. I still thought it was good to show what it was about. Facebook doesn’t allow usernames in their API however there are still places that it can be used or accessed.

Given an account with user_videos access and a session user with at least one video it is possible to determine the username of that session user in 2.0+ applications

Using a video from the user

Video ID: 10101896785723137

Prepend with the userID: 13608786

Post ID:13608786_10101896785723137

Calling this post will result in the link field being shown as

"link": "https://www.facebook.com/philippeharewood/videos/10101896785723137/",

Notice the username is placed here and not the app scoped ID.

May 11 at 12:06pm

May 11, 2015 12:06pm – Reported to Facebook Developer Support
May 11, 2015 4:51pm – Bug Assigned
May 20, 2015 8:54am – Patched

This used to be a bug that qualified for Facebook Bounty. However they no longer award these bugs. I still thought it was good to show what it was about. Facebook doesn’t allow usernames in their API however there are still places that it can be used or accessed.

Using a 2.0 application

Execute the following query in FQL

SELECT substr(url,25,25) FROM object_url WHERE id = 13608786

Response

{
"data": [
{
"anon": "philippeharewood"
}
]
}

id can be changed for any user ID.

For 2.0 applications that have transitioned to only app scoped IDs, the error message is

{
"error": {
"message": "(#606) The global ID 13608786 is not allowed. Please use the application specific ID instead.",
"type": "OAuthException",
"code": 606
}
}

To get around this append with 0

SELECT substr(url,25,25) FROM object_url WHERE id = 013608786

or use the app scoped ID equivalent.

Timeline

May 5, 2015 7:11pm – Reported to Facebook Developer Support
May 7, 2015 11:58am – Bug Assigned
May 12, 2015 6:04pm – Patched

A while back a vulnerability was reported concerning vault images being seen by third party applications. This seems to be fixed with error messages for accessing such as

{
"error": {
"message": "(#3) App must be on whitelist",
"type": "OAuthException",
"code": 3
}
}

What the patch did not check however was whether it was possible for a third party application to publish a private vault photo.

And this is possible using the /me/photos edge and vault_image_id.

This means that any application that was able to use the patched vault images vulnerability and stored any of those vault image IDs will still be able to access the image by publishing it to /me/photos

Timeline

Apr 28, 2015 2:25pm – Report Sent
May 1, 2015 4:11pm – Escalation by Facebook
May 13, 2015 6:33am – Patched by Facebook
May 17, 2015 11:14pm Bounty Awarded of $500 by Facebook

According to https://www.facebook.com/help/289207354498410 and previous reports an analyst seems to be a read only role. Using a photo object it is possible to tag as the page when documentation suggests only read access to this user.

This behaviour now returns

{
"error": {
"message": "(#322) Subject does not have permission to tag this photo",
"type": "OAuthException",
"code": 322
}
}

Timeline

Apr 13, 2015 1:22am – Report Sent
Apr 17, 2015 2:52pm – Escalation by Facebook
Apr 22, 2015 8:31pm – Patched and Bounty Awarded of $750 by Facebook

According to https://www.facebook.com/help/289207354498410 and previous reports, an analyst seems to be a read only role. Using any external Facebook object edge, an analyst can like and comment on any object here when documentation suggests only read access to this user.

This behaviour now returns

{
"error": {
"message": "(#200) Permissions error",
"type": "OAuthException",
"code": 200
}
}

Timeline

Apr 13, 2015 10:01am – Report Sent
Apr 15, 2015 3:28pm – Clarification by Facebook
Apr 15, 2015 3:49pm – Clarification Sent
Apr 17, 2015 3:17pm – Escalation by Facebook
Apr 22, 2015 8:35pm – Patched and Bounty Awarded of $750 by Facebook

According to https://www.facebook.com/help/289207354498410, an analyst seems to be a read only role. However as seen in previous reports, it is understood that there are areas that aren’t consistent with the read level.

In plain sight, probably used everyday is the “Like as your page” option, an analyst is able to pull down the list here inclusive of pages he/she is assigned as an analyst. This activity also doesn’t appear in the activity section of the page, so it appears that no admins will be aware unless they monitor the list of likes. It isn’t possible to add a like here as an analyst but the workaround is the API.

As an analyst either the documentation here https://www.facebook.com/help/289207354498410 should better reflect which “write” actions are possible for an analyst or this is a bug that everyone assumed was allowed.

The correct behaviour now returns

{
"error": {
"message": "(#200) User does not have sufficient administrative permission for this action on this page.",
"type": "OAuthException",
"code": 200
}
}

Timeline

Apr 13, 2015 1:22am – Report Sent
Apr 15, 2015 2:52pm – Clarification by Facebook
Apr 15, 2015 3:40pm – Clarification Sent
Apr 16, 2015 8:54pm – Additional Clarification by Facebook
Apr 16, 2015 9:24pm – Screencast Sent
Apr 17, 2015 3:01pm – Escalation by Facebook
Apr 22, 2015 8:30pm – Patched and Bounty Awarded of $500 by Facebook

Using a whitelisted application it is possible to change the ordering of photos displayed in a Facebook of any user using the reorder_pids parameter.

Though a subtle change, it does demonstrate control of a user’s properties not under the session user’s control.

This is now fixed and returns the following error

{
"error": {
"message": "(#200) Insufficient privileges to edit the given object.",
"type": "OAuthException",
"code": 200
}
}

Timeline

Apr 9, 2015 2:37pm – Report Sent
Apr 16, 2015 1:02am – Escalation by Facebook
May 8, 2015 7:46pm – Patched and Bounty Awarded of $500 by Facebook