A Cold Day in E-Commerce - Guest Post

This guest post appears courtesy of one of my team mates, Jonathan Spruill, and shows some of the extremely cool work we get to do in our Incident Response practice at Trustwave's SpiderLabs.

Recently an investigation led me to research the vulnerability described in the following CVEs: CVE-2013-0625, CVE-2013-0629, CVE-2013-0631, and CVE-2013-0632.  From the Adobe Security Bulletin  (http://www.adobe.com/support/security/bulletins/apsb13-03.html): “vulnerabilities that could permit an unauthorized user to remotely circumvent authentication controls, potentially allowing the attacker to take control of the affected server”.  This sounds particularly ominous and in a moment we will see just how damaging the attack was in this case.  As with most e-Commerce cases, this investigation relied very heavily on the review of web access logs.  Using basic tools to analyze the log files, I quickly found the entries where the compromise occurred. 

Here the attacker checked to see if the site has been compromised already.  I found this source: https://www.it.cornell.edu/services/alert.cfm?id=2419&back=security

which indicated that h.cfm, help.cfm and others were variations of the name used for a webshell in this attack.

Here the attacker accessed the page at the heart of this exploit.  By accessing the administrator.cfc page using with the specific options, the server returned the base64 encoded version of the administrator password hash.

The attacker then passed this encoded and hashed password back to the server.  The server allowed access to the mappings.cfm page without complaint.  I was puzzled for a bit as to why the attacker would go directly to this page.  In recreating the exploit, I discovered that this page holds the path information the attacker would need to know in order to upload his malicious files.

The attacker accessed the page sheduleedit.cfm and created the task which would upload the malicious files.

In this step of the attack we presume the attacker has generated the task to upload the webshell.  We must presume this is the case as there is no record of the successful task creation in the web access logs, or any other log for that matter.  By default, there is no logging enabled for scheduled tasks.

An interesting feature of these scheduled tasks is that they can be run either on a time schedule or launched directly.  ColdFusion can be configured to use these tasks to generate web content from static data sources.   However, an attacker can arbitrarily load any file from any location.  In this case the file uploaded was a webshell.

Here the attacker forced the newly created task to run.

And in the next transaction, the attacker deleted the task.  This very effectively covered his tracks within the ColdFusion management interface, since, as mentioned previously, logging of scheduled tasks is not enabled by default.

   

The last step in this sequence, the attacker accessed the newly uploaded webshell.  In the postmortem analysis of the site’s codebase, I was able to find and further examine the webshell. 

The webshell was not encoded or obfuscated as we typically see in our investigations.  It includes a fair bit of functionality: upload and download files, search for filename or file content, and issue SQL queries.  If you are interested in the code used in the webshell, I found a copy on pastebin: http://pastebin.com/2v3PMx4M

The conclusion of the investigation showed a customized database scraping script was uploaded and successfully downloaded a significant amount of card holder data.

Not quite satisfied with seeing the attack in the logs, I wanted to further understand how this exploit worked.  I was able to duplicate the attack in a test environment using a browser and with the help of my new favorite proxy tool, ZAP from OWASP, I could see in better detail the key data elements passed from browser to server and back again.  I couldn’t help but feel that this was still not a best representation of the attack seen in the logs.  I first searched all the typical places for a proof of concept to try in my test environment.  I exhausted my Google-Fu with no success. Left with no other option I decided I would write it myself. 

So why would a forensics guy want to write an exploit?  First, like folks who climb Mt. Everest, because it’s there.  Second, since I couldn’t find an example of the exploit code, I wanted to see if there was something else that could be learned and identified as an Indicator of Compromise (IOC) for future investigations.  Third, it gave me the opportunity to work on my scripting skills and learn a few things along the way.

Rather than post the script itself for all the kiddies to sponge up, here's a video demo of the exploit against a default install of ColdFusion 9.0.2.

The script duplicates the most important behavior in this attack, which is the POST request to scheduleedit.cfm, forcing a task to run, followed by immediately deleting the task.  These IOCs along with unusual filenames, such as h.cfm, a.cfm,  help.cfm or similar files in the /CFIDE directory should cause any web administrator to investigate their logs more closely.  An interesting IOC missing from this attack is directory traversal as seen in other ColdFusion exploits. 

As for mitigating the vulnerabilities, Adobe recommends setting a password for the RDS user account, preventing access to the CFIDE path, and applying the patch per APBS13-03.  In my testing, setting the RDS password was sufficient to prevent this attack.

The End Game: Part 1

Last weekI posted about some of the reconnaissance tools that attackers are using against E-Commerce sites, then about what some of the evidence looks like in the logs. Now I want to go over what they are doing with their ill-gotten access.

Attackers aren't just in it for the fun anymore. While we still see our share of political defacement's and attacks that are pulled off just to prove a point, most of the cases that forensics firms like mine are working involve the theft of data. Attackers are stealing Personally Identifiable Information and selling it to crooks that use it to defraud Medicare/Medicaid and other social programs. The same data can be used to commit classic "Identity Theft" and open accounts under other peoples names.

Even easier is the theft of Cardholder Data, there is a sophisticated black market built around the sale of credit card numbers. I talk about it in my conference presentation "Hunting Carders for Fun and Profit" (coming to a con near you in 2013) and it really blows people away how readily available the hardware, plastics and card numbers are. It's really easy for an attacker to gather card numbers and sell them in bulk to a middleman that specializes in parting out these "dumps" for a set price.

All of this data capture and sale really is the "End Game". It's how they get there that I want  to talk about.

The top way I see data being exfiltrated is SQL injection. I talked about this in my last post and put up a quick example. I usually see an attacker hammer away at a site for a couple of days with different tools, but once they find that vulnerable page, it's over in a matter of minutes or hours. This is a very direct kind of attack. They poke around until they find a way to directly access your DB and just suck all the records right out. It's very effective but not terribly sophisticated (usually, see Hunting Carders for a very sophisticated attack).

New Year, New Look, New Post: How did they find me? Part 2.

Last post we went through some of the free utilities available to attackers for reconnaissance purposes.  The utilities I talked about in that post are all things that I have seen used over and over again in successful attacks. What I did not touch on was what these attacks look like in Apache and IIS log-files.

Let's start with some basic search methodology. The idea here is to "read" through a log-file and search it for specific terms. You can use grep by itself or sed, awk, gawk or a dozen other commands. If you use a Linux workstation or the windows ports of Linux utilities it will look something like this:

grep -i "keyword" -r *

If the output doesn't look the way you want it to or you are having trouble targeting specific files with grep alone, you can refine somewhat by stacking commands like so:

Strings -s *.log |grep -i "keyword"


I guess the big secret here is the keywords. They will vary slightly from case to case but, generally speaking, SQL injection can be identified by searching for union select, xp_cmdshell, concat and also by looking for specific database table names in the logs. The last of these is especially true if you know what type of data is at risk and where it resides. One of my favorite PCI related searches is to look for "cvv" in the logs or "cc_number".  If you are concerned about data being snatched from a particular database, grab the table names and run a search. It's very common to see fields like "First_Name, Last_Name, Address"

11.22.33.44-[01/Jan/2011:00:03:01 -0700] "GET /catalog.php?pageid=99999+union+select+1,2,3,4,5,6,7,8,9,10,OrderNumber,CardDateExpire,CardNumber,CardCVV,FName,LName,Address1,City,State,ZipCode,Coountry,12,13+from+Orders+limit+10,5000--+ HTTP/1.1" 200

 OUCH!