Security Research & Defense

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

April, 2014

  • Continuing with Our Community Driven, Customer Focused Approach for EMET

    The Enhanced Mitigation Experience Toolkit, best known as EMET, helps raise the bar against attackers gaining access to computer systems. Since the first release of EMET in 2009, our customers and the security community have adopted EMET and provided us with valuable feedback. Feedback both in forums and through Microsoft Premier Support Services, which provides enterprise support for EMET, has helped shape the new EMET capabilities to further expand the range of scenarios it addresses.

    Today, we will be talking about how we are taking our community driven and customer focused approach even further. We will cover both the present version (4.1) as well as the future versions (5.0 Technical Preview and beyond) in detail next.

    What you are about to read is the outcome of our work over the past couple of months listening to customer and community feedback. Keep in mind that we are always working on new things, so… stay tuned! :) As always, please let us know what you think.

    - The EMET Team

    EMET 5.0 Technical Preview available on Microsoft Connect

    The release of EMET 5.0 Technical Preview in late February had a tremendous response from customers and the industry. We have received a lot of feedback on the new features and how they can be further improved. We believe EMET is and should continue to be customer-driven, where the feedback we receive is an integral part of our development process. In order to facilitate and streamline the communication between you (our beloved customers) and us (the EMET team), we have decided to create a project on Microsoft Connect for EMET 5.0 Technical Preview. Simply access the Microsoft Connect tool to download packages – which will be released periodically and frequently – and have a taste of what is coming up for EMET 5.0. What is great about this new tool is that, you will able to provide direct feedback, respond to surveys, and find all the new additions.

    The first download package for EMET 5.0 Technical Preview is already available, and it includes fixes for many items reported to us. Please subscribe to the Microsoft Connect for EMET 5.0 Technical Preview (you will need a Microsoft Account for that), download the installation package and continue to send your great ideas to us.

    EMET 4.1 Update 1

    Today, we are releasing EMET 4.1 Update 1, which contains improvements and bug-fixes. More details on the list of the introduced improvements are available at this KB article. These improvements are the outcome of the feedback you have given us and the forward thinking work we continue to do. We recommend all EMET 4.1 customers download this new version and install it, since the benefits of all these improvements are noticeable. The upgrade experience is seamless, as all the current settings can be kept as-is by choosing “Keep Existing Settings” option during the install process. We also recommend all EMET 3.0 and 4.0 customers to upgrade to EMET 4.1 Update 1 (remember EMET 3.0 will go out of support next June!).

    Certificate Trust default rules update

    With EMET 4.0, we introduced the Certificate Trust, which is a feature that detects Man in the Middle attacks that leverage maliciously-issued SSL/TLS certificates. The feature works through a configurable certificate-pinning mechanism, which binds the certificate for a specified website to a trusted Root Certificate Authority (Root CA). This feature comes pre-configured with a set of rules related to authentication portals for Microsoft services and other third-party services. These default rules used in Certificate Trust don’t require frequent updates. It can happen, however, that an organization decides to renew its SSL/TLS certificate, for different reasons (e.g. natural aging of the certificate, change in their PKI infrastructure, response to a security incident, etc.). When a change like this occurs, the renewed SSL/TLS certificate may be issued under a different Root CA not included in the default Certificate Trust configuration, resulting in EMET detecting the new certificate as malicious.

    Since several SSL/TLS certificates for many popular third-party websites were recently updated, we are releasing an easy to install Fix it solution that will update the default Certificate Trust rules, while maintaining the ones that you have manually added. The Fix it can be either installed on a standalone machine by just double-clicking it, or it can be silently deployed throughout a network with your favorite deployment mechanism. If you have just downloaded and installed EMET 4.1 Update 1 you don’t need to apply this Fix it solution as the new rules are already included. You can use the link below to download this solution:

    Microsoft Fix it 51012

    Fix this problem
    Microsoft Fix it 51012

  • Protection strategies for the Security Advisory 2963983 IE 0day

    We’ve received a number of customer inquiries about the workaround steps documented in Security Advisory 2963983 published on Saturday evening. We hope this blog post answers those questions.

    Steps you can take to stay safe

    The security advisory lists several options customers can take to stay safe. Those options are (in summary):

      • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
      • Block access to VGX.DLL
      • Enable Enhanced Protected Mode
      • Use built-in Internet Explorer configuration options to disable active scripting

    We’ll address the questions we have heard from customers in relation to each of those options.

    Update on Enhanced Mitigation Experience Toolkit (EMET) protections

    The original security advisory and the SRD blog post from this past week both listed EMET 4.1 as effective in helping to block attacks. In our deeper analysis of the two exploit samples we have, we found that EMET 4.0 is also effective in helping to block attacks. The advisory and blog have both been updated to point out that both EMET 4.0 and EMET 4.1 are effective. Our technical preview of EMET version 5.0 also is effective in this regard; however, we do not recommend a technical preview for production deployment. Several customers asked which specific EMET mitigations were effective in helping to block attacks. We’ve prepared the following table to answer those questions:

    EMET 4.0 / EMET 4.1 EMET 5 Tech Preview
    Heapspray Protection Effective Effective
    StackPivot ROP Mitigation Effective with Deep Hooks enabled Effective
    Caller ROP Mitigation Effective with Deep Hooks enabled Effective
    MemProt ROP Mitigation Effective with Deep Hooks enabled Effective
    EAF+ Not present. EMET 4.x EAF does not block this attack. Effective
    Attack Surface Reduction Not present Effective because it blocks VGX.DLL and FLASH.ocx in Internet Zone

    As you can see, three of the four EMET 4.x mitigations capable of blocking this attack required the Deep Hooks feature to be enabled. The attackers in this case leveraged ZwProtectVirtualMemory which is not protected unless Deep Hooks is enabled. Deep Hooks is not enabled in the default configuration for EMET 4.0 or EMET 4.1. The default EMET 4.x install was effective in helping to block attacks due to the Heapspray mitigation alone; however, the ROP mitigations are more robust and less likely to be bypassed than the Heapspray mitigation so we recommend enabling Deep Hooks to get the full protection of the ROP mitigations.

    We have a planned update for EMET 4.1 scheduled for release on the Microsoft Download Center today. EMET 4.1 Update 1 was primarily released to address minor bug fixes. However, the update also will be enabling Deep Hooks for EMET 4.1 by default. We will post an additional SRD blog post when the EMET 4.1 Update 1 bits are live with a link to the KB describing the new release.

    Clarifying the VGX.DLL workaround

    The exploits we have seen have relied on Vector Markup Language (VML) to trigger the use-after-free vulnerability. As we analyzed different ways to trigger this vulnerability, we concluded that additional attacker research would be required to develop an exploit that did not rely on the presence of VML. Therefore, we recommended in the original security advisory that customers disable VGX.dll, the library that provides VML functionality. Customers can choose to either ACL the file or unregister the DLL. Unregistering the DLL can be accomplished with a single command line, silently, with no user interaction, and may be scripted to run via Microsoft System Center Configuration Manager or other infrastructure management solutions. VML is not natively supported by most web browsers today, so this remediation option may have the least impact on enterprise web app compatibility.

    However, we’d like to clarify that VGX.DLL does not contain the vulnerable code leveraged in this exploit. Disabling VGX.DLL is an exploit-specific workaround that provides an immediate, effective workaround to help block known attacks.

    Clarifying the IE Enhanced Protected Mode workaround

    We also received questions about the Internet Explorer Enhanced Protected Mode workaround. Enhanced Protected Mode will help protect 64-bit Internet Explorer users from this attack. There is a difference between Internet Explorer 10 and Internet Explorer 11 that led to some confusion. Internet Explorer 10 has one setting to enable and Internet Explorer 11 has two settings to enable. The 64-bit aspect of Internet Explorer is a key element of this workaround as the heap spray attack is not effective in 64-bit address space, leading to a failed exploit. Enhanced Protected Mode alone on 32-bit Internet Explorer 11 is not effective in blocking the attack. The screenshots below illustrate the Internet Explorer 10 versus Internet Explorer 11 “checkbox” differences:

    IE10 64bit EPM (one setting to mitigate) IE11 64bit EPM (two settings to mitigate)

    Choosing the best workaround for your environment

    The security advisory provides several different recommended workarounds because each customer environment is different and there might be a different “best” workaround for different customers. Each workaround has different pros and cons, described below.

    • Option 1: Deploy the Enhanced Mitigation Experience Toolkit
      • Pro: As described above, helps block exploits leveraging this vulnerability by adding several different hardening mechanisms to Windows.
      • Pro: Even after the eventual security update is applied, continues providing protection against other potential security vulnerabilities in Microsoft’s and third party products.
      • Con: Microsoft recommends testing before deploying widely across enterprise network as previous versions of EMET have introduced application compatibility issues.
    • Option 2: Block access to VGX.dll
      • Pro: Very simple workaround. Easy and quick to deploy across enterprise network.
      • Con: May not protect against future or new exploits that may emerge to exploit this vulnerability.
    • Option 3: Enable Enhanced Protected Mode on 64-bit Internet Explorer
      • Pro: Helps block exploits leveraging this vulnerability and potentially other vulnerabilities that may be discovered in the future.
      • Con: Requires 64-bit Windows and requires running 64-bit version of Internet Explorer.

    In general, for customers that already have EMET 4.x deployed, enabling Deep Hooks is likely to be the best workaround option. For customers who have not yet deployed EMET 4.x, the priority should be on immediate, quick protection which is likely to be blocking access to VGX.dll. Deploying EMET is the best long-term protection but doing so without first testing in your environment is unlikely to be the best option. As always, we recommend staying up-to-date with the latest version of Internet Explorer for improved security features such as Enhanced Protected Mode, better backward compatibility through Enterprise Mode, increased performance, and support for the modern web standards that run today’s websites and services.

    Conclusion

    We hope that this blog post helps guide you in choosing the best mitigation strategy for your environment. The Internet Explorer team is hard at work preparing a security update that will be released as soon as it is ready for broad deployment. Stay tuned to the Microsoft Security Response Center (MSRC) blog [link] for any news about the availability of an update.

    - Elia Florio and Jonathan Ness, MSRC Engineering

  • More Details about Security Advisory 2963983 IE 0day

    Today we released Security Advisory 2963983 regarding a potential vulnerability in Internet Explorer reported by FireEye and currently under investigation.

    We are working closely with FireEye to investigate this report of a vulnerability which was found used in very limited targeted attack:

    -          the vulnerability is a “use-after-free” memory corruption and the exploit observed seems to target IE9, IE10 and IE11;

    -          while the vulnerability affects Internet Explorer, the exploit relies deeply on two other components to successfully trigger code execution and in particular it requires presence VML and Flash components;

    Our partner FireEye posted an analysis with some details and confirmed that the exploit wasn’t able to run successfully when EMET protection is added for Internet Explorer. The following EMET configuration can help to mitigate this specific exploit seen in the wild:

    -          EMET 4.0 / 4.1: all mitigations enabled, deephooks/antidetour enabled

    -          EMET 5.0TP: all mitigations enabled (including ASR/EAF+), deephooks/antidetour enabled 

    Also, given the current details shared by FireEye, we believe that the exploit can be also mitigated by:

    -          Disable VML in IE.

    -          Run Internet Explorer in “Enhanced Protected Mode” configuration and 64-bit process mode, which is available for IE10 and IE11 in the Internet Options settings:

    Cristian Craioveanu, Elia Florio and Chengyun Chu, MSRC Engineering

     

  • MS14-019 – Fixing a binary hijacking via .cmd or .bat file

    Command (.cmd) and batch (.bat) files can be directly provided as input to the CreateProcess as if it is an executable. CreateProcess uses the cmd.exe automatically to run the input .cmd or .bat.

     

    Today, with the bulletin MS14-019 we are fixing a vulnerability, where in particular scenario it is possible to hijack the cmd.exe with a copy present in the attacker controlled current working directory (CWD) of an affected application.

     

    The typical attack vector for this vulnerability is same as the DLL hijacking, i.e., via opening an application specific file in a WebDav/SMB share invoking the targeted application automatically because of file association. The targeted application will be vulnerable only if they ever do CreateProcess on .cmd or .bat file irrespective of where the file is located. That means attacker need not control the .cmd or .bat file. Another important thing for exploiting this vulnerability, is that the application should set the directory from where the associated file was opened as its CWD.

     

    As such we are not aware of any application that is affected by this vulnerability. But we understand the security issue this vulnerability can pose to some of the applications, so we are addressing this as an important severity bulletin.

     

    The way we are fixing this issue is to always invoke the system version of the cmd.exe for the input .cmd or .bat file during process creation. This fix could affect applications which does CreateProcess on .bat or .cmd file directly and depend on a different version of the cmd.exe other than the one present in Sytem directory by copying them in either application directory or CWD. Such applications should pass fully qualified path to the version of cmd.exe as input while performing CreateProcess, and pass .cmd or .bat as input parameters.

     

    Applications passing just cmd.exe to the CreateProcess to run the .cmd or .bat as input could also be vulnerable for similar binary hijacking. This bulletin is not to address such vulnerable usage since it is application specific problem as they are not passing fully qualified system path to cmd.exe. Such application should fixed to pass fully qualified cmd.exe path or just passing .cmd or .bat file as input.

     

    - Swamy Shivaganga Nagaraju, MSRC engineering team

  • Assessing risk for the April 2014 security updates

    Today we released four security bulletins addressing 11 unique CVE’s.  Two bulletins have a maximum severity rating of Critical while the other two 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 exploitability Likely first 30 days impact Platform mitigations and key notes

    MS14-017

    (Word)

    Victim opens a malicious RTF or DOC/DOCX file. Critical 1 Likely to continue to see RTF and DOC based exploits for CVE-2014-1761. Addresses vulnerability described by Security Advisory 2953095, an issue under targeted attack.

    MS14-018

    (Internet Explorer)

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

    MS14-020

    (Publisher)

    Victim opens malicious Publisher (.PUB) file. Important 1 While we may see reliable exploits developed within the next 30 days, unlikely to see widespread exploitation due to limited deployment of Publisher.

    MS14-019

    (Windows File Handling)

    Attacker places malicious .bat and/or .cmd file on a network share from which a victim launches an application that calls CreateProcess in an unsafe manner.  Similar attack vector as DLL preloading. Important 1 While this is an exploitable vulnerability, we have historically not seen widespread exploitation of this type of vulnerability. More details about this vulnerability in this SRD blog post today.

     

    - Jonathan Ness, MSRC engineering team