(Special thanks to Neil Carpenter for helping out on this blog post)
Beginning late last year, a number of websites were defaced to include malicious HTML <script> tags in text that was stored in a SQL database and used to generate dynamic web pages. These attacks began to accelerate in the first quarter of 2008 and are continuing to affect vulnerable web applications.
The web applications compromised share several commonalities:
This represents a new approach to SQL injection (http://msdn.microsoft.com/en-us/library/ms161953.aspx). In the past, SQL injection attacks were targeted to specific web applications where the vulnerabilities and the structure of the underlying database were either known or discovered by the attacker. This attack differs because it has been abstracted such that it is possible to attack virtually any vulnerability that is present in an ASP page creating dynamic SQL queries from URI query strings. Additional technical details and a walkthrough of the specifics are available at http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx.
This attack does not exploit vulnerabilities in Windows, IIS, SQL Server, or other infrastructure code; rather, it exploits vulnerabilities in custom web applications running on this infrastructure. Microsoft has investigated these attacks thoroughly and determined that they are not related to any patched or 0-day vulnerabilities in Microsoft products. More information can be found at http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx.
As indicated above, these attacks have been accelerating through the year. This would appear to be related to at least two factors. First, there is a malicious tool that is in the wild that automates this. SANS discusses that tool here -- http://isc.sans.org/diary.html?storyid=4294. The tool uses search engines to find vulnerable sites to SQL injection.
The second factor is that one or more malicious bots are now launching SQL injection attacks as a way of spreading the bot further. SecureWorks discusses an example at http://www.secureworks.com/research/threats/danmecasprox/.
Once a server has been defaced using this attack, it will begin including a malicious <script> tag pointing to a .js file. While the contents of these files differ, they all attempt to exploit various vulnerabilities including already-patched Microsoft vulnerabilities and vulnerable third-party ActiveX controls. Since these scripts are hosted independently, it is possible that the scripts can be changed rapidly to exploit new client vulnerabilities and can be easily tailored to target on a “per browser” basis.
There are a number of things that IT administrators and database administrators should do to limit risk and respond to possible incidents on the code and infrastructure they manage:
Since this exploit takes place via the URI query string, administrators can review IIS logs to find anomalous queries that may be attempts to exploit this. Information on how to do this manually is available at http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx. A sample of an automated tool is available at http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436.
If IIS logs show that the server has possibly been exploited, the next step would be to inspect tables in databases that are used by the associated web applications, looking for <script> tags appended to cells in text columns.
NOTE: IIS servers should never run in production with logging disabled. While the storage and administration requirements of IIS logging can be significant, the lack of IIS logs makes it very difficult to respond to security incidents.
In cases where 3rd party ASP web applications are being used, administrators should contact the application vendors to ensure that they are not susceptible to SQL injection attacks.
Administrators should make sure that the SQL users that the web application uses have the least privilege necessary. Web applications should never connect as users with administrative privilege such as “sysadmin” at the server level or “db_owner” at the database level. The white paper “best practices for setting up and maintaining security in SQL Server 2005” http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc provides recommendations for various aspects of SQL server security.
There are several good documents on how Web developers can prevent SQL injection attacks when writing code. Since these attacks leverage vulnerable web application code, the only way to completely prevent them is to resolve vulnerabilities in the code. Any place that the code dynamically generates a SQL query using data from an external source (and, particularly, from a URI query string) should be considered suspect. Once code vulnerabilities are identified, they need to be carefully resolved.
http://msdn.microsoft.com/en-us/library/bb671351.aspx
Also, the above document contains a pointer to the following article “How To: Protect From SQL Injection in ASP.NET” http://msdn.microsoft.com/en-us/library/ms998271.aspx (which still applies to ASP)
A very useful video can be found here (this is the video refer on the previous article, but that link is currently broken): http://channel9.msdn.com/wiki/default.aspx/SecurityWiki.SQLInjectionLab
http://msdn.microsoft.com/en-us/library/ms161953.aspx
http://msdn.microsoft.com/en-us/library/cc676512.aspx
How to call SQL Server stored procedures from ASP:
http://support.microsoft.com/kb/q164485
Michael Howard covers those topics in http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx
Also, Writing Secure Code 2nd has good guidance on how to prevent these type of attacks as well (see pages 399-411)
Part 1: http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx
Part 2: http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx
Nazim from the IIS team explains how to do the filtering in detail here: http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx
If you are still not sure where to start, all web code that accesses a database with a particular focus on ASP code and areas of code which use user-supplied data should be review first.
End users should review the information at http://www.microsoft.com/protect/default.mspx; in addition, here are some specific steps that you can take to protect yourself.
While responsible browsing limits your exposure to vulnerability, it is possible that even websites you trust may have been compromised. Watch for unusual behavior, be aware of the risk, and implement the other recommendations in this section.
Since the malicious scripts are exploiting known vulnerabilities, you should make sure that you are running the latest Microsoft and 3rd party security updates. Microsoft security updates are available via http://update.microsoft.com. Additional information is available at http://www.microsoft.com/protect/computer/updates/OS.aspx.
You should disable any unneeded ActiveX controls and add-ons in Internet Explorer. To do this on Windows XP Service Pack 2 or later, follow these steps from KB883256 (http://support.microsoft.com/kb/883256):
1. Start Internet Explorer.
2. On the Tools menu, click Manage Add-ons.
3. Click the name of the add-on.
4. Use one of the following methods:
• Click Update ActiveX to replace the add-on with the current version. This option is not available for all add-ons.
• To enable an add-on, click Enable, and then click OK.
• To disable an add-on, click Disable, and then click OK.
You may have to restart Internet Explorer for the changes to take effect after you enable or disable an add-on.
For earlier operating systems, follow the instructions in KB154036 (http://support.microsoft.com/kb/154036).
If you are using an Internet browser other than Internet Explorer, you should ensure that you have installed the latest security updates and that you disable unneeded extensions and add-ons. Information for popular browsers can be found at:
Firefox - http://support.mozilla.com/en-US/kb/Firefox+Support+Home+Page
Opera - http://www.opera.com/support/
Safari - http://www.apple.com/support/safari/
End users should ensure that they have anti-virus and anti-spyware software installed and that it is up to date. More information can be found at http://www.microsoft.com/protect/computer/antivirus/OS.aspx and http://www.microsoft.com/protect/computer/antispyware/OS.aspx. You can get a 90-day trial copy of Windows Live OneCare anti-virus/anti-spyware software at http://onecare.live.com/standard/en-us/install/install.htm.
- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*