Yesterday I was doing some searches on a sick server to troubleshoot the Iframe Injection issue. A user had posted some additional information regarding a file that appeared on his server that had this issue. The file was named "fection.cfm" so we now know the hacker casually removes his prefixes (or I should say 'emoves his 'efixes). I began my search by looking for the file specifically, then moved on to look for the string "cfexecute" in all of the *.cfm files. But that got me thinking. A clever hacker might know some things about ColdFusion. He could in fact, further obscure his code with some knowledge of cfinclude and IIS. Such a technique can be used to secure your code as well. You can create code that is only runnable by ColdFusion using cfinclude. Here's the skinny.
First, understand that IIS 6 excludes all files unless it is specifically tasked with serving it. It does this by examining the file extension. It knows, for example, to serve an *.html file as text/html. In the old days you could create any extension you wanted, throw it on the web server and then call it from a browser. IIS would assume (given lack of instruction to the contrary) that it was an HTML file and serve it. So if you created a hello world page, named it "hello.bob" and then called /hello.bob from a browser, the web server would happily serve your file. Try that on IIS 6 and you get "page cannot be found".
On the other hand, cfinclude doesn't know or care about file extensions. You could create hello.bob and then create hello.cfm with this code:
When is this useful? Actually it can be a very useful technique for excluding certain pages from direct execution. Consider a folder structure like this:
Are you with me so far? Good. Now looking at the code above you might think, "Hey Muse, my query code is safe. After all I'm explicitly setting the siteID to either 5 or 10 in the preceding code. I don't even need cfqueryparam." Yes, and you are free to make faces at the dinner table too - but if your face sticks like that don't come crying to me. Actually, the issue here is that I (the clever hacker) can bypass index.cfm and browse to www.mydomain.com/queries/qry.cfm. ColdFusion has a convenient (and risky if you don't understand it) order of precedence in evaluating scopes (variables, then url, then form). To hack your site table I could use the following:
But let's say you are clever too and you decide you don't want to be able to serve qry.cfm from the address bar. You have a few choices. You could move the included files outside of the web root and use a ColdFusion mapping (this is pretty common). You could add code to the application.cfc or application.cfm files that exclude any direct access by examining the template path (this is the way some of the frameworks handle it). Or you could change all of your included sub files to be non-CFM files (qry.inc for example). Your index.cfm page would then look like this:
My original point had something to do with Iframe injection right? Remember what I was doing when I started? I was looking for cfexecute in all the *.cfm files. What if my clever hacker, who obviously has the ability to add files to the server, has put the malicious code into a file with some other extension and is simply using cfinclude. My search would never pick it up. So now I'm forced to search all files instead - a much slower process.
On a side note (for those of you dealing with this), this attack seems unlike others I have battled. It seems very much customized to the server in question - as if I was matching wits with an actual person who continues to tap tap tap away at the server. That would also be a good reason why the signature of the attack is not picked up by common scans and security tools I guess.