[Looking for Charlie's main web site?]

Serious security threat for ColdFusion servers [now covered by a hotfix]

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Hey folks, there's a fairly serious security threat out in the wild, and you may want to check if your server's been hit. (It may be old news to some, but for now it's hitting people in the past week or so.) It's been confirmed to have hit at least CF9 (9.01 and 9.0.2) servers, but it seems it would apply to as well to CF10 or down to CF 7, as it leverages the Admin API.

And note that it's NOT one that you're protected against by having applied CF security hotfixes. (Updated Jan 15 2013, as Adobe now has a hotfix for this. More below.)

There's quite a bit for you to consider regarding this recent threat, as I discuss here.

Two updates since first writing this entry:

  • First, I have now struck out that last sentence and changed the title, as Adobe has come out with a fix for the problem today. See my entry, Part 3: Adobe hotfix released for "Serious security threat for #ColdFusion servers. But if you are coming to this entry for the first time, you will want to read the rest of this, and part 2, before going to part 3 (or if you go there just to get the hotfix applied first, do come back for more, as there's still plenty to consider beyond just the one problem and the one fix).
  • Second, as I wrote here the night after I'd first posted this entry, I've had a lot more info to share and so created another entry, Part 2. Among the new information shared there are such things as how the hack worked (not too much detail, though), how to determine what the exploit may have exposed, how to handle resolving things for many sites via scripting, how to lock down the /adminapi and /administrator directories, and most important, why you should not skip all this just because "we already block all access to the CFIDE/adminapi" (and /administrator)". There may be exposure you're not considering. As one more update (on Jan 15) since posting this originally, the technote from Adobe indicates that we should also block unfettered public access to the CFIDE/componentutils directory, used for the component browser.

A Quick Overview

There's quite a bit that you should (and will want to) understand about the hack, which you can learn more in a thread on the Adobe CF Admin forum, where a poster first pointed it out on Friday, and I found that I too had been hit.

See the specific thread for more details, including a fairly substantial reply I offered (which he's marked as "the answer"), where I explain more I'd found about it, including how how it got there, how to confirm how it got there for you, how to rectify things, how one might already be protected against it, etc.

The upshot is that a file is put on your server which gives a hacker pretty much unfettered access to a lot of things including reading/downloading/uploading/renaming and creating files, accessing datasource information, and more. The file to look for is called h.cfm and is placed in the CFIDE directory (at least in the current rendition of the hack, which may very likely change when the hacker learns that it's being publicized.) See the forum thread for more on what specifically to look for.

Fortunately for some, the degree to which the hacker would have access to things may be limited by how careful you've been in other protections, such as explained in the various lockdown guides for CF (here for CF10, CF9, and CF8).

I also explain how, despite my own efforts to protect the AdminAPI folder through which the exploit happened, I still fell victim. Perhaps it could happen to others. And it will certainly likely happen to those who have not implemented any protection against that folder (whether blocking access to it by IP address, requiring additional authentication, or otherwise). More in the forum thread.

Why am I posting here, now?

I was torn whether to blog my answer to that forum reply when the thread was created, or write a reply there in the forum. I chose the latter, and pointed it out to Adobe and some other CF experts, waiting to see any reply, especially if perhaps it was "old news", as I didn't want to alarm people here if it was not. From some replies I've gotten (some not public), it does seem others have been hit.

Also, as I note there, it's always dicey publicizing discovery/resolution of a security breach, as it can open the door to copycats. I tried in the forum thread to avoid giving any info to open new exploits. I also waited a couple of days to see if any specific other response might be posted from Adobe or others. You'll see in the thread that Adobe has offered to investigate further. So with that, I wanted to now spread the word here, and in twitter (do share the word with others).

I suppose comments ought to be offered there on the forum, since Adobe and others (seeing that thread) will be looking there and not here. Still, I realize some may not have an Adobe forum account, or may simply prefer to respond here rather than there. I'll let you decide. I just wanted to get the news out in case anyone else may be hit.

That said, I do realize that some may prefer not to publicly acknowledge that they got hit by this, but if you want to offer an anonymous comment here to say if you did and/or if the info shared helped, feel free. I think it would help some to see that they are not alone in this.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Actually Charlie, this is fixed via hot fix. The details of the exploit can be found here: http://www.blackhatl...
Ken, help a brother (thousands of them) out. What do you mean it "is fixed via hot fix"? Which hot fix? for which version? I said in the forum thread that I was running 9.0.2, which has all the hotfixes, cumulative hotfixes, security hotfixes that existed for 9.0.1 as of May of this year. And the two hotfixes since then do not address this vulnerability.

So what hotfix do you mean? Also, that link mentions no hotfixes. Indeed, it refers to an exploit, but it doesn't seem to be this one. There's no reference to adminapi (which is what this one used, without question).

I'm not trying to demean your attempt to help. I appreciate that you were trying. But I really don't want people to be left with some impression that you have provided "the answer". I just don't see it.
MANY THANKS for the heads-up: we've also been hit on dec 25 on several CF 9.0.2 servers, due to the unlocked cfide/admin* folders in some of the hosted sites.
Not quite sure yet what the exploit has been used for (if anything), but at least that hole has been plugged.
# Posted By Nicolas | 1/2/13 7:00 PM
Let me add, also, in case anyone wonders about there being no replies: trust me, there have been many, all in direct emails to me! As I feared, people don't want to publicize that they were hit.

I'm grateful to see that most are expressions of appreciation. Sadly, a lot of people have been hit by this, some just hours before the blog entry.

Some have asked for more info, and I've updated the entry with one clarification.

Others have asked for more info on how to lock down the /adminapi and /administrator directories.

There have been many blog entries discussing it, but do be careful that some are old (so things may have changed):


http://www.aaronwest... Administrator-in-Apache




http://www.raymondca... rotecting-CFIDE

http://www.michaels.... tion-on-windows


I welcome if anyone has any more to propose. (I may just create a new one of my own.)
@Nicolas, and thank you. It's really been gratifying to hear how many people this has helped.

Of course, that also means that a lot of people have been hacked. I look forward to any possible fix that Adobe may come out with.

But in the meantime, let's all do lock down those /adminapi and /administrator folders from unfettered public access in our web servers!
Actually, it references this:

Don't know if that fixes it entirely, but I do know that I tried the exploit on my own servers, which have all optional security updates installed, and couldn't make it work.
Here's another tip: if you want to find if that h.cfm file exists on your server, there are of course many ways to do a search for such a file. Some people use their editor/IDE, which works, but I'd argue that such tools aren't necessarily focused on doing fast file searches, especially across thousands, tens/hundreds of thousands, or millions of files.

If you're on Windows, I'd recommend the following free tool(s) to do it quicker and more effectively (in my experience)

Then again, I realize that the reason this may not work on my machines is that my default configuration has the CFIDE directory on a different drive than ColdFusion is installed on, and directory traversal will obviously not work in that case -
Once you've been compromised basically anything could have happened. Any tips for tracking down what nasties might be on your server after the stable door has been shut?
# Posted By me | 1/2/13 7:26 PM
@Ken, ok, thanks for the clarification. I didn't readily see a link to a hotfix there.

Anyway, no, that one is NOT the fix for the exploit being used in the case discussed in this entry. It's NOT a directory traversal exploit. As I said originally (in the forum thread and in the post, and in my reply), it's an adminapi exploit.

More specifically, that fix you point to is one that is included in 9.0.2 (because it was for 9.0.1 before 9.0.2 was built), so again, it is NOT a fix that protects against this (because I do already have it, and was exploited).

Hope that helps other readers.

And as for you, please don't take consolation in your having moved the CFIDE to another directory. That is NOT going to protect you in this case. The only protection is to prevent public access via your web server to files in the /CFIDE/adminapi folder.
@"me", that's a reasonable question. I'd been wanting to add a little on that but have been so busy addressing questions and calls on this that I'd not had a chance.

I'll add that as an update to the entry above (since many people never seem to read comments.)
We are also seeing this, currently securing our servers but we are getting other files too - i.cfm, help.cfm, info.cfm all in the cfide directory. If we browse to them they display all passwords for DSNs etc.

Our plan is to create blank copies of these files and set the permissions to read only for a specific user - any thoughts on whether this will be enough to limit this exploit, at least until Adobe release a patch (if they will?)?

Thanks for the blog post by the way, we always look but first time commenting.
# Posted By lukester! | 1/3/13 10:10 AM

Cannot thank you enough for putting yourself out there with reporting this. We were able to get in front of it and lock down both parts of our CFIDE directory (across all IIS sites) using IP restrictions. I'm trying to get our WAF rules set too as the first layer of defense. We too thought we had our administrator blocked...
# Posted By Lee | 1/3/13 2:39 PM
We are tracking this as a very high priority issue and actively working on a fix.
# Posted By Hemant Khandelwal | 1/3/13 10:28 PM
What if adminapi and administrator folders are deleted from the server?
# Posted By Tom | 1/4/13 9:02 AM
Sorry folks. I was just slammed last week (helping people deal with this) so just could not keep up with the comments. Let me now take care of the few I missed since I last replied here:

@lukester, that would be an "interesting" approach. I'd just have deleted the files, rather then leave them there "blank". No one needs them to be there, and indeed the most important thing at the time would have been to block access to the vulnerable /CFIDE directories.

That said, just today Adobe did release a fix, which I discuss in a new part 3 entry, at http://www.carehart....

Anyway, thanks for the kind regards as a "first time caller, long time listener". :-)

@Lee, thanks also for your kind remarks. Also, note that the Adobe bulletins clarify that we want to also protect /CFIDE/componentutils as something not to leave open as unprotected. I just updated the blog entries to reflect that new info. While any current known vulnerabilities in there are indeed now fixed, there could be others that might appear later, so better to protect it now.

@Hemant, thanks so much for jumping in here that week and leaving that comment that you guys were working on this as "very high priority". I'm sure that was as comforting to others as it was to me.

Finally, @Tom, while you could "delete" the folders, that could be overly drastic. First, are you saying that you mean you'd have one copy of the CFIDE used by most sites that would NOT have these, and another used by some one site that WOULD have these directories? If that's so, are you then going to be careful when applying CF updates/hotfixes, when they tell you to extract (as the latest one does) a CFIDE zip over top of your current one, to make sure you do that in both places you now have copies? And what if someone else does that and doesn't know you have 2 copies?

Or perhaps you're thinking, "no, we just have one place for the CFIDE, and we'll delete these and add them back when we need to use the Admin". I know some who have said that. My warning still applies: when you (or someone else does) apply the update's extracted CFIDE zip, you will indeed have a CFIDE there to update (just not these directories you deleted).

Indeed, when the extracted hotfix files are placed over your current CFIDE, you will now have in those directories you had deleted only those few files provided by the hotfix, which could lead to still other confusion.

Just be very careful with the idea of "just removing the folders". The wiser thing, I think, is just to protect them, which I cover more in the Part 2 article.

(And Tom, do note as I said above to others that you now need to consider also removing/protecting the /CFIDE/componentutils, as Adobe says it has vulnerabilities.)

Finally, if anyone might be getting these blog comments as email, and doesn't know it, I have done a Part 2 and Part 3 with lots more info, and have a part 4 (post mortem) in the works. Check out the blog to find them.
Charlie -

We run multiple instances. So, if someone needs to manage the instance, they hit the instance port. Not *:80/cfide/administrator. Therefore, we remove it in the /cfide folder that is presented to the web sites. Along with adminapi and a couple other folders.

And to help address IIS' and CF's "back channel abilities" to still get to /cfide/administrator we put a handy little rewrite rule in blocking access should anyone sneak in on port 80.

Patching is no big deal. It's part of the documented process to update the public cfide folder.
# Posted By Tom | 1/16/13 8:12 AM
@Tom, fair enough. Was warning others as much as you. Glad to hear you feel you have it all under control.

And fortunately, Adobe has addressed the issue in CF10, even with multiple instances, by defaulting to having the CFIDE dir only within the cf10 folders (even if using IIS or Apache), and using a virtual directory for CFIDE in those to point to that. Then the CF10 updater knows automatically to update the "right" CFIDE folders. This should help avoid confusion over CFIDE updates...unless of course one starts creating their own copies manually. Forewarned is forearmed.
I was hit by this as well. They uploaded the files, then used it to mess around on my server, exposing passwords and tons of other stuff. I locked down the CFIDE/admin and adminapi directories, but not the componentutils (just did that now), and they were still able to get in, so componentutils is definitely important to secure.

I was hit again this morning (before securing componentutils) and noticed them hitting the h.cfm file, which I had removed in the first attack. I decided to place the file back there, but I edited it to email me with their IP address and anything else I could grab. They hit it a short time later, and when I went to check the server I noticed they had REMOVED the h.cfm file! No surprise that the IP address came back to China.
# Posted By Gord | 3/7/13 11:15 AM
I just found that help.cfm file sitted on my cfide directory after seing many request for that file on my log.
I previously secured my cfide directory just by authentification + renaming the cfide virtual directory to a name of my choice... ( need to copy administrator/image and recreate a CFIDE virtual directory for this directory, and change script path in cf setting to point to new virtuel directory).
Beside passing the authentification they will have to guess for the folder name... I don't see what else to do...
# Posted By isabelle | 3/12/13 1:16 PM
@Isabelle - Even if you remove your cfide virtual directory, with no protection, you can still call the CFIDE folder and many parts of it will still work. Noticed that by accident on our multi-instance boxes. Ended up writing a rewrite rule to 404 any calls to admin(istrator) via the httpd.
# Posted By Tom | 3/13/13 7:18 PM
To @Isabelle and @Tom, on this matter of how even a site with no CFIDE could expose the CF Admin, I'll note that I did discuss that in more detail in the part 2 article, http://www.carehart...., specifically in the section, "A real gotcha: implicit access to the built-in web server root".

It's really very important that people understand this issue, or they may think they are protected when they are still exposed.
These threats are considerably very dangerous because once your server gets infected everything else follows. That's why its very important to have the right knowledge and perspective on how to handle such threats.
# Posted By server management | 2/17/14 3:50 PM
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting