Security Research & Defense

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

July, 2012

  • Technical Analysis of the Top BlueHat Prize Submissions

    Now that we have announced the winners of the first BlueHat Prize competition, we wanted to provide some technical details on the top entries and explain how we evaluated their submissions. Speaking on behalf of the judges, it was great to see people thinking creatively about defensive solutions to important security problems!

    To set the stage for this post, we thought it would be helpful to quickly remind everyone of the problem that entrants needed to solve.  Specifically, entrants were required to design a novel runtime mitigation technology that would be capable of preventing the exploitation of memory safety vulnerabilities (such as buffer overruns).  The BlueHat Prize judging panel was then responsible for evaluating each submission as described according to the following criteria (as described in the contest rules):

    1. Practical and functional (30%)
      1. Can the solution be deployed at large scale?
      2. Does the prototype have low overhead?
      3. Is the prototype free of any application compatibility or usability regressions?
      4. Does the prototype function as intended?
    2. Robustness (30%)
      1. How easy would it be to bypass the proposed solution?
    3. Impact (40%)
      1. Does the solution strongly address key open problems or significantly refine an existing approach?
      2. Would the solution strongly mitigate exploits above and beyond Microsoft’s current arsenal?

    The judges for this contest consisted of representatives from Windows, Microsoft Research, and Microsoft’s Security Engineering Center (MSEC).  Of the 20 entries received, the top three submissions described different methods of mitigating return oriented programming (ROP).  Let’s dive into the technical details of these submissions.

    3rd place: mitigating ROP via return site whitelisting (/ROP)

    This entry, as submitted by Jared DeMott, described a method of imposing a whitelist on the set of locations that a return instruction can transfer control to.  More specifically, this solution calls for the introduction of a new compiler flag (“/ROP”) that would add metadata to an executable that describes the set of valid return sites in the image.  When the image is loaded at runtime by the operating system, the image’s list is added to a master list.  As the program executes, each invocation of a return instruction triggers an exception that causes the operating system to validate the target return site against the master list of return sites.  If the target return site is in the list, the program continues executing as normal; otherwise, the program is safely terminated. 

    To prototype this idea, the submission included a Pin tool that simulated the hardware support that would be needed to augment the behavior of the return instruction.  In addition, the prototype also included an IDA Python script to identify the set of valid return sites for an image.  This script generated the input that was needed for the Pin tool to check whether a return target was to be considered valid.

    Practical and functional

    Although this solution is functional, it is not seen as practical for large scale deployment as described. The primary reason for this is due to the execution cost associated with implementing this check. This cost is expected to be significant because the design calls for a software interrupt to be raised for each return instruction.  A second issue with this design is related to the data structure that is used to store the address of valid return sites.  In particular, the prototype of this design uses the STL map container which, although it enables O(1) lookups, is not optimally compact and can therefore lead to considerable memory overhead depending on the number valid return sites that exist in modules loaded by a process.  The design for this solution did not propose optimizations that could help to address both of these concerns.

    Robustness

    This solution is seen as a partial mitigation for ROP.  It could be bypassed by leveraging gadgets that are in the set of valid return sites or by using a gadget chaining method that does not involve a return instruction.  The feasibility of finding a sufficient set of gadgets in the set of valid return sites is expected to be uncommon.  The use of alternative chaining methods is feasible, although the complexity associated with doing so exceeds the current state of the art in ROP-based exploits seen in the wild.

    Impact

    This solution would have a moderate impact if were possible to deploy it at large scale.  The fact that this solution does not fully address all forms of code re-use limits the expected long term impact of the design as described.

    2nd place: mitigating ROP by placing new checks in critical functions (ROPGuard)

    This entry, as submitted by Ivan Fractic, described a method of mitigating ROP by introducing additional checks that are performed when critical functions, such as VirtualProtect, are called.  These checks are designed to detect conditions that are indicative of ROP occurring, such as an API being called out of context.  The checks proposed by this submission included:

    1. Verifying that the stack pointer is within the bounds of the thread’s stack.
    2. Verifying that that the return address of a critical function is executable and preceded by a call.
    3. Verifying that all stack frames are valid and satisfy criteria 1 and 2.
    4. Simulate execution forward from a critical function’s return address to verify that subsequent returns satisfy criteria #2.
    5. Function specific contract changes (e.g. prevent reprotecting of the stack as executable).

    Although adding checks to critical functions to detect ROP is not a new idea, and indeed some of the checks above have already been described in previous research, this submission included novel elements that we had not seen discussed before.  We actually received a number of submissions which proposed adding new checks to critical functions, but the other submissions had a subset of the checks proposed by this submission or by previous research.

    Practical and functional

    The checks proposed by this submission are considered to be both practical and functional.  By limiting these checks to certain critical functions, the performance impact is minimized.  Some of the proposed checks would be incompatible with certain applications.  Specifically, criteria #1 is known to be incompatible with some legacy applications that do custom stack switching and #3 is incompatible with x86 programs that enable frame pointer omission.

    Robustness

    ROP mitigations that rely on introducing new checks to critical functions are not considered to be robust over the long term.  The checks proposed by this submission and in previous research are capable of mitigating ROP payloads that are used today, but it is expected that attackers would be able to adapt to these checks at relatively low cost.  For example, a fundamental problem with this type of approach is that an attacker could attempt to call a lower level API that has not been instrumented by the checks.  A variant of this bypass is to transfer control after the instruction block that performs the checks (depending on how the checks have been added).

    Impact

    This solution would have a moderate impact if implemented correctly and deployed at large scale. The fact that this solution does not fundamentally address ROP limits the expected long term impact of the design as described.

    1st place: mitigating ROP via Last Branch Recording (kBouncer)

    This entry, as submitted by Vasilis Pappas, described a novel method of using the Last Branch Recording (LBR) feature of Intel processors to detect ROP when system calls are made.  This method relies on a kernel component that allows branch recording to be enabled for return control transfers.  When a system call occurs, the kernel component then enumerates each entry in the LBR stack and verifies that the destination address is preceded by a call instruction.  The prototype for this solution relied on evaluating the contents of the LBR when certain critical APIs were called rather than at the system call layer.  The cited reason for this was due to Windows kernel restrictions around interposing the system call layer in kernel mode.

    Practical and functional

    This solution is considered to be both practical and functional.  The use of supported hardware features to track the destination address of return control transfers helps to drive down the performance cost and complexity of implementing this solution.   There should also be minimal application compatibility impact through this approach.

    Robustness

    This solution is not expected to be robust over the long term, although it should be robust against ROP payloads that are used today.  There are multiple reasons why it is not expected to be robust.  First and foremost, the Last Branch Recording feature of Intel processors has a limited stack for storing control transfers (16 entries on Nahelam and up).  If an attacker can ensure that a sufficient number of valid returns happen between the control transfer that eventually leads to an API call and the point where the LBR stack is checked, then this solution can be bypassed.  It is believed that attackers would be able to accomplish this in most cases with a low to moderate development cost.  While it may be possible to use the Branch Trace Store (BTS) feature to help address this problem, the performance cost may become unacceptable.  The other reasons for this solution not being robust are shared with the two previous submissions: specifically, imposing these checks on specific APIs (as in the prototype) may be prone to bypasses and imposing checks only on returns does not mitigate all methods of chaining gadgets.

    Impact

    This solution would have a moderate impact if implemented correctly and deployed at large scale. The fact that this solution does not fundamentally address ROP limits the expected long term impact of the design as described.

    Closing thoughts

    The winning submissions illustrate some of the creative thinking that has gone into developing defensive methods of making it more difficult and costly to exploit memory safety vulnerabilities.  As we look toward the future, we will investigate whether there are elements of these methods that may make sense to integrate into EMET or a future version of our products.  We have already taken steps in this direction by integrating features from the ROPGuard submission and related prior research into the Technical Preview of EMET 3.5.

    As the judging criteria makes it clear, it can be quite challenging to turn an interesting defensive security idea into something that can be shipped in a retail product at large scale.  Nevertheless, ideas that may seem impractical on the surface can eventually be turned into an innovative and practical solution – it just takes some additional focused thinking.

     

    Matt Miller

    MSEC Security Science

  • Announcing the availability of ModSecurity extension for IIS

    Vulnerabilities in on-line services, like cross-site scripting, cross-site request forgery, or even information disclosure, are important areas of focus for the Microsoft Security Response Center (MSRC). Over the last few years Microsoft has developed a number of tools capable of mitigating selected web specific vulnerabilities (for example, UrlScan). To help on this front we have participated in a community effort to bring the popular open source module ModSecurity to the IIS platform. Yesterday at Black Hat Las Vegas, we have announced the availability of an RC version and we expect that stable release will be available soon.

    Installation

    Although the source code of ModSecurity’s IIS components is fully published and the binary building process is publicly described (see mod_security/iis/winbuild/howto.txt in SourceForge repository), it is highly not recommended to self-build the module for non-research or non-development purpose.

    A standard MSI installer of ModSecurity for IIS 7 and later versions is available from SourceForge files repository of ModSecurity project and in the future designated maintainers will be keeping it updated with latest patches and minor versions of the module.

    Configuration

    The IIS installer does not interfere with currently running web applications. This means that the installation process must be followed by an application pool restart or recycling in order to load the new module into the application pool process. For the RC version of the module the restart/recycle step is also highly recommended each time a ModSecurity configuration file has been changed:

    After successful load of the module into the application pool process a series of informational events is recorded in the application event log:

    Runtime messages and notifications generated during the operational phase, both coming from the user-defined rules and system specific events or errors, are sent to the same application event log repository.

    To apply a ModSecurity configuration file to a web application or a path, one has to use IIS configuration schema extension, like in the example below:

    <?xml version="1.0" encoding="UTF-8"?>

    <configuration>

        <system.webServer>

            <ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\test.conf" />

        </system.webServer>

    </configuration>

    The c:\inetpub\wwwroot\test.conf config file is a regular ModSecurity configuration containing the same directives as used on the Apache web server.

     

    Examples of Protection

     

    The most common application of ModSecurity is a protection layer called “virtual patching” (see Resources section, [5]). Using two recent vulnerabilities as an example we would like to show how this layer can be specified in an environment with IIS server running with ModSecurity.


    CVE-2011-3414

    In December 2011 a vulnerability was addressed in ASP.NET that allowed attackers to cause excessive processor load on most ASP.NET web applications. The hash collision issue required attacker to send a large (typically 1MB or 4MB) POST request to the server, with tens of thousands of arguments with specially crafted names. There are at least four ways to mitigate this kind of attack:

     

    • Restrict the request body size.
    • Restrict the number of arguments.
    • Identify repetitive payloads.
    • Check arguments names against PoC data.


    The approach of checking for the presence of repetitive payload is the most sophisticated one and it can be implemented in ModSecurity using the following chain of rules:

     

    SecRule &ARGS "@ge 1000" "chain,id:1234,phase:2,t:none,deny,msg:'Possible Hash DoS Attack Identified.',tag:'http://blogs.technet.com/b/srd/archive/2011/12/27/more‑information‑about‑the‑december‑2011‑asp‑net‑vulnerability.aspx?Redirected=true'"

     

      SecRule REQUEST_BODY "^\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&" "chain,capture"

     

        SecRule TX:1 "@streq %{tx.2}" "chain,setvar:tx.hash_dos_match=+1"

     

        SecRule TX:2 "@streq %{tx.3}" "chain,setvar:tx.hash_dos_match=+1"

     

        SecRule TX:3 "@streq %{tx.4}" "chain,setvar:tx.hash_dos_match=+1"

     

          SecRule TX:HASH_DOS_MATCH "@eq 3"

     

    When this rule is loaded into an IIS server configuration and the attack is launched on the protected path, the Windows application event log will record an access denied message from ModSecurity:

     

    At the same time the attacker will see HTTP response 403, stopping the attack before it reaches ASP.NET vulnerable component.

    CVE-2012-1859

    In July 2012, Microsoft patched a classic case of reflected cross-site scripting vulnerability in Microsoft SharePoint 2010. For the attacks to exploit the vulnerability it was enough to trick user into clicking on a malicious URL, like the one below:

     

    http://sharepoint/_layouts/scriptresx.ashx?culture=en‑us&name=SP.JSGrid.Res&rev=laygpE0lqaosnkB4iqx6mA%3D%3D&sections=All<script>alert(‘Hacked!!!’)</script>z

     

    The script injected by the attacker could gain access to the entire data set available to the victim through the hacked SharePoint server.

     

    One possible way to block this attack is a whitelist approach: let the URL with sections argument that does contain only valid characters pass through, while block all other URLs. Below is a ModSecurity rule implementing this approach for alphanumeric characters:

     

    SecRule REQUEST_FILENAME "@contains /_layouts/scriptresx.ashx" "chain,phase:1,block,msg:'SharePoint Sections Param Violation - Illegal Chars"

     

      SecRule ARGS:sections "!@rx ^\w+$"

     

    The rule included through ModSecurity config file into the SharePoint web.config file, generates the following event when any invalid character (indicating possible attack attempt) is discovered in the corresponding SharePoint URL:

     

    Feedback

     

    We encourage you to download and try out the tool.  If you have any feedback on your experiences with the tool, you can reach us at switech@microsoft.com.

     

    Acknowledgments

     

    The following people have contributed to the multi-platform effort of ModSecurity:

     

    •  Microsoft – ModSecurity Port for IIS
      •    Greg Wroblewski – Senior Security Developer
      •    Suha Can – Security Researcher / Developer
    •  Trustwave - ModSecurity
      •    Ziv Mador – Director of Security Research
      •    Ryan Barnett – Security Researcher Lead
      •    Breno Pinto – ModSecurity Researcher & Developer
    •  Open community  - Security Port for Nginx
      •    Alan Silva  - Software Engineer at Locaweb

     

    We would like to thank Wade Hilmo and Nazim Lala, members of the Microsoft’s IIS team, for their support and help in solving many technical problems.  Finally, thanks to Russ McRee for the behind-the-scenes collaboration and encouragement which kicked off this effort.

    Resources

     

    [1]    ModSecurity home page: http://www.modsecurity.org/

    [2]    OWASP Core Rule Set for ModSecurity: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

    [3]    http://blog.modsecurity.org/files/enough_with_default_allow_r1_draft.pdf

    [4]    http://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf

    [5]    https://www.blackhat.com/presentations/bh-dc-09/Barnett/BlackHat-DC-09-Barnett-WAF-Patching-Challenge-Whitepaper.pdf

    [6]    http://holisticinfosec.blogspot.com/2012/12/toolsmith-modsecurity-for-iis.html

    -          Greg Wroblewski, Microsoft Security Engineering Center

    -          Ryan Barnett, Trustwave

     

     

     

  • EMET 3.5 Tech Preview leverages security mitigations from the BlueHat Prize

    Last year at Black Hat Las Vegas, we announced the BlueHat Prize contest – a large cash prize awarded for defensive security research. One month ago, we announced the names of three finalists. On Thursday night shortly after 10 PM, at the Microsoft Researcher Appreciation Party, we will unveil which finalist won which prize – the grand prize of $200,000 USD, the second prize of $50,000 USD, and the third prize of an MSDN subscription, valued at $10,000 USD. We are excited to reveal this to the finalists and to the world live at the same time.

    Having said that, each of these winning submissions demonstrated creative ways that help increase the difficulty of exploiting memory safety style vulnerabilities, allowing for arbitrary code execution. We wanted to put these novel ideas to work right away to help protect customers. To that end, today we are announcing that a new version of EMET incorporates several ideas from one of the contest finalists and is available for immediate download: EMET 3.5 Tech Preview.

    In this blog post we are going to take a look at the new updates and mitigations that are implemented in EMET 3.5 Tech Preview. Please note this is a “tech preview” release intended to evaluate the application compatibility risk of several mitigation ideas in real-world scenarios. EMET 3.0 is ready for wide-spread enterprise adoption. EMET 3.5 Tech Preview is available to help us field test these new ideas in real-world environments.

    In this release, we implemented four ROP mitigations that we selected from the BlueHat Prize submissions.

    The new ROP mitigations

    We have implemented four new ROP mitigations in this tech preview version. Some of the mitigations we received in the BlueHat submission were not original (please see the following section) but can provide protection against many current exploits. The “Execution flow simulation mitigation” (described below) was the main novel contribution in this submission.

    Previous work on ROP mitigations

    Some of the mitigations we implemented have already been addressed by the security community. For example, Piotr Bania wrote a nice paper about ROP mitigations which can be found here: http://kryptoslogic.com/download/ROP_Whitepaper.pdf

    Mitigations description

    The ROP mitigations rely on the fact that at some point the ROP chain will need to call certain critical functions (VirtualAlloc, VirtualProtect, HeapCreate, LoadLibrary, etc…) before they transfer execution to the shellcode. EMET will filter all calls to those critical functions and perform the following checks:

    Caller checks mitigation

    EMET will make sure that when a critical function is reached, it is reached via a “call” instruction rather than a “ret” instruction. This is a very useful mitigation and breaks many ROP gadgets. This mitigation may be incompatible with some programs so use it with caution.

    Execution flow simulation mitigation

    This mitigation tries to detect ROP gadgets following a call to a critical function. It works by emulating a specified number of instructions at the return address of the caller of a critical function. The number of instructions to emulate can be configured manually by editing the desired application’s registry key and creating the “SimExecFlowCount” DWORD value as shown below:

    By default, 15 instructions are simulated. Like the “Caller checks”, this mitigation may not be compatible with all programs.

    Stack pivot mitigation

    This mitigation is very useful and is used to detect if the stack has been pivoted. It is compatible with most programs, so it is safe to enable it by default.

    Special function checks

    The special function checks mitigation is split into:

    • Load library checks
    • Memory protection checks

    The former validates calls to load library to see if it comes from a ROP gadget or shellcode, while the latter aims at preventing any attempts to change the protection of stack area for a given thread.

    Changes in the user interface

    Because the total number of mitigations in EMET grew and do not nicely fit in one screen anymore, we decided to group the mitigations into tabs. The screenshot below shows the new ROP mitigations:

    We also added a context menu item in the notifier tray icon that allows you to easily launch EMET graphical interface:

     

    Enabling the ROP mitigations

    The ROP mitigations are disabled by default, you have to explicitly enable them. It is possible to import a preconfigured set of applications from the “Application Configuration” dialog:

     

    Select File/Import and then navigate to “[EMET_Install_Folder]\Deployment\Protection Profiles” and choose “All.xml”. To enable certain ROP mitigations for all applications, just edit the “DefaultConfig/Mitigations” node and set the desired ROP mitigations to “true”:

    When a ROP attempt is detected, EMET will show you a tooltip and create an event log entry:

    Additionally, in this tech preview version, EMET will display a message box with more details about the detected ROP attempt and will present you with a choice to continue (ignoring the ROP checks) or terminate the process. We present the user with this dialog so that if a false positive was detected EMET won’t terminate your application immediately. The confirmation dialog looks like this:

    ROP mitigations in action

    We tested EMT 3.5 against a bunch of public ROP exploits. The following screenshot shows how EMET 3.5 TP mitigates against Metasploit’s ms12_037_same_id :

    Here we see how EMET blocks CVE-2010-0188 (LibTIFF):

    A Note about Application Compatibility

    Security mitigations carry an application compatibility risk with them. Some applications rely on precisely the behavior that the mitigations block. For this reason mitigations are typically turned off by default and require opt-in from a developer before they are enabled. While EMET allows users to override this, it is important to be aware of the risk. EMET is intended for tech savvy users such as IT professionals and security researchers who can troubleshoot issues that these mitigations may introduce. We also recommend testing your applications and use scenarios with these mitigations prior to deploying them on any production systems.

    Known limitations

    As stated above, as long as one of the critical functions is called then ROP checks will take place. It is possible for the attacker to circumvent this by not calling any of the hooked functions (for example directly calling into NTDLL and not kernel32) or just circumventing the hook. The following Phrack article presents many attack vectors that can be used to break those mitigations: http://www.phrack.org/issues.html?issue=62&id=5

    Feedback

    EMET 3.5 TP requires uninstalling previous versions of EMET first. Previously configured applications and rules will be retained and will work again after installing EMET 3.5 TP.

    We encourage you to download and try out this release. Any feedback or comments are welcome; you can reach us at switech@microsoft.com.

    Acknowledgements

    I would like to thank the MSRC engineering and the science team, in particular: Chengyun Chu, Suha Can, Elia Florio.

    Elias Bachaalany, MSRC Engineering

  • More information on Security Advisory 2737111

    Today we released Security Advisory 2737111 to describe the way in which vulnerabilities in Oracle’s Outside In technology impact the document preview functionality of Microsoft Exchange Server 2007 and 2010 and FAST Search Server 2010 for SharePoint. In this blog, we would like to discuss the following:

    • What is the Oracle Outside In technology?
    • Why are Microsoft Exchange and FAST Search Server affected by a vulnerability in Oracle’s product?
    • What are the mitigating factors that reduce the risk to customers?
    • What workaround options exist in absence of a security update?

    What is the Oracle Outside In technology?

    The Oracle Corporation provides a solution called Oracle Outside In to software developers (such as Microsoft) to access, transform, and control the contents of a number of file formats.  Microsoft Security Advisory 2737111 describes Microsoft's exposure to the vulnerabilities addressed by Oracle via their recent Critical Patch Update Advisory - July 2012 and recommends steps affected users may take to protect servers from these vulnerabilities until a comprehensive Microsoft security update is available.

    Why are Microsoft Exchange Server and FAST Search Server affected by a vulnerability in Oracle’s software?

    In Microsoft Exchange Server 2007 and Exchange Server 2010, Outlook Web App (OWA) users are provided with a feature called WebReady Document Viewing that allows users to view certain attachments as a web page instead of relying on local applications to open/view it. Oracle Outside In is used by the conversion process in the server backend to support the WebReady feature. Microsoft licenses this library from Oracle.

    In FAST Search Server 2010 for SharePoint, “Oracle Outside In” is used to index file content in a non-default scenario. Only SharePoint 2010 SP1 installations using FAST Search Server 2010 for Sharepoint can potentially be affected by this issue, as we will describe in the mitigating factors section below.

    What are the mitigating factors that reduce the risk to customers?

    In the Exchange Server 2007/2010 scenario, the conversion process that uses Oracle Outside In, TranscodingService.exe, runs as LocalService. The Local Service account is a built-in account that has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard the system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null or anonymous session without even machine credentials.

    In the FAST Search Server 2010 for SharePoint scenario, the functionality that uses Oracle Outside In, Advanced Filter Pack, is NOT enabled by default. SharePoint Server is only impacted if FAST Search Server 2010 for SharePoint is used.

    Moreover, the process in FAST Search Server 2010 for SharePoint that uses “Oracle Outside In”, is running with a restricted token similar to the Office 2010 Protected View sandbox, which further limits what the attacker may access even if the process is compromised.

    Last, the attacker needs to have the access to upload malicious documents into one of the data stores, such as the SharePoint server site, that will be indexed by FAST.

    What workaround options exist in absence of a security update?

    In the Exchange Server 2007/2010 scenario, we recommend disabling WebReady Document Viewing on the VDir of all CAS Servers. You can do so with a single PowerShell command, as described below:

    • Launch Exchange Management Shell as a user with Exchange Administrator privileges.
    • Issue the following Powershell Command:

      Get-OwaVirtualDirectory | where {$_.OwaVersion -eq 'Exchange2007' -or $_.OwaVersion -eq 'Exchange2010'} | Set-OwaVirtualDirectory -WebReadyDocumentViewingOnPublicComputersEnabled:$False -WebReadyDocumentViewingOnPrivateComputersEnabled:$False

      Note: On Exchange Server 2010, Server Management privileges are also required.

    This will immediately disable the ability to render via WebReady Document Viewing on all current and future OWA sessions. Users could still open and view attachments using the local application. Only the in-browser document preview functionality would be impacted.

    In the FAST Search Server 2010 scenario, we recommend disabling the Advanced Filter Pack if FAST Search is installed and Advanced Filter Pack is enabled. To do it, please follow the following steps described in http://technet.microsoft.com/en-us/library/ff383314.

    On the FAST Search Server 2010 for SharePoint administration server (or single server), follow these steps:

    • On the Start menu, click All Programs.
    • Click Microsoft FAST Search Server 2010 for SharePoint.
    • Right click Microsoft FAST Search Server 2010 for SharePoint shell and select Run as administrator.
    • At the command prompt, browse to installer\scripts under the installation folder.
    • Type the following command: .\AdvancedFilterPack.ps1 -disable

    Special thanks to Greg Lenti, Brent Alinger, Travis Rhodes, Anund Lie and David LeBlanc for the help with this issue.

    - Suha Can, Elia Florio, Chengyun Chu from MSRC Engineering

  • MSXML - 5 steps to stay protected

    Today Microsoft provided nine bulletin updates, as described in July’s Security Bulletin Summary. This post is going to focus on the first of the issues described in the above summary - Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution.

    Step 1 – Be informed

    MS12-043 describes the security update that resolves a publicly disclosed vulnerability in Microsoft XML Core Services. The vulnerability could allow remote code execution if a user views a specially crafted webpage using Internet Explorer.

    This security update is rated Critical for Microsoft XML Core Services 3.0, 4.0, and 6.0 on all supported editions of Windows; it is also rated Critical for Microsoft XML Core Services 5.0 for all supported editions of Microsoft Office 2003 and 2007. Office 2010 is not affected.

    For more detailed information about the vulnerability, the affected software and the mitigations and workarounds available, please refer to the security bulletin (http://technet.microsoft.com/en-us/security/bulletin/ms12-043)

    Step 2 – Install the Update

    As stated in our previous MSXML post, we are already aware of targeted attacks exploiting of this vulnerability in Windows via Internet Explorer. We recommend installing the update as soon as possible in order to address this issue for Microsoft XML Core Services 3.0, 4.0, and 6.0.

    If you have previously installed the Microsoft Fix it solution 50897, we recommend uninstalling it only after the update has been applied. To uninstall, please run Microsoft Fix it solution 50898.

    Step 3 – Install the Fix it for MSXML 5

    The security updates for Microsoft XML Core Services 5.0 are unavailable at this time. Microsoft will release the updates when testing is complete, in order to ensure a high degree of quality. In the meantime, customers running Microsoft Office 2003 or 2007 are encouraged to apply the automated Microsoft Fix it solution that blocks the attack vector for this vulnerability:

    ApplyUninstall

    The attacks Microsoft has seen do not target XML Core Services 5.0. In the default configurations of Internet Explorer 7, 8 and 9, an attack against XML Core Services 5.0 would require the user to manually enable the control by clicking the Allow button on the Internet Explorer gold bar:

    Step 4 – Use EMET

    We are recommending EMET as a potential mitigation for possible attacks attempting to exploit this vulnerability. The Enhanced Mitigation Experience Toolkit (EMET) is a utility that helps prevent vulnerabilities in software from successfully being exploited by applying the latest mitigations to applications configured in EMET.

    MS12-043 fully protects customers from attempts to exploit the issue in MSXML versions 3.0, 4.0 and 6.0; EMET provides an excellent mitigation against attempts to reach the vulnerability in MSXML 5.0.

    Step 5 – Browse safe

    Last but not least, following good browsing practices can help you stay safer online: http://www.microsoft.com/security/family-safety/online-safety-tips.aspx

     - Cristian Craioveanu, MSRC Engineering

  • Microsoft's continuing work on digital certificates

    Over the past several months, Microsoft has made changes both to our own internal PKI practices and to the Windows Update channel (client-side and server-side) PKI handling. You’ve likely already read about those changes on the MSRC blog, the Microsoft Update blog, and in the associated KB articles (949104, 2720211).

    We continued this evolution last month by announcing our intention to release a defense-in-depth measure that changes how Windows manages certificates that have RSA keys of less than 1024 bits in length. On systems where this hardening package is installed, those certificates using the RSA algorithm with key length less than 1024 bits will be treated as invalid, even if they are otherwise valid and signed by a trusted certificate authority. We will deploy this update via our usual update channels for all supported versions of Windows as a Critical non-security update. We encourage WSUS administrators to approve and deploy that update when we release it in August, to proactively harden your environment against brute force cryptographic attacks. All customers who have opted into Automatic Updates will get the update according to your Automatic Update settings. You can read more about this hardening at the PKI blog post originally published in June: http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx

    As a continuation of this effort, we reviewed a number of Microsoft digital certificates and found several which do not meet our standards for security practices. As an extra precautionary measure, we released Security Advisory 2728973 today to announce the availability of a Critical, non-security update that moves several of these certificates into the Untrusted Certificate Store. None of the certificates involved are known to have been breached, compromised, or otherwise misused. This is a pre-emptive cleanup to ensure a high bar for any certificates owned by Microsoft.

    Finally, we are making one further proactive change today that will help us respond more quickly to any digital certificate issues in the future. Last month, we announced the availability of a new automatic updater of untrusted certificates for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This new feature provides dynamic updates, allowing Windows clients to be updated with untrusted certificates once per day without requiring user interaction. You can read more about the feature in the PKI blog post previously mentioned and in KB 2677070. This new feature had been available as an optional update available through Windows Update. We are changing the Windows Update metadata today to make this automatic updater available as a Critical non-security update, enabling it to be automatically deployed to all customers who have opted-in to Automatic Updates (according to your AU settings) and to appear as a Critical update in WSUS dashboards. This automatic updater is the fastest way for customers on Windows Vista and later platforms to get untrusted digital certificate updates such as the one included in Security Advisory 2728973 mentioned above. Customers on Windows Vista and later platforms who have not yet installed this new feature can deploy untrusted certificate updates through WSUS or from the Download Center. Windows XP and Windows Server 2003 computers will continue to receive Untrusted Certificate Store updates via Windows Update – although Security Advisory 2728973 has an installation pre-requisite to which customers using Windows XP and Windows Server 2003 should pay special attention (described in the FAQ).

    We will continue to monitor the threat landscape and take action where we believe we can strengthen the security of Microsoft’s handling or use of public key-based encryption technologies.

    - Gerardo Di Giacomo and Jonathan Ness, MSRC

  • Assessing risk for the July 2012 security updates

    Today we released nine security bulletins addressing 16 CVE’s. Three of the bulletins have a maximum severity rating of Critical and the other six have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Likely first 30 days impact Platform mitigations and key notes
    MS12-043

    (MSXML)

    Victim browses to a malicious webpage. Critical 1 We are aware of active attacks leveraging CVE-2012-1889, the single CVE addressed with this bulletin.

    All active attacks we have seen leveraged MSXML version 3. MSXML versions 3, 4, and 6 are addressed with this update. MSXML 5 will be addressed in a future security update.

    Read this SRD blog post for more information about the mitigating factors making the MSXML 5 less severe than other versions of the product.

    MS12-045

    (MDAC)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days.
    MS12-044

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Both vulnerabilities affect only Internet Explorer version 9. Versions 6, 7, and 8 are not affected.
    MS12-046

    (DLL Preloading in Visual Basic for Applications [VBA])

    Victim navigates to a malicious WebDAV or SMB share and double-clicks on an Office document. Malicious DLL in same folder loads within the Office application, running arbitrary attacker code. Important 1 We are aware of limited, targeted attacks leveraging CVE-2012-1854, the single CVE addressed with this bulletin.

    Affects only a subset of locales where IMESHARE.DLL is not present by default, primarily far eastern locales.  Does not, for example, affects English locale installations by default.

    MS12-048

    (Windows Shell)

    Victim navigates to a malicious WebDAV or SMB share and double-clicks on a file in a malicious directory. Important 1 Likely to see reliable exploits developed within next 30 days.
    MS12-047

    (Windows drivers [win32k.sys])

    Attacker running code on a machine already elevates from low-privileged account to SYSTEM. Important 1 Likely to see an exploit released granting a local attacker SYSTEM level access.
    MS12-050

    (SharePoint)

    Attacker sends victim a link exploiting a Cross-Site Scripting (XSS) vulnerability on a SharePoint server for which they have access rights. When the victim clicks the link, an automatic action is taken on their behalf on the SharePoint server that they otherwise might not have wanted to execute. Important 1 Likely to see a XSS exploit developed in next 30 days (no exploit here for code execution on the SharePoint server itself). The IE XSS Filter (on by default on IE8 and IE9) blocks attempts to exploit these vulnerabilities.
    MS12-049

    (SSL / TLS)

    Victim browses to a trusted website via HTTPS. A malicious attacker positioned on the network as a man-in-the-middle under certain circumstances can potentially decrypt the encrypted data. Important 3 A variant of this issue that does not affect Windows has been discussed publicly. We have seen proof-of-concept code attempting to exploit the similar issue. However, we believe reliable exploitation of this issue on Windows is unlikely due to the nature of the vulnerability.
    MS12-051

    (Mac Office installer)

    Victim who has installed Office for Mac 2011 on a multi-user Mac system may inadvertently launch malicious executable placed by a malicious user of the same system due to ACL changes made by the Mac Office installer. Important 1 Likely to see reliable exploits developed within next 30 days. Single user Mac installations, or Mac installations where no malicious users are able to replace files, are not vulnerable.

    Today we’re releasing Security Advisory 2719662, which allows system administrators to disable the Windows Sidebar and Gadgets on supported versions of Windows Vista and Windows 7 with one Fix it click. And we are releasing Security Advisory 2728973 announcing the availability of an update that moves additional certificates into the Untrusted Certificate Store. This SRD blog post provides additional information about the digital certificates advisory.

    - Jonathan Ness, MSRC Engineering