Recent ColdFusion Vulnerabilities Follow-Up

For about three weeks now, ColdFusion servers have been under attack making use of one of two exploits, one in older versions of an application written in ColdFusion and some through the built in FCKEditor.  Both of these issues have an active fix and should be handled with the utmost priority.
FCKEditor
When Adobe initially shipped ColdFusion 8.0 it included the FCKEditor, which was enabled when using <cftextarea richtext=”true”>.  In version 8.0, the built in FCKEditor file manager and uploader were disabled.  While there was a post about enabling them, most developers didn’t use these features much, either because they would rather handle file uploads separately.  However, when the upgrade to 8.0.1 was released, Adobe enabled file uploads by default on the FCKEditor instance.
It was determined that an attacker could access the upload files directly and by using some form of spoofing, get files uploaded to the server that could potentially allow compromise of Windows security.
To correct this, there are two fixes.  The first is simply to edit the config.cfm file at CFIDEscriptsajaxFCKeditoreditorfilemanagerconnectorscfm to disable uploads [see].  Also, Adobe released a security patch for this issue and is a very high level patch that should be applied to your servers [link].
CFWebstore
As I mentioned in my last post, users who were running older versions of CFWebstore could also be vulnerable due to a few upload scripts that are accessible directly and can be susceptible to file spoofing.  It’s important to note that CFWebstore responding very quickly providing a temporary fix to prevent access to the upload files.  They also released a more detailed description of what exactly was happening to servers which was compiled from many user’s experiences described on their mailing list.
Staying on Top of Things
So how can you stay on top of these sort of issues in the future?  My first recommendation is to subscribe to as many ColdFusion related blogs as possible, at least start with the ColdFusionBloggers.org feed.  Second, join any related forums or mailing lists related to any applications you are running.  Third, try to keep your software as up-to-date as possible, the longer software is in the wild, to more likely someone with lots of time on their hands has found some way of exploiting even the smallest hole to create a very large hassle for you.  Lastly, keep an eye on SANS Internet Storm Center which posts up and coming vulnerabilities that are being learned of and patched, this includes everything from Apple products, web applications, and Windows issues.
Additional Resources

 

6 thoughts on “Recent ColdFusion Vulnerabilities Follow-Up”

  1. Thanks for the followup article on this. I ran into a situation where the hackers were clearly making use of both vulerabilites to attack a site and keep it infected, it was really confusing until we figured out they were using the CF 8 hole as well and got that patched up.

    Also, I’m not sure why no one is mentioning it, but a huge part of problem as I saw it was the handling of JSP pages on CF enterprise, not to mention having cfexecute and cfregistry turned on. These all played a part in alloweing the hackers to gain access to the entire server, and it seems that people should be sure to turn all of them off unless they are REALLY needed. There’s no way of knowing how many other vulnerable applications or installations of fckeditor might be out there for hackers to attack, so it seems a big part of the follow up on this incident should be better locking down of cf servers so that even if a hacker got a cfm page onto one site, they would stay locked on that site alone. I would expect most CF hosts have already taken such steps, but the information seems to be particularly missing from most blogs on the topic, so I just thought I’d mention it for anyone that might be running enterprise on their server and wasn’t aware of this risk.

  2. @John,

    You’re correct, part of the initial payload was indeed a JSP script that was another web shell and I mentioned disabling JSP in my first post about the initial hit to CFWebstore sites. The cost for Enterprise may be high, but knowing that you can save yourself the time involved in re-deploying a server is more than worth it. Hopefully, over the next week or so I’ll be able to finish compiling what directories are required in your Sandboxes for each CF tag and function (admittedly a very large task).

  3. Brent, thanks for all great CF security posts recently.

    You may want to add to your post that the cffile upload vulnerability in CFWebstore could be present in any home grown CF application and that its important for all CF developers to search their code for cffile action=upload and ensure that files are being written to temp or secure directories that aren’t web accessible.

    I know you did a post recently on the spoofed mime types issue but in case readers are just chiming in it would be worth reminding them and linking to it.

    Thanks, Mike G.

  4. Thanks for this update! It will help a lot of people and I will forward it to those clients that think it is too expensive to be vigilant.

Leave a Reply

Your email address will not be published. Required fields are marked *