On May 13, 2:18=A0pm, Eric <eisa...@[EMAIL PROTECTED]
> wrote:
> Here's the news link I found...back from April 23...
>
> http://www.pcpro.co.uk/news/192051/hackers-infect-half-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 do***ent.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 #re****t(Tablename varchar(255), columnname
varchar(255), datatype int, affectedrows int)
DECLARE @[EMAIL PROTECTED]
varchar(10)
DECLARE @[EMAIL PROTECTED]
varchar(255),@[EMAIL PROTECTED]
varchar(255),@[EMAIL PROTECTED]
int
Set @[EMAIL PROTECTED]
=3D '</script>'
DECLARE Table_Cursor1 CURSOR FOR select a.name,b.name,b.xtype
from sysobjects a,syscolumns b
where a.id=3Db.id and a.xtype=3D'u' and (b.xtype=3D99 or b.xtype=3D35 or
b.xtype=3D231 or b.xtype=3D167)
delete from #re****t
OPEN Table_Cursor1
FETCH NEXT FROM Table_Cursor1 INTO @[EMAIL PROTECTED]
WHILE(@[EMAIL PROTECTED]
)
BEGIN
exec('Declare @[EMAIL PROTECTED]
int;
SELECT @[EMAIL PROTECTED]
=3D COUNT(1)
FROM ['+@[EMAIL PROTECTED]
']
WHERE RIGHT(convert(varchar(4000),['+@[EMAIL PROTECTED]
']),9) =3D '''+@[EMAIL PROTECTED]
''';
if @[EMAIL PROTECTED]
> 0 begin
INSERT INTO #re****t select '''+@[EMAIL PROTECTED]
''', '''+@[EMAIL PROTECTED]
''', '''+@[EMAIL PROTECTED]
''',
COUNT(1)
FROM ['+@[EMAIL PROTECTED]
']
WHERE RIGHT(convert(varchar(4000),['+@[EMAIL PROTECTED]
']),9) =3D '''+@[EMAIL PROTECTED]
'''
end;')
FETCH NEXT FROM Table_Cursor1 INTO @[EMAIL PROTECTED]
END CLOSE Table_Cursor1
DEALLOCATE Table_Cursor1
select * from #re****t
|
