Code (not sql) injection by hackers via coldfusion

[John Ertel]

Does anyone have any information on how hackers might inject code into my coldfusion files.  I am having a problem with hackers installing javascript links to their trojans inside the actual pages of my site.  I run the server with many different sites on it and the injections are ONLY happening on the coldfusion sites.  I tried to search for code injection coldfusion information through the search engines and this forum but didn't find anything.  What potential holes in my coldfusion code would allow a hacker to inject code into the actual files on the server?  I am mainly seeing the code injected into application.cfm itself so that the links are displayed on every page.  Guess these hackers are familiar with coldfusion.

[craigkaminsky]

John,

What happens in your Applicatiopn.cfm file? DB queries? One common defense against XSS is to use CFQUERYPARAM in your queries (makes it tougher for the SQL injection attacks to work).

There's a couple of nice utilities on RIAForge.com that will scan your server for vulnerabilities/protect against XSS, etc.

http://portcullis.riaforge.org/

http://qpScanner.riaforge.org/

[John Ertel]

This is not an sql injection attack.  Nothing from the database is being read or displayed.  The application.cfm file is actually being edited somehow to include javascript calls to trojan software.  When I load up application.cfm, the lines have actually been physically added to the file itself.

[mack_]

I've seen these effects before (files being psychically modified on

the server). A developer machine with FTP access to the files was

compromised by a trojan, FTP username and passwords were compromised

and used by the attacker to connect to FTP, get the files, modify them

and upload them back.

Check your FTP logs on the server to confirm this (you should see a

download of the file followed quickly by an upload of the file - not

necessary from the same IP address).

Mack

[John Ertel]

I thought it might be an ftp/password crack myself after virus scan found some password sniffing trojans.  But after cleaning, password sanitizing, and now an entire OS reload, I am sure it's not.  Within a couple of hours of the os reload being complete the application.cfm files for almost all the coldfusion sites were updated with a new iframe code and the server was restarted.  I'm at my wits end.  My server provider is saying because the exploit is only taking advantage of the coldfusion application.cfm files then it must be a code exploit due to poor code so they're trying to wash their hands of it.

I've ruled out ftp/passwords... I've ruled out a file upload exploit.  I have no other idea what other exploit someone could use through coldfusion to accomplish this... but it also does make sense to me that if it's only affecting the coldfusion sites that it is probably some kind of coldfusion exploit -- after all why not alter the master page on the .net site or php sites on the site to have similar code.

[Dan_Bracuk]

Regarding, "One common defense against XSS is to use CFQUERYPARAM in your queries", the last time I tested this theory, I was able to successfully store javascript in a database and have it execute after selecting it.

[ilssac]

Yes, we are confusing our attack vectors here.

1) Is SQL injection attacks.  This is where <cfqueryparam...> helps.  Using this tag will generate prepared SQL statements so the database knows what is SQL commands and what is SQL data and not try to run any SQL commands that a hacker attempts to insert into the SQL data.

2) Is XSS cross scripting attacks.  This is where a hacker inserts JavaScript into a web site so that the script hijacks a visitor and redirects or delivers to them undesired content.

Where these two cross paths is that the payload of some recent high visibility SQL injection attacks was XSS scripts into web content data.  But this is by no means the only way to insert XSS data into a web site nor is it the only SQL injection payload that a hacker may choose to use.

Back to the topic of the original post:

The first thing is to confirm is the server itself is locked down.  The attackers may have acquired simple FTP, Telnet or other remote access to the site and are capable of modifying the content as they desire.  Look at logs, change passwords and|or usernames and look for un-patched security holes, etc.

A large recent hole was published last week, where Windows IIS server that have WebDAV enabled can be tricked into allowing access to secured sections outside of the WebDAV directorys with special Unicode URL strings.

HTH

Ian

[craigkaminsky]

My apologies, I meant to write "One common defense against SQL injection attacks is to use CFQUERYPARAM in your queries", not "One common defense against XSS is to use CFQUERYPARAM in your queries". Thanks, Dan.

The first project link (http://portcullis.riaforge.org/) is the one that offers some relief and options for both XSS and SQL injections.

[Ken_Ford_-_ACP-QFo4AB]

This is probably what it is.

http://blog.unmaskparasites.com/2009/05/07/gumblar-cn-exploit-12-facts-about-this-injected-script/

Ken Ford
Adobe Community Expert - Dreamweaver/ColdFusion
Adobe Certified Expert - Dreamweaver CS4
Adobe Certified Expert - ColdFusion 8
Fordwebs, LLC
http://www.fordwebs.com
http://www.cfnoob.com

[TLC-IT]

The only way that hackers can modify your ColdFusion Code is to get access to your server so that they can actually modify the CFM and/or CFC files that are stored upon it.  Unfortunately, on a shared-hosting setup that's not terribly difficult to do.  And, most programmers neglect to consider the file access permissions (other than the "x"ecutable bit in Unix/Linux) that they attach to any particular file when they upload them.

You need to be certain that all of the files in your directories, and the directories themselves, are locked-down so that no one can modify them, and so that no one but "you 'n the web server" can see what they contain.  (Remember, shared-hosting companies give away shared-hosting accounts like water, and it's sometimes effortless for "the web-site next door" to see much more than it ought to be able to see... and maybe, to modify something!)

If you're running on a Linux host, see if the server appears to support Access Control Lists (ACLs) and whether you as a secure-shell user can establish them.  If so, this will allow you to restrict access more thoroughly than the "owner/group/world" permissions-mask system would allow.  The equivalent mantra with regards to Windows hosts is different in details only.  One way or the other, implement the "principle of least privilege."

The larger problem, of course, remains with us:  the end-user's computer, and the shameless reality that the aforesaid user is probably an all-powerful Administrator of a Windows "Home Edition" something-or-other ... whose entire system, therefore, is a sitting duck with no backups.   You can't do anything at all about that.