Earlier this week, SpiderLabs Research team released a blog post outlining analysis of a malicious IIS module that was able to scrape clear text credit card data in transit. This resulted in many news outlets reporting on the story and one included this quote:
"Online security firm Trustwave just won't stop scaring the sh** out of me."
The SpiderLabs Research Malware Analysis Team did an excellent job of describing the functionality of this IIS module backdoor. In this blog post, however, we will analyze the initial web application attack vector (Method of Entry) that was exploited which allowed the attackers to ultimately install the malicious IIS module.
Thanks to my colleagues in SpiderLabs IR/Forensics (Grayson Lenik and Jon Spruill) for assistance with this blog post.
The following graphic shows the top "Method of Entry" items according to the Trustwave Global Security Report (GSR) 2013.
These are the top vectors used to compromise sites according to the SpiderLabs Incident Response/Forensics investigations. The attack method used in the malicious IIS module case exploited a Remote Access vulnerability in Adobe's Cold Fusion application.
ColdFusion RDS is described as:
ColdFusion RDS is a security component of ColdFusion Server used by the ColdFusion Administrator and ColdFusion Studio to provide remote HTTP-access to files and databases. You can use RDS to manage ColdFusion Studio access to files and databases on a server hosting ColdFusion.
ColdFusion RDS features include:
| Secure server access, both basic and advanced | |
| Data source browsing and SQL query building | |
| Remote file access | |
| CFML debugging |
ColdFusion RDS basic security requires developers in ColdFusion Studio to supply a password which, when authenticated, permits access to files and database sources.
The list of robust features above make it an attractive target for attackers. As the last sentence describes, when attempting to directly access the Adobe Cold Fusion "cfcexplorer.cfc" page, a user would be promoted with the provision of an RDS or Admin password:
The first attack attempt that was made against the target site was to check if the Cold Fusion application was vulnerable to CVE-2013-0629 which would allow the attacker to obtain the admin password or hash data.
Here is a snippet taken from the victim site's IIS web server log file:
As described in the OSVDB vulnerability information, the attacker is attempting a directory traversal attack against the cfcexplorer.cfc page's path parameter in order to access the password.properties file. If this had worked, the attacker would have been presented with a page similar to the following:
The attacker could then take the password HASH data and submit it in the RDS cfadminPassword field on the initial screen. In this case, however, the attack was unsuccessful so they moved onto a different variation.
The attackers are able to bypass authentication and can access arbitrary files by passing data to the path parameter value. They next verify if they can access the ColdFusion Admin Parser Toolset:
Despite the returned 500 HTTP Status Code, they are able to access the parser.cfm file. They next send multiple requests to the parser.cfm page and pass Cold Fusion Markup Language (CFML) to the INPUTFILE parameter value.
The attacker is attempting to create a webshell backdoor using CFML data. Note that due to log line limits in the IIS log file, the complete contents of the INPUTFILE parameter payload is not shown. The parser.cfm program will attempt to parse the data passed to it via the INPUTFILE parameter and if there are any problems it will write error and stack information to the ColdFusion exception log (/logs/exception.log). In this scenario, the attackers need to review the exception log in order to identify the filename and location of their uploaded webshell backdoor. This is the next request attempt:
Based on the details stack dump/error data listed in the exception.log file, the attackers were able to local their webshell backdoor (sysinfo_div0.cfm) and send the following request to access it:
Here is a screenshot showing some of the funcationality of the webshell/backdoor.
As you can see, the webshell includes a "File Upload" feature that allowed the attackers to upload the malicious IIS module described in the inital blog post. Here we can see the attackers using a POST command to upload the IIS module:
Once uploaded, the attackers where then able to use the CMD feature of the webshell to execute OS level commands and load/activate the malicious IIS module:
Here's a Pastebin link to a similar CF webshell.
If you are running Cold Fusion applications, Adobe recommends the following Mitigation steps for this vulnerability:
ColdFusion customers using an unsupported version of ColdFusion (including ColdFusion 8.x and earlier) can take the following steps to mitigate these vulnerabilities:
Configure a username and password for Remote Development Services (RDS). These credentials should be different from the Administrator account. After configuring the username and password, users should disable RDS.
Disable external access to the following directories for all hosted sites:Remove any unknown or unnecessary ColdFusion components or templates from the CFIDE or webroot directories.
Implement access control restrictions for the Administrator interface and internal applications via the Administrator Console (in ColdFusion version 10) or within your web server's access control mechanisms for versions 9.0.2 and below.
Ensure your ColdFusion product has the latest hotfix applied.
Refer to the ColdFusion 9 Lockdown Guide and ColdFusion 10 Lockdown Guide for security best practices and further information on these hardening techniques.
It is important to also highlight the criticality of having an expedited patching life-cycle. If you compare the data of vulnerability disclosure by Adobe (January 4, 2013) vs. the time of this particular attack (February 28, 2013), they target organization was compromised less than two months later. In this particular incident, the victim organization was aware of the vulnerability report by Adobe, however they were on a quarterly patching process and had not yet installed the patch. Deploying a Web Application Firewall (WAF) is an excellent method for minimizing the Time-to-Patch expsures for web application vulnerabilities. In this case, the victim organization did not have a WAF already deployed so actual software patching was their only option. In response to this incident, the victim organization updated CF sofware and deployed a WAF.
