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.
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.
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’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
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?
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.
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 ‘’,‘’
[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'
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.
