Major SQL Injection Trojan out!

Stephen

Stephen

US Operations
Staff member
Make sure your pages are secure against SQL injections there is a MAJOR trojan out and about!

We have several reports of people sites being hit today, some are calling it a Kisswow SQL Injection

We have the tools to help you find the vulnerable pages if you get hit, but this is just a warning! This bug is big, it seems to be coming from trojaned computers as there is not a single network really that is hitting repeatedly, it is from all over the world one single hit, very hard if not impossible to stop serverside!

I do not know this part for a fact, but I would guess that the attacking machines are actually malware infected zombies under some other person's control.
 
http://www.f-secure.com/weblog/archives/00001427.html

and
http://www.f-secure.com/weblog/archives/00001432.html

I'd like to note one thing they mention:

UPDATE: We've received some questions on the platform and operating systems affected by this attack. So far we've only seen websites using Microsoft IIS Web Server and Microsoft SQL Server being hit. Do note that this attack doesn't use vulnerabilities in any of those two applications. What makes this attack possible is poorly written ASP and ASPX (.net) code.
 
Hey Stephen,

We have the tools to help you find the vulnerable pages if you get hit, but this is just a warning! This bug is big, it seems to be coming from trojaned computers as there is not a single network really that is hitting repeatedly, it is from all over the world one single hit, very hard if not impossible to stop serverside!
Click to expand...

I'm having issues with my login on MSSQL9. You mentioned that you have tools to help find vulnerable pages. I've used Nikto and tried to sanitize any inputs but I'm wondering if this is causing my issues. What tools do you have that might help? Any idea why I'm having the issues posted at the link below?
http://support.jodohost.com/showthread.php?t=12265

Thanks!
 
Stephen,
Looks like I may have been hit with this one. I thought I was pretty secure against this after getting scanned for PCI, but obviously I missed something. You mentioned you may have some tools to help identify the vulnerable pages?
 
Yes the basic thing to do is search NVARCHAR in http logs, to find the vulnerable pages.

PCI scans unfortunately are terribly worthless :(
 
btw if you dont know the time of the injection we can search your logs for you but will need a ticket with info on the domain.

unlike most hacks we don't need any original file timestamps to track it down.
 
Most events I've seen of this on my own pages appear to stem from an automated program that simply seeks out asp websites and attempts the injection through the query string. So really, any page that request database info via the query string on loading is especially vulnerable.

I find the easiest way to stay safe is to include a small function that looks for all major SQL commands in the query string (declare, varchar, nvarchar, cast, etc.) and if found simply doesn't load the page or redirects the user. After you cover that base you can start worrying about checking your text input fields and protecting them as well.

The majority of my sites get attacked 3 or 4 times per day and there haven't been any problems yet. Fingers crossed ;-)
 
I had a site hacked yesterday, or possibly the day before. It was hacked once before and I did an audit of the site. Unfortunately, I found the problem I missed today.

The good news is that last problem is fixed now, but the bad news is the DB is still hosed. Stephen, is there any chance you have a backup of lbtrail_trailers on MSSQL6 from a few days ago that could be restored?

I submitted a ticket a few hours ago, but still no response. Client is breathing down my neck.


thanks,
.brit
 
It is restored now, I have been moving the backups for MSSQL servers around on the backup servers, so there is some chance they may not know where I put this just yet, and causing a delay in reply because they were looking for it :)

you can reply in the ticket that it is done already, I am eating a very late dinner at the moment.
 
The interesting bit is that ANY query that has non-parameterized variables is a vector for this exploit. You can sanitize inputs all you like (even regular expressions restricting to integers) and it will make no difference.
 
here is a little help... A stored proc to do a search and replace throughout the database...

Usage
EXEC SearchAndReplace '<script>blah,blah,bla</script>',''


Code: 
/****** Object:  StoredProcedure [dbo].[SearchAndReplace]    ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROC [dbo].[SearchAndReplace]
(
	@SearchStr nvarchar(100),
	@ReplaceStr nvarchar(100)
)
AS
BEGIN

	SET NOCOUNT ON

	DECLARE @TableName nvarchar(256), @ColumnName nvarchar(128), @SearchStr2 nvarchar(110), @SQL nvarchar(4000), @RCTR int
	SET  @TableName = ''
	SET @SearchStr2 = QUOTENAME('%' + @SearchStr + '%','''')
	SET @RCTR = 0

	WHILE @TableName IS NOT NULL
	BEGIN
		SET @ColumnName = ''
		SET @TableName = 
		(
			SELECT MIN(QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME))
			FROM 	INFORMATION_SCHEMA.TABLES
			WHERE 		TABLE_TYPE = 'BASE TABLE'
				AND	QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME) > @TableName
				AND	OBJECTPROPERTY(
						OBJECT_ID(
							QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME)
							 ), 'IsMSShipped'
						       ) = 0
		)

		WHILE (@TableName IS NOT NULL) AND (@ColumnName IS NOT NULL)
		BEGIN
			SET @ColumnName =
			(
				SELECT MIN(QUOTENAME(COLUMN_NAME))
				FROM 	INFORMATION_SCHEMA.COLUMNS
				WHERE 		TABLE_SCHEMA	= PARSENAME(@TableName, 2)
					AND	TABLE_NAME	= PARSENAME(@TableName, 1)
					AND	DATA_TYPE IN ('char', 'varchar', 'nchar', 'nvarchar')
					AND	QUOTENAME(COLUMN_NAME) > @ColumnName
			)
	
			IF @ColumnName IS NOT NULL
			BEGIN
				SET @SQL=	'UPDATE ' + @TableName + 
						' SET ' + @ColumnName 
						+ ' =  REPLACE(' + @ColumnName + ', ' 
						+ QUOTENAME(@SearchStr, '''') + ', ' + QUOTENAME(@ReplaceStr, '''') + 
						') WHERE ' + @ColumnName + ' LIKE ' + @SearchStr2
				EXEC (@SQL)
				SET @RCTR = @RCTR + @@ROWCOUNT
			END
		END	
	END

	SELECT 'Replaced ' + CAST(@RCTR AS varchar) + ' occurence(s)' AS 'Outcome'
END
 
A dummy needs help here: (me)

How do I keep these things from being added to my database fields?

"<script src=http://www.jk*edited*n3.ru/js.js></script>"

The database keeps getting attacked.....

if i run it in google all I get are tons of other websites that it is affected by...
 
You need to be sure that all SQL commands are parameterized.

You'll need to check every file in every site. No way around it. Adobe Dreamweaver CS3 does a nice job of parameterizing legacy code written in previous copies of DW semi-automatically; for hand-written code, it will all need to be manually replaced.
 
hafa said:
You need to be sure that all SQL commands are parameterized.

You'll need to check every file in every site. No way around it. Adobe Dreamweaver CS3 does a nice job of parameterizing legacy code written in previous copies of DW semi-automatically; for hand-written code, it will all need to be manually replaced.
Click to expand...

Are you saying that some of my actual files might have been altered? Or?
 
You must log in or register to reply here.
Back
Top