MS13-037 addresses a number of vulnerabilities in Internet Explorer, several of which were reported to us by the TippingPoint Zero Day Initiative (ZDI) program. We’ve gotten questions from customers about the specific vulnerabilities purchased by ZDI from the CanSecWest pwn2own contest. We’d like to use this blog post to provide more background on the set of vulnerabilities required for an attacker to exploit modern-day browsers and the state of fixes for those specific vulnerabilities.

Exploiting recent versions of Internet Explorer

Several years ago, a single memory corruption style vulnerability in the browser could be directly leveraged to compromise a system, could be used to run code in the context of the browsing user. Microsoft has invested heavily in platform-level mitigations for client-side applications such as browsers to the extent that today multiple different vulnerabilities must now be discovered and chained together in an exploit to compromise a system. A single memory corruption style vulnerability is just the start of an attacker’s discovery process. Typically, the attacker would need to also need to bypass ASLR and discover a way out of the IE Protected Mode limited code execution environment.

Pwn2own 2013

ZDI reported five separate vulnerabilities to Microsoft as a result of the contest:

• VUPEN’s IE10 exploit
• IE10 memory corruption style remote code execution vulnerability (CVE-2013-2551)
• IE post-exploitation Low Integrity -> Medium Integrity escalation (CVE-2013-2552)
• MWR Labs (Jon Butler and Nils) Chrome exploit
• Windows kernel elevation of privilege to escape sandbox (CVE-2013-2553)
• VUPEN's FireFox exploit
• Windows LDRHotpatch ASLR/DEP bypass (CVE-2013-2554)
• VUPEN's Adobe Flash exploit
• IE9 broker issue used in the exploit for Adobe Flash (CVE-2013-2556)

Status of security updates

MS13-037 addresses the two Internet Explorer vulnerabilities used in the VUPEN exploit. The Windows vulnerabilities and the IE9 broker issue will be addressed in a future security update cycle. Here’s a chart that describes the state of fixes and level of exposure for these vulnerabilities provided to us by the ZDI.

As you can see, MS13-037 addresses the primary or initial code execution vulnerabilities but we still are working on the updates to address other vulnerabilities used as part of the exploit chains to win pwn2own. Thankfully, ZDI reported those vulnerabilities directly to us and we don’t have any reason to believe that ZDI or the researchers who discovered these vulnerabilities have disclosed the vulnerability details to any third party. So we typically treat the pwn2own vulnerabilities as any other vulnerability report received as part of the coordinated vulnerability discovery process. It’s super interesting for us as security researchers ourselves to see the ingenuity displayed during the contest to exploit the hardest targets out there (!!) but its the severity of the vulnerabilities (not necessarily their debut as part of the contest) that guides our prioritization of fixes.

Each bulletin lists our “official” acknowledgement and thanks to the researchers and third parties involved in discovering and reporting these vulnerabilities to Microsoft. But today from everyone on the SRD team, we want to also pass along our thanks and a hat tip to the pwners out there – really impressive job on these vulns, guys. Thanks for helping us make the platform stronger.

- Jonathan Ness, MSRC Engineering and William Peteroy, MSRC

Today we released ten security bulletins addressing 33 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and eight 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.

- Jonathan Ness, MSRC Engineering

Today, we are making available a “Microsoft Fix it” solution to block attacks leveraging the Internet Explorer 8 (IE8) vulnerability described in Security Advisory 2847140. This code-signed, easily downloadable and install-able Fix it package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time IE is loaded. Here are the links to both apply and uninstall the Fix it solution: 

Apply Fix it	Uninstall Fix it
Microsoft Fix it 50992	Microsoft Fix it 50991

In this blog post, we’d like to describe the following:

• More information about the progress toward a comprehensive security update
• More information about workaround options to disrupt exploits leveraging this vulnerability
• More information about how the Fix it solution works

Comprehensive update in testing now

We have built a comprehensive security update that addresses this vulnerability and it is currently being tested around-the-clock. We will release it as soon as testing confirms it is ready for broad release to all customers.  Tomorrow, please visit our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle.

Workaround options

As listed in Security Advisory 2847140 and confirmed externally, Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is a good workaround option for the in-the-wild attacks and public pentest framework that we have seen. The exploit version in the pentest framework that target Windows Vista and Windows 7 leverages a DLL module installed by Java 6 to bypass ASLR. EMET’s Mandatory ASLR feature blocks this exploit by enforcing ASLR randomization for this DLL when it gets loaded by IE8. At the moment, we are aware of a limited number of attacks in the wild and they target IE8 on Windows XP only. These exploits currently used by attackers are also blocked both by EMET’s EAF mitigation and by the EMET 3.5 TP and 4.0 Beta anti-ROP mitigations. The first ROP stage triggers EMET’s StackPointer, CallerCheck and SimExecFlow checks.  Enterprises already using EMET can anlyze their machine logs to investigate possible exploitation events for this exploit reported by EMET mitigations.

For a stronger level of protection, we recommend installing the Fix it solution until the comprehensive security update is available. The Fix it applies changes to the mshtml loaded binary, similar to the changes applied by the IE team’s comprehensive security update.  More information about the vulnerability, and how it is blocked by the Fix it, can be found in the next section.

How the Fix it “fixes” the vulnerable code

The vulnerability is exposed due to a page layout issue, triggered when Internet Explorer 8 is trying to calculate layout information for nodes no longer in the DOM tree. The issue is caused by layout structures that are not properly cleaned up and contain dangling pointers to page elements. When the layout is updated, the browser crashes due to accessing the freed memory. The code that cleans up the dead links already exists, but it runs after the layout structures are accessed. The solution is to move the cleanup logic before the layout structure access.

The appcompat shim-based “Fix it” protection tool does the exact same thing as the fix provided by the Internet Explorer team. This is still a workaround, but more surgical as compared to other workarounds because it blocks the root cause of the vulnerability. The shim modifies in memory the mshtml!CBlockContainerBlock::BuildBlockContainer function in order to force the code flow change that results in the layout structures being properly cleaned up before access:

      InjectLoopHere:            CODE XREF: CBlockContainerBlock::BuildBlockContainer+103

match:74CC08DC 8B 45 08          mov     eax, [ebp+arg_0]     Inject code here!!
match:74CC08DF 8B 40 08          mov     eax, [eax+8]
patch:74CC08DC E9 ?? ?? ?? ??    jmp     WhilepNextExistingBlock2
patch:74CC08E1 90                nop

      ResumeExecution:
.text:74CC08E2 C1 E8 0A          shr     eax, 0Ah
.text:74CC08E5 A8 01             test    al, 1
.text:74CC08E7 0F 85 FB 8E FD FF jnz     loc_74C997E8


      WhilepNextExistingBlock:   CODE XREF: CBlockContainerBlock::BuildBlockContainer-6C6CE
.text:74CC094E 39 7D F4          cmp     [ebp+pNextExistingBlock], edi 
.text:74CC0951 0F 85 38 36 F9 FF jnz     LoopToRelocate


      LoopToRelocate:            CODE XREF: CBlockContainerBlock::BuildBlockContainer+2DF
.text:74C53F8F FF 75 F4          push    [ebp+pNextExistingBlock]
.text:74C53F92 8B 4D 0C          mov     ecx, [ebp+arg_4]
.text:74C53F95 FF 75 08          push    [ebp+arg_0]
.text:74C53F98 8D 55 F4          lea     edx, [ebp+pNextExistingBlock]
.text:74C53F9B E8 2B 64 0A 00    call    CLayoutBlock::RemoveChild ; layout structure cleanup
.text:74C53FA0 8B F0             mov     esi, eax
.text:74C53FA2 3B F7             cmp     esi, edi

match:74C53FA4 0F 8D A4 C9 06 00 jge     WhilepNextExistingBlock
patch:74C53FA4 E9 ?? ?? ?? ??    jmp     CLOBBER_NOPS_PATCH_BYTES
patch:74C53FA9 90                nop

.text:74C53FAA E9 25 58 04 00    jmp     CHK_FAIL
.text:74C53FAA                   END OF FUNCTION CHUNK CBlockContainerBlock::BuildBlockContainer


      CLOBBER_NOPS_PATCH_BYTES:
patch:???????? 7D 07             jge     WhilepNextExistingBlock3
patch:???????? E9 ?? ?? ?? ??    jmp     CHK_FAIL
      WhilepNextExistingBlock2:
patch:???????? 33 FF             xor     edi, edi
      WhilepNextExistingBlock3:
patch:???????? 39 7D F4          cmp     [ebp+pNextExistingBlock], edi  
patch:???????? 0F 85 ?? ?? ?? ?? jnz     LoopToRelocate
patch:???????? 8B 45 08          mov     eax, [ebp+arg_0]  
patch:???????? 8B 40 08          mov     eax, [eax+8]
patch:???????? E9 ?? ?? ?? ??    jmp     ResumeExecution

The “Fix it” solution will apply only for the x86 versions of Internet Explorer 8 that have applied MS13-028: Cumulative Security Update for Internet Explorer: April 9, 2013. Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, after you apply the yet-to-be-released final security update, you should uninstall the Fix it workaround as it will no longer be needed.

Conclusion

We want to reiterate that only IE8 is vulnerable to this issue and we currently see only limited attacks. We are hard at work developing a comprehensive security update. Tomorrow, please review our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle. In the meantime, feel free to reach out to us with any questions on the above. You can contact us at switech@microsoft.com or secure@microsoft.com.

Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.

- Cristian Craioveanu and Jonathan Ness, MSRC Engineering

Three weeks ago, we released a beta version of EMET 4.0 to get feedback on the new EMET features and to get more real-world testing before the official release. We have been amazed and so grateful for the thousands of downloads and hundreds of emails with feature suggestions, bug reports, questions about the new features, and kind words cheering us on. Thank you (!!) to those of you who are helping us make EMET 4.0 a great release. Seeing how much the community of defenders cares about this product drives and motivates us to make it awesome! With this blog post, we want to give you an update on the EMET schedule and walk through the steps to leverage EMET 4.0’s new Certificate Trust feature.

Official release delayed two weeks to May 28, 2013

We have acted on and addressed a number of bug reports and points of feedback already. One of the most important was a vulnerability first reported by TK of NSFocus where having EMET loaded made exploitation of system vulnerabilities easier – that is fixed. We also received the “Agent not running” bug report several times and that is addressed for the final release of EMET 4.0. We are fixing several application compatibility issues reported that we otherwise would be unlikely to have discovered on our own pre-release. Your feedback is making EMET 4.0 a better product – thank you!

We want to make product changes to address more of the feedback before we release EMET 4.0 to the world. So we decided to postpone the release of final version of EMET 4.0 by two weeks, to May 28th, 2013. We are sorry if this decision may interfere with your future plans of deploying EMET, but we prefer to take some extra time to work on all the feedback received and to release a product as reliable and safe as possible.

EMET and certificate pinning

As you may know EMET 4.0 implements a new protection feature known also as “certificate pinning” which in its simplest form could be described as a method of associating an X509 certificate (and its public key) to a specific Certification Authority (root or leaf).

Certificate pinning and certificate cross-validation became two very popular topic in recent years because of the major incidents and fault happened in the PKI space; in fact the current PKI and Certification Authorities model has demonstrated some limits and shown critical issues when scaled to a globalized and fully interconnected world where it’s not entirely safe to assume that every CA in the world is immune from breach, errors or poor practices as clearly showed by the table below which summarizes the most significant PKI issues seen so far. On the other hand the reason why users should care about certificate pinning is the fact that the numbers of CA across the world and located in multiple countries has grown significantly in recent years and the entire PKI model works with the assumption that all these CA will always operate with the same level of trust and confidence.

For this reason EMET 4.0 decided to take a little step far from the traditional exploit mitigation area and introduces a new feature called Certificate Trust to allow anyone to create pinning rules for any SSL/TLS website certificate, giving the ability to detect Man-In-The-Middle attacks leveraging untrusted certificates. EMET 4.0 comes with Certificate Trust enabled by default, including a set of pre-configured websites for the most common domains used by Microsoft online services; nevertheless, since we believe that certificate pinning is a useful tool to detect MITM attacks targeting any domain and not just Microsoft services, we designed Certificate Trust totally configurable, in order to allow any user to configure custom pinning rules that will be enforced when browsing the web with Internet Explorer.

Since we received a lot of feedback about this new feature and a lot of users sent inquiries on how to properly use it, we are publishing this blog to explain how to configure and test Certificate Trust.

Introducing the Certificate Trust feature

EMET 4.0 has a main switch button in the system mitigation panel that can be used to activate or de-activate Certificate Trust. Once enabled, users have to specify which certificates and Root Certificate Authorities to trust. Users can verify that the Certificate Trust feature is activated from the EMET GUI by checking that the system status of this mitigation is “Enabled” and that Internet Explorer process (iexplore.exe) is in the list of configured apps (with or without memory mitigations enabled). This configuration allows EMET to inject into the protected process a new small module (EMET_CE.DLL) that will operate only within Internet Explorer to enforce the certificate pinning protection.

EMET pinning model is based on two simple types of metadata: Pinning Rules and Protected Websites. Users can define custom “pin” relationships between subject name(s) seen in SSL certificates and a set of trusted Root Certification Authorities. EMET supports the creation of “one-to-one” pinning rules (one domain pinned to one specific RootCA) or “one-to-many” (one domain pinned to a set of specific RootCAs), and gives the ability to define minor exceptions for each rule.

For example, let’s consider the domain “login.live.com”, which is configured and protected by default by EMET 4.0 Beta. EMET has a specific pin rule for the subject name of “login.live.com” which is linked to two RootCAs. One of these RootCAs is VeriSign RootCA, which is visible when manually inspecting the certificate for that domain. Any certificate seen by Internet Explorer for “login.live.com” and originated from a RootCA different than the two configured in EMET will be detected and reported as suspicious.

Configuring Certificate Trust: an example

In order to understand the exact steps required to create a custom pinning rule, we are providing a step-by-step configuration guide for Twitter. This guide can be used as reference to configure any other online service (e.g. webmail, social networks, file sharing, online banking, etc.) or any corporate portal that uses SSL/TLS connections (e.g. webmail.mycompany.com, fileshare.mycompany.com, etc.), and take advantage of EMET’s Certificate Trust feature.

• From a clean computer using a trusted internet connection download and inspect the SSL/TLS certificate for the domain that has to be protected with EMET (e.g. https://twitter.com) and find the correct subject name that will be used in the “Protected Websites” tab (e.g. “twitter.com”)

• Lookup the RootCA for “twitter.com” in the “Certification Path” and make note of some significant details related to this RootCA certificate (name, thumbprint, validity, serial number, etc.). For example the current RootCA of “twitter.com” has a VeriSign certificate with the following details:
• CN = VeriSign Class 3 Public Primary Certification Authority - G5
• Thumbprint = 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5
• Validity = From: November ‎7, ‎2006; To: ‎July ‎16, ‎2036

• Open EMET_GUI and click on “Configure”->”Certificate Trust”. In the “Pinning Rules” tab add a new rule (e.g. TwitterCAs) which will be used to import the specific VeriSign RootCA acquired earlier for twitter.com (double check you’re importing the correct VeriSign CA). This pinning rule will be used to create a “one-to-one” pinning, but anytime it is possible to add more RootCA certificates into this rule to create “one-to-many” pinning.

• Go to the “Protected Websites” tab and add a pin that links “twitter.com” to the just created rule “TwitterCAs”.

• Click “OK” to save the settings and restart the browser if needed.

The Certificate Trust configuration can be exported as XML file and later imported on a different machine or distributed to a corporate environment to be imported using the EMET_conf command line utility. For the Twitter example used in this blog, the exported XML configuration file is shown below:

  
<EMET Version="4.0.4854.22469">
  <Pinning>
    <PinRules>
      <PinRule>
        <ID>{67626c91-5591-4acd-a87f-864593250fff}</ID>
        <Name>TwitterCAs</Name>
        <ReferencedCertificates>
          <UniqueCertificateIdentifier>
            <Issuer>CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US</Issuer>
            <SerialNumber>18DAD19E267DE8BB4A2158CDCC6B3B4A</SerialNumber>
          </UniqueCertificateIdentifier>
        </ReferencedCertificates>
        <Expiration>5/10/2014 4:00:00 PM</Expiration>
      </PinRule>
    </PinRules>
    <PinnedSites>
      <PinnedSite>
        <Domain>twitter.com</Domain>
        <PinRuleMember>{67626c91-5591-4acd-a87f-864593250fff}</PinRuleMember>
        <Active>True</Active>
      </PinnedSite>
    </PinnedSites>
  </Pinning>
</EMET>

Notes about Certificate Trust configuration

After evaluating the initial feedback received and some questions from users regarding the Certificate Trust feature, we think it’s also important to share some additional notes and guidelines for users dealing for the first time with certificates and pinning rules:

• Some websites may use different portal as entry-point for authentication; it’s always good to carefully check the correct domain name to add into the “Protected Websites” tab (e.g. “outlook.com” service is accessed via the “login.live.com” authentication service);
• Each pinning rule has an expiration date that delimits for how long a rule is effective; after the specified date, the rule will no longer be used to check certificates; expiration date can be usually aligned with the expiration date of the certificate included in a pinning configuration;
• Domains cannot be added in the “Protected Websites” tab by using wildcard characters (e.g. *.live.com is not allowed); also, the domain name added into this tab is not the domain name in the URL bar of the browser, but it’s one subject name of the SSL certificate;
• To avoid false positives and to configure less restrictive rules, it is possible to add exceptions on each pinning rule based on three properties of the RootCA certificate: key size, country, and signature hashing algorithm; when a RootCA is not present in the defined trusted set for a specific domain, EMET may allow an exception of the pinning rule if explicitly configured (for example: allows an exception if the RootCA certificate does not use MD5, has a minimum key size of 4096 bits, and is located in USA);
• When EMET detects a suspicious certificate it will be reported with a visible message from EMET Agent, while the important details of the certificates are logged into the Window Events Log; a warning message is a good pointer to examine carefully what’s happening for a SSL/TLS certificate but doesn’t necessary mean that the detected certificate is malicious, few times changes of RootCAs happen also for legitimate reasons;
• The quickest way to test that the Certificate Trust feature is working is to configure a wrong pinning rule that will fail for a test domain; for example, if for twitter.com we configure a different RootCA than the specific VeriSign CA identified earlier, EMET will display the following warning message when browsing with Internet Explorer on “twitter.com”:

Conclusion

We hope you are as excited about using the final release of EMET 4.0 as we are about releasing it. If you have any questions about EMET 4.0, specifically about the Certificate Trust feature detailed in this blog post, please email us at emet_feedback@microsoft.com. And if you haven’t yet tested EMET 4.0 beta, download it here and try it out!

- Elia Florio, MSRC Engineering

Even though cross-site scripting vulnerabilities have a 15-year history, they remain a big problem in the web security space. According to our research, there are hundreds of new issues discovered each month, and at least a few of them are being used in high-severity attacks.

The general problem of cross-site scripting has no easy solution. Yet, some of the existing mitigation techniques show high (over 95%) levels of efficiency in detection of real-life XSS attacks. One such solution is Internet Explorer’s XSS filter. As David Ross described in his blog posts, the core of the IE filter consist of a set of heuristics detecting common patterns of XSS attacks in URLs. Thanks to our collaboration with OWASP community, analogous set of rules is now available through OWASP ModSecurity Core Rule Set 2.2.7.

The new rules are present at the end of the file: base_rules\modsecurity_crs_41_xss_attacks.conf. They are divided into non-volatile (15 rules) and volatile (11 rules) sets, marked accordingly:

# non-volatile
#
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:<script.*?>)" "phase:2,rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'8',accuracy:'8',id:'973315',capture,logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',t:none,t:htmlEntityDecode,t:compressWhiteSpace,block,msg:'IE XSS Filters - Attack Detected.',tag:'OWASP_CRS/WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"
…

In our practice, the non-volatile rules produce a very low number of false-positive hits, while the volatile ones tend to be susceptible to application-specific behavior. On most applications volatile rules also have a low false-positives ratio, but when a web application relies too much in its design on “suspicious” characters, selective disabling of specific volatile rules might be needed.

Application of the XSS-catching heuristics on IIS server is very simple, since version 2.7.3 users can install ModSecurity IIS module using Web Platform Installer. Also, with the recent general-availability release, when using Windows Azure Virtual Machines one can easily automate installation of ModSecurity IIS over Remote PowerShell, for example, by extending the launching script from Michael Washam’s blog with this simple snippet:

# Use native PowerShell Cmdlet to install ModSecurity IIS on the remote virtual machine
Invoke-Command -ConnectionUri $uri.ToString() -Credential $credential -ScriptBlock {
$msidir = $env:temp+"\modsecurityiis"
md $msidir
$file = $msidir+"\modsecurityiis.msi"
$webclient = New-Object System.Net.WebClient
$webclient.DownloadFile("http://www.modsecurity.org/tarball/2.7.3/ModSecurityIIS_2.7.3.msi",$file)
msiexec /i $file /qb
}

After installation, the default OWASP CRS IIS rules can be enabled for a selected website by adding to the web.config file, in system.webServer section:

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

This simple step should let web server administrators see a significant majority of XSS attempts and attacks launched on their websites.

The releasing of ModSecurity IIS version was a major milestone for the ModSecurity web application firewall project. We also won some community awards and WAF comparison tests. It is good to look back on past accomplishments, but it is also important to look ahead. How can we make ModSecurity IIS better in the future?

As part of this effort, the ModSecurity Team in SpiderLabs Research has developed a new user survey for 2013.

Click here to take survey.

If you are a user of ModSecurity IIS, I encourage you to take the survey as it will give us a better understanding of how ModSecurity IIS is being used, and also to get feedback on what we are doing well and what we need to improve.

It is only 15 questions. As an added incentive, you can also enter your email address into a raffle to win a copy of Ryan Barnett’s new book: "The Web Application Defender's Cookbook: Battling Hackers and Protecting Users".

Thanks for using ModSecurity IIS and for helping us to make it better!

- Greg Wroblewski, SRD Blogger

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

Great news!  Today we are proud to announce a beta release of the next version of the Enhanced Mitigation Experience Toolkit (EMET) – EMET 4.0.  Download it here:

http://www.microsoft.com/en-us/download/details.aspx?id=38761

EMET is a free utility that helps prevent memory corruption vulnerabilities in software from being successfully exploited for code execution.  It does so by opt-ing in software to the latest security mitigation techniques.  The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an available update has not yet been applied.  We encourage you to test out the beta release by downloading and installing it, asking questions about the new features, and reporting any issues you find for us to address before the final release.  We plan to officially release EMET 4.0 on May 14, 2013.

The feature set for this new version of the tool was inspired by our desire for EMET to be an effective mitigation layer for a wider variety of potential software exploit scenarios, to provide stronger protections against scenarios where EMET protection already exists, and to have a way to respond to 0day exploits as soon as possible.  Here are the highlights of the EMET 4.0 feature set:

•        EMET 4.0 detects attacks leveraging suspicious SSL/TLS certificates
•        EMET 4.0 strengthens existing mitigations and blocks known bypasses
•        EMET 4.0 addresses known application compatibility issues with EMET 3.0
•        EMET 4.0 enables an Early Warning Program for enterprise customers and for Microsoft
•        EMET 4.0 allows customers to test mitigations with “Audit Mode”

SSL/TLS Certificate Trust features

EMET 4.0 allows users to configure a set of certificate pinning rules to validate digitally signed certificates (SSL/TLS certificates) while browsing with Internet Explorer. This option allows users to configure a set of rules able to match specific domains (through their SSL/TLS certificates) with the corresponding known Root Certificate Authority (RootCA) that issued the certificate. When EMET detects the variation of the issuing RootCA for a specific SSL certificate configured for a domain, it will report this anomaly as an indicator of a potential man-in-the-middle attack.

Advanced users can also add exceptions for each pinning rule.  This will allow EMET to accept SSL/TLS certificates even if the pinning rule doesn’t match.  Exceptions are related to some properties of the RootCA certificate, such as key size, hashing algorithm, and issuer country.

Strengthened mitigations, blocking bypasses

We learned a great deal during the “Technical Preview” phase of EMET 3.5.  We saw researchers poking and presenting clever tricks to bypass EMET’s anti-ROP mitigations.  EMET 4.0 blocks these bypasses.  For example, instead of hooking and protecting only functions at the kernel32!VirtualAlloc layer of the call stack, EMET 4.0 will additional hook lower level functions such as kernelbase!VirtualAlloc and ntdll!NtAllocateVirtualMemory.  These “Deep Hooks” can be configured in EMET’s Advanced Configuration.  We have seen exploits attempt to evade EMET hooks by executing a copy of the hooked function prologue and then jumping to the function past the prologue.  With EMET 4.0’s “Anti detours” option enabled, common shellcode using this technique will be blocked.  Finally, EMET 4.0 also includes a mechanism to block calls to banned API’s.  For example, a recent presentation at CanSecWest 2013 presented a method of bypassing ASLR and DEP via ntdll!LdrHotPatchRoutine.  EMET 4.0’s “Banned API” feature blocks this technique.

Application compatibility fixes

Users of previous versions of EMET had encountered isolated compatibility issues when enabling mitigations on both Microsoft and third party software.  EMET 4.0 addresses all these known app-compat issues.  That list includes issues in the following areas:

-          Internet Explorer 9 and the Snipping Tool

-          Internet Explorer 8’s Managed Add-ons dialog

-          Office software through SharePoint

-          Access 2010 with certain mitigations enabled

-          Internet Explorer 10 on Windows 8

The EMET 4.0 installer also opts-in protection rules with certain mitigations disabled where we know a mitigation interacts poorly with certain software.  Examples include Photoshop, Office 2013’s Lync, GTalk, wmplayer, and Chrome.

Early Warning Program for enterprise customers and for Microsoft

When an exploitation attempt is detected and blocked by EMET, a set of information related to the attack is prepared with the Microsoft Error Reporting (MER) functionality.  For enterprise customers collecting error reports via tools like Microsoft Desktop Optimization Package or the Client Monitoring feature of System Center Operations Manager, these error reports can be triaged locally and used as an early warning program indicating possible attacks against the corporate network.  For organizations that typically send all error reports to Microsoft, this information will add to the set of indicators we use to hunt attacks in the wild, and will facilitate the remediation of issues with security updates before vulnerabilities become a large scale threat. The EMET Privacy Statement (available also via the main EMET window) includes more information about the type of data that will be sent in the error report via Microsoft Error Reporting.  The Early Warning Program is enabled by default for the EMET 4.0 Beta and can be disabled in the EMET UI or via the EMET command line component.  We are eager to hear customer feedback about this feature to help shape the Early Warning Program for the EMET 4.0 final release.

Audit Mode

When previous versions of EMET detected exploitation attempts, it would report the attack via the EMET agent and then terminate the program to block the attack.  For EMET 4.0, in response to customer feedback, we provided an option to configure EMET’s behavior when it detects an exploitation attempt.  The default option remains to terminate the application.  However, customers wanting to test EMET in a production environment can instead switch to “Audit Mode” to report the exploitation attempt but not terminate the process.  This setting is not applicable for all mitigations but we provide this option whenever possible.

Other Improvements

EMET 4.0 includes a bunch of other improvements.  The quantity of new features and volume of work put into this release is the reason we skipped the EMET 3.5 full release and jumped straight to EMET 4.0.  Please refer to the EMET 4.0 Beta Users Guide for the full set of features but here are several other highlights:

-          EMET Notifier becomes EMET Agent, with new duties and functionalities

-          More granular reporting options (tray icon, event log, both, or none)

-          New default profiles for both mitigations and Certificate Trust

-          Registry configuration to customize the EMET Agent’s messaging

-          Optimized RopCheck for significantly better performance

-          Numerous UI tweaks to make EMET easier to use

-          Enable wildcard support when adding applications to be protected

-          Allow processes to be protected even if they do not have .exe extension

-          Switched to .NET Framework 4.0

-          EMET is an officially supported Microsoft tool with support available for customers with Premier contract

We are eager to hear feedback on this new version of EMET!  This beta period is a short four weeks – we learned our lesson from the long EMET 3.5 Technical Preview about crisp timelines and short beta periods.  We need to get customer feedback during this beta period, before the official release of EMET 4.0.  Some of the EMET 4.0 feature set came straight from customer feedback. We want to make EMET a tool that you feel great about deploying and configuring in your environment.  This beta period provides an option to get the feedback of early adopters before it goes live to everyone.  Please email us at emet_feedback@microsoft.com with any feedback, questions, or suggestions.  And download EMET 4.0 Beta today and try it out. 

Thanks,

The EMET Team

Today we released nine security bulletins addressing 13 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and seven 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.

- Jonathan Ness, MSRC Engineering

Today we released seven security bulletins addressing 20 CVE’s. Four of the bulletins have a maximum severity rating of Critical, and three 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.

- Jonathan Ness, MSRC Engineering

Today we are addressing a vulnerability in the way that the Windows USB drivers handle USB descriptors when enumerating devices. (KB 2807986). This update represents an expansion of our risk assessment methodology to recognize vulnerabilities that may require physical access, but do not require a valid logon session. Windows typically discovers USB devices when they are inserted or when they change power sources (if they switch from plugged-in power to being powered off of the USB connection itself). To exploit the vulnerability addressed by MS13-027, an attacker could add a maliciously formatted USB device to the system. When the Windows USB device drivers enumerate the device, parsing a specially crafted descriptor, the attacker could cause the system to execute malicious code in the context of the Windows kernel.

Because the vulnerability is triggered during device enumeration, no user intervention is required. In fact, the vulnerability can be triggered when the workstation is locked or when no user is logged in, making this an un-authenticated elevation of privilege for an attacker with casual physical access to the machine. Other software that enables low-level pass-through of USB device enumeration may open additional avenues of exploitation that do not require direct physical access to the system.

- Josh Carlson and William Peteroy, MSRC

Today we released twelve security bulletins addressing 57 CVE’s. Five of the bulletins have a maximum severity rating of Critical, and seven 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.

- Jonathan Ness, MSRC Engineering