SQL Injection Attack

(Special thanks to Neil Carpenter for helping out on this blog post)

Recent Trends

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:

• Application uses classic ASP code
• Application uses a SQL Server database
• Application code generates dynamic SQL queries based on URI query strings (http://contoso.com/widgets.asp?widget=sprocket)

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.

IT/database administrators Recommendations

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:

• Review IIS logs and database tables for signs of previous exploits

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.

• If running 3rd party code that uses a database back-end, consult ISV about susceptibility to SQL injection

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.

• Validate that the account(s) that are used from the web application have least possible privilege in the database

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.

Web developers Recommendations

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.

• Explained – SQL Injection, ASP.NET, ADO.NET:

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

• Generic information about how SQL Injection works:

http://msdn.microsoft.com/en-us/library/ms161953.aspx

• SQL injections in ASP code (this is different from ASP.NET!):

http://msdn.microsoft.com/en-us/library/cc676512.aspx

How to call SQL Server stored procedures from ASP:

http://support.microsoft.com/kb/q164485

• The Microsoft Security Development Lifecycle (SDL) has specific guidance to defend against SQL injection. In simple terms there are three different strategies to eradicate SQL Injection attacks:

1.  
   1.  
      1. Using SQL parameterized queries
      2. Using stored procedures
      3. Using SQL execute-only permissions

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 2^nd has good guidance on how to prevent these type of attacks as well (see pages 399-411)

• SQL Injection Mitigation: Using Parameterized Queries (Part 1 & 2). The advantage of using parameterized queries is that it separates the executable code (ie, the SELECT statement) from the data (the dynamic information supplied by the application’s user). This approach prevents any malicious statements passed along by the user from executing.

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

• Filtering SQL injection form Classic ASP code (or blacklisting keywords), we considered the below as temporary workarounds since in reality it does not fix the root cause of the bugs (i.e. the code is still vulnerable and it might be reachable even after the filtering)

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 User Recommendations

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.

• As always, browse responsibly — but be aware that this could also affect websites that the user trusts

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.

• Keep up to date on security updates, both Microsoft and 3rd party

Since the malicious scripts are exploiting known vulnerabilities, you should make sure that you are running the latest Microsoft and 3^rd 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.

• Disable unneeded ActiveX controls and Internet Explorer add-ons

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).

• Take steps to reduce attack surface of 3rd party browsers if you are using them

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/

• Run up-to-date anti-malware software

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.html.

SQL注入攻击-来自微软安全博客的建议

本文翻译自微软博客上刊载的相关文章，英文原文版权归原作者所有，特此声明。 （特别感谢Neil Carpenter对本文写作提供的帮助）

近期趋势

从去年下半年开始，很多网站被损害，他们在用于生成动态网页的SQL数据库中存储的文本中被注入了恶意的HTML <script>标签。这样的攻击在2008年第一季度开始加速传播，并且持续影响有漏洞的Web程序。这些Web应用程序有这样一些共同点：

• 使用经典ASP代码的程序
• 使用SQL Server数据库的程序

应用程序代码根据URI请求字符动态地生成SQL查询（http://consoto.com/widgets.asp?widget=sprocket）这体现了一种新的SQL注入（SQL injection）的途径（http://msdn.microsoft.com/en-us/library/ms161953.aspx）。在过去，SQL注入攻击的目标是具有如下特点的特殊Web应用程序：攻击者知道或者可以探测出后台数据库的漏洞或者结构。这样的攻击（指本文讨论的攻击-译者注）不同，因为它是抽象的，对于攻击来说，任何存在于使用URI请求字符串动态创建SQL查询的ASP页面都可能存在。你可以在 http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到更多的技术详情和简单代码。 这样的攻击并非利用了Window、IIS、SQL Server或者其他底层代码的漏洞，而是利用了在这些平台上运行的由程序员自行编写的代码中的漏洞。Microsoft已经对这些攻击进行了彻底的调查，并且发现，他们和以往的Microsoft产品的补丁和0-day漏洞无关。你可以在http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx获取跟多的信息。 正如上面所指出的，这些攻击在近年来呈现一种增长的趋势。这至少与两个因素有关： 第一，有暴力性的恶意攻击工具自动化进行此类操作。SANS在http://isc.sans.org/diary.html?storyid=4294讨论了这类工具。该工具使用搜索引擎来寻找具有SQL注入漏洞的站点。 第二，一个或多个恶意僵尸正在进行SQL注入攻击，用以广泛传播僵尸。SecureWorks在http://www.secureworks.com/research/threats/danmecasprox/讨论了一个案例。 一旦某台服务器被该漏洞所攻击，它将被插入指向某.js文件的恶意<script>标签。虽然这些文件的内容不同，但是他们都尝试利用已经被修复的Micfosoft产品的漏洞或者第三方ActiveX控件的漏洞。由于这些脚本被单独存储，这些脚本就很容易的被更新以利用更新的客户端漏洞，也更容易按照不同浏览器来定制。

给信息技术/数据库管理员的建议

有很多事情是信息技术管理员或者数据库管理员可以采取的，以减少他们的风险和响应他们的代码和平台中可能出现的事件：

• 检查IIS日志和数据表来寻找未知风险的标志。

由于该漏洞利用方式通过URI请求字符串作用，管理员们可以检查IIS日志来查找尝试利用该漏洞的非正常请求。你可以在http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到如何手动进行改操作的详细信息。在 http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436有进行自动化操作的工具。 如果IIS日志表明服务器可能已经被侵害，那么下一步要采取的行动就是审计相应的Web应用程序所使用的数据库中的表，并且查找附加在文本内容中的<script>标签。 提示：IIS服务器不应当在生产环境中关闭日志。存储和适当的管理对于IIS日志都是重要的，缺少IIS日志对于响应安全事件是非常困难的。

• 如果运行了使用后端数据库的第三方代码，则考虑不受SQL注入影响的独立软件开发商（ISV，Independent Software Vendors）。

在使用第三方ASP Web程序的情况下，管理员应当联系应用程序厂商来确定他们的产品不受SQL注入攻击的影响。

• 确认Web应用程序所使用的数据库帐户具有最少的权限。

管理员应当确保Web应用程序所使用的SQL用户具有最小的必要权限。Web应用程序不应当以诸如"sysadmin"的服务器管理员权限或者"db_owner"的数据库权限链接。白皮书"在SQL Server 2005中的最优化安全设置和维护"： http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc 提供了关于SQL Server安全的多方面建议。

给Web开发者的建议

有很多优秀的文档论述在编码时如何防御SQL注入攻击。由于这些攻击者leverage有漏洞的Web应用程序代码，所以完全防御他们的唯一方法是解析在代码中存在的漏洞。程序中任何一个使用外部资源（一般指从URI请求字符串）数据来动态生成SQL请求的地方都应当被认为是可疑的。当代码漏洞被识别出来，他们应当被小心的修复。

• 说明-SQL注入、ASP.NET和ADO.NET ：

http://msdn.microsoft.com/en-us/library/bb671351.aspx 同时，上面的文章包含到相关文章"如何在ASP.NET中避免SQL注入" http://msdn.microsoft.com/en-us/library/ms998271.aspx，该文章同时适用于ASP。 这里有一个非常有用的视频（该视频是针对一篇防御文章的，然而链接可能已经无效了）：http://channel9.msdn.com/wiki/default.aspx/SecurityWiki.SQLInjectionLab。

• 关于SQL注入如何实现的简单信息：

http://msdn.microsoft.com/en-us/library/ms161953.aspx

• ASP代码中的SQL注入（与ASP.NET中的并不相同）：

http://msdn.microsoft.com/en-us/library/cc676512.aspx 如何在ASP中执行SQL Server存储过程： http://support.microsoft.com/kb/q164485

• Microsoft安全部门（The Microsoft Security Development Lifecycle,SDL）对SQL注入的防御进行了一些指导。简单来说有三种策略来应对SQL注入攻击：

1. 使用SQL参数查询
2. 使用存储过程
3. 使用SQL仅执行（execute-only）许可

Michael Howard在http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx谈论了这些内容。 同时，编写安全的代码（第二版）也指导了如何防御此类攻击（请浏览399-411页）。

• 减轻SQL注入：使用参数查询（第一部分和第二部分）。使用参数化查询的好处是它将执行的代码（例如SELECT语句）和数据（由程序使用者提供的动态信息）分开。该途径防御了通过用户传递来执行的恶意语句。

第一部分： http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx 第二部分： http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx 在经典ASP代码中过滤SQL注入（或者黑名单中的字符），我们将如下的工作认为是实际中临时性的解决方案，因为它治标不治本。（例如，代码仍然是有漏洞的，他仍然可能被绕过过滤机制而被访问到） IIS团队中的Nazim解释了如何过滤的详细信息：http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx。 如果你仍然不了解从哪里开始，所有使用特定ASP代码访问数据库，尤其是使用由用户提供的数据的代码应当首先被检测。

给最终用户的建议

最终用户（下简称用户-译者注）应当浏览位于http://www.microsoft.com/protect/default.mspx的信息。另外，这里也有一些你可以采取以保护自己的步骤。

• 通常应当有选择的访问网站-但是也需要了解，该漏洞也会影响用户信任的网站。

有选择的访问网站减少了你暴露在漏洞下的风险，当然即使是你所信任的也有可能被攻击。留意不正常的行为，了解面临的风险，并且实施本节提供的其他建议。

• 针对Microsoft和第三方软件，保持安全更新。

由于恶意代码通常利用了已知的漏洞，因此你应当确保你在运行最新进行安全更新过的的Microsoft和第三方软件。Microsoft安全更新可以通过http://update.microsoft.com了解。http://www.microsoft.com/protect/computer/updates/OS.aspx有更多信息。

• 禁用不必要的ActiveX控件和IE加载项。

你应当禁用所有不必要的ActiveX控件和IE加载项。根据KB883256（http://support.microsoft.com/kb/883256）的方法在Windows XP Service Pack2或者更新版本中来实施本步骤：

1. 打开IE。
2. 在"工具"菜单点击管理加载项。
3. 点击加载项的名称。
4. 使用如下的方法：
   • 点击更新ActiveX来使用最新的版本替换该控件。这个方法并非对所有的加载项都可用。
   • 点击"启用"，而后点击"确定"，来启用加载项。
   • 点击"禁用"，而后点击"确定"，来禁用加载项。

你可能需要重启IE来确保在启用/禁用插件的操作成功。针对更糟的操作系统，根据KB154036（http://support.microsoft.com/kb/154036）的说明进行操作。

• 减少你所使用的第三方浏览器的受攻击风险的步骤。

如果你使用了IE之外的浏览器，那么你应当确保你安装的是最新的安全更新版本，同时你应当禁用了不必要的扩展和加载项。流行浏览器的信息可以在如下链接找到： 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/

• 更新反恶意程序软件

用户应当确保已经安装了杀毒软件和反间谍软件，并且保持他们的更新。你可以在http://www.microsoft.com/protect/computer/antivirus/OS.aspx和http://www.microsoft.com/protect/computer/antispyware/OS.aspx找到更多信息。你可以在 http://onecare.live.com/standard/en-us/install/install.htm得到一份90天使用的Windows Live OneCare杀毒/反间谍软件。