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/adminapi, CFIDE/administrator, CFIDE/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:

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.