Neil Carpenter's Blog

SQL Injection Hijinks

neilcar — Fri, 31 Oct 2008 23:07:00 GMT

or Why I Keep Harping On Blacklisting

Summary:

An incident reveals attempts to get around blacklisting by manipulating behavior in ASP, illustrating the weakness of blacklist approaches.

A new version of UrlScan is shipping today with a change specifically to address this.

Discussion:

I was working with a colleague on an incident last week that looked like a garden-variety SQL injection drive-by except for something interesting.

While looking through the IIS logs from the affected server, I saw this:

abc=120364DEC%LARE%20@S%20VAR%CHAR(4000)%3BS%ET%20@S%...

As I looked at this, "DEC%LARE", "VAR%CHAR", and "BS%ET" immediately stood out to me. Obviously, the percent sign is usually used to escape something in a URL (like the %20's in there, which are spaces); however, this naked percent sign thrown in there didn't seem to have any purpose and should have caused SQL to not execute the code in question.

When I see somebody do something like this, it's usually for a purpose so I took another look at it. I realized that, if ASP silently stripped that percent sign out of there, then this would be an efficient way to bypass a lot of blacklist-based filters.

I wrote a quick test ASP page(1) and found that my guess was right on -- ASP drops a percent sign from the query string if it isn't followed by two valid hex characters(0-9, A-F) when it actually interprets it via Request.QueryString. This means that any filter that inspects raw headers using Request.ServerVariables is going to miss "DEC%LARE" if it is looking for "DECLARE" but, on the other hand, the ASP app that actually consumes that string using Request.QueryString("abc") is going to get it without the percent sign.

Conclusion:

As this incident illustrates, a blacklist approach to SQL injection only works for as long as nobody finds a way around your blacklist. As soon as somebody finds a way around it (and experience suggests that attackers are motivated to do so), the value of your blacklist is zero.

The right approach is to fix the actual vulnerability in the code using parameterized queries. See the articles below for more information and examples.

http://msdn.microsoft.com/en-us/library/cc676512.aspx

SQL Injection Mitigation- Using Parameterized Queries

SQL Injection Mitigation- Using Parameterized Queries part 2 (types and recordsets)

The IIS team is releasing an update to UrlScan today that includes changes to address this in their filtering product. Of course, as I've said over and and over, no filter-based approach is going to be perfect, but UrlScan is still an excellent defense-in-depth tool and a way to mitigate SQL injection vulns in the short term while your developers fix them.

For more information on the UrlScan update, Wade Hilmo has all the details:

http://blogs.iis.net/wadeh/archive/2008/10/31/urlscan-3-1.aspx

(1)

<HTML>
QUERY_STRING = <%= Request.ServerVariables("QUERY_STRING") %> <BR>
test =<%= Request.QueryString("test") %> <BR>
</HTML>

PASSGEN

neilcar — Wed, 22 Oct 2008 21:52:02 GMT

Occasionally, I see a security incident where one of the things that went wrong was that all of the customer's machines have the same password for the built-in administrator's account. Whenever this happens, I suggest the PASSGEN tool that was included with the book "Protect Your Windows Network" by Steve Riley and Jesper Johansson. Obviously, most people don't want to run to the bookstore in the middle of a security incident but, fortunately, it was available on their website.

Unfortunately, the website disappeared recently and I had to scramble around to find it. If you're looking for PASSGEN (and you should be if you have the same password for local admin across a number of machines), you can find it in two places:

Err

neilcar — Wed, 13 Aug 2008 05:10:00 GMT

I might be the last person to know this but one of my favorite internal Microsoft tools is now external. Err.exe is a command-line tool that looks up error codes and spits out possible matches from various header files. This is invaluable when you're reading through a log and run across something like "Failed, err 0x80070003" -- just run err and you'll find out what this possibly means:

C:\Users\Neilcar\Downloads\Err>err 0x80070003
# for hex 0x80070003 / decimal -2147024893 :
COR_E_DIRECTORYNOTFOUND corerror.h
# MessageText:
# The specified path couldn't be found.
# 1 matches found for "0x80070003"

The download for err is available at http://www.microsoft.com/downloads/details.aspx?familyid=be596899-7bb8-4208-b7fc-09e02a13696c&displaylang=en. Download it and extract it to somewhere in %PATH% so that it's only a command prompt away.

Input Validation Is Not The Answer

neilcar — Thu, 07 Aug 2008 21:11:00 GMT

I just sent a piece of e-mail to my team about input validation and SQL injection and it occurred to me that I've been meaning to get into this here, too:

If you're trying to solve a SQL injection problem, input validation is NOT the answer!

There, I've said it. I keep seeing blog posts, forum posts, e-mail, etc, that say "Oh, you got hax0red by SQL injection, you should have been doing input validation". I'm sorry, but y'all are wrong, wrong, wrong, wrong. Let me copy-and-paste my e-mail to explain why:

Your customer is failing to stop SQL injection because they don’t understand the problem (or, by extension, the solution).

It sounds like the customer is trying to do input validation. What input validation does is to check input coming from an untrusted user to make sure that it doesn’t contain any blacklisted characters/phrases. Depending on the implementation, it either replaces items on the blacklist with something innocuous or it blocks the input entirely.

This is the wrong way to stop SQL injection, period. Input validation is sometimes useful as part of a defense-in-depth strategy but that’s it. There are several major problems with input validation:
It only works for as long as you’re smarter than your attackers because you have to anticipate every potential attack.
It doesn’t solve your real problem, which is that SQL can potentially execute something in input you get from your untrusted user.
You can end up with a lot of false positives if you’re not careful — if you’re blocking “exec”, what happens when one of your users has the title “Executive Assistant”?
To use an analogy, using input validation to stop SQL injection is like using anti-virus software to stop malware. It might work, it might not, but you’d be far better off if you actually resolved the vulnerability instead of just trying to mitigate it.

How, then, should the customer fix their vulnerabilities? Parameterizing queries is the single best step. Instead of simply mitigating the vulnerability, this actually resolves it. At a high level, I think of parameterized queries as DEP for SQL — it separates the executable code from the data and prevents anything in the data from executing.

Bala Neeumalla wrote a great MSDN article on how to code in ASP to prevent SQL injection (http://msdn.microsoft.com/en-us/library/cc676512.aspx) that covers this in detail. His article should be considered definitive. I wrote a few blog entries (http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx, http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx) that have additional examples that might be helpful to the customer.

Michael Howard also wrote a great blog entry regarding SQL injection and the SDL (http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx). Besides using parameterized queries, there are two additional steps that can be taken to further protect an application:
Use properly designed stored procedures
Use SQL Execute-only permission so that the application can only execute the stored procedures and cannot execute other statements.

This doesn't mean that input validation isn't useful and it doesn't mean it isn't appropriate mitigation in some cases. It's still not the way to prevent SQL injection.

And I'm not just talking about ASP, either. The same thing holds true for ASP.Net, the same thing holds true for Cold Fusion (look up CFQueryParam), Java, etc, etc. Wherever you query, there shall ye parameterize.

Forefront Server Security Management Console, Templates, and Revisions

neilcar — Fri, 11 Jul 2008 23:57:00 GMT

Sometimes, working in support, you come across a best practice or a bit of knowledge that is well-known to some people...but that bit of knowledge has never actually been documented. Today was one of those days.

While working in an environment with multiple Exchange Server 2003 servers running Antigen 9.1 Hotfix Rollup 3, we had to reinstall Antigen on one of the servers. We installed Antigen 9.1 and tested to make sure that mail was flowing after the install (it was). We then configured Antigen, including re-installing the FSSMC agent, redeploying the template for this server, and disabling Antigen performance counters.

At that point, things went off the rails. When we opened the Antigen admin console, it told us "You have 4 days left on your evaluation". Confused, we tried various things, including rebooting the box; however, every time, the console mocked us with it's eval message.

Since we were working in a maintenance window and we had run out of time, we made a decision to disable Antigen temporarily and investigate further. We took the template to a non-production Antigen 9.1 server and applied it. After applying it, we opened the admin console and we were greeted with "You have 4 days left on your evaluation".

At this point, we knew we were onto something. After working with our sustained engineering team to investigate further, we found out the root cause was something that is an FSSMC best practice even though I don't know that it's been written down before:

You should never apply a template created with a later version of Antigen or Forefront Server to an earlier version.

In this case, the template had been created in Antigen 9.1 Hotfix Rollup 3. As long as we applied it to servers running rollup 3 (or later), everything was A-OK; however, when we applied it to an Antigen 9.1 with no hotfix rollup on it, we ran into trouble.

The trouble, in this case, is that the schema for scanjobs was changed to add some additional options into the scanjobs. The template includes this new information but, once it's applied, the older code doesn't know how to handle it. This resulted in memory corruption which caused the false eval notice.

The takeaway here is that, if you're running a mixture of patch levels for your Antigen or Forefront Server servers, you have to be sure that the templates you are deploying with FSSMC were created in the earliest patch level you have in production. This will mean that you can't take advantage of any settings that are added in later patch levels but it also means that you won't run into issues like the one we wrestled with today.

Alternately, you could create templates for each patch level but I think that would end up being more difficult to manage.

Does This Make Me A Fanboy?

neilcar — Fri, 11 Jul 2008 06:21:00 GMT

I upgraded my iPhone to the 2.0 firmware today and I've been playing with the app store all day. It's pretty neat stuff.

Since I'm on a conference call tonight but I'm only here in an advisory/observational way, I put my phone on mute and kept playing with the app store. I downloaded the PhoneSaber application, which lets you pretend your phone is a light saber from Star Wars. As you move the phone around, it makes light saber sounds.

So, I amused myself with my virtual light saber for a few moments before somebody said "What is all that noise? I think we have a bad connection!"

I stopped what I was doing and thought for a long, hard moment before sending her an instant message: "Ummm, did it sound like a light saber?"

"Yes."

Antigen 9.1 Hotfix Rollup 3 and Performance Monitor

neilcar — Wed, 09 Jul 2008 22:56:30 GMT

While investigating an issue where mail was queuing in the Exchange Information Store, we discovered an issue that affects customers running Antigen 9.1 Hotfix Rollup 3 when there are performance monitoring tools such as Perfmon, Perfwiz, and the MOM client running. This issue will manifest itself as mail queuing (and never un-queueing), particularly immediately after the store is restarted. In this particular instance, we were seeing this happen when we failed from one cluster node to another. This could also occur in non-cluster environments and it could occur if scanjobs are restarted for other reasons (such as scan timeouts).

Additionally, you may see entries in ProgamLog.txt similar to the following:

"ERROR: scanjobs.cpp::ConfigScanJobFile(): AddNewScanJob() Failed 0x80030021"
"ERROR: scanjobs.cpp::CheckScanJobs(): ConfigScanJobFile() failed. hr[0x80030021]"

"ERROR: Unexpected, RetrieveScanJobIdentifier could not find the index"
"ERROR: Problems retrieving ScanJob identifier from RegisterMonitor"
"ERROR: antigenvsapi.cpp::VSAPINavigatorThread(): RegisterMonitor() returned 8000ffff"

You may also see instances where you open the Antigen Administrator console and scanjobs are not visible.

The root cause of this is a regression in the Antigen performance counters DLL that results in Antigen services being unable to access the configuration information for scanjobs; thus, when the server is in this state, scanning processes cannot be started and the admin console cannot access scanjob configuration information.

These symptoms will not occur in all instances.

Recommendations:

If a server is having this issue, you should be able to resolve the immediate issue by stopping all applications that are performing performance monitoring and restarting Exchange services.

If you are running services/applications that gather performance data on your Exchange Server with Antigen 9.1 Hotfix Rollup 3, you can mitigate this in the short-term by disabling Antigen performance counters. The following steps will disable those counters:

At c:\program files\microsoft antigen for exchange\
Enter command: antigenpmsetup -uninstall
You will also have to restart any application that loads performance counters. Rebooting the server will accomplish this; however, short of that, you can run 'tlist -m antigenpmdll.dll' to get a list. (Tlist is part of the debuggers package.)

This will be resolved in Rollup 4 when it is released. After Rollup 4 is available, we recommend re-enabling Antigen performance counters by running 'antigenpmsetup -install'.

SQL Storm: Possible ASP.Net

neilcar — Thu, 05 Jun 2008 00:13:59 GMT

I’ve had an unconfirmed report that the SQL Storm attacks are now also affecting ASP.Net pages, specifically with a URL of http://www.chliyi.com/m.js (this appears to be offline currently but I wouldn't suggest browsing there...) being injected into those pages. My team hasn’t worked on any incidents yet so I can’t confirm that it is the same issue; however, it certainly looks very similar.

This is a good time for me to remind everybody that Microsoft does provide no-cost support in the case of a security incident. If you’ve been affected, you can call 1-866-PCSAFETY in the United States & Canada. Outside of that area, refer to http://support.microsoft.com/common/international.aspx?rdpath=4 to find the right contact information.

(Thanks to Erwin Geirnaert for the heads-up.)

SQL Injection: Trends & Guidance

neilcar — Fri, 30 May 2008 19:17:11 GMT

I've been working with the SWI team to write a comprehensive overview of the SQL Storm attacks with guidance for IT administrators, developers, and end users. That article is posted at sql-injection-attack.aspx.

For developers, specifically, Bala Neerumalla has written an excellent overview of SQL injection and classic ASP code for MSDN at cc676512.aspx. This is well worth a read for any developer who has legacy ASP code running -- it covers a variety of scenarios and how to resolve them.

SQLInjectionFinder

neilcar — Tue, 27 May 2008 20:51:23 GMT

My colleague Greg, who has forgotten more about command line scripting than I will ever know, put together a sample on CodePlex that automates finding SQL injection attacks from the ongoing mass SQL injection attack ("SQL Storm", as I saw it dubbed today). This is a fairly convenient approach to searching logfiles on an IIS server.

SQLInjectionFinder -- http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436

SQL Injection Mitigation: Using Parameterized Queries part 2 (types and recordsets)

neilcar — Fri, 23 May 2008 19:18:00 GMT

(Part 1 is here)

Previously, I provided a simple example of using parameterized queries in classic ASP; however, that sample lacked a few things such as explicit typing for the parameters. It also created a read-only ADODB.RecordSet which, obviously, isn't one-size-fits-all.

Typing

In the last installment, we had worked up this code to do our query:

Set objConnection = Server.CreateObject("ADODB.Connection")
objConnection.Open "Provider=SQLOLEDB;Data Source=SQLSERVER;" _
& "Initial Catalog=website;User Id=user;Password=password;" _
& "Connect Timeout=15;Network Library=dbmssocn;"
strSql = "SELECT name, info FROM [companies] WHERE name = ?;"
set objCommand = Server.CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = strSql
objCommand.Parameters(0).value = strSearch
Set objSearchResults = objCommand.Execute()

As I noted then, this code has a minor performance issue because ADODB is going to have to made a round-trip to SQL to figure out the parameter type before it can execute the query. We can fix this and do input validation by explicitly typing our parameters like this:

Set objConnection = Server.CreateObject("ADODB.Connection")
objConnection.Open "Provider=SQLOLEDB;Data Source=SQLSERVER;" _
& "Initial Catalog=website;User Id=user;Password=password;" _
& "Connect Timeout=15;Network Library=dbmssocn;"
strSql = "SELECT name, info FROM [companies] WHERE name = ?;"
set objCommand = Server.CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = strSql
set objParameter = objCommand.CreateParameter("search", adVarChar, adParamInput, 20)
objCommand.Parameters.Append objParameter
obParameter.value = strSearch
Set objSearchResults = objCommand.Execute()

Here, we are creating an explicit parameter with a type of adVarChar (ie, it's a string) that is an input parameter with a maximum length of 20. We append the parameter to our ADODB.Command object and set the parameter's value to the search string we want in our command. More info about ADODB.Parameter objects is here, more info about the possible types is here.

RecordSets

We may want to be able to write to the ADODB.RecordSet that we create; however, the code above won't work for that because it creates a recordset with the default parameters (Set objSearchResults = objCommand.Execute()). If we want to be able to update the recordset, we have to create it with explicit parameters:

Set objConnection = Server.CreateObject("ADODB.Connection")
objConnection.Open "Provider=SQLOLEDB;Data Source=SQLSERVER;" _
& "Initial Catalog=website;User Id=user;Password=password;" _
& "Connect Timeout=15;Network Library=dbmssocn;"
strSql = "SELECT name, info FROM [companies] WHERE name = ?;"
set objCommand = Server.CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = strSql
set objParameter = objCommand.CreateParameter("search", adVarChar, adParamInput, 20)
objCommand.Parameters.Append objParameter
obParameter.value = strSearch
Set objSearchResults = Server.CreateObject("ADODB.RecordSet")
objSearchResults.Open objCommand,null,adOpenDynamic,adLockOptimistic

Now, we are explicitly providing parameters to indicate that we want a dynamic cursor (adOpenDynamic) and that we want optimistic locking (adLockOptimistic). This creates a recordset that can be updated via the RecordSet.Update method (http://msdn.microsoft.com/en-us/library/ms676529(VS.85).aspx).

SQL Injection Mitigation: Using Parameterized Queries

neilcar — Wed, 21 May 2008 16:05:00 GMT

Michael Howard wrote an excellent article yesterday on how the SDL addresses SQL injection. He walks through three coding requirements/defenses:

Use SQL Parameterized Queries
Use Stored Procedures
Use SQL Execute-only Permissions

As Michael points out, only the first, parameterized queries, remedies the problem. The other two provide additional defense.

The good news is that changing your ASP pages to use parameterized queries instead of just dynamically building the query is dead simple. The bad news is that MSDN doesn't have a lot of samples of how to do parameterized queries in ASP so I thought providing one would be helpful.

As an example, I'm sure that a lot of the websites that have been compromised recently via SQL injection have something like this:

Set objConnection = Server.CreateObject("ADODB.Connection")
objConnection.Open "Provider=SQLOLEDB;Data Source=SQLSERVER;" _
& "Initial Catalog=website;User Id=user;Password=password;" _
& "Connect Timeout=15;Network Library=dbmssocn;"
strSQL = "SELECT name, info FROM [companies] WHERE name =" & strSearch & "';"
Set objSearchResults = objConnection.Execute(strSQL)

This code is going to be extremely vulnerable to SQL injection since it's just taking the user input (which was passed in via a query string from a web form) and pasting it into the SQL statement.

The good thing about parameterization is that it separates the 'executable' code ("SELECT name, info...") from the 'data' (strSearch) we're using. With a few changes, we can make this code use parameters for the query and, with this small change, defend against being exploited in this way.

Set objConnection = Server.CreateObject("ADODB.Connection")
objConnection.Open "Provider=SQLOLEDB;Data Source=SQLSERVER;" _
& "Initial Catalog=website;User Id=user;Password=password;" _
& "Connect Timeout=15;Network Library=dbmssocn;"
strSql = "SELECT name, info FROM [companies] WHERE name = ?;"
set objCommand = Server.CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = strSql
objCommand.Parameters(0).value = strSearch
Set objSearchResults = objCommand.Execute()

All that we needed to do was:

Replace the query string in our SQL squery statement with a ? (which is the placeholder for a parameter).
Create a new Command object for our command.
Assign our active connection and command text to the Command object.
Set the first parameter in the parameters collection to our dynamic string.
Execute the command.

If we needed to use multiple parameters in our query, we'd add additional question marks to strSQL and additional parameters to the Parameters collection. For example:

...

strSql = "SELECT name, info FROM [companies] WHERE name = ?" _
& "AND info = ?;"
...
objCommand.Parameters(0).value = strName
objCommand.Parameters(1).value = strInfo
...

There is a BIG caveat on this -- the method I show above has a performance hit because I haven't specified the types of the parameters. This means that ADO has to make a roundtrip to the SQL server to figure out the type before actually using it. You can fix this by creating parameters objects with the appropriate type which would have the added bonus of doing simple input validation as well. If there's interest, I'll write a followup in the next few weeks with some samples of typed, parameterized queries. (EDIT: Written, it's here.)

Additional info is available on MSDN here. NomadPete has a fuller walkthrough here that covers parameterized queries and stored procedures.

As always, this is only part of the job in securing against SQL injection; however, it is probably the single most useful change you could make.

(Big thanks to Bala Neerumalla for tech reviewing this for me.)
(Edit: Fixed two minor issues with the code examples. Thanks, Steve!)

Continue on to Part 2

SQL Injection -- A Comment

neilcar — Mon, 07 Apr 2008 17:51:19 GMT

Kumar comments here and I think he has some questions/concerns that are worth addressing. I'm going to add my own comments (and, please note, the comments I make here are my own and do not necessarily reflect Microsoft's corporate opinions).

---------------------------------------------------------------------------------------

My site extensively uses asp and sql server. My site ranking is good with google for certain keywords searches.

Friday morning I found that the bad people (nmidahena) had updated text fields in almost all of the tables with a <script> some thing.js </script>. This has created a nightmare for me.

[nbc] This is consistent with what we've seen elsewhere. You had one or more SQL injection vulnerabilities on an ASP page that used a query string as the SQL query. The attackers found you on Google and ran their scripted attack against you, resulting in all your text getting the <script> tag appended to it.

Fortunately, I had a backup that came to my rescue. I also downloaded all asp and html files to my local machines and searched for "nmidahena" - nothing came up.

[nbc] You won't find anything in the code files, at least not in this attack.

This is what I have done:

a) Restore sql server tables from the backup.

[nbc] This is a very good step as long as you also fix the holes that were used to compromise it in the first place.

b) Rewrite my asp forms to not to accept any character or words that could be used for sql injection.

[nbc] This one is more problematic. Just blacklisting a set of characters/words is probably going to break this attack but it's not likely to prevent future attacks from working. I am not really qualified to answer this as I'm not a developer by trade. Thankfully, Michael Howard and David LeBlanc spent a lot of time answering it in Writing Secure Code. I have the 2nd edition on my desk and pages 399-411 cover this at great length.

[nbc] There are almost certainly other issues to be considered here. The first one is that, in most of these attacks, it looks like the web app is using a user with sysadmin privileges in SQL. This is as bad an idea as putting IUSR_MYSERVER in the administrators group. Your web app should have the least possible privilege in SQL. Running as sysadmin in SQL enables things such as xp_cmdshell, which is a great way for attackers to run sniffers, password-stealing utilities, and other malware on your SQL Server.

[nbc] Another thing to consider is the possibility that this isn't the first SQL injection attack against you. Another attacker might not have defaced your website; instead, they might have silently stolen every bit of data in your database. If your web app was running as sysadmin, they might have silently stolen every bit of data in EVERY database on your SQL Server. It is entirely possible that every name, e-mail address, password, credit-card number, etc that is in your database server's possession is now in somebody else's possession as well. If so, your IIS logs should tell the story.

Do you think this would be sufficient to prevent future attack?

[nbc] There are two answers to this question:

I think this is sufficient to prevent future iterations of this same attack...until the attackers change the script they're using.
I don't think this is sufficient to prevent all future SQL injection attacks. The only approach that is going to help with that is to make sure that you are using least privilege in SQL and build secure SQL statements/stored procedures. Even then, of course, there may be other vulnerabilities in your site that can lead to compromise.

I dont know where to look for help. The hosting agency has no good answers.

[nbc] I don't envy your hosting company or, for that matter, any hosting company. In general, I don't think it's going to be their responsibility to ensure that your code is secure, so I'm not surprised that they don't have good answers. On the other hand, if the security bugs in your code are severe enough, you might be opening their facility up to further compromise.

---------------------------------------------------------------------------------------

Other people may have better advice than I, and I'd love to hear it. Since I'm seeing another 11K (and rising) servers compromised this month via this attack, I think you're not the only person asking these questions. I've spent a lot of time thinking about this lately from a support/incident response perspective and I have some very large questions that I can't seem to answer.

Since my team operates from a reactive position (customer gets compromised, customer calls us, we investigate and offer suggestions), how can we help customers remediate this problem when we work with them? Realistically, the customer needs to do a security code review; however, this is beyond the scope of my team. There are offerings that cover this but, given the amount of work and expertise involved, they are costly.
Even if I had the opportunity to be proactive, how could I contact the large number of people who appear to be vulnerable due to their own code defects (67K+ from last month's attack, 11K+ so far this month)?

Mass SQL Injection -- Get Used To It

neilcar — Fri, 04 Apr 2008 21:00:34 GMT

It looks like another wave of the mass SQL injection I talked about last month is going on. The inserted link is different and, in the one specific incident I've seen, the source IP address is different; however, other than that, the attack looks to be identical.

2.1K websites so far, this month.

Good News

neilcar — Fri, 21 Mar 2008 00:50:45 GMT

The good news is that, whatever else might happen, these guys won't get pwned by SQL injection.

(Via GrumpySecurityGuy.)