Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

May, 2008

  • MS08-026: How to prevent Word from loading RTF files

    This month we released an update for Microsoft Word that fixed issues relating to loading RTF files (CVE-2008-1091) and HTML files (CVE-2008-1434).  Office applications like Microsoft Word can load a large variety of different file formats, and some people may want to reduce their attack surface by disabling the formats they don’t typically use.  As of May 2007, Office 2003 and 2007 have had a feature in place called File Block which allows you to do exactly that via the registry. 

    It’s important to note that the file extension doesn’t tell you what format a file is.  For example, you can rename an .RTF or .HTM file to .DOC, and Microsoft Word will load it.  File Block doesn’t key off the file extensions; these format “kill switches” are actually checked in each of the file format parsers, so the restriction can’t be bypassed by simply changing a file’s extension.  That means that simply disabling the file association between .RTF and Microsoft Word will not prevent Word from loading potentially malicious RTF files, since they can end with a .DOC extension.

    Microsoft Word, Excel, and PowerPoint can each load a number of different formats which you can individually disable with File Block.  You can also specify a trusted (Office 2007) or exempt (Office 2003) folder, so that files loaded from that location are always allowed through. 

    Here are some links that explain how to enable File Block and also how to configure trusted/exempt folders:

    For general information about File Block and MOICE see this advisory: http://www.microsoft.com/technet/security/advisory/937696.mspx

    We talk about File Block and MOICE with customers as often as we can.  Our team has presented this information at FIRST 2007, BlueHat 2007, CanSecWest 2008, and on several customer visits.  We are hoping the Black Hat selection committee will accept our talk for the 2008 Vegas conference.  Let us know (switech@microsoft.com) if you have questions about File Block or MOICE, and we can either answer them or put you in touch with someone who will have the answer.

    - Security Vulnerability Research & Defense Bloggers

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • 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:

    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. 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 2nd 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 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.

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

    - Security Vulnerability Research & Defense Bloggers

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

    Blog Update - June 2, 2008: Updated above url to "http://contoso.com..."