In a previous blog post, I provided "Method of Entry" analysis for a ColdFusion compromise baed on sanitized data from a SpiderLabs IR/Forensics team investigation which resulted in the attacker's installing a malicious IIS module that captured customer credit card data. In this blog post, we will analyze another ColdFusion compromise that again resulted in customer credit card data being stolen, however the initial vulnerability and exfiltration methods differed.
Thanks to my SpiderLabs colleagues Jon Spruill, Grayson Lenik and Ryan Jones (IR/Forensics), Ryan Linn (Pentest) and Chris Woodbury (Research - Vulnerability Analysis Team), for assistance with this blog post.
Step 1: Access Password Hashes (CVE-2010-2861)
The vulnerability exploited in this attack was CVE-2010-2861.
Here is sanitized snippet from the IIS web server log file when the attacker sent the directory traversal attack data in the "locale" parameter of the "enter.cfm" page:
The attacker is attempting to access the ColdFusion "password.properties" file. The result of this attack would present the attacker with data similar to the following example in the HTML response HTML:
Notice that the HTML page now contains the password hash data from the password.properties file. This data can now directly be used by the attacker. They do not even need to attempt to do hash cracking as it is possible to simply submit the hash value in the password field of the form and ColdFusion will authenticate the user with it.
Step 2: Login with CFADMIN Password Hash
Here are two log snippets showing the attacker successfully logging in with the obtained hash value:
After successful authentication, the attacker received a 302 redirect to the index.cfm page.
Step 3: Create a New Scheduled Task
Once the attacker was logged into ColdFusion as an admin, they immediately went to the Schedule Task page.
This is what the Schedule Tasks web page looks like:
The attacker then click on the "Schedule New Task" button:
This presented them with a screen similar to the following:
The attacker then edited the Scheduled Task form to instruct ColdFusion to download a backdoor/webshell called "a.cfm" from a remote URL location.
Step 4: Execute the Task and Download Backdoor/Webshell
The attacker then immediately sends a request to execute the new task to download the webshell file:
The attacker then cleans up by removing the scheduled task:
Step 5: Access "a.cfm" Backdoor/Webshell
The attacker then used their web browser to access the "a.cfm" backdoor/webshell page.
The webshell looked similar to the following screen shot:
Step 6: Review Application's "Checkout" Process
The attacker then proceeded to review/test out the multi-step checkout process of the site when customers are purchasing items.
After running through this process, the attacker identified that the final page that receives the customer's credit card data is "Checkout_Step_4".
Step 7: Edit Checkout_Step_4 to Capture Credit Card Data
The attacker then used the a.cfm webshell to edit the Checkout_Step_4 file:
The bolded/highlighted code below is what the attacker added to this page:
Notice that this CF code is taking the customer data and then appending it to a file called "noties.txt". This file is located in the website's document root so that the attacker can access it for exfiltration purposes. After editing this file, the attacker then uses the a.cfm webshell page to save the new changes:
Step 8: Periodically Access Noties.txt and Profit
With this credit card data snarfing CF code in place, the attacker can then periodically access the "noties.txt" page and exfiltrate the data:
ColdFusion Botnet Connection?
Brian Krebs, an independent security investigative reporter, recently outlined compromises at two organizations that appeared to be the result of a ColdFusion Botnet campaign. In his report, he outlined how two companies were compromised by vulnerabilities in ColdFusion. Here is a snippet of one of the breach notification pages:
Sounds familiar right? We do not have any specific confirmation as to how these companies were compromised or the exact code implemented by the attackers in those incidents, however the attack vectors are strikingly similar.
Conclusions
Attacker Trend: Accessing Credit Card Data In-Transit
As organizations are making improvements to their sensitive data storage practices, criminals are responding by utilizing methods that may access credit card data in-transitincluding:
- POS Malware - that scrapes in-memory data before it is sent across the network encrypted.
- Network Sniffing Malware - that captures data traversing internal network access points in non-encrypted form (no-SSL).
- Time of Purchase Malware - as in this example where attackers add malicious code directly to web applications to grab customer data as it is submitted to the web application with their browsers.
Keep 3rd Party Apps Up-to-Date
The first glaring issue identified here was that this site was popped by a vulnerability that was from 2010. Organizations have many "Time-to-Fix" challenges but 3+ years is not going to cut it. There must be processes in place to manage/update versions of software especially when vulnerabilities are released. There are many publicly available tools that actively look for this specific vuln such as cfide-autopwn. Trustwave offers PCI scanning services that can check for these types of vulnerabiities.
Web Application Firewall (WAF) Protections
In addition to code update processes, organizations should also deploy WAFs to help identify active attacks. Trustwave WAFs can identify and block the example attack we outline here in the blog.
