Adobe ColdFusion Reflected Cross-Site Scripting Flaw

Impact

By gaining remote command execution on a machine running ColdFusion, an attacker can access the internal network, databases, sensitive files and credentials, and the application source code. This level of access may allow a malicious user to easily compromise more assets on a network or in an organization.
Further details can be found in the accompanying blog post.

Patch Date

April 14, 2015

Reported Date

January 11, 2015

Vendor

Adobe

Systems Affected

ColdFusion 10 and 11

Summary

A reflected cross-site scripting vulnerability was found in the post-authentication administrative panel for ColdFusion, an Adobe web application development platform. Due to the critical functionality in the administration panel, an attacker could leverage this vulnerability to execute arbitrary commands on the server.

Vendor Status

Adobe was informed of this vulnerability on January 11, 2015. As part of the responsible disclosure process, we worked together to successfully remediate the issue. Affected versions of ColdFusion can be patched via the administration panel. A CVE has been released for this vulnerability, CVE-2015-0345.

Exploit Availability

The exploit payloads we developed for this vulnerability are located at the Bishop Fox GitHub.

An API used by ColdFusion to list folders and files in dynamic views contains a parameter named dir. The value of this parameter is reflected into the HTML response of any page that uses this functionality.

Since the parameter’s value is reflected in the JavaScript scope, appropriate filtering for JavaScript meta-characters and escape sequences are typically applied. However, this was not the case with ColdFusion. The only filtering found to occur was for HTML tags.

Because of this, it was possible to inject a JavaScript-based cross-site scripting payload successfully. When we executed the second payload in the ColdFusion administration panel, the following actions were performed through JavaScript to gain a backdoor shell:

1. GET request made to a CFIDE administrative page to obtain the CSRF Token
2. POST request made to /CFIDE/administrator/scheduler/scheduleedit.cfm with the relevant parameters put in
3. POST request to run the now added task. A CFML shell is uploaded to /CFIDE/update_cf.log
4. POST request to change the 404 template and 500 template to execute /CFIDE/update_cf.log

Once the payload has been executed successfully, the ColdFusion shell will be available at /404.cfm, /500.cfm or by forcing 404/500 errors on the ColdFusion server.

Researcher

Shubham Shah of Bishop Fox