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.

[More]

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.

[More]

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( )....

[More]

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.

[More]

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.

# Helicon ISAPI_Rewrite configuration file

# Version 3.1.0.54


RewriteEngine On

RewriteCompatibility2 On

RepeatLimit 20

RewriteBase 

# unsupported directive: [ISAPI_Rewrite]


# CacheClockRate 300


RewriteRule ^.*DECLARE%20.*$ http://www.cybercrime.gov/ [NC]

RewriteRule ^.*NVARCHAR.*$ http://www.cybercrime.gov/ [NC]

RewriteRule ^.*sp_password.*$ http://www.cybercrime.gov/ 
[NC]
RewriteRule ^.*%20xp_.*$ http://www.cybercrime.gov/ [NC]

RewriteRule ^.*EXEC\(@.*$ http://www.cybercrime.gov/ [NC]

RewriteRule ^.*%20@.*$ http://www.cybercrime.gov/ [NC]


RewriteRule ^METHOD$ OPTIONS

Please note that these rules will actually redirect the request to the governments cybercrime website. That's going to freak a few folks out if you end up with any fals positives :)

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...

[More]

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.

[More]

Please note - I have not changed my stance on the use of CFQUERYPARAM. The real "fix" for injection is validation routines for form inputs and binding variables using Cfqueryparam. A blacklist function (a function that checks for "known bad" input) is useful in that it provides protection on the perimeter. It can help you intercept hack attempts before they reach your DB - where presumably they would fail in any case. They are also useful for thwarting immediate threats if you discover a security flaw that might take some time to fix. The recent spate of attacks caused a proliferation of blacklist techniques from simple to complex. In my own post on the vulnerability of using string concatenated SQL I published a snippet that made use of the iSQLInject function from CF Lib. There is a better approach however.

[More]

So you got hit with the latest SQLi attack eh? SQLi is the hip acronym for "sql injection" that fancy pants security people use. You've put in some stop gap measures and now you are slogging through 3000 queries trying to add cfqueryparam to everything. It's a laborious task to be sure. Here are some special tips from the muse that might help shorten it.

[More]

So... you have diligently added CFQUERYPARAM to every input variable. Your database is secure and safe from SQL Injection - right? Well... maybe not. Did you remember to account for the ORDER BY Clause? Let me explain.

[More]

If you have been following the muse the last few days you will know that I've had my shoulder to the wheel helping customers and fellow developers sort through making changes to their site to protect against a particularly malicious SQL Injection attack (read about the details here). Some of the folks who have contacted me are dealing with extra problems because their code uses string concatenation to build dynamic SQL strings. So the question has been asked a few times, "How do I go about building an SQL string with CFQUERYPARAMs in it?" Unfortunately, if you have chosen this approach it's going to be difficult to help you without seriously refactoring your code. Here's a few tips that can help, and one approach that might get you most of the way there.

[More]

Back in February I wrote a blog post on SQL Injection that included an example of how a malicious user might inject into a character field even though ColdFusion escapes single quote marks. The attack involved other forms of escaping single quotes - and was effective against MySQL. This week I stumbled upon (more like a train wreck) an attack that is much more sophisticated - and also involves injection into a character field. I am told that others have discovered and written on this attack over the last few weeks - but I was unaware of it until a customer of ours was victimized. Amazingly, the specific real world attack I discovered and fixed allowed the hacker to append a string to every char column in every table of the database. It was so pervasive it left me wondering if it was SQL injection at all - until I found a URL entry that looked something like this:

[More]

On Tuesday I took in a workshop on Cryptography by Dean Saxe. Dean is an impressive character with a head stuffed full of knowledge and spilling out everywhere. He obviously knew what he was talking about. As a topic, cryptography is so impossibly complicated and intricate that he could not do it justice in a 50 minute session. Most discussions about cryptography center around keys, algorithms and best practices - and this was no exception. Dean recommended against relying on CF's own encrypt and decrypt functions for anything but the most rudimentary encryption. In fact, he probably didn't even go that far. That tidbit of advice is common from almost every security pro I have ever heard mention the subject. When it came to discussing keys it was like a trip to the dentist.

[More]