Monday 23 January 2017

Facebook Vulnerability - Delete Any Video on Facebook

Back in June of last year I discovered a critical vulnerability that allows me to remotely delete any video on Facebook. In addition, I also had the ability to disable commenting on any video. This allows a bad actor the ability to delete videos on Facebook without permission or authentication.

This vulnerability is similar to another video deletion bug that another researcher discovered here:

Instead of attaching the victim's video to a comment, I discovered a way to attach the video to an event post. When you delete an event post it also deletes the attached video.

To exploit this vulnerability I took the following steps:

1. Create a public event on Facebook or visit any public event

2. Go to the Discussion tab of the event and create an event post by uploading a photo or video

3. Upload the photo/video and intercept the POST request. The POST request will look like this:<Profile ID>&dpr=1

Where <Profile ID> is the user account you're posting from

4. In the post request there is a vulnerable parameter called:
composer_unpublished_photo[0]=<Video ID>

<Video ID> represents the ID of the video that you were just uploading.

5. Replace <Video ID> with any video on Facebook

6. The server response will give you an error saying "This content is no longer available". But the video has been successfully attached to the event post you made.

7. Refresh the Events Discussion page and you will see that the event posting has appeared with the victim's video attached

8. Click on the small arrow dropdown on the top right of the post and choose "Delete Post"

9. A popup dialog box will appear that says:
"You are about to delete this post. The video will also be removed from Photos and Videos."

10. Click Delete

11. Wait approximately 20-30 seconds and the video will be deleted from Facebook

You will also notice in the dropdown section that there is the option to "Turn off commenting". This allows you to disable commenting on the video of your choice.

These are the steps that allowed me to delete any video on Facebook.

Video demonstration: 

I used the Fiddler tool to intercept the request

June 29th, 2016 - Reported Vulnerability to Facebook
June 30th, 2016 - Video demonstration requested by Facebook
June 30th, 2016 - Video demonstration sent
June 30th, 2016-  As POC, Facebook requests I delete a demo video on their test account
July 1st, 2016 - I confirm that I've deleted the demo video
July 15th, 2016 - $10,000 bounty awarded by Facebook
January 23rd, 2017 - Wrote about the vulnerability publicly

Thursday 14 November 2013

Facebook Open URL Redirection Vulnerability

About a week ago, I discovered an open url redirection vulnerability in Facebook that allowed me to have a link redirect to any website without restrictions.

The flaw exists in the way facebook handled the url parameter. Visiting the link below would always redirect to the facebook homepage:

But I noticed that changing the url to a random string, for example:

The link above generated a unique "h" variable and passed the url parameter to Facebook's Linkshim:

So how do you bypass the restrictions and load arbitrary links? You simply remove the http:// part of the target destination and it will redirect successfully:

Facebook's Linkshim (l.php) interprets the same as thus allowing for a working redirection. As you may have read in the past, url redirection flaws in facebook and third party applications puts a user's access token at risk if that link is entered as the final destination in an Oauth dialog. But the most common use of a redirection flaw in general is the ability to convince a user to click on a trusted link which is specially crafted to take them to an arbitrary website.

However, facebook informed me that because the redirection occurs through the l.php method, they have the ability to filter and ban particular websites from redirecting using their automatic spam and malware analysis. But not all malware/spam can be caught by facebook, and by the time a link is banned, an attacker would have already moved on to another link.

Video Proof of Concept:

(Best Viewed in HD)

Facebook responded the day after my report, and they were quick to patch the flaw in about a week and a half. The payout for this bug is $1,000.

~Dan Melamed

Friday 23 August 2013

Critical Pinterest Exploit Compromised Privacy of over 70 Million Users

I'm writing about a critical vulnerability that I discovered in Pinterest. The flaw allowed me to view the email address of any user on Pinterest.

To reproduce the flaw, you first visit the link below:

As you can see, the information belongs to the owner of the 
access token. However, by changing the /me/ part of the link to someone 
else's username, you will be able to see that user's email address.

For example:

The link above will show the email address that belongs to the user 
"pinterest". This flaw works with any user on Pinterest. It works with 
either a username or a user id. And it works with any access token.

Video Proof of Concept:

(Best Viewed in HD)

A solution to this problem, is to check the owner of the access token 
against the user whose information is being requested.

With Pinterest surpassing over 70 million users and given the amount of high profile figures and brands that are using the site, such a flaw could have spelled disaster in the hands of a blackhat. A hacker could have setup a bot to retrieve all of the email addresses from a list of users for spam or malicious purposes.

The Pinterest Security Team has confirmed that the exploit has been patched. My experience with Pinterest has been outstanding and they even added my name to their Pinterest Heroes List:

I would also like to say that I had discovered the same type of security flaw in StumbleUpon. I was able to view the full name, email address, age, gender, and location of any user on StumbleUpon. Unfortunately, they never gave me permission to disclose the exploit, even after they patched it. So I'm not going to write about the StumbleUpon flaw in particular.

But I'm glad that Pinterest is much more open to the discussion of security issues. Combining both the Pinterest and StumbleUpon flaw would have allowed a hacker to collect over 100 million email addresses.

~Dan Melamed

Thursday 8 August 2013

Facebook Fanpage Invite Exploit & CSRF

I'm finally able to write about another vulnerability now that its been patched. This is probably considered to be a medium-severity bug

I discovered a feature on Facebook that allows you to invite your friends to like a Facebook Fanpage. I've discovered 2 vulnerabilities in this feature:

1. I found a way to invite any Facebook user to like a Fanpage even if they are not my friend
2. A Cross Site Request Forgery flaw

The scenario is that a spammer could setup a bot to collect every single Facebook ID and spam them all with unwanted invites to like their fanpage. The CSRF allowed invites to be sent on behalf of another user who visits a malicious website.

To reproduce this flaw, you first visit a link with the ID of the page you want to invite friends to:

You will see a list of your friends to invite. When clicking to invite someone, you change the invitee_id parameter in the HTTP request to another Facebook user id that belongs to someone who is not in your friends list.

The CSRF flaw was that the request was using the GET method without any anti-csrf tokens:

Visiting the link above would invite Mark Zuckerberg (profile id: 4) to like your fanpage.

After the patch, the link now requires a POST method which includes the fb_dtsg token. And you can no longer send invites to people who are not on your friends list. Depending on the target user's notification settings, the invite would either appear in their notifications or under the "Like Pages" tab and it usually sends out an email informing the user that they were invited to like the fanpage.

Video Proof of Concept:

(Best viewed in HD)

Update (August 20th): I'm receiving $5,000 for both of these bugs

Friday 14 June 2013

Hacking Any Facebook Account Exploit POC

This is my first documented Facebook vulnerability. I have a couple other vulnerabilities which I will be disclosing once they are patched by the Facebook security team. 

A critical vulnerability exists in Facebook that would allow a hacker to easily take complete control over any Facebook account. If the victim is logged into Facebook, all a hacker has to do is get the victim to visit a website link. Once the link has loaded, the attacker is able to reset the victim's password.

The vulnerability exists in the "claim email address" component of Facebook.

When a user tries to add an email address that already exists in the Facebook system, they have the option to "claim it".

When claiming an email address, Facebook did not check who the request came from. This allows an email to be claimed on any Facebook account.

In order to exploit this, you need 2 Facebook accounts.
1. An account with the email address (that you want to claim) already added to it.
2. Another account to initiate the claim process.

For example:

When making a claim request for a email, you are taken to a link that looks like this:[fbid]=AQ3Tcly2XEfbzuCqyhZXfb8_hYHTnHPPd-CDsvdrLzDnWLpsKTMcaXtIzV0qywEwbPs

Updated (July 16th):
Some people asked me to clarify how I got the link above, so I've added 2 new visuals below:

After the exploit was fully patched, here is what happens when you try to claim an email:

Now since I did not take a screenshot of the claim process before the patch, I will provide an edited image of what the Claim popup dialog looked like: (its not exact):

Clicking on the "Claim" button would automatically redirect you to the link above

I found out that this parameter appdata[fbid] was the encrypted email address. For this demonstration, the encrypted email was "". The link will redirect you to the sign in page for Hotmail. You must sign in with the email address that matches the encrypted parameter. Once signed in, you are taken  to a final link that looks like this:

Viewing the source code will show that the claim email process has succeeded:
<script type="text/javascript">window.opener.location.href = "\/claim_email\/add_email\/check_code?email=funnyluv196\"; window.close();</script>
There were two important aspects which made this exploit simple.
- The link expires in around 3 hours, giving plenty of time for a hacker's use.
- It can be visited on any Facebook account because there is no check to see who made this request.

All a hacker has to do is insert this link on a webpage as either an image or an iframe. Example:
<img src="" width="0" height="0"/>
 The victim is now sent a link

Once clicked, the email (in this case: is instantly added to their Facebook account. The victim does not receive any notification whatsoever that this email has been added.

The hacker can then reset the victim's password using the newly added email address. Thus allowing the attacker to take complete control over the Facebook account.

This vulnerability has been confirmed to be patched by the Facebook Security Team.

Video Demonstration Below:
(HD option is available.)

~Dan Melamed

About Me

I'm a security researcher. You can follow me on twitter @danmelamed


Media Inquiries:

Questions or Comments