All,
sorry to hear about your issues, I thought I would post some of my thoughts here.
SQL Injection attacks rely on the ability of the hacker/program to inject arbitrary sql code onto existing sql statements (known as "dynamic sql"). Typically this happens when hackers find a way to concatenate new statements to existing statment often via querystring parameters e.g. "somepage.aspx?someid=1" get's changed to "somepage.aspx?someid=1;delete from users" . If the underlying code concatenates the someid text into a dynamic query then the additional query get's carried out.
DotNetNuke uses stored procedures instead of dynamic sql. This means that sql injection attacks are almost impossible (this is a development best practice). I believe we do use SQL injection in one core proc but it’s careful to not allow injection attacks so I don’t believe this is a core problem.
I took a check for the b.js payload indicated by one of the posters, and see that there are a large number of sites of all technologies that have that file(http://www.google.co.uk/search?hl=en&q=b.js&meta=). A short time ago there was a huge increase in sql injection attacks that are commonly believed to have been caused by automated attacks that leveraged search engines to find targets (http://blog.wired.com/monkeybites/2008/04/microsoft-datab.html has some good details on this and contains a link with some tips to clean up these entries). These were not dotnetnuke specific, but rather looking for any site that might allow dynamic sql. A number of popular 3rd party use dynamic sql, so perhaps one of them has a parameter that was found and used by this attack. I would recommend that people with access to their IIS logs take a look in there as it's likely you'll see the requests that caused the issue(s), and that will help you pinpoint the attack points and whether they're modules or other applictions (if an unrelated application is running with a database user with a high privileges a single site could allow sql injection across all databases on a server)
Note: the code to iterate through lists of tables, columns and users via sql injection is actually quite straightforward and very well known (basically it uses tables such as syscolumns/systables/sysusers etc.), most sql injection attacks do not need to know the underlying database to exploit it. In fact it's usually one of the signatures of a generic attack that data is changed in multiple places as the tools used don't know what (if any) data stored in the database will be displayed on a webpage.
Thanks,
Cathal