This all happened around Christmas and went downhill from there most likely automatic network scanning of availability of a certain URL path followed by automated attack.
Charlie Arehart has several blog post on this topic so I am not going to expand too much:
- http://www.carehart.org/blog/client/index.cfm/2013/1/2/serious_security_threat
- http://www.carehart.org/blog/client/index.cfm/2013/1/2/Part2_serious_security_threat
The old adage to lock down your server still holds but is no solace to the people that got hit since it would impact a fully patched server.
The short of this is to disable access to certain CFIDE paths. This may be the practice that you already follow, then kudos!, more importantly, get the word out to other users. Let your friends know so they don't fly blind.
Overall I am surprised by this vulnerability since it seems to originate from a vector that, in my mind, should require authentication or at least some sort of access control. Seemingly the scheduling of tasks is vulnerable and wide open by default. Initial thought on this: Crap!
Maybe, as a community, we should vet more closely the out of the box CFML code that is being deployed. The secure stance always has been to not deploy any example and docs on production, however, this is part of the system would be required to administer it.
Couple of things that I would like to delve deeper into:
a) Detecting Code Compromise:
In the last talk that I had presented around application security I had shown an example that can be easily implemented and allows users to detect any code change on the machine.
The idea is to generate an application signature that, then, can be verified to see whether the application is still consistent with what you published.
This is a simple version, you may expand and adjust. This will help you detect whether you have been compromised.
You can do this against the CFIDE, Customtag, and/or any other directory you store code in. You can create separate signatures (i.e. modules) or combined ones.
The goal is to quickly be able to tell whether you were hit by a zero-day vulnerability or anything else made its way onto your server that you did not expect.
It involves two general steps:
First run a recursive cfdirectory on your website/app and, second, create a hash from it.
Something like this:
<cfdirectory action="LIST" directory="c:\inetpub\wwwroot" name="myAppFiles" filter="*.cf*" recurse="Yes"> <!--- build md5 hash ---> <cfset myAppSig = Hash(SerializeJSON(myAppFiles),"MD5","us-ascii")>
Then compare the generated application signature against a last known good one. This can be done on App start, or a scheduled basis, even add hock if you app is small.
Here is the similar sample that stops application execution if compromised if you include it in your OnApplicationStart function:
<cffunction name="OnApplicationStart"> <!--- This assumes that you have a database with a table named "appcheck" that has at least two fields id = auto number/indexed value = text (20) The first time the app starts, the valid application signature will be determined. There after the application will abort if the signature does not match. To publish new code. Clear the appcheck table or insert the new valid signature as last row. ---> <cfquery name="selCheck"> SELECT value FROM appcheck WHERE id = (SELECT Max(ID) FROM AppCheck) OR id=0 </cfquery> <!--- determine app check crossum ---> <cfdirectory name="selAppFiles" action="list" filter="*.cf*" directory="#getComponentPath()#" recurse="Yes"> <cfset strJson = SerializeJSOn(selAppFiles)> <cfset md5Hash = Hash(strJson,"MD5","us-ascii")> <cfif selCheck.RecordCount> <!--- application compromise check. We could email someone automatically, raise alarms, call the cops ---> <cfif md5Hash neq selCheck.value> Application compromised.<br/> <cfoutput> #md5Hash# -- #selCheck.value# </cfoutput> <cfabort> </cfif> </cfif> <cfquery name="insCheck"> INSERT INTO AppCheck (VALUE) VALUES ('#md5Hash#') </cfquery> </cffunction>
b) Preventing people from using the vulnerability:
Charlie and other have done a good job of summarizing the source and ways you can prevent the exploit. It all seems to boil down to not let users hit certain CFIDE paths:
- /CFIDE/administrator
- /CFIDE/adminapi
- /CFIDE/componentutils
The bad thing is that using IIS/Apache facilities to lock out call URLs may not be good enough. There is the question of virtual paths and ColdFusion built in webservers that can bypass your effort. In addition, the normal Adobe CF connection between IIS and CF is using a wildcard based handling of all request. That means all requests to your website are first routed to CF/connector, even, if you ask for an image. If you know me you know I am biased, but obviously this blows big time, since it causes unnecessary processing on IIS and CF. Try to pause or stop CF and call a static HTML page on IIS or Apache, you will wait for a while. Enough of the ranting! In short, please test your lockout configs after you make changes to make sure that everything is locked out as it should be.
If you are using ColdFusion 10 on IIS you also have the option to deploy my BonCode connector. It does not block static page access, or hinder non CF processing. Since its first version it had the ability to block access to administration pages; you will not be able to bypass this even if you have the built in CF webserver running (yes, you can still hit the built in webserver if you bypass IIS altogether but that would require deliberate foolishness where you have opened the non-standard port on your Windows OS and firewalls everywhere).
Here is a blog post on how this feature is used to secure Railo administration pages. This method also works for OpenBD, and Adobe CF10.
The installation for CF10 is not out of the box, if there is interest in this I will provide it in later versions. Also this is not officially supported by Adobe, though given the system instability issues and problems that have occurred with the supplied connector you may want to consider testing anyway.
Cheers,
B.
