How patching ColdFusion 8.0.x made you more vulnerable in some cases (or fun with CVE-2013-0632 from APSB13-03)

On March 17th, there was yet another story from Krebs on Security, The Long Tail of ColdFusion Fail, which sparked some interesting comments. It also provided some additional insight to a post that Wil Genovese made on March 6th, IIS Vulnerability Steals Payment Information since he commented on Krebs that he dealt with eLightBulbs.com.

Before I knew the two were related, I made the comment that it is really a failure of the sysadmin to properly configure and lockdown ColdFusion based upon the published lockdown guides for ColdFusion 9 or ColdFusion 10.

Now eLightBulbs.com was running ColdFusion 8.0.x (yes, Adobe there are people that DO NOT upgrade that fast) and there was no lockdown guide published, right? Well not exactly. In October 2007, Adobe published the ColdFusion 8 developer security guidelines. In this guide, on page 30 it directly states that access to CFIDE/adminapiCFIDE/administratorCFIDE/componentutils, and CFIDE/wizards should be restricted.

Almost all the recent stories of ColdFusion compromises involve APSB13-03 which had a patch released in January 2013 for ColdFusion 9.0.x and 10. If you were running ColdFusion 8.0.x, there was no patch for you since it had reached end-of-life (core) support, but Adobe again offered guidance to secure the CFIDE directory. 

To understand how easy it is to exploit CVE-2013-0632 from APSB13-03 see the demo below which I showed at cf.Objective() 2013.

This vulnerability is actually pretty easy to exploit and is also completely preventable without a patch if CFIDE is properly secured. But I started wondering when the vulnerability was introduced. A clean install of ColdFusion 8 or 8.0.1 is not vulnerable and will generate the following error:

AdminAPI Error from unpatched ColdFusion 8.0.1

So I started to go through the hotfix matrix that I have from Unofficial Updater 2. I had always assumed it was introduced with APSB11-04 because it had updated CFIDE/adminapi/administrator.cfc. I was wrong. The vulnerability was actually introduced with the first security hotfix for ColdFusion 8.0.1, APSB08-12 on April 8th, 2008.

What changed? The access attribute of the Login method changed from public to remote and it was carried through to ColdFusion 9 and 10. I can’t say whether it should  have been changed or why it was, but it is at this point of time when ColdFusion became vulnerable to the authentication bypass in CVE-2013-0632.

So while patching is important, you never know if it will produce another vulnerability. This is why securing software according to configuration guides, security benchmarks, and lockdown guides is important, it provides additional defense aside from relying on a vendor to get a patch out and to get it out correctly.

del.icio.us Digg StumbleUpon Facebook Technorati Fav reddit Google Bookmarks
  1. Jose

    #1 by Jose - March 19, 2014 at 11:08 AM

    Thanks for the article. When I try to apply the hotfix I'm getting all sorts of JRE errors in CF admin's applet to select the jar file. Any idea how to apply the patch? I've tried on Chrome, FF, Safari, both PC and Mac and none of them work with the applet (System Info > Update File).
  2. David Epler

    #2 by David Epler - March 24, 2014 at 2:55 PM

    @Jose,

    It isn't clear to me which version of ColdFusion you are using. If you are using ColdFusion 8.0.1 or 9.0.x I would recommend using Unofficial Updater 2 to apply the updates. If you are on ColdFusion 10, it should work regardless of the browser you are using, but can also run the updates via command line.

    Highly recommend taking a look at http://www.carehart.org/blog/client/index.cfm/2014/3/14/cf9_and_earlier_hotfix_guide

  3. Jose

    #3 by Jose - March 24, 2014 at 2:57 PM

    Hi David,

    I ended up apply the updates by copying the file(s) to lib/updates (I'm running CF 9.01 multi-server).

    Thanks
  4. David Epler

    #4 by David Epler - March 24, 2014 at 4:11 PM

    Just be careful doing it manually. They need to be applied in the correct order and require more than just updating the jar files.

    The link to Charlie Arehart's blog in the previous comment outlines possible problems you can encounter. It is also why I recommend using Unofficial Updater 2 since it is automated based on Adobe's instructions on how to apply it. On a multi-server install you would just need to run UU2 against all the individual instances to ensure they are properly patched.
(will not be published)
Leave this field empty: