David Sopas

Since I published my Reflected File Download Cheat Sheet I’m getting lot’s of private messages and emails from security researchers and bounty hunters telling that most companies ignore RFD attacks.
So I decided to clear things up and answer three most popular questions.

First a little introduction.
In my opinion they’re three ways of implementing a successful RFD attack.

1. URL address automatically prompts the download dialog in most popular browsers
2. Attack is only available using a external page in modern browsers but works like (1) in Internet Explorer 8 and 9 browsers
3. Attack is only available using a external page in modern browsers

“Reflected File Download is a social engineering attack.”

On attack scenario (1) the victim is prompted with a download dialog just by visiting/clicking the URL – just like a reflected XSS but here the victim downloads a file from a trusted source. In 90% of the cases the victim runs the file. Imagine having the following URL:

https://www.google.com/app/setup.bat?callback=calc
[It’s just an example, this will not work]

If the victim runs the URL it will prompt the download of setup.bat. On Chrome you don’t need to see the source because you see the URL. On Firefox and IE you’ll the the source on the download dialog.

Attack scenario (2) works like (1) in IE 8 and 9. Other browsers need a external page to work using HTML5 download attribute.
The attackers in this last case need to launch a malicious campaign with that link. It’s like phishing emails but here the URL is from a trusted source.

Imagine this attack scenario:

1. Attacker creates a page with a RFD link to a hosting company
2. That page offers domain or hosting promo codes
3. When the victim checks the link (mouse hover or view the source code) it will see that’s from a trusted source [the hosting company]
4. Victim clicks the link and downloads the file (when they view the source of the download they will see the hosting company)
5. Victim gets hijacked

On attack scenario (3) it’s the same scenario from (2) but don’t work as told before on IE 8 and 9.

Some may consider (2) and (3) a social engineering attack. The attacker needs to attract victims into his RFD page. For me it’s a grey area. They’re lot’s of ways to bring victims to a malicious page [blackhat seo, forums, social networks] without too much trouble. The key point here is that the RFD URL is from a trusted source which give the victim a little of confidence that they will download something that is what they’re are loooking for.
Companies that ignore this will have their reputation affected because they didn’t do anything to prevent this attack to their clients.

“We can’t do anything about it. It’s a external page that we can’t control.”

Wrong! On (1) you don’t need a external page.
On (2) and (3) the affected companies can protect and prevent RFD attacks by forcing the filename:

content-disposition:attachment; filename="f.txt"

Even if the attacker external page is using:

<a href="http://RFD_URL" download="setup.bat">Click here</a>

It will try to download f.txt.

Workable fix this by using the following:

“Google don’t consider this to be a issue”

Google has a specific page that tells security researchers that Reflected File Download security reports aren’t reliable for a reward.

But at the end of the text you can read the following:

Before sending a report please remember to include a realistic attack scenario, preferably, one that doesn’t require social engineering.

I already sent two (1) issues to Google and they were both accepted. So always give a good attack scenario.

I already helped most popular companies to fix Reflected File Download issues – Yahoo!, eBay, Microsoft, Google, Linkedin and many more.
Keep your security report clear and complete. Don’t argue with the affected company about their opinion. It’s their prerogative to deny your security report. In the end it’s their decision. – Keep calm and carry on!

Have a good and secure year of 2016 🙂