Manually Patching ColdFusion 9 with APSB15-21 (CVE-2015-3269)

So ColdFusion 9 core support ended on December 31, 2014. As such, Adobe has not released any security updates for it since APSB14-23 on October 14, 2014. There was a question regarding the latest security patch, APSB15-21, released for ColdFusion 10 and 11, if it affected ColdFusion 9. The answer was yes, it is affected as well. And apparently Adobe does have a procedure on how to apply the patch, if you email and ask for the instructions. Honestly, Adobe should just post the instructions, but given that it is no longer covered by core support can understand why they are not.

This post is a collection of my notes and procedure used to manually apply the patch to ColdFusion 9. These steps are not the official Adobe ones. Unofficial Updater 2 was previously run to patch to the last official patch, APSB14-23. 

The underlying BlazeDS libraries have not changed since ColdFusion 9.0.2. The exact same files are used in ColdFusion 10 through Update 16 and ColdFusion 11 through Update 5.

ColdFusion 9.0.2

FileVersionSHA-1 HashFunction
flex-messaging-common.jar 81eb386a31933aff9819499198fb9945ebb03771 BlazeDS - Common Library
flex-messaging-core.jar d74583ebe8e1fd9651641ca8291d19edf4563335 BlazeDS - Community Edition
flex-messaging-opt.jar 5c91681ca2f719b0a368f61a3f0f22bdb4c9eaaa BlazeDS - Optional Vendor
flex-messaging-proxy.jar b9f28b0916f03432a7011cf6cfb04c2ec45b16af BlazeDS - Community Edition - Proxy Module
flex-messaging-remoting.jar c8771cc64f35457c874b07ccccb010b8631194c9 BlazeDS - Community Edition - Remoting Module

ColdFusion 9.0.1

FileVersionSHA-1 HashFunction
flex-messaging-common.jar 303b1cb8a04e910d43c9be4894f6d6b7b814a928 BlazeDS - Common Library
flex-messaging-core.jar 31820e6ca453d1c42e602b4bf226711c63f4aa2d BlazeDS - Community Edition
flex-messaging-opt.jar 5c91681ca2f719b0a368f61a3f0f22bdb4c9eaaa BlazeDS - Optional Vendor
flex-messaging-proxy.jar b9f28b0916f03432a7011cf6cfb04c2ec45b16af BlazeDS - Community Edition - Proxy Module
flex-messaging-remoting.jar c8771cc64f35457c874b07ccccb010b8631194c9 BlazeDS - Community Edition - Remoting Module

ColdFusion 9.0.0

FileVersionSHA-1 HashFunction
flex-messaging-common.jar d84e30b86f7a9236a0fc53e71c838e4b50e4d26d BlazeDS - Common Library
flex-messaging-core.jar a4e9c048d2126af717fb7ca5a375812e436a170d BlazeDS - Community Edition
flex-messaging-opt.jar cbcbbda606c0eafaa290c359341b20f647f8e75c BlazeDS - Optional Vendor
flex-messaging-proxy.jar 00e53347d77c0d5265ad96fecd382019abf582b7 BlazeDS - Community Edition - Proxy Module
flex-messaging-remoting.jar 34082c9ff1a5c3da781a097fd3b2c7a46ecc6e14 BlazeDS - Community Edition - Remoting Module

It is possible to update the BlazeDS libraries in ColdFusion 9.0.1 and 9.0.2 from those contained in the ColdFusion 10 Update 17. Here are the steps:

  1. Stop ColdFusion
  2. Download ColdFusion 10 Update 17 and verify it
  3. Backup existing BlazeDS libraries
  4. Extract needed files from the update to the proper location
  5. Restart ColdFusion

Below are the commands, executed as root on an Ubuntu server running ColdFusion 9.0.1 installed to /opt/coldfusion9 running as user cfusion.

/opt/coldfusion9/bin/coldfusion stop
mkdir /tmp/cf9-apsb15-21
cd /tmp/cf9-apsb15-21
md5sum hotfix_017.jar
zip /opt/coldfusion9/lib/flex*
unzip -j hotfix_017.jar Disk1/InstData/
unzip -j "\$IA_PROJECT_DIR\$/hotfix/dist_zg_ia_sf.jar"
unzip -j dist_zg_ia_sf.jar cfusion/lib/flex* -d /opt/coldfusion9/lib
chown cfusion:cfusion /opt/coldfusion9/lib/flex*
/opt/coldfusion9/bin/coldfusion start


The steps for Windows are the same, just use 7Zip or similar to extract the files from hotfix_017.jar and place them in the ColdFusion lib directory, typically C:\ColdFusion9\lib.

These steps only deal with updating the BlazeDS libraries, not configuring Flash/Flex remoting as noted in the technote and Adobe ColdFusion 9 Lockdown Guide. Also see Pete Freitag's post, Disable Flash Remoting on ColdFusion Servers

Patching ColdFusion 9.0.0 is more problematic because of different version of BlazeDS used. It might be possible to follow the same steps, but did not try since none of the servers I deal with are running ColdFusion 9.0.0.

Regardless of specific version of ColdFusion 9 one is running, upgrading to ColdFusion 10 or 11 is the best options since they are supported by Adobe and receiving security updates.



Enough Fail to Go Around

So the talk surrounding the Krebs on Security post, The Long Tail of ColdFusion Fail, continues. Some have taken issue with that he seems to be singling out ColdFusion. Personally, I like the fact that he is reporting on breaches. It helps bring to light issues with installs that are out there, so others can learn from the problems. The ones he has highlighted are severe since they involve credit card processing. 

The underlying problem is that hackers have identified ColdFusion as an easy target and are going after it. The only way to fix that is to make it more difficult to attack and compromise, but that requires involvement from everyone that touches a ColdFusion installation. 

Now I have no involvement with and these are my impressions based upon the information that is publicly available from the following sources:

Security Firm had a third party firm perform annual PCI compliance penetration testing and apparently this firm did not find any ColdFusion 8 vulnerabilities with the installation. I find that a bit hard to believe. They should have had at least one finding stating that the CFIDE directory was publicly available. Another risk that should have been noted was that ColdFusion 8.0.x had reached end of core support on July 31, 2012 (Extended support for ColdFusion 8.0.x ends on July 31, 2014).

There are many tools out there that will identify ColdFusion issues. HackMyCF, by far, is the best ColdFusion specific tool to find configuration issues. Nessus currently has 40 plugins that deal with ColdFusion. Either tool most likely would have found issues. The specific issues found would depend upon the configuration and patches applied. 

Without knowing the exact scope of the testing, tools used, and state of the ColdFusion install, it is hard to say how good of a test this firm actually performed. If I was using them, I'd really question them on how they do things because as it looks, they were just taking $6000 a year from

Hosting Provider

While it has been stated that the hosting provider that used wasn't contractually obligated to patch and secure the VPS they were using, one would hope that the hosting provider would have been a bit more hands-on regarding security. Given that the hackers were able to inject a malicious IIS DLL, they had complete control of the VPS guest OS. Depending on virtualization software, it might have been possible for the hackers to break out of the guest OS that ran the VPS, take control of the host OS, and pivot to attack other servers the hosting provider runs.

It is really in the interest of the hosting provider to help customers maintain a secure environment.

Business is a story where they thought they were doing everything right and it went terribly bad. They were handling credit cards and doing annual PCI compliance testing as they were required to. They had a service level agreement (SLA) with the hosting provider and thought the hosting provider was providing support to patch and secure their VPS through a managed service contract.

Unfortunately, they were too hands off regarding security and seems like they did not completely understand the scope of services or assumed some services were included in the various agreements they had with the security firm and hosting provider. 

The other area where was at fault was not staying on a supported version of ColdFusion. While just upgrading would have put them on a supported version, the underlying problems of properly securing the environment probably would have still existed.

The positive from this is that has been very forth coming with details of their experience and the steps they have taken to remedy their security issues.

Software Vendor

Some will probably not like what I have to say in regards to Adobe, but Adobe has not done enough to help the situation. Unlike the first three sections, I can speak here from direct experience.

Adobe has not learned from the mistakes Microsoft made with early versions of IIS, to install the product with defaults that make it secure from the start. Do not rely on the sysadmins to come back around to secure it. This is precisely the problem with the published lockdown guides. There is an expectation that whoever is installing ColdFusion knows the lockdown guides exist and follows them properly. It also does not help that they have been published months after the release of the product. That at least will be rectified with ColdFusion 11 (hopefully). 

There were improvements regarding security in ColdFusion 10, but as the past year has shown they are not enough. Adobe touted that they put ColdFusion 10 through Veracode, AppScan, and fuzzing (slide 8) to find security issues. Given the ColdFusion 10 vulnerabilities found so far, the code review process for security issues should be improved. 

Another security feature in ColdFusion 10 that has been pushed is Secure Profile. While it does improve the security settings within ColdFusion, it is an OPT-IN option in the installer (appears this will be fixed in ColdFusion 11, Bug #3529334) but does not protect the CFIDE directory as well as if one follows the lockdown guide. At NCDevCon last year I showed how ColdFusion 10 with Update 9 applied and Secure Profile turned on but not locked down as per the lockdown guide could be exploited using the Sub-Zero v2 script.

Patching ColdFusion 8.0.x and 9.0.x is an absolute pain, which is how Unofficial Updater 2 (UU2) came about. While UU2 is not perfect, it does make it a hell of a lot easier for older versions.

Patching has gotten better in ColdFusion 10 with the HotFix Installer but there are still  issues. Almost all of the issues regarding patching are about the quality of the patches issued. The track record has not been good. 

As I showed in my previous post, How patching ColdFusion 8.0.x made you more vulnerable in some cases (or fun with CVE-2013-0632 from APSB13-03), Adobe caused CVE-2013-0632 with a security hotfix and was not dealt with for nearly 5 years until it became widely exploited. Adobe had to pull Update 3 for ColdFusion 10 completely. They have had to re-issue other updates due to errors. In the case of APSB13-10 [Update 9] they broke functionality that was not related (Bug #3540876) and people had to wait over a month until APSB13-13 [Update 10] to get it resolved. These patch quality issues directly impact the confidence people have in applying them and leaves more installations vulnerable because of the slower adoption rate of the patches.

The communication of security hotfixes and updates for ColdFusion could also be improved. ColdFusion 10 will generate a notification regarding updates, but only if it is configured to do so. What is needed is a notification service that is more like the Adobe Security Notification Service which notifies for all updates to ColdFusion not just security ones. Not everyone reads blogs or follows @ColdFusion on Twitter. Adobe should be contacting those with support agreements directly via email and telephone when any update to ColdFusion occurs, otherwise what are they really paying for?

Adobe needs to engage more with its customers regarding ColdFusion security. They need to ask their customers if they are having any problems and fix them or direct them to companies and people that can. [Marketing Plug: AboutWeb has experience in securing ColdFusion and the entire web stack. We have done this for numerous clients and if you need help, please contact us.] 

Also while I don’t expect them to comment on all the ColdFusion breaches that occur, silence does not help.


While nothing in the story directly talked about code developers wrote being exploited, developers have a role in security as well. 

Unfortunately, too many ColdFusion applications are written poorly in regards to security. Part of that is due to the materials that are the de-facto standard for teaching ColdFusion, The ColdFusion Web Application Construction Kit (CFWACK). I respect all the authors of the series, but it is time for a complete re-write showing good, modern, and secure ColdFusion coding practices. The community itself tried to tackle this problem with Learn ColdFusion in a Week, for which I contributed the chapter on security.

The reality is developers need to know how to write secure code. If you are a developer and have no idea what SQL injection is or why cross-site scripting (XSS) can be extremely dangerous, among others, you need to improve your skills. There are many resource out there, but the first one I’d point you to is OWASP with the 2013 Top Ten and various cheat sheets.

The bottom line is that it takes everyone involved with a web application to ensure the security of it. A security breach can happen to anyone and does not matter the underlying technology used.

1 Comment

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

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 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.


Unofficial Updater 2 now patches APSB13-27

This has been one of the faster turn around times to get an updated Unofficial Updater 2 out. One of the items that stuck out was that one of the acknowledgments was to Alex Holden who co-discovered the Adobe password and software breach.

In the news of the latest patch, there is contention of whether the hole reported by Alex Holden is actively being exploited, from the second to last paragraph.

Holden maintains this flaw was being used by attackers prior to today. "Hold Security identified an attack attempt against a ColdFusion version 8 resource by the same hackers behind breaches like LexisNexis, Adobe, and others," Holden said. Unaware of the possible effectiveness of this attack, Hold Security reached out to Adobe. While Adobe did not find the precise attack effective against any of supported CF versions, they did identify a critical flaw in the same resource which led to the patch issued today.

The first thing that struck me was that ColdFusion 8 was specifically mentioned. Now ColdFusion 8 core support ended July 31, 2012 which means Adobe will not issue a patch to close this hole on ColdFusion 8 (the last patch was APSB12-21 on September 11, 2012). The only effective measure is to make sure you properly lockdown ColdFusion 8 or upgrade to a supported version (and properly secure it). The other thing is Adobe's statement about being "effective against any supported CF version" and since ColdFusion 8 is no longer supported it is probably valid. 

Regardless of if it is being exploited, the best defense is to be running a supported version of ColdFusion, staying current on patches, and properly securing ColdFusion using the published lockdown guides for ColdFusion 9 or ColdFusion 10.

Also tomorrow (11/14) at 2pm ET, I will be giving a free webinar on the security enhancements that have been made in ColdFusion 10. To register, please visit


Unofficial Updater 2 now patches APSB13-19

Well, I kind of missed blogging the last update to Unofficial Updater 2 back in May while I was at cf.Objective(). The latest update APSB13-19 dropped while I was on vacation at the beach, but still got it done two days after it was released by Adobe.

For ColdFusion 9.0.x the latest security update only applies if you are running as a standalone install or as a JRun Multi-Server. If you are running ColdFusion 9.0.x on top of any other J2EE server like JBoss, Weblogic, or others you don't need to apply the fix.

As usual the best defense is to stay current on patches and properly secure ColdFusion using the published lockdown guides for ColdFusion 9 or ColdFusion 10.

No Comments