SQL Injection Attacks on IIS Web Servers

You may have seen recent reports that have surfaced stating that web sites running on Microsoft’s Internet Information Services (IIS) 6.0 have been compromised. These reports allude to a possible vulnerability in IIS or issues related to Security Advisory 951306 which was released last week.

Microsoft has investigated these reports and determined that the attacks are not related to the recent Microsoft Security Advisory (951306) or any known security issues related to IIS 6.0, ASP, ASP.Net or Microsoft SQL technologies.

Instead, attackers have crafted an automated attack that can take advantage of SQL injection vulnerabilities in web pages that do not follow security best practices for web application development. While these particular attacks are targeting sites hosted on IIS web servers, SQL injection vulnerabilities may exist on sites hosted on any platform.  More information on SQL injection attacks can be found here and here.

Guidance from Microsoft for web application development best practices can also be found on this MSDN page. Best practices guidelines that developers may follow to mitigate SQL injection, can be located here. As we continue to make progress in our investigation on this attack, we will provide updated guidance and information on the IIS.net site. For the latest information on this issue, please subscribe or visit the IIS security forum.

For end-users, the investigation also shows no indication of an un-patched vulnerability in IIS, SQL Server, Internet Explorer or any other Microsoft client software, so we recommend customers apply the latest updates to be protected from these attacks.

To further protect themselves from reported attacks, we encourage all customers to apply our most recent security updates to help ensure that their computers are protected from attempted criminal attacks. For more information about security updates, visit: www.microsoft.com/protect.

Anyone believed to have been affected can visit: http://www.microsoft.com/protect/support/default.mspx and should contact the national law enforcement agency in their country.  Those in the United States can contact Customer Service and Support at no charge using the PC Safety hotline at 1-866-PCSAFETY.  Additionally, customers in the United States should contact their local FBI office or report their situation at: www.ic3.gov


  • Pingback

  • Ahhh BS, what's all this hoopla about?! Just tell it like it is: A LOT of developers are just plain lazy and don't care enough to use parameterized queries; end of story.

  • Does denying access to the webserver, still allow a sql attack >?

  • thank you

  • Even if Microsoft is not at fault for the SQL injection attacks, the malware specifically targets Windows clients.

    Since the SQL injection attack is specific to T-SQL, wouldn't it be responsible to give developers and DBAs some hints to at least detect infections? Other than using Google to find all 500,000 infected web pages?

  • if this is not due to an IIS-vulnerability, why does it only affect IIS-servers?

  • Hi Max -

    the exploit code is specific to SQL server, which is normally found behind an ASP/ASP.NET application that has not followed best practices. The exploit code doesn't work against mysql or other databases, which is why it appears to be an IIS/ASP/ASP.NET/SQL bug, but it is not. The same exploit could have been done with code specific to mySQL or any other database.

  • John.B - MS do provide info for developer and DBAs either via MSDN:

    also via multiple blog entries, for example:

    problem is most Devs and DBAs are just not interested in doing the work...

  • I wrote some T-SQL to scan your entire server for "<script" in all databases.


    exec sp_msforeachdb '
    Print(''Scanning Database [?]'')

    DECLARE @T varchar(255), @C varchar(255)
    select a.name,b.name from [?].dbo.sysobjects a,[?].dbo.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)
    order by a.name, b.name

    OPEN Table_Cursor
    FETCH NEXT FROM Table_Cursor INTO @T,@C
    If Left(@T,1)''#''
    Print('' Scanning Table [''+@T+''], Column: [''+@C+'']'')
    Exec(''if exists(select [''+@C+''] from [?].dbo.[''+@T+''] where [''+@C+''] like ''''%>> FOUND in [''+@T+''].[''+@C+'']'''''')
    FETCH NEXT FROM Table_Cursor INTO @T,@C
    CLOSE Table_Cursor
    DEALLOCATE Table_Cursor


    Just search the printout for ">>> FOUND" to see in what table the malicious code was found.

    Be warned: this might take a LONG time!

  • A few of our legacy ASP application were affected by this outbreak. It was an accident waiting to happen though. The blame is on the poorly written code, not in SQL or IIS. Since it is too expensive (and difficult) to fix all code, you have to live with it. I found an interesting and free (GNU with source code) application for IIS that proved very efficient. I am still being attacked, but the filter has blocked the effects of such attacks.

    Installation and code can be found here:

    The only bad thing is that it is not compatible with Windows 64 bits. I had to move all ASP application to a lesser server :(

  • Once you recover your web server from the attack you are not done. You may find that the seach engines now have cached pages for your site that include the malicious code. Yahoo takes a simple e-mail. Google takes an online form. I have been fighting for 2 weeks to get Microsoft to remove cached pages that are now 6 weeks old from their Live Search.

  • Who should be responible for fixing a website that has recently been affect by an SQL injection attack? Should it be the people responible for developing website or the company that purchased it? We had a website developed a year ago and it's currently being hosted by the developer. It has recently been attacked and now they want to charge us to fix it, but if this is due to their poor code shouldn't they be responible for fixing it?

  • The above component do not work and fail if SQL is defined in form action:

  • It is important to learn how to implement best security practices and protect your database. There's a great tutorial test on http://www.microsoft.com/hellosecureworld7 where you can see an SQL Injection attack in action and learn ways to stop it. Look for the SQL Injection Lab.

Comments have been disabled for this content.