ColdFusion

File Integrity Checking CFIDE

So with the most recent attack on ColdFusion (detailed by Charlie Arehart, Part #1, Part #2) there was a comment left on the post that got me a bit concerned where the comment said all you had to do is search for h.cfm to remove the file placed by the attacker. My experience has been if an attacker has had access to the server there is no absolute way of knowing what they might have done, even with good log reconstruction. As I noted in my comment in one instance I have previously encountered a situation where an attacker put a file called fck_dialog_common.cfm into CFIDE/scripts/ajax/FCKeditor/editor/dialog/common. At first glance of the directory it looks right, but inactuallity it a file that was buried and hidden so the attacker could come back through it instead of the original entry point. 

The only way to know is to have a way of doing file integrity checks against a good known source. The initial attack that was posted to the Adobe forum was found because an intrustion detection system (IDS) alerted the administrator that a file had been written to CFIDE that was called h.cfm.

Thoughts on ColdFusion 10 Update 1

So if you didn’t see it via the ColdFusion Blog or by the new indicator inside ColdFusion Administrator, the first update for ColdFusion 10 dropped on August 31st.

First, I have to say “Thank You” to the ColdFusion Team. FINALLY there is an easy way to patch ColdFusion and I can get out of the business of building a patch tool for ColdFusion. The other good thing is that the TechNote actually links the bug IDs back to the ColdFusion bugbase.