Facebook RFD and Open File Upload

WS201504 – Facebook Reflected Filename Download and Open File Upload
by David Sopas @dsopas


I found a couple of security issues on Facebook that I share with them via the Whitehat Security Program but after some discussions they concluded not to be worth much attention.

#1 File Upload

The first security issue I found was that it’s possible to upload a file with any kind of extension to Facebook server via Ads/Tools/Text_Overlay tool. This online tool checks the upload image for too many text on a image to user on their ads. Back to my research… A user can upload executable files or just use Facebook servers as file repository. In my proof-of-concept I uploaded a batch file without any restriction and I can access to it anytime anywhere as long as I’m logged in on my account.



#2 Reflected Filename Download

My main research was focus on this type of vulnerability. I discovered two RFD on Facebook and they just ignore both of them. The first one was present on Graph Facebook API and could be replicated under Internet Explorer 9 just by sending a link:



I used a temporary access_token that can be achieved here – https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2 – if this access_token expire you can get one easily there or use a persistent one created in a Facebook app.

Or by using HTML5 <A DOWNLOAD> vector working this way on latest versions of Google Chrome and Opera. On Firefox it works if you can force the user to use “Save link as”. [You can do this simply with JavaScript]

Online proof-of-concept:


To the user the entire process looks like a file is offered for download by Facebook trusted domain and it would not raise any suspicious. A malicious user could gain total control over a victims computer and launch multiple attacks.

On all my PoC’s I used calc from Microsoft Windows as showoff but other operating system commands could also be used and injected on Facebook JSON file:

shutdown -t 0 -r -f [reboot victims machine]

ping facebook.com [or multiple commands for DoS]

The second RFD I found is only replicated via HTML5 <A DOWNLOAD> vector because it lacks filename manipulation on the URL so you need to force them.


Facebook described this attack scenario as:

The attacker either posts this link and
1. hopes people with an outdated version of IE click it, download an unexpected random file. Then find that file on their drive and run it?
2. socially engineers people with updated versions of their browsers to click a link to a non-facebook domain, then click a second link to download the file, and THEN find the downloaded file on their drive and run it?

Which I replied:

1. Yes keeping in mind that IE9 is the second most used version of IE. Added to IE8 they still are the most used IE versions.

2. A good explanation of a possible attack scenario was already presented at Blackhat covered by Oren Hafifhttps://www.youtube.com/watch?v=V9YYAiMZY9k.
Also a victim don’t need to “find” the downloaded file. You can just run it when download is finished.

Again Facebook replied about my RFD:

We can’t control all the ways browsers may allow content downloads or the different app formats that a computer may allow.
We can’t know apriori all potential executable formats nor can we reasonably prevent someone from saving a response to their computer.

In my opinion that it’s wrong. Facebook can control it by using for example:

Content-disposition: attachment; filename = f.txt

Controlling what is passed via URL on their WAF or Web Application. Why should a user need to use || or other strange characters on their API URL without encoding?
Hey, Google fixed RFD issues this way why shouldn’t Facebook do the same?

Facebook has now open vulnerabilities that can be used by malicious users and affected millions of users.

Hope they fix them someday and that my full disclosure prevents unaware users of this type of security risk.

I did my best…

Achaste interessante? Partilha!