Coldfusion Directory Monitoring with Event Gateways

This just came up on Twitter today and I realized I hadn’t posted about it so here you are.

Many hacks of ColdFusion over the years have been through people manipulating the CFIDE directory. (the most famous being the FCKeditor Hack) There are many ways to combat this but here’s a simple one.

Using the DirectoryWatcher Event Gateway built into CF versions 8 & up, you can in just a few minutes set up some code to monitor & alert you of changes to the CFIDE (or any other) directory.

You need 2 piece of code.

The Config File

CFIDE_Alert.cfg

# The directory you want to watch. If you are entering a Windows path
# either use forward slashes (C:/mydir) or escape the back slashes (C:\\mydir). 
directory=C:/Inetpub/wwwroot/cfide
# Should we watch the directory and all subdirectories too
# Default is no. Set to 'yes' to do the recursion. 
recurse=yes
# The interval between checks, in milliseconds
# Default is 10 seconds
interval=10000
# The comma separated list of extensions to match.
# Default is * - all files
extensions=*
# CFC Function for file Change events
# Default is onChange, set to nothing if you don't want to see these events
changeFunction=onChange
# CFC Function for file Add events
# Default is onAdd, set to nothing if you don't want to see these events
addFunction=onAdd
# CFC Function for file Delete events
# Default is onDelete, set to nothing if you don't want to see these events
#deleteFunction=

and a CFC to use for the Gateway. (note: I don’t have Delete events turned on as I delete CFIDE/Admin files when not in use…for another post)

CFIDE_Alert.cfc

<cfcomponent>
<cffunction name="onAdd" returntype="any">
<cfargument name="CFEvent" type="struct" required="yes">
<cfset data = CFEvent.data>


 <cfmail to="webmaster@example.com" 
		server="yoursmtp.server"
		username="youruname"
		password="yourpwd"
		from="alert@example.com"
		subject="CFIDE CHANGE DETECTED!"
		type="html">
<cfdump var="#data#">
</cfmail>
</cffunction>

<cffunction name="onCHANGE" returntype="any">
<cfargument name="CFEvent" type="struct" required="yes">
<cfset data = CFEvent.data>


 <cfmail to="webmaster@example.com" 
		server="yoursmtp.server"
		username="youruname"
		password="yourpwd"
		from="alert@example.com"
		subject="CFIDE CHANGE DETECTED!"
		type="html">
			
<cfdump var="#data#">
</cfmail>
</cffunction>

</cfcomponent>

Then all you need to do is create the Event Gateway

Capture

Now, if any files are changed or there are files added, you are sent an email. You could also use Event Gateways to send a an SMS message so you can be notified anywhere, anytime.

Capture

CF, XSS & SQLi – Keeping Your Users Safe

I’ve recently been thinking a lot (more) about web security, specifically XSS (Cross Site Scripting) and SQLi (SQL injection). Coldfusion is one of, if not the easiest, web scripting language to code securely. Straight out of the box, it’s harder to run an SQLi attack against than most. (please… I said harder, not impossible)

here’s a pretty good discussion about this with several of the top CF “experts” at EE

Bottom line for a CF coder is that using cfqueryparam will eliminate your SQLi risk. It’s an Adobe recommended best practice

Adobe recommends that you use the cfqueryparam tag within every cfquery tag, to help secure your databases from unauthorized users. For more information, see Security Bulletin ASB99-04, “Multiple SQL Statements in Dynamic Queries,” in the Security Zone, http://www.adobe.com/devnet/security/security_zone/asb99-04.html, and “Accessing and Retrieving Data” in the ColdFusion Developer’s Guide.

From LiveDocs

and you’re crazy not to use it.

You may actually see a performance boost using it as well.

If the DBMS doesn’t have to parse, analyze, and validate as much text, it’ll be able to respond to requests quicker and more efficiently

Faster and Safer Queries Using The cfqueryparam tag

However, just because you use cfqueryparam don’t get smug. You still may be vulnerable to exploits. XSS is harder to deal with and while CF does have some built in protection you can enable, it doesn’t protect you in all cases.

In CF8 (and maybe CF7..I can’t remember) CFadmin has a Server Settings > Settings > Enable Global Script Protection.

This is to “Specify whether to protect Form, URL, CGI, and Cookie scope variables from cross-site scripting attacks”. Sounds great. Check that box and your done. Safe and sound? Not so much.

Submit the following form with Global Script Protection (GSP) disabled. You should see an alert box which means you’re hax0red. Enable GSP and you won’t get the alert and you’re safe. However, while GSP is good for protecting against js hacks like alert(‘Gotcha?’) it -won’t- do anything to protect you against an iFrame attack. I’ve simulated one here using a visible iFrame, an actual iFrame used in an attack would be hidden. You’ll notice that the injected iFrame shows up whether GSP is enabled or not. This is because an iFrame is not actually a “script” so it’s not filtered. To fix this we need to strip html tags from input (which you should never allow to be submitted in any case) by using reReplaceNoCase and the regex <[^>]*>

As you can see, this eliminates the iFrame issue. This also defeats the JS inject issue as well even without GSP enabled.

<cfoutput>
 <cfif structkeyexists(form, "f1")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 Did you see the JS Alert???<br>
 #form.f1#
 </div>
 </cfif>
 <cfif structkeyexists(form, "f2")>
 <cfset myvar = rereplacenocase(form.f2,"<[^>]*>", "", "All")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 #myvar#
 </div>
</cfif>
 <cfif structkeyexists(form, "f3")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 I'm an injected iframe<br>
 #form.f3#<br>
 That's bad ;(
 </div>
 </cfif>
 <cfif structkeyexists(form, "f4")>
 <cfset myvar = rereplacenocase(form.f4,"<[^>]*>", "", "All")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 No iframe here
 #myvar#
 </div>
 </cfif>
 </cfoutput>
 <hr>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 <h2>XSS Demo</h2><br>
 <form name="1" method="post" action="index.cfm">
 <input type="text" name="f1" value="<script>alert('Gotcha?')</script>"><br>
 <input type="text" name="f2" value="<script>alert('I am harmless')</script>"><br>
 <input type="text" name="f3" value="<iframe>http://www.google.com</iframe>"><br>
 <input type="text" name="f4" value="http://www.google.com"><br>
 <input type="submit">
 </form>
</div>

I’ve got a couple of free tools to recommend as well.

SQL Injection Blocker v.3
by Mary Jo Sminkey

This is a “blacklist” tag which looks at common CGI variables and checks them for common SQLi keywords like insert|delete|select|update etc and for other nasty bits which don’t belong in form submits. You just cfinclude it in application.cfm or cfc and it should head off most attacks. Note:this is -not- meant as a replacement for everything I’ve outlined above. It’s an added layer.

I figure it’s a good idea to find out if a site is under attack ASAP so I customized blocker.cfm by adding a log variable to each cgi variable section
ie:
log =url;
log =form;
etc

and then output the log as well as a cgi.remote_addr (attacker IP) in a cfmail which gets sent to me via SMS when blocker intercepts a hack attempt. This gives me the time, remote ip and details of the hack.

Another set of tools I just came across and really like are the ExploitMe plugins for firefox from Security Compass They do SQLi, XSS and Access Control Checking

You can also use HP Lab’s scrawlr for SQLi

If you have already been hacked with a SQLi attack you can use scrubbr from OWASP.org to help sanitize your db.

Take Out? Always use cfqueryparam, always use rereplacenocase to remove html and test, test, test.