Reflected File Download - A New Web Attack Vector

PLEASE NOTE: As promised, I've published a full white paper that is now available for download:
White paper "Reflected File Download: A New Web Attack Vector" by Oren Hafif.

On October 2014 as part of my talk at the Black Hat Europe 2014 event, I presented a new web attack vector that enables attackers to gain complete control over a victim's machine by virtually downloading a file from trusted domains. I decided to call this technique Reflected File Download (RFD), as malware can be "downloaded" from highly trusted domains such as Google.com and Bing.com without ever being uploaded.

As long as RFD is out there, users should be extremely careful when downloading and executing files from the web. The download link might look perfecty fine and include a popular, trusted domain and use a secure connection, but users still need to be wary. Look at the following link for example. Up until a few months ago, it could have been used to steal ALL cookies from your browser, perform actions on your behalf and steal emails from your Gmail inbox:

https://www.google.com/s;/ChromeSetup.bat

Google fixed the vulnerability so that the link above now only downloads a harmless text file.

RFD, like many other Web attacks, begins by sending a malicious link to a victim. But unlike other attacks, RFD ends outside of the browser context:

1) The user follows a malicious link to a trusted web site.

2) An executable file is downloaded and saved on the user's machine. All security indicators show that the file was "hosted" on the trusted web site.

3) The user executes the file which contains shell commands that gain complete control over the computer.

Figure 1 – The three steps attack flow of reflected file download

For a Reflected File Download attack to be successful, there are three simple requirements:

1) Reflected – Some user input is being "reflected" to the response content. This is used to inject shell commands.

2) Filename – The URL of the vulnerable site or API is permissive and accepts additional input. This is often the case and is used by attackers to set the extension of the file to an executable extension.

3)Download – The response is being downloaded and a file is created "on-the-fly" by the Web browser. The browser then sets the attacker-controlled filename that was parsed in requirement 2 above.

Figure 2 – A service is vulnerable if the three RFD requirements are met

At the conference, I presented three proof of concept videos that show different exploitation techniques of an RFD attack found on www.google.com:

1. Execute operating system commands – the video shows how attackers can create RFD links that execute the "calc" command as a proof-of-concept command, opening windows calculator. To show that RFD is not limited to any specific browser, the attack is demonstrated on Firefox, Chrome and Internet Explorer 8.
   
   
   
   
2. Steal cookies and emails from Gmail – this video shoes how RFD can be used to open Chrome in an insecure mode, disable Same-Origin-Policy and steal information that is associated with any domain. The victim domain for demonstration purposes was mail.google.com, but in fact the attacker can target any domain using this attack or even target a dozen domains at once.
   
   
   
   
3. A cross-social-network-worm – the video uses similar techniques to the ones used in the second proof of concept above, however, this time the exploit spreads the malicious link on behalf of the victim through social networks, infecting more users.
   
   

Though RFD is not a "JSON attack", the nature of JSON APIs (which conveniently conform to the RFD requirements) and the vast number of JSON APIs, make JSON an ideal target. To date, a site generating JSONP responses is almost certainly vulnerable in one way or the other to RFD.

Mitigating RFD using Web Application Firewalls

Trustwave encourages application owners to mitigate RFD vulnerabilities by implementing the mitigations described in the white paper. Implementing mitigations takes time, and Trustwave WAF users can add the following custom rule in order to detect active probes and exploits of Reflected File Download vulnerabilities until a permanent fix is applied:

SecRule REQUEST_URI "@rx (?i\:^[^?]*\\.(bat\|cmd)(\\W\|$))"

The above rule detects exploitation using the more dangerous "bat" and "cmd" extension, however, there are quite a few additional dangerous extensions that you might want to add to the rule. Note that if your site legitimately host files with "bat" and "cmd" extensions, this rule will block such functionality.

ModSecurity users can use the following equivalent rule:

SecRule REQUEST_URI "@rx (?i:^[^?]*\.(bat|cmd)(\W|$))" "phase:1,id:100,t:none,t:urlDecodeUni,block,msg:'Potential Reflected File Download (RFD) Attack.'"

What's next?

Users should inspect links carefully and access downloads by searching for the real setup files using your favorite search engine. Don't execute files you have downloaded by following links from emails, social networks and sites you don't normally trust.

Breakers should help secure their Web sites by finding and reporting RFD issues in penetration tests and code reviews.

Defenders should deploy secure configurations in web servers and web application firewalls to prevent exploiting RFD issues.

Builders should write secure APIs and follow secure development guidelines that are not vulnerable to RFD.

To review the technical details of this attack and the complete set of mitigations, please read the complete White Paper:

Download Eu-14-Hafif-Reflected-File-Download-a-New-Web-Attack-Vector-wp