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.
