Part 2: Serious security threat for ColdFusion servers [now covered by a hotfix]
Note: This blog post is from 2013. Some content, links and indeed comments from others may be outdated--though not necessarily. Corrections are welcome, in the comments. I may revise the content if necessary.Since I posted my entry earlier today about a Serious security threat for #ColdFusion servers [
At first I was adding these as updates to the previous entry, but I fear that some who may have read it earlier in the day may then miss some of this new info, thus this "Part 2". You will definitely want to read part 1 before proceeding here.
[Update: And since writing this entry 2 weeks ago, Adobe has indeed now come out with a hotfix. I have more to say about that in the new Part 3: Adobe hotfix released for "Serious security threat for #ColdFusion servers". While you should proceed to get that fix in place, you'll likely benefit from reading parts 1, 2, and 3, as there's more discussed than just the thread and fix, itself, which could benefit you down the road.]
Among the new information shared below 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, /administrator, and /componentutils directories, and most important, why you should not skip all this just because "we already block all access to the CFIDE/adminapi" (and /administrator and /componentutils)". There may be exposure you're not considering.
How did the hack work?
[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. I'll update the other references to these directories, below. And while certainly any current known vulnerabilities in those folders are indeed now fixed, there could be others that might appear later, so better to protect them now.]
I didn't want to share too much info, but again I've been asked enough so I'll share at least this: the adminapi exploit allowed the hacker to create a scheduled task, and then that task called a page on another server, and the scheduled task was configured to "save" the output of that to this h.cfm file. Well, the page did a CFHTTP of a page that returned CFML, and so what was "saved" was in fact CFML code into that file. And it's THAT code (and that page) which then allowed the hacker to attempt further exploits (the file manipulation and db access I discussed previously), mostly leveraging a file manager interface (written in CFML) and some of the undocumented java objects (servicefactory).
The good news is that depending on other security hotfixes or updates you may have applied, some operations may have been prevented. More on that later here.
Also, if you followed some of the standard precautions about running CF with a user having limited rights and privileges, that also would have limited potential damage. Again, see the lockdown guides (mentioned in the last entry) for more on that.
What to do if you have been hacked? what did the hackers get?
I've had some people ask what to do if they have been exploited. Of course, the original forum entry explained the need to delete the file (h.cfm) and the scheduled task (if there), and I added in reply (and clarified above) that really one needs to close down public unfettered access to the /CFIDE/adminapi, /CFIDE/administrator, and /CFIDE/componentutils folders to prevent them being exploited again. That's THE MOST IMPORTANT thing to do first. I discuss more about "how" to do that below (if you do go do that first, be sure to come back to read the rest of this section).
So if you DID find the file ended up on your server (and have deleted it and closed the hole), how can you find out what they actually "did" with the hack in place.
Well, first, if you have web server logging turned on, you can see their calls to the h.cfm file. If that gets a 200, then they were able to access the page. And then that page let them do things like access/manipulate files, and access DB info, including passwords. Most operations on the page would lead to GET requests to the h.cfm file, with a fuseaction indicating what operation to perform. So you could search your web server logs for requests to "/h.cfm fuseaction" (assuming your logs have the requested file and then the query string next to each other, separated by a space, as is true for IIS logs).
Be careful, though, when interpreting the logs: Not all the operations in the page lead to "gets". Some lead to "posts", which then have no query string.
You can even run the page (if you didn't delete it, or only renamed it), to see what sort of operations it performs. The file is open CFML source (not precompiled or encoded), so you can see what it does, and at least with the version I had it did not do any operations that sent info off the server, etc.) It would be wise to rename or move it before running it, so no one else can find it.
Update: when you run it, you will be asked for a code. The code is in the file itself. Just look for "code" in the source to find the value, and use that to get in.
You can then see that operations you perform lead to these web server log entries. (Do beware that sometimes web servers are slow to flush their buffers, so don't expect an operation you do to lead to an immediately updated web server log.)
Now, as for the database stuff, when I ran that page , I found that (at least on my server, running 9.0.2) the page would NOT expose the datasource info. I suspect some hotfix included in 9.0.2 (and available for 9.0.1) blocked that. So if that's true for you, then you don't need to worry about db info/password exposure.
But if that page DID let you see DB/password info, then the hacker could see it, too. You'll want to change your DB passwords, which means changing your CF DSNs and any CFML code if you may have hard-coded passwords in the code (bad practice, but some do it.)
Then you should also look to see if any files were created or modified, anywhere on the server, since the date of the exploit, to see if any look suspicious. There are tools that enable that. I blog about a couple at this blog entry. As for deletes, that's a lot harder to track.
Caution: Don't be lulled into a false sense of security/confidence!
Based on some private feedback I've gotten, I want to make this caution. Before you may say, "oh, we're not exposed to this problem because we block all access to the CFIDE/adminapi" (and /administrator and /componentutils), I'll say just be very careful before moving on, as there are a couple ways you might get burned that might not have considered. I did explain this in the forum thread, but since some may not bother reading it if they thought themselves "already covered", I wanted to add this caution here
First, be sure you've done that protection on ALL sites.
Besides the fact that you may have a real or virtual CFIDE defined in more than one site, note as well that in CF10, if you have it configure "all sites" for IIS or Apache, note that it puts a CFIDE virtual mapping in all sites. Be sure to have protected it then on all those.
Second, you may have things set so that only the "default site" (at least as its known in IIS) has the Admin directories open. And you may bind your web site to another site, assuming then that you can "only get to the default site" on the server. Beware: if you have that default site bound to "all ip addresses", then any request that gets to your server (whether for a domain name not otherwise bound, or using an IP address that does exist on your server) WILL then get to that site.
So as discussed above, do be sure to protect those directories, as discussed variously in the lockdown guides.
A real gotcha: implicit access to the built-in web server root
Third, there's another real potential gotcha. You may find you can get into the CF Admin on sites where you don't even HAVE a CFIDE folder as a real or virtual directory (such as would be shown in IIS, but this can happen on Apache as well)!
How could a request for /CFIDE/administrator/index.cfm work when your web server docroot doesn't have that folder (nor a virtual folder), you might reasonably ask?
This is a real surprise to some: CF has always had a capability whereby if you have the built-in web server enabled (the JRun web server in CF 6-9, or the Tomcat web server in CF10), then when a request is made for a CF page via the external web server (IIS or Apache, for instance), CF looks for the file FIRST in the external web web server's docroot, and THEN in the built-in web server's docroot, such as \coldfusion9\wwwroot or C:\JRun4\servers\cfusion\cfusion-ear\cfusion-war\wwwroot.
Now, you may think you don't have the built-in web server enabled, but you may. And note that if you are running CF multiserver (multiple instances), then by DEFAULT all new instances have the built-in web server enabled (specifically for accessing the Admin, before you may connect the instance to the external web server.)
So bottom line: if you have the built-in web server enabled for CF, then a request to any CFM page (including the CFIDE folder's pages) can and will be sought and executed if found, even if it's only in the built-in web server root. So test all your sites to see if they respond to http://servername/CFIDE/administrator/index.cfm, for instance. If it responds, even though there's no CFIDE defined for or existing in the IIS/Apache site/docroot itself, then this built-in web server root is where and how it's finding one.
Now, one way to stop this would be to disable the built-in web server, but some (especially CF multiserver users) may not want to do that.
And one may also wonder if they could lock down the CFIDE in the built-in web server--but that won't work in this case, because we're talking about when you're accessing the CFIDE through an external web server (so lockdown features in the built-in web server won't be honored during external web server page processing.) And of course because the built-in web server runs on a non-standard port, by default, it will generally already not be possible for anyone "from the outside" to access these Admin directories using that built-in web server.
So we're talking about how to block access to the internal web server docroot by way of requests made through the external web server. The only solutions (to me, which have worked for some I've helped today) is to do either of the following:
- If on IIS 7, use the new "request filtering" feature, to block access to the to-be-protected /CFIDE paths (/CFIDE/adminapi, /CFIDE/administrator, and /CFIDE/componentutils directories at a minimum, for all but the sites where you may still want access to these). There may be a corresponding way to globally block access to these paths for all sites within Apache, but I am not familiar with that.
- If not on IIS 7 (if on IIS 6, Apache, etc), you could specifically ADD a virtual directory to your web server (in each site that is connected to allow processing of CFML files). This virtual directory could be a folder with no files or folders at all. And then you could use the techniques alluded to previously (and later) for locking down the to-be-protected /CFIDE paths.
Remember, we are talking (in this section) about the problem of your having a site which has NO CFIDE, so you would assume that it should NOT allow any access to the CF Admin, but you find that it unexpectedly does, because of this implicit invocation of the CFIDE within the internal CF web server's docroot.
I know it may seem counterintuitive to add a CFIDE directory to such a site (for which you're trying to block access), but in this situation where the built-in web server folder is being accessed, and you don't have a global means to block these paths, it seems the only solution.
Don't lock down the entire CFIDE, without due consideration
Finally, do be careful that before you go locking down the entire CFIDE directory, be sure that your apps are not using the CFIDE/scripts or other directories, which are referred to by HTML code that CF generates when using many tags--and not just CFFORM-related ones, such as the new Ajax features since CF8, and more. Again, the lockdown guide talks about how you can use the CF Admin to change the location for that scripts directory, and then create a new virtual directory for it, if you may want to create better separation/access among these CFIDE folders.
How to lock down the /adminapi, /administrator, and /componentutils directories
Some people have asked for more info on how to lock down the /CFIDE/adminapi, /CFIDE/administrator, and /CFIDE/componentutils directories. There have been many blog entries discussing it, and I'll point to some, but do be careful that some are old (so things may have changed).
More than that, be sure to have read the previous sections here before going off to tackle this, as there may be nuances I share that these other entries do not consider.
More important, again, note the warning above on not stopping at what you "think" is full protection of your "sites that have a CFIDE" or not.
Finally, for those on IIS 7 or above, you definitely want to consider the "request filtering" feature, mentioned in some of the blog entries below, and the CF9 and 10 lockdown guides. Note that on IIS 7.0, there is no UI to configure these, but in IIS 7.5 there is. The CF9 lockdown guide was written in the time of IIS 7.0, so does not mention the request filtering UI. If you're on CF9 and IIS 7.5, do be sure to look at the CF10 lockdown guide for its section on setting up request filtering, as it's mostly not specific to CF10.
But with those caveats, here are some blog entries with traditional recommendations on locking down the Admin (beyond the discussion in the lockdown guides, mentioned in the last post):
- http://www.morgankelsey.com/post/how-to-lock-down-cfide-in-iis (focused on solving it in IIS 5/6)
- http://www.aaronwest.net/blog/index.cfm/2010/10/4/Blocking-ColdFusion-Administrator-in-Apache (focused on Apache, obviously)
- http://www.petefreitag.com/item/774.cfm (focused on changing the scripts location, and locking things down in IIS 7, at least one way to go)
- http://www.petefreitag.com/item/750.cfm (focused on a couple of ways)
- http://www.clarke.ca/post.cfm/coldfusion-administrator-lockdown (focused on doing it for CF Multiserver deployments, aka "multiple instances")
- http://www.raymondcamden.com/index.cfm/2007/5/11/Ask-a-Jedi-Password-protecting-CFIDE (general info on what to protect)
- http://www.michaels.me.uk/post.cfm/securing-your-coldfusionmx-installation-on-windows (more details on various protections)
- http://www.talkingtree.com/blog/index.cfm/2005/7/20/SecureAdmin (providing general guidance)
And again, of course, see the lockdown guides, linked to in part 1.
I welcome if anyone has any more to propose. (I may just create a new one of my own at some point.)
How to protect dozens or hundreds of sites
If you find that you have dozens of IIS sites which you need to modify (to add IP or web server authentication), you may wonder if you have to go through and manually. Well, no. There are ways to script these operations, such as appcmd (an exe built-into windows), powershell (free from MS to install into Windows, if not already installed), or programmatic APIs like ADSI, WMI, and more.
For more like this: