Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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
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.
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!).
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:
Fix this problem Microsoft Fix it 51012
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):
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:
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:
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.
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.
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
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
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
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.
(Windows File Handling)
- Jonathan Ness, MSRC engineering team