This is the second entry by Wil Genovese (Trunkful.com) in our effort to provide a complete picture of how CF, Various versions of JVMs and various versions of SSL all work together. Wil's previous article on Surviving Poodle detailed a blow by blow description of how to troubleshoot a system broken due to the upgrading of SSL. This article includes some detailed technical information as well as the results of some painstaking tests. It is our hope that it will serve as a guide. It represents yet another reason to insure that you are upgrading to the latest JVM and CF version. Take it away Wil:

There's been a great deal of buzz about poodle. Poodle is an SSL exploit capable of highjacking a session using a browser's ability to "negotiate downward" the level of SSL it uses. It's recent prolifieration has put some urgency into the efforts to force existing applications and platforms to deny the use of any standard of SSL less than version 3.0. Super guru Wil Genovese (Trunkful.com) recently did some troubleshooting on a ColdFusion server with an issue related to this necessary configuration step. Wil writes:

We ran into an issue when a company contacted us at CF Webtools because ColdFusion was suddenly no longer able to connect to their email providers mail servers. One day ColdFusion was sending emails to their clients just fine and the next day it was failing. As you know these issues are usually best resolved by asking "What changed?" As far as the client knew, nothing had changed - but we knew enough not to stop digging.

Super guru Wil Genovese (Trunkful.com) is back to describe an IIS vulnerability that was inserted using a long-known (and patched) CF vulnerability. The Muse will make 2 points. First, if you are hit with this one call us! We will gladly put our shoulder to the wheel and help you dig out. Second, don't forget to patch your servers and keep up on the latest security news. No matter what your chosen platform you need to be vigilant and attentive. Take it away Wil.

First let me point out that the vulnerability that was found has a patch that has been available since January of 2013. So as the Muse said, patch your servers! I first read about this attack in a PC World article titled, PCWorld - Attackers exploited ColdFusion vulnerability to install Microsoft IIS malware. I spent hours reading all the linked websites and blog posts by the security researcher that discovered the IIS Malware (see this Trustwave post) trying in vain to learn the name of said DLL that gets installed, where it gets installed and how to detect the file(s). The few details I found were not completely useful. While I learned the behavior of the malware I never learned how to find the offending DLL or even the file name. I did discover that no existing anti-malware or anti-virus software would detect this rogue DLL. I repeated my futile search every few weeks to see if anything new was being reported.

Since knowing how to locate and expunge such things is part of my job I needed a way to find it, but how? I could search any of the servers at CF Webtools until the cows come home, but if none of them have been hit with this malware I will never find it. What I needed was a server that had been exploited to examine. Over the past year with the slightly larger than usual number of security holes discovered in ColdFusion we've had a few new clients come to us for help in patching and repairing servers. None of the IIS modules on those servers stood out to me as 'unusual', but I wasn't looking directly for this. Finally we had a company come to us for help with a breach.

We were recently called to fix a hacked ColdFusion server. This was a file hack. Something was appending JS code to the end of variuos .cfm files on the server. The appended code redirected the user's browser to a different site (to sell them viagra or puppies or whatever). When analysing the server we found an interesting attack vector. I say interesting because it used a technique I had not seen before that leveraged a quirky feature of ColdFusion. The end result of the hack was a layered infection that was difficult to find and resulted in the infected files coming back regardless of our lockdown efforts. If that sounds like something you are experiencing or if you are interested in ColdFusion security, read on!

I know it's an uncomfortable topic. I understand that you would like to keep your validation private. You would probably rather learn about this from your friends at the coffee shop, Jeremy who is two cubes down from you, or some guy on a forum (shudder). Still, the Muse has an assignment in life to point these things out and make sure you are well informed and prepared when temptation strikes. Oh I know what you say now. I know what I'm doing. The risk factor is slight. I'm too small... I mean... my application is too small to need it. But take it from me - you will need to understand how to use protection or bad things will happen. So let's talk about it.

Yesterday I had a server with IIS and a few hundred sites on it. Some, though not all, of the sites had an unprotected CFIDE directory mapped. So my task was to protect these directories by denying all IPs from access except a specific IP range. Before I describe the task and my trick let me remind you that this is not time to tout Linux or Apache or bash Microsoft in the comments. The muse welcomes comments but enjoys variety. We all know about Apache and its manifest benefits. We don't need you to remind us in spite of your excellent credentials and biting wit. IIS is fine platform with many strong points too and there are folks who need this information. They should not feel like they are sneaking into the adult section of the video store to get it. Now back to the Muse' usual good humor. Here's the scoop....

If you are CF community connected (and if not why not?) you know about the latest "sub-zero" exploit to ColdFusion that once again targets the Administrator or adminapi directory under the CFIDE directory. It leverages tags that work with files from within these directories to place code on your server which can then be leveraged to do other things. Basically it can function as a hostile takeover of your server. See this entry titled 0-Day Exploit for ColdFusion by the awesome folks at Edge web hosting for more information. It will point you to the Adobe Docs. The exploit targets CF 9 and 8 if I'm reading the source correctly.

The lockdown guide will give you a few dozen steps some of which will have you pulling out your hair unless you have carefully built your server. But the main "fix" for this exploit is fairly simple. Do not allow arbitrary access to the CFIDE/Administrator and CFIDE/adminapi folders from the web. This seems to be pretty head scratchingly obvious but you'd be surprised how many folks say "But don't you need a password to get into the administrator?". Yes, and you need a key to get into your house too, but an "exploit" is rather like a brick through the window. To really secure your house you need a security system, good locks, good lighting, and a Rottweiler the size of a pony.

Why is it there in the first place?

This is a question I get sometimes. "I don't remember adding that virtual directory. How did it get there?" No you did not fugue off while adding web sites - unless you see one for a Ukrainian tether ball team or something - then probably yes you did fugue off. The real story is that when you install ColdFusion using selecting the "configure all websites" option during the install the CFIDE is mapped on all the sites on your web server as a physical (for the default site) or virtual (for everything else) directory. That's how it seems to "show up" everywhere. In addition the "connector" scripts - the ones you run to "remove all" and "add all" will add it as well. If you are like me you configure each site separately outside of the CF ecosystem. Then you join it to the ColdFusion engine using wsconfig. My servers use the multi-server config and I use the built in web-server (at ports 830X) to admin them from inside the network. When a new site is needed I add it in IIS or apache, then I use wsconfig to connect it to the ColdFusion instance I want. Yes it's extra steps and yes it requires more knowledge, but it's the way I like it. And I'm worth it. Doing it this way does not add the CFIDE directory by default - which is why if I need the scripts directory I use an alias or virtual and alter the setting within the admin.

But what I notice from time to time is that there actually is a CFIDE directory that shows up on some of my sites. How can this be? I've been so careful. Here's what happens. A team member - a developer - is assigned to a site for the first time. Perhaps this is the first site they have set up on their local environment, or perhaps they are sys admin challenged and don't know how to create an alias or virtual directory. For whatever reason the CFIDE physical directory is installed and is living in the root directory of the site. Then at some point the developer remembers (through the prodding of his project manager) that he needs to do regular updates of our subversion repository as a part of his task list. Suddenly (with apologies to Emeril if he's still alive and has not exploded) BAM! the CFIDE directory itself is now part of the source code. Our Jenkins CI server ignores this directory and does not deploy it to either staging or production but usually the initial site setup is not done by Jenkins. So one thing leads to another and the directory is deployed to staging (small yikes) or production (big yikes and a shudder).

Of course this is bad in more than one way. For one thing this directory has the vulnerabilities in question in the form of CF Scripts. For another it is likely not being used to admin the server - which means that updates in the form of hot fixes and security patches will never make it into this code. It might also end up being the wrong version of admin as the site code is transitioned from version to version. I'm not sure if that last is bad or good - but it is another thing to worry about.

In conclusion get out there and secure those directories (and other things). Let's make sure we are on top of this before it get's out of hand. :)

I spent yesterday cleaning and inoculating another server infected with SQL Injection. Unless you have been living in a cave you know that SQL injection (SQLi) is the most common vulnerability of web based application. This is due to 2 factors - 1) almost all databases use numeric fields and B) web applications by nature pass user input into queries. Of course I could throw in there that web developers are often lax about inoculating their code. There is also the problem of legacy code - code that has been around since the dark ages of the late 90's. Of course SQLi has been around that long as well, but it is surprising how much legacy code chugs along for a decade or more with no problem in spite of the vulnerability.

Anyway, here's the skinny on the latest attack I found. It uses our old friend "Cast" in conjunction with the char() function of MS SQL. Note, this is not a new attack on the web - it's only new to me in that I've never battled this particular attack before.

If you read my post on the script injection attack that has been going around you will note that I suggest four solutions or remedies to protect your server (upload off the web root, use cfcontent, disable script and execute permissions on certain directories, and remove superfluous handlers). A fifth solution was pointed out to me that is somewhat related to uploading off of the web root.

The idea would be to create a subdomain just for user resources. So, for example, you could have "www.ilovemoles.com" and "pics.ilovemoles.com". User uploads would go the share for the "pics" subdomain and be served from there. You would still vet the content to make sure it was ok, but the "pics" domain would not allow ColdFusion (or PHP or ASP or any scripts or executable at all). I can see some issues that you might run into - chiefly that you are not really "securing" the content from unauthorized access. I believe that still makes it suitable for public resources, but not able to be fully integrated into an application without a lot of run around. Still it seems an elegant solution.

Many of you may know there is a web server attack going on in the wild that involves appending a JS script to all the htm, php, cfm, js, jsp files found on a server. If you are unfamiliar with this attack see some of my previous posts like this one for more of an explanation. While I have found the script that actually does this dirty deed and I have combated this issue on numerous servers by now, I have never really been confident that I have discovered where the attack actually begins (i.e. how this file gets on the server to begin with). Yesterday I was made aware of a technique that might be the smoking gun. It has been tested by some folks I trust and I want to give a full explanation here to assist all those Muse readers who battle the bad guys at the server level.

If you are a technician or network operations professional who is trying to scan your way out of this attack, I'm afraid you are probably out of luck (but keep reading anyway). This attack specifically targets application code - not just CF but ASP, JSP, PHP and any others. All of them can be subject to this problem because it has to do with insecure coding, not specific platform vulnerabilities. I would add that if you find your code vulnerable don't feel too bad. This exploit is clever enough to get by code that seems secure as we shall see. If you are a web developer of any stripe you should definitely read this post. The examples are in ColdFusion, but you will be able to extrapolate for your own language or technology pretty easily.

Regular readers know I'm always on the lookout for interesting issues regarding SQL Injection and ColdFusion. This year has been a banner year for injection on ColdFusion sites and if you are not on the Cfqueryparam bandwagon yet I have one more example of a code that might seem to be inoculated but is not. It has to do with the use of val( )....

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.

For those of you interested in stopping the SQLi attack before it even hits your ColdFusion server, you might try these rewrite rules are from the CF-Linux email list (run by House of Fusion). They were provided by list member Mike Chytracek and forwarded to me by Linux CFG Ryan Stille.
These rules are for for use with Helicon's ISAPI Rewrite filter, but with very little tweaking these rules aught to work for Apache Mod_rewrite as well.

Unless you have had your head in the sand (those of you on your honeymoon are excused) you know that the ColdFusion world has been awash in SQL Injection attacks over the last month. Anecdotally I am seeing a significant increase in attacks this week - about 15 times what they were a few days ago. Michael Dinowitz reports that house of fusion was receiving 4000 attacks in 5 minutes (that's nearly 50 thousand an hour). Brad Wood reports no less 90 request per second. The suspicion is that the attack is driven by searching Google for sites with ".cfm" pages. That means the more successful that you are at search engine optimization the more likely you are to be targeted. Conversely if you don't have a good number of pages ranked then you are probably then you will see fewer attacks.

It seems these attacks are orchestrated using infected computers throughout the internet. Some effort is underway to collect IP addresses to see if a pattern emerges. I suspect that approach will not yield fruit, but I still applaud the effort. We (CF Webtools) are continuing to assist customers in any way we can - everything from wholesale changes to sites, to blacklist techniques to friendly advice over the phone. As these attacks accelerate they become more like Denial of Service attacks than anything else. Even if you are binding all your variables and you have great controls you will still have to deal with a bombardment of thousands of requests against your CF pages. I recommend that you use one of the many blacklist techniques out there - at least temporarily. Some folks have started out sending emails alerts when these attacks are underway but quickly discovered that the volume of email can be pretty hefty. I recommend just killing the request - abort it at the top of your application prior to the application being instantiated. Then at least you have kept it from filling up your error log. Meanwhile this round of attacks has had the positive affect of causing folks to suddenly pay attention to a great deal of vulnerable code. Here's another silver lining you may not have considered...

Muse Reader Asks:
If you want to allow someone to search your site by keyword, how do you protect against an SQL injection? CFqueryParam is great if testing for an integer, but what about for a string? Surely there's got to be a way to do it since all kinds of sites let you perform keyword searches. Thanks!

Whoa... slow down there. Do my ears deceive me? Did my reader just indicate that he (or she) thinks that cfqueryparam "tests" for a string? I hate to break it to you, but the purpose of Cfqueryparam is not to insure that the value passed into the tag is one thing or another. The validation that occurs is more of a by-product of binding. Sure, the tag will error out when you try to pass "abc" instead of "123" to a param of the "integer" type, but that is a result of type binding. It's simply trying to bind variables of type for the driver to use, so naturally it errors out. But pass in a decimal like 123.123 and it says "okey dokey - that will work". Testing to see what a form element contains is the job of the developer, not the job of a magic box tag.

But to answer your question more specifically, cfqueryparam will protect you from those malicious hack attempts anyway - even if the attack is passed to the database. Let's examine a working case and see if we can figure out what is happening.