The ColdFusion Directory Traversal vulnerability

There has been a lot of noise over the past week about the ColdFusion Directory Traversal Vulnerability.  If you haven’t heard, the basic issue is that ColdFusion allows the inclusion of just about any file on the server (usually Windows servers) to be included by using either a URL parameter or form parameter.  Without special encoding the vulnerability will let you grab any file ending in “.xml”, but by adding a “%00” to the parameter, just about any file gets included in the normal display of the ColdFusion Administrator login page.  This means that no authentication is required to pull this off.  The flaw is in the internationalization tags being used by the Administrator pages which include XML files to render the text for different languages in the CFAdmin section.  In turn the XML files aren’t really XML files, but instead are files containing large switch/case statements which, according to the arguments, spit out the value for the piece of text the XML file is called with.  The flaw is that the code calling the file uses user input to decide which file to grab, but doesn’t properly sanitize the request, allowing the inclusion of other files from the same disk the CFAdmin section is living on.  As Adrian Pastor points out, CF runs under the SYSTEM account by default, which means access to any file on the drive.  Including the CF configuration files which may include things like database connection settings (with passwords saved which can be decrypted easily).  Adrian also points out that once an attacker gains access to the CF Admin, it’s game over.

The patches provided by Adobe for the problem are quite simple, and in most cases shouldn’t even require a restart of the ColdFusion services.  The impact of the vulnerability is huge.  As Rafal Los, who rightfully calls this a “Disaster”, points out, there are a lot of ColdFusion servers with the Administrator pages available to the world.

Even worse, the vulnerability can be exploited on versions 6-9 (CFMX6, CFMX7, CF8, CF9), but Adobe is only releasing patches for versions 8 and 9.

Now for my confession.  I’ve been working with (and frustrated by) ColdFusion since version 4.5.  I understand how CF developers work, and how poorly the servers are administered in most installations.  In his post, Rafal Los offers some Google dorks for finding CF servers, and states that “There is really no legitimate reason to have a ColdFusion Admin interface on the public internet … really, I can’t think of one… yet there are many results!”.  So why are there so many results?

It is a combination of factors, laziness I’m sure being close to the top of the  list, but there are others.  The primary reason that comes to my mind is the location of the ColdFusion Administrator directory, inside of the “/CFIDE/” directory.  This directory has other directories inside of it which are used by CF for things like form validation, rendering of graphs, etc. and as such some applications stop working if the entire directory is locked down.  This means having the administrator (who may know nothing about ColdFusion) has to try to lock down the directories individually (in Adobe’s defense, the most recent version has a Lockdown Guide written by Pete Freitag which is well done).  I think the security of ColdFusion has suffered as a result of this mixture of programming functionality and server administration.

Another problem is those older versions for which no patch is forthcoming.  CF developers are very wary of changing the version of CF their application currently works on.  Much of this comes from a botched move by Macromedia a long time ago, when their first version of ColdFusion MX 6 (6.0.0) became notorious for breaking apps and eating resources.  This means that there are now a lot of old applications which are on old versions of CF.

Unfortunately, ColdFusion is starting (well, continuing) to look a lot like PHP for its reputation in security circles.  Like PHP, CFML is easy to pick up, and makes it very easy to write applications.  It also makes it very easy to write insecure applications.  Most CF sites are vulnerable to SQLi, XSS, and LFI, much like PHP.  Now with a vulnerability like this in the core of ColdFusion, I can’t say the reputation it is gaining isn’t deserved.

8 responses to “The ColdFusion Directory Traversal vulnerability”

  1. Jason Dean says:

    While most of this post is accurate, I am going to take issue with your last paragraph. I think that you have gone a bit far with that one and will need to offer some qualifying evidence to keep me from calling BS on it.

    Do you have some evidence to suggest that ColdFusion’s reputation is similar to PHP’s in “security circles”. Do you have your finger on the pulse of said circles?

    You also say that “Most CF sites are vulnerable to SQLi, XSS, and LFI, much like PHP…” but you offer no citation for that statement either. Did you conduct these tests yourself?

    It seems to me that you are making guesses and stating them as facts.

    Most programming environments do not offer the number of built in security features that CF offers. And all I’ve seen from Adobe is a commitment to continue improving security. I’ve been most impressed by how seriously Adobe takes security.

    ColdFusion may make it easier to write insecure applications, but it also makes it easier to write secure applications. What I see in other environments is that it’s hard to write secure programs as well as harder to write programs in general.

    As for this statement : “Now with a vulnerability like this in the core of ColdFusion, I can’t say the reputation it is gaining isn’t deserved.” Really? Do you think so? I’ll admit that it is a serious vulnerability, but do you really think it is enough to go that far?

    Since we’re all such big fans of Google Search results, check out these:

    php vulnerability site:cert.org Results: 629
    java vulnerability site:cert.org Results: 419
    ColdFusion vulnerability site:cert.org: 3

    Vulnerabilities at “the core” of a system are nothing new. It happens and it sucks. But when there are no glory-hungry consulting firms trying to make a big deal out of how amazing they are at finding vulnerabilities, there usually isn’t that much hype around them.

  2. Dave Watts says:

    Wow, this is not even wrong.

    There are plenty of poorly configured ColdFusion servers. But there are plenty of poorly configured servers, period. Pick a platform, any platform.

    Best practices for securely configuring ColdFusion have been around for YEARS. It’s not difficult to secure the CF Administrator. I’ve been working with ColdFusion since version 1.0, and the basics of securely configuring the CF Administrator haven’t changed significantly since version 3. This information is out there, for those who want it. The same is true for running CF as something other than SYSTEM on Windows. Anybody who performed the minimal research required for due diligence setting up a server would know both of these things. Changing the service account is even right in the documentation!

    http://help.adobe.com/en_US/ColdFusion/9.0/Installing/WSc3ff6d0ea77859461172e0811cdec18c28-7fb7.html

    As for the “older versions” for which no patch is forthcoming – they’re OLD. Is anyone producing patches for “classic” ASP? PHP 3? Gee, I can’t patch my Exchange 5.5 server either. And as for CF 6.x being a “botched move” – it’s the only reason CF is still around. Prior versions were written as native C++ programs for specific platforms. Since 6, CF has been written in Java, which brings a tremendous set of advantages to the table – a far greater degree of platform independence, entree to the J2EE web stack used across the enterprise development world, etc, etc. And CF 7+ can SCALE. CF 6.x was definitely a bit rocky, but considering the radical makeover it entailed, it did pretty well – once developers learned the differences between memory management in Java and previous versions. And, unlike previous versions, it wouldn’t UTTERLY FAIL due to unhandled concurrent access to memory! I worked to fix a lot of CF 4.x and 5 sites that simply couldn’t handle load, because they didn’t lock access to Server/Application/Session scopes. It was lots of fun adding CFLOCKs to everything! That problem completely disappeared in CF 6.

    Finally, you talk about “most sites” – got any statistics? Anecdotes != data. Sure, many sites have vulnerabilities, and following Sturgeon’s Law, 90% of everything is crap. But that’s not true just for CF – every platform lets people do bad things.

    Dave Watts, CTO, Fig Leaf Software

  3. I think you went a bit ANTI-CF there for no apparent reason and I wonder on the validity of some of your comparisons so I have reposted the parts I consider useful and informative with regards to the vulnerability plus my own edits and additions.

  4. david says:

    First I would like to thank the other members of the ColdFusion community for offering your comments. This is not a one way medium, and I certainly appreciate the input (positive or negative).

    Perhaps I did go a little too far on the “Anti-CF” end of things. But I have been working with CF and CF developers for a long time (as I said, starting from 4.5 in 1997). During that time I have had my hands and eyes in a lot of CF applications. In many (and yes, I would say most) I have seen these vulnerabilities first hand. I am not guessing here. Perhaps part of the problem is the issue of why I am looking at the code in the first place. That is, if I am looking at the code, perhaps there is already a problem (be that security or performance in some cases), so maybe I am just seeing the bad apples. So from the sample of applications I have been involved in, yes, most contain these types of vulnerabilities. No I can’t provide an exact number, but easily more than half. Again, perhaps because of my position, the sample may be poor. At the same time, when I mention ColdFusion to penetration testers, a big smile comes across their face due to CF’s reputation in the security community.

    While, yes, as Jason points out, CF does have a lot of security features built in to the language, but in many cases I do not see developers using them. This includes the basics like CFQUERYPARAM and output encoding.

    As pointed out by Dave Watts, all platforms let you do bad things. My point is that perhaps CF needs to make it easier to do the right thing than the wrong thing (of course, not every developer or administrator will do that). Why not have the CFIDE files needed for validation, ORM, etc. in a different place than the admin interface? Why not include IP address filtering in the CFAdmin interface from the start? Disable some of the more dangerous tags like CFEXECUTE and CFREGISTRY when installed? Why not force the creation of a new account for use with CF when CF is installed? The idea here is “secure by default”. I think these are all things which would make CF better as a platform. Yes, the Lockdown guide published for CF9 is well done (and recommended reading for anyone deploying CF servers).

    My point in drawing the comparison between CF and PHP is that both languages and application servers are easy to use, but that the ease of use comes at a price.

  5. Jason Dean says:

    I’m sorry, but your anecdotal evidence is clearly tainted by your preconceived notions, your admittedly tainted sample, and, likely, by confirmation bias. Looking at code over the course of 10+ years does not mean that “most” applications are vulnerable now it only means that many of the applications you have looked at are vulnerable, again, your memory could be tainted by confirmation bias.

    Regardless, even if it is true that most of the applications you have looked at have had this simple vulnerabilities, that is not exactly ColdFusion’s fault, is it? You say silly things like “My point is that perhaps CF needs to make it easier to do the right thing than the wrong thing…”, you mean like Java? Or Ruby? .NET? What is it that any other environment offers that makes doing the right thing easier?

    ColdFusion offers the tools. The information is out there for those that are willing to look for it. It is not ColdFusion’s fault, nor Adobe’s, if developers opt not to use them any more than it is ORACLE’s fault if people develop Java applications insecurely(which is very easy to do).

    The argument that ColdFusion is insecure because it is too easy to program in is just complete bullshit. I’m tired of hearing it. The idea that for something to be secure that it has to be difficult to work in so that novices cannot touch it is simply dumb. Making ColdFusion harder to use is not the answer. And ColdFusion already offers more security features than most environments. So I don’t see where you get off saying that it should be made easier, as if everyone else is doing it.

    As for this: “At the same time, when I mention ColdFusion to penetration testers, a big smile comes across their face due to CF’s reputation in the security community”, Bullshit. When I have talked to “security-experts” and pen-testers about ColdFusion, they are simply ignorant. ColdFusion is no less-secure than anything else out there, so they would have no reason to smile. And I do think it is funny that such a large sampling of pen-testers would react to information about ColdFusion in exactly the same way. A big smile. My guess is that it was ONE pen-tester and that his qualifications we that he went to 6 hours of training on the scanner he was using. (See, I can make shit up too).

    I do agree with you that secure defaults need to be improved in ColdFusion. I have said so on my blog, and I have been e-mailing Adobe about some of my ideas. Being proactive about such things is a better solution. Macromedia and Adobe has always been big about Backward-Compatibility, hence the reason defaults have not changed over the years. But I think the time is overdue that the backward-compat argument needs to take a back-seat to the security argument.

  6. Chris says:

    Love the discussion! I think there are some great things to be learned here about all environments, especially for a non-programmer like myself.

  7. Jay says:

    Too bad our forums aren’t being used for these types of discussions =/ Great input however and there will always be people on either side of the fence when it comes to these types of discussions.

  8. david says:

    This may be some interesting reading for everyone, given the nature of the discussion:

    http://www.whitehatsec.com/home/resource/stats.html (sorry, registration is required to get the full version).

    Which is Whitehat Security’s report on vulnerabilities across different languages (ASP, ASPX, CFM, DO, JSP, PHP, PL) used in web applications.

Leave a Reply