Here's one of the culprits that you would be looking for with this injection attack...

www.nihaorr1.com/1.js

Not exactly sure what the end result of that js file does but it has made its way around the Internet and appears to be doing its thing at this very moment. :(

Ya, this is NOT an MSFT problem, it is a programming problem. ASP and PHP are the most susceptible tp SQL Injection attacks. Whether it's Windows or Linux, SQL Server or MySQL, it doesn't matter, sloppy coding is sloppy coding.

This is an app developer problem, but it could be prevented if Microsoft provided an inbuilt function for escaping SQL statements.

Even well respected articles on how to prevent ASP SQL injection are still vulnerable because they only rely on basic matching, they do not seem to unescape anything. This is useful since it is possible to hex encode the statement (as this attack does). PHP provides a common escaping function so fewer people roll their own broken implementations.

[sitepoint.com...]

I do not think the recommendations would prevent against this attack (except limiting privileges), correct me if I am wrong.

Obviously it is recommended to use prepared statements but there are some times where this is not possible, plus it is easier for new users to build sql statements.

This WAS Microsofts problem but they ignored it for so long that it is now an app developers problem.

At this point, blame is of little concern. Right now there are challenges afoot for those who are open to this exploit. I've been doing some research and it appears that the www.nihaorr1.com scripts are responsible for a good percentage of these attacks or at least the ones that are highly visible. Searches for that domain turn up all sorts of stuff. Discussions at other fora, the scripts it invokes, etc. A search in Yahoo! only returns 7 results but you can see the scripts that are being used. Be careful, they are pretty nasty. My security software marked them all as extremely high risk so watch out.

What I don't understand is why the security firms/Internet watchdogs don't shut down these domains where the scripts are being hosted?

I just got off the phone with my lead programmer who is fairly new on our team and is now reviewing existing architecture, database structure, etc. We're talking about this 1.js exploit and how it works and what it does. Man, this thing is nasty too. If you've been exploited, you'll most likely know it real soon.

What really surprised me during the telcon was this statement...

"Edward, if there are any SQL statements on the page, you are susceptible to the SQL injection attack. You cannot use SQL statements on the page, they must be Stored Procedures."

I then asked him why people do the on page SQL stuff to begin with and he said because it is the "easy way". The year is 2008 and the "easy way" is no longer an option. Security is of the utmost concern and "everything" needs to be locked down. We're currently in the process of doing a review and seeing where we can lock things down further. I did find a few pages with SQL statements here and there. Those will be addressed immediately.

What did I gather from the telcon? If you are using SQL Statements on any of your pages, you're at risk for the SQL injection attack.

What percentage of programmers and/or database administrators are using SQL Statements on page? I think the numbers are much, much higher than we might expect.

as I understand it this particular attack in fact does not rely on an sql statement existing ( so stored procedures will not in themselves stop the attack - although is a useful defence technique )

This is as the attack only needs a logon to be made into a database then it is creating its own statement which is executed.

I have no exact answer, except for withdrawing permissions on as many tables as possible. Several large corporates have already been caught - and i am sure they have more resources than we do.

Even if you check data from forms this attack is in binary data format so checking strings for words like UPDATE etc will not catch this little critter.

IMHO of course

Even well respected articles on how to prevent ASP SQL injection are still vulnerable because they only rely on basic matching, they do not seem to unescape anything. This is useful since it is possible to hex encode the statement (as this attack does). PHP provides a common escaping function so fewer people roll their own broken implementations.

Ahhh no. PHP provides a "common escaping function" WHICH STILL NEEDS TO BE CALLED by the developer.

Believe me, it's a coding problem, not a language problem.

If there were a common MSSQL escape function then it would be easy for ASP developers to fix this problem, all they would have to do is use that function on all SQL input. As it stands they are running around making broken escape functions themselves. Having to call a function is a better situation than having to write and then call the function.

It is certainly a fault of the language that there is no proper escape function and way to stop this attack easily.

Here are some developers who wish there was a proper built in escape function.

[forums.iis.net...]

I see this is going to be a real problem with MS blaming the developers and developers looking to MS for a proper fix. The fixes listed on that forum are very easy to work around.

Here ya go.

<%
function cleanInput(str)
dim re
set re = new RegExp
'(</?(?:u¦i¦b¦a\s+href="[^">]*"¦(?<=/)a)>)¦</?[^>]*>
re.Pattern = "[^0-9a-zA-Z\s\@\:\.\,\-\_\!\?\+]"
re.Global = True
cleanInput = re.Replace(str, "")
set re = nothing
end function
%>

Just call the function on every input :)

I am not sure exactly what that function is doing but it looks fairly vulnerable to me. Is it just replacing a small subset of characters? Even if it is good, it would also bring up a lot of false positives (it would reject this post)

To really escape the input you need to pass the string to the actual program that will eventually escape it (ie MSSQL), anything else and you have two sets of code which are attempting to do the same thing.

Just blocking ; does not work either because sql servers often have a different EOL sequence (ie MySQL uses \g as well). There are many many ways to encode a string to hide what it actually is, I have seen exploits that use multibyte encoding to get around simple filters.

mikedee, use stored procedures. don't use dynamic sql in them. who cares then about EOL, it is a parameter anyway.

This is an app developer problem, but it could be prevented if Microsoft provided an inbuilt function for escaping SQL statements.

They are not going to do this, it will just encourage bad design.You shouldnt use raw SQL code in web pages everyone knows that.

You shouldnt use raw SQL code in web pages everyone knows that.

Obviously everyone being hit at the moment doesn't ;)

There is already a open source solution to this, which my company uses

[aqtronix.com...]

Aqtronix Webknight basically blocks viruses, script kiddies, and SQL injections.

You also got URLScan & IIS Lockdown both supported by Microsoft themselves

[microsoft.com...]

[microsoft.com...]

You shouldnt use raw SQL code in web pages everyone knows that.

What exactly does this mean? I've written some PHP scripts that include MySQL queries, but none of the SQL code gets to the browser, e.g., the actual webpage itself. Does this count?

By the way, what input I accept is always run through a few regexes to remove unexpected data, then put through

mysql_real_escape_string()

before I put it into my query.

PHP, if properly coded, is perfectly safe. SQL statements in your PHP code are unavoidable, and in fact encouraged if you're using MySQL, where the mysql_real_escape_string function works perfectly to prevent attacks of this sort. MSSQL, even in PHP, is another matter--stored procedures are the way to go, simply because there's no MS equivalent to mysql_real_escape_string, and this function won't block every possible attack on MSSQL.

So yes, basic good practices apply here too--if you MUST use embedded SQL statements, parameterize each and every variable before using it in the SQL statement. Otherwise, use stored procedures. In either case, use restricted logins that are only capable of doing what they absolutely must do--no need for your reporting system to have UPDATE, INSERT, or DELETE capabilities.