China Hack

Snitz™ Forums 2000
https://forum.snitz.com/forumTopic/Posts/67053?pagenum=1
05 November 2025, 12:58

Topic

Astralis
China Hack
14 May 2008, 11:13


I don't know how they've got it. They messed with member ID #2 and made it admin and went to town.
In the member table, they added:

Code:

Member'sName<script src=removed></script>

How can I go through the database and remove this? They updated MANY fields and columns with this.<

 

Replies ...

HuwR
14 May 2008, 11:20


you will almost certainly need to do this manually, sounds like you also need to ensure you have ALL current patches applied.<
Astralis
14 May 2008, 11:22


I have all the patches unless a new one just came out.
Anyhow, could there be a regex to delete everything after the first "<".<
HuwR
14 May 2008, 11:25


not if they have updated many fields and columns, it would be just as quick to do it manually.
There are NO known hacks/issues that will allow someone who is not an admin create one, therefore you must still have an issue that is not patched, or a MOD that requires patching, you need to scour your log files to find out how they managed to change a member to admin<
Astralis
14 May 2008, 11:33


Unfortunately I can't access SQL Server logs. Will the info be in IIS Logs?
What should I look for?<
AnonJr
14 May 2008, 11:37


It would be in the IIS logs. As to what to look for, that's a tougher question...<
Astralis
14 May 2008, 11:46


Couldn't there be a simple way to get a script to run through each column, identify where "<scrip" is, cut it, save everything before it and then update the field?
I just don't know what type of regexp would identify that. Otherwise, I could easily write an asp script to do that.<
Astralis
14 May 2008, 11:56


This appears to be a Database hack and it seems like they're doing it to many tables, not just the forum table. They seem to know the structure of Snitz, though.<
AnonJr
14 May 2008, 11:59


Or it could be related to this: [link] For the type of attack Podge mentioned you don't need to know the database structure.
Have you added any MODs? While I won't 100% rule it out, I don't think that a fully patched 3.4.06 forum is vulnerable to that sort of attack.<
Astralis
14 May 2008, 12:14


That's exactly what happened. How to stop this??<
ruirib
14 May 2008, 12:24


If that was the case, seems like they got in using non Snitz code? Do you have non snitz code?<
AnonJr
14 May 2008, 12:24


Originally posted by AnonJr
Have you added any MODs? While I won't 100% rule it out, I don't think that a fully patched 3.4.06 forum is vulnerable to that sort of attack.
<
Astralis
14 May 2008, 12:25


Besides PM, there are no other mods.
It's a HEX SQL Injection attack based on other sections of the site.
How do I prevent a HEX attack?<
AnonJr
14 May 2008, 12:27


You need to find what [form/query string] values aren't being properly sanitised and start there.
Were you able to find in the logs what page they were using?<
Astralis
14 May 2008, 12:36


They were using several pages, but they're not actually using any IDs to get through!
They're doing this:

id=11510;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST ...etc...
How do I stop this?<
HuwR
14 May 2008, 12:38


if you know which pages you just need to check that any querystring variables/form variables are being sanitised before being used in any queries<
HuwR
14 May 2008, 12:38


for what you just posted, simply checking that id is an integer will prevent the attack<
Astralis
14 May 2008, 12:49


Clng, right? If that's the case, then those pages are protected.
If it shows up in the IIS that they're attaching the HEX value, does that mean they succeeded or merely that they were trying?
<
HuwR
14 May 2008, 12:56


it just means they were trying with/without success, the http status may indicate if it succeeded (although not all the time)<
HuwR
14 May 2008, 12:58


it may not even be evident from the querystring either, what you need to do is work out when they logged in using the member they had elevated to admin, this will enable you to filter the log by their IP, it should then be easy to work out what the last page they accessed was prior to hacking the account.<
Astralis
14 May 2008, 13:20


Huw,

I have thousands of rows and multiple columns with this script injection. Do you, or anyone, know of a way to eliminate it using ASP?

The formula for each injection is:
Code:

The quick brown<script...
or
Code:

The<script
<
HuwR
14 May 2008, 13:29


it would be fairly simple to do in asp, but would need to be able to see the data in order to write the code correctly<
Astralis
14 May 2008, 13:35


How can I provide it for you? E-mail? FTP?<
Astralis
14 May 2008, 13:45


Looks like this might do it?
Code:

UPDATE table SET field = REPLACE( field, '<script ...full text of injection>', '' )

Simply run it manually, I think.<
HuwR
14 May 2008, 13:53


don't forget it may take some time to complete smile<
Astralis
14 May 2008, 14:04


Yeah, I'm running them in small blocks of 100 rows, as well.<
Astralis
14 May 2008, 15:43


Question. This might seem very obvious, but the script injection must be placed inside a query, correct?
For example, I'm running a querystring with the title of the document but this title is never placed inside a query so I don't sanitize it. This is safe, right?<
MarcelG
14 May 2008, 16:20


No, when you use the queryestring somewhere in the HTML that's not safe as it allows for cross site scripting attacks (which may lead to stolen cookies/credentials) and other malicious practices using your website.<
Astralis
14 May 2008, 16:27


I don't use it in the HTML. It's just for displaying the title for search engines within the querystring.<
AnonJr
14 May 2008, 16:47


Doesn't matter. If you're not properly sanitizing any input it is a potential vector for someone with too much time on their hands to use to play silly buggers with your site or someone else's.<
Astralis
14 May 2008, 17:16


Okay. I'll sanitize it.
UPDATE:

Several things:

1) This hack had nothing to do with Snitz. They didn't change the member levels as I initially believed. 2) I discovered that some of my SQL Injection script simply DID NOT work. Lesson: Test your injection script! 3) Back up your database. 4) Many people are dealing with this right now. I used the following script to go through the rows quickly. Bill Wilkinson on www.ASPMessageboard.com wrote it. Depending on the size of your database, run it on just a couple of fields at a time. This is what I used to update the Snitz Member's table.
Code:

Set zap = New RegExp
zap.Pattern = "\<" & "script[\s\S]*?\<\/script\>"
zap.IgnoreCase = True
zap.Global = True

'#### CAUTION ####
'  Either this regexp or the script injection trimmed a couple of 
'  the text fields such as M_SIG while deleting the injection.  I 
'  simply told my members to recreate it.  I suspect it was the script
'  injection, though. There are other fields you need to add...it's 
'  self-explanatory if you compare it with your database table design.
'  Uncomment only a couple of fields at a time.  If you try to run 
'  them all at the same time your database will timeout.
'
'  Also, if you have a field that is NULL, run the code using this 
'  model or else you will get errors:
'
'    uname = RS("username")
'    If Not IsNull(uname) Then If uname <> "" Then RS("username") = zap.Replace(uname,"") 
'
'############

Set RS = Server.CreateObject("ADODB.Recordset")
RS.Open "FORUM_MEMBERS", openyourconnection, 3, 3
Do Until RS.EOF
        'RS("M_AIM") = zap.Replace( RS("M_AIM"), "" )
	'RS("M_ICQ") = zap.Replace( RS("M_ICQ"), "" )
	'RS("M_Yahoo") = zap.Replace( RS("M_Yahoo"), "" )
	'RS("M_MSN") = zap.Replace( RS("M_MSN"), "" )	
	'RS("M_FIRSTNAME") = zap.Replace( RS("M_FIRSTNAME"), "" )	
	'RS("M_LASTNAME") = zap.Replace( RS("M_LASTNAME"), "" )	
        'RS("M_OCCUPATION") = zap.Replace( RS("M_OCCUPATION"), "" )
        'RS("M_SEX") = zap.Replace( RS("M_SEX"), "" ) 
	'RS("M_HOBBIES") = zap.Replace( RS("M_HOBBIES"), "" )	
	'RS("M_LNEWS") = zap.Replace( RS("M_LNEWS"), "" )			
	'RS("M_QUOTE") = zap.Replace( RS("M_QUOTE"), "" )			
	'RS("M_MARSTATUS") = zap.Replace( RS("M_MARSTATUS"), "" )			
	'RS("M_BIO") = zap.Replace( RS("M_BIO"), "" )	
	'RS("M_LINK1") = zap.Replace( RS("M_LINK1"), "" )			
	'RS("M_LINK2") = zap.Replace( RS("M_LINK2"), "" )			
	'RS("M_CITY") = zap.Replace( RS("M_CITY"), "" )							
	'RS("M_STATE") = zap.Replace( RS("M_STATE"), "" )			
	'RS("M_KEY") = zap.Replace( RS("M_KEY"), "" )			
	'RS("M_PWKEY") = zap.Replace( RS("M_PWKEY"), "" )				
	'RS("M_PHOTO_URL") = zap.Replace( RS("M_PHOTO_URL"), "" )					
	'RS("M_NEWEMAIL") = zap.Replace( RS("M_NEWEMAIL"), "" )					
	'RS("M_PMBLOCKLIST") = zap.Replace( RS("M_PMBLOCKLIST"), "" )					
	RS.Update
    RS.MoveNext
Loop
RS.Close
response.write "finished"
<
Classicmotorcycling
14 June 2008, 18:31


OK, this is what I have been dealing with for a while now, and I have posted how it is stopped over here: Did this hack get through?<
ruirib
15 June 2008, 12:08


This SQL Script uses a strategy similar to the injection script to clean your tables
Code:

DECLARE @T VARCHAR(255),@C VARCHAR(255), @scr varchar(1000)
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 
  
SET @scr = 'UPDATE ['+@T+'] SET ['+@C+']=REPLACE(CONVERT(VARCHAR(4000),['+@C+']),''<script src=http://www.bigadnet.com/b.js></script>'','''')'
exec (@scr)
FETCH NEXT FROM Table_Cursor INTO @T,@C 
END 
CLOSE Table_Cursor 
DEALLOCATE Table_Cursor
It's faster and much easier to use than the previous ASP script, but you will need to execute it from SQL Server Management Studio or Enterprise Manager. You may need to replace the link to the javascript file, since it seems the link varies. If in doubt, please post and I'll help with it.

You should also be aware that the original hack script will have trimmed your existing data to its first 4000 characters, if the column data had more than 4000 chars. This script does the same, but the harm is already done.<
MPaulsen
25 June 2008, 19:49


I'm a newcomer to the board but a longtime Snitz user. I've been hit in the past and I finally decided to leverage SQL Server to reject these types of injections.

I use constraints on the text fields that these hacks attempt to access. Using SQL Enterprise Manager, in Design Table mode right click and select Check Constraints... then add a new constraint for all nvarchar fields using the following expression:

not([FIELDNAME] like '%<script%')

for each FIELDNAME in the table of type varchar or nvarchar with a size > 20 (e.g., M_NAME, M_EMAIL, etc.)<
ruirib
25 June 2008, 19:54


That will work, just to protect you from this specific hack, but the base problem persists - a hole in the asp pages. If the hole is there, nothing stops the user from doing things like deleting all your records or even dropping your tables, if your user has such permissions. This basically means your solution may as well deceive you into thinking that you're safe with it, but you really aren't!<
MPaulsen
26 June 2008, 12:31


Originally posted by ruirib
That will work, just to protect you from this specific hack, but the base problem persists - a hole in the asp pages. If the hole is there, nothing stops the user from doing things like deleting all your records or even dropping your tables, if your user has such permissions. This basically means your solution may as well deceive you into thinking that you're safe with it, but you really aren't!

True enough, but these attacks are practically a daily occurrence on my board yet I don't see where the vulnerability lies. It was worth the effort since these kinds of SQL injection attacks are by far the norm -- not deliberately malicious but aggravating nonetheless. I combed over a recent log file and there were hundreds of attempts. Has anyone been able to pinpoint which forum page (or pages) are vulnerable?
<
AnonJr
26 June 2008, 12:50


As far as we can tell its not any base forum pages. In a small number of cases its been an older, insecure MOD; and in the rest its been via some other page on the site that shares the same database (that may or may not include the same tables).<
ruirib
26 June 2008, 13:49


What pages were attacked, in your log files? You can use that info to select the pages to analyse for security holes...<
© 2000-2021 Snitz™ Communications