Security Research & Defense

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

Security Research & Defense

  • Assessing risk for the July 2014 security updates

    Today we released six security bulletins addressing 29 unique CVE’s. Two bulletins have a maximum severity rating of Critical, three have maximum severity Important, and one is Moderate. 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
    MS14-037

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Addresses 23 remote code execution issues and one lower severity Security Feature Bypass vulnerability.
    MS14-038

    (Windows Journal)

    Victim opens malicious .JNT file or navigates with Explorer to a WebDAV share under attacker control where a malicious .JNT file is automatically rendered. Critical 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-040

    (AFD.sys)

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-041

    (Sandbox escape via DirectShow)

    Attacker running code at low integrity level runs exploit binary to elevate to context of logged-on user. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-039

    (Sandbox escape via on-screen keyboard)

    Attacker running code at low integrity level runs exploit binary to elevate to context of logged-on user. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-042

    (Service Bus)

    Attacker could cause Service Bus to stop responding to incoming AMQP messages. Moderate n/a Lower severity issue unlikely to see significant attacker interest. Windows Azure not affected.

    - Jonathan Ness, MSRC

  • Assessing risk for the June 2014 security updates

    Today we released seven security bulletins addressing 66 unique CVE’s.  Two bulletins have a maximum severity rating of Critical while the other five have a maximum severity rating of Important. This table is designed to help you prioritize the deployment of updates appropriately for your environment.

    Bulletin         Most likely attack vector Max Bulletin Severity Max XI Likely first 30 days impact Platform mitigations and key notes
    MS14-035

    (Internet Explorer)
    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. CVE count (59) is result of focusing on in-the-wild exploits last month. These are the May + June fixes for issues not under active attack.
    MS14-034

    (Word 2007)
    Victim opens malicious Office document. Important 1 Likely to see reliable exploits developed within next 30 days. Issue addressed in embedded font parsing. Reachable via either doc or docx.  Word 2010 and later not affected.
    MS14-036

    (GDI+)
    Victim open malicious graphics file or malicious PowerPoint document Critical 1 Likely to see reliable exploits developed within next 30 days. Issue addressed is in EMF+ record type parsing, an area we have not seen real-world attackers pursue recently.  (Hence, table lists Word security update ahead of GDI+ update.)
    MS14-033

    (MSXML)
    Victim browses to a malicious webpage or opens a malicious document, inadvertently sending local path name of downloaded file to attacker.  Path name by default includes the user’s login name. Important 3 Less likely to see widespread usage of information disclosure vulnerabilities. Information disclosure only.
    MS14-030

    (Terminal Services)
    Attacker acting as man-in-the-middle at the start of a Remote Desktop session may be able to read information from or tamper with RDP session. Important n/a Less likely to see widespread usage of vulnerabilities enabling tampering. Terminal Services NLA feature mitigates this vulnerability.

    MS14-031

    (TCP)
    Attacker initiates large number of connections with malformed TCP options.  Each connection temporarily consumes non-paged pool memory longer than it should, leading to resource exhaustion. Important 3 Less likely to see widespread usage of vulnerability allowing resource exhaustion denial-of-service only. Attacker must control TCP Options fields.  Attacker would be unable to cause denial-of-service for systems behind network infrastructure that overwrites the TCP Options field.
    MS14-032

    (Lync Server XSS)
    Victim clicks on a specially-crafted malicious link to an established Lync meeting.  Attacker can take action in context of Lync Server service that victim would normally have access to take. Important 3 Less likely to see widespread usage of this vulnerability. XSS style vulnerability.

     

    - Jonathan Ness, MSRC engineering team

     

     

  • An Overview of KB2871997

    An Overview of KB2871997

    Microsoft recently released KB2871997 for Windows 7, Windows 8, Windows Server 2008R2, and Windows Server 2012. This blog will give an overview of the feature changes, their impact, and some important configuration changes that can be made in conjunction with the update to further improve system security.

    1. Support for the Protected Users group

    “Protected Users” is a security group added to Windows Server 2012R2 domains. When a user account is added to the “Protected Users” group, several additional security restrictions are placed on the account:

      1. A member of the Protected Users group can only sign on using the Kerberos protocol. The account cannot authenticate using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.
      2. The Kerberos protocol will not use the weaker DES or RC4 encryption types in the pre-authentication process. This means that the domain must be configured to support at least the AES cypher suite.
      3. The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.

    In a nutshell, this setting blocks everything besides Kerberos authentication and applies hardening to the Kerberos authentication used (enforces AES encryption). We recommend you place high value accounts, such as accounts used by server administrators, in the “Protected Users” group to harden the accounts.

    Since a “Protected User” is restricted to Kerberos authentication they work well with “Authentication Policies and Silos”, a new feature introduced for Windows 2012R2 functional level domains. Authentication Policies and Silos allow you to place users and computers within a silo and apply policy (such as logon restrictions) to them. More information on “Authentication Policies and Silos” can be found here: http://technet.microsoft.com/en-us/library/dn486813.aspx.

    2. Remote Desktop Client support for the Restricted Admin RDP mode

    Part of Microsoft’s official guidance for reducing the risk of lateral movement (or pass-the-hash) attacks is to authenticate to servers using a “network logon” (a specific Windows logon type). Why? Because when a user authenticates to a remote server using a “network logon”, the users credential is never sent to the remote server. This means that even if the remote server is compromised, the users credential cannot be captured.

    Virtually every management tool Microsoft ships authenticates using “network logon”. This includes but is not limited to: PowerShell Remoting, WinRM, PSExec, WMI, etc… Prior to this update, Remote Desktop required the user send their clear-text password to the remote server (encrypted over-the-wire but decrypted on the remote server) so they could log on for an interactive session. With this update, it is now possible to use Remote Desktop without sending credentials to the remote server.

    Note that this update back ports changes to the Remote Desktop client, not Remote Desktop server. This means you can make Restricted Admin connects from an updated system, but you can only make Restricted Admin connects to a Windows 8.1/2012R2 system.

    Only administrators can use the “Restricted Admin” mode; members of the “Remote Desktop Users” group are not allowed to use the Restricted Admin mode. Because the users credential is not sent to the remote system, it is impossible for the user to make authenticated connections from the remote system to other systems. Since the user connecting to the system is an administrator (and can by-design impersonate other users on the system), we have made Restricted Admin connections automatically impersonate the computer account for remote connections. This allows a Restricted Admin to access network resources such as shares as long as the computer account has access.

    Microsoft recommends that Restricted Admin is used whenever possible, as this follows the “least privilege” principal. If you are authenticating to a server (even a highly trusted server) and do not need to “double hop” with your privileged account, it is recommended you use Restricted Admin. One common scenario that will greatly benefit from Restricted Admin is the “helpdesk scenario” where a helpdesk agent uses remote desktop with a privileged account to repair user workstations.

    Restricted Admin can be used by starting Remote Desktop as follows:

    Mstsc.exe /restrictedadmin

    3. LSA Credential Cleanup & Other Changes

    a. Removal of credentials after logoff

    As outlined in Microsoft’s Pass-the-hash whitepaper, Windows caches the credentials of a user in the LSASS process whenever the user logs in. This includes the user’s clear-text password, the users NT/LM password hash, and the users Kerberos TGT/Session key. When the user logs off, the credentials should be cleared out of memory. Prior to this update, this was not always the case. This issue preventing credentials from being cleared is now fixed, credentials will always be cleared from memory after a user logs off.

     b. New well known SID’s

    This update adds support for two new well known SID’s:

    1. LOCAL_ACCOUNT – Any local account will inherit this SID
    2. LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP – Any local account that is a member of the administrators group will inherit this SID

    These SID’s were introduced to make it easier to prevent local accounts from being used over the network (something attackers commonly do when performing pass-the-hash attacks). An administrator can configure the Group Policy settings “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services” using the above SID’s to prevent attacks from using local accounts over the network. More information on these settings (and detailed instructions) can be found in Microsoft’s Pass-The-Hash whitepaper.

    c. Removal of clear-text credentials from LSASS

    As noted previously, one of the credentials stored by LSASS is the user’s clear-text password. This update prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s clear-text password. WDigest still stores the user’s clear-text password because it cannot function without the user’s password (Microsoft does not want to break existing customer setups by shipping an update to disable this). Microsoft recommends users look through their domain controller logs for Digest authentication logons (instructions provided below); if Digest authentication is not being used, customers can apply the FixIt found on the KB article to disable WDigest. Doing this will eliminate all clear-text credentials from LSASS memory.

    It’s important to realize that while clear-text credentials will no longer be stored, the NT hash and Kerberos TGT/Session key will still be stored and are considered credentials (without credential equivalents stored in memory, single sign-on would be impossible). Additionally, even though the clear-text credentials are no longer stored in memory, an attacker can use other techniques such as key loggers to recover clear-text passwords. Eliminating clear-text passwords from memory is useful and reduces risk, but it is not guaranteed to stop attackers.

                 

    Identifying WDigest use:

    WDigest use can be identified in two places: your domain controller logs, or your server logs (every server must be checked).

    1.       Domain Controller Security Event Logs: Event ID 4776

    Authentication Package:     WDigest

    Logon Account:    Administrator

    Source Workstation:             WIN2K12R2CLIENT

    Error Code:             0x0

     

    2.       Server Security Event Logs: Event ID 4624 (must be checked on all servers)

    An account was successfully logged on.

    Subject:

                    Security ID:                            NULL SID

                    Account Name:                     -

                    Account Domain:                 -

                    Logon ID:                               0x0

    Logon Type:                                          3

    Impersonation Level:                            Impersonation

    New Logon:

                    Security ID:                            TESTLAB\administrator

                    Account Name:                     Administrator

                    Account Domain:                 TESTLAB

                    Logon ID:                               0x2D8B63

                    Logon GUID:                          {00000000-0000-0000-0000-000000000000}

    Process Information:

                    Process ID:                             0x0

                    Process Name:                      -

    Network Information:

                    Workstation Name:              -

                    Source Network Address:    ::1

                    Source Port:                           57514

    Detailed Authentication Information:

                    Logon Process:                     WDIGEST

                    Authentication Package:     WDigest

                    Transited Services:                -

                    Package Name (NTLM only):              -

                    Key Length:                           0

     

     

     

    - Joe Bialek, MSRC Engineering

  • MS14-025: An Update for Group Policy Preferences

    Today, we released an update to address a vulnerability in Group Policy Preferences (MS14-025). Group Policy Preferences was an addition made to Group Policy to extend its capabilities. Among other things, Group Policy Preferences allows an administrator to configure:

    • Local administrator accounts (name of the account, account password, etc)
    • Configure a service or scheduled task (allowed to specify alternate credentials to run as)
    • Mount network drives when a user logs in (allowed to specify alternate credentials to connect with)

    Group Policy Preferences are distributed just like normal group policy: An XML file containing the settings is written to the SYSVOL share of the domain controllers, and computers periodically query the SYSVOL share (authenticating to it using their computer account) for updates to the group policy.

    Several of the Group Policy Preferences allow credentials to be specified. When this option is used, the password is symmetrically encrypted using a static key and written to the XML file along with the rest of the settings. What is this key you ask? It turns out, we document it on MSDN: http://msdn.microsoft.com/en-us/library/cc422924.aspx.

    If an attacker is able to get access to the SYSVOL share (which is open to all authenticated users, so a malicious or spear phished employee will have access to it) and obtain the AES encryption key used to encrypt/decrypt passwords set with GPP (which we document on MSDN), the attacker will be able to obtain the credentials set with GPP.

    Microsoft has observed that Group Policy Preferences abuse is one of the most common tactics used by attackers to elevate permissions in a domain. Multiple toolkits used by attackers such as Metasploit (http://www.rapid7.com/db/modules/post/windows/gather/credentials/gpp) and PowerSploit (https://github.com/mattifestation/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1) provide easy to use methods for retrieving and decrypting GPP passwords. In the worst case scenario, companies use Domain Administrator credentials in their Group Policy Preference accounts, resulting in a full domain compromise as soon as the attacker is able to access with SYSVOL share (and decrypt the passwords using the documented key).

    Microsoft has released an update to change the behavior for this issue, but companies using GPP need to take action. Microsoft has removed the ability to create or modify any Group Policy which contains a Group Policy Preference that specifies account credentials. The only action that can be performed on such a Group Policy is “delete”. Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature. You can see in the picture below that when attempting to create a local account the “username” and “password” fields are disabled. If you attempt to create a user, an error dialog will be displayed.

    In addition to the change in behavior, Microsoft is providing customers with two PowerShell scripts. The first script, Enum-SettingsWithCpassword, will search existing GPO’s for use of the account password functionality. We urge companies to immediately run this script and delete vulnerable GPO’s detected.

    The second script, Invoke-PasswordRoll, can be used to set local administrator passwords on remote systems (something that Group Policy Preferences is commonly used for). The script takes a list of usernames and computers, and uses PowerShell remoting to connect to each computer and change each specified usernames password to a randomized password. The username/password combinations will be written recorded in a file on disk (which is encrypted, but optionally can be stored in clear-text). Note that the script enforces randomized passwords to ensure the local accounts cannot be used in pass-the-hash attacks.

    You can find both scripts at http://support.microsoft.com/kb/2962486.

    - Joe Bialek, MSRC engineering team

  • Load Library Safely

    Dynamically loading libraries in an application can lead to vulnerabilities if not secured properly. In this blog post we talk about loading a library using LoadLibraryEx() API and make use of options to make it safe.

    Know the defaults:

    • The library file name passed to LoadLibrary() / LoadLibraryEx() call need not contain an extension. If one is not specified, then the default library file extension, .DLL, is used. As a result of this feature, if a null is passed as library name it tries to load ".DLL" which could be exploited by placing a ".DLL" in the path searched.
    • The library file name passed to LoadLibrary() / LoadLibraryEx() call need not specify a directory path. If one is specified, library is loaded only from the specified path. Otherwise, following default DLL search order is used:
    1. The current process image file directory, application directory.
    2. The system directory.
    3. The 16 bit system directory.
    4. The windows directory.
    5. The current working directory.
    6. The directories listed in the PATH environment variable.
    • Windows maintain a list known DLLs, which are basically a set of system DLLs, that are always guaranteed to load from the system directory when absolute name is specified.
    • DllMain() function within the loaded library is called after loading the library into memory.

    Control the DLL search order:

    There are various option to modify the order in which the loading library is searched other than the default search order when absolute name is provided.

    Some of the APIs that can influence the DLL search order/path by the LoadLibraryEx() are as below:

    LoadLibraryEx() provide many flags that can be used to alter the default search order. Below table lists most of the flags and also depicts the DLL search order that is followed for each of them. Some of the options even consider the paths set with above mentioned APIs.

     
    Table 1: Depicting different options to the LoadLibraryEx and how it affects the DLL search order.
     

    Loading library as non-executable:
    It is not always required to load a library as an executable image. LoadLibraryEx() makes it possible to load a library as a data file, or an image resource, for example. For this purpose, it supports following different options:

    • LOAD_LIBRARY_AS_DATAFILE
    • LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
    • LOAD_LIBRARY_AS_IMAGE_RESOURCE
    • DONT_RESOLVE_DLL_REFERENCES

    These options helps in treating a file as a normal data file rather as an executable module. Loading with this option doesn't call DLLMain() and none of the memory space of the loaded DLL data is marked as executable.

    Blocking the library from loading:
    Sometimes it might be required to block a library or block an illegitimate library from loading into an application. Check out following facilities to aid that:

      • AppLocker is a policy based mechanism to block DLLs from loading into applications. These policies can be pushed via group policy. AppLocker can control executables, scripts and installers.
      • When a new DLL loads, a notification is sent to AppLocker to verify that the DLL is allowed to load. AppLocker calls the Application Identity component to calculate the file attributes. It duplicates the existing process token and replaces those Application Identity attributes in the duplicated token with attributes of the loaded DLL. AppLocker then evaluates the policy for this DLL, and the duplicated token is discarded. Depending on the result of this check, the system either continues to load the DLL or stops the process.
      • AppLocker can block the DLL based on path, publisher or file hash.
      • Microsoft Authenticode technology can be used to sign the DLL, which is to attach digital signatures to the DLL to guarantee its authenticity and integrity.

    To summarize our discussion:

    To ensure secure loading of libraries

    • Use proper DLL search order.
    • Always specify the fully qualified path when the library location is constant.
    • Load as data file when required.
    • Make use of code signing infrastructure or AppLocker.

    Some common attack vectors we see:

    • Application directory attacks, especially from the temporary internet or download folder perspective. Particularly when the application is an installer, it is a common thing for people to download the installer into default directory and execute from there. Considering attacker can drop malicious file in the default directory can make use of application directory to load the DLLs. Manifest and .local redirection can also be used in this scenario.
    • Loading DLL from memory and also Powershell DLL injection. Which can be used by malwares to keep the loading of a malicious DLL from getting detected.
    • TOCTOU attacks when loading library from remote location.

    - Swamy Shivaganga Nagaraju, MSRC engineering team

  • Assessing risk for the May 2014 security updates

    Today we released eight security bulletins addressing 13 unique CVE’s. Two bulletins have a maximum severity rating of Critical while the other six have a maximum severity rating of Important. The table is designed to help you prioritize the deployment of 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
    MS14-029

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to continue to see exploits leveraging CVE-2014-1815. This update includes the fix for CVE-2014-1776, first addressed by the MS14-021 out-of-band security update on May 1. However, MS14-029 is not a cumulative security update. Please first install the last cumulative security update for Internet Explorer before applying this update.
    MS14-024

    (Common Controls - MSCOMCTL)

    Victim opens malicious RTF document Important n/a Security Feature Bypass only. Not likely to be exploited directly for code execution. This vulnerability has been leveraged as the ASLR bypass for in-the-wild exploits leveraging the following CVE’s:
    • CVE-2012-0158
    • CVE-2012-1856
    • CVE-2013-3906
    • CVE-2014-1761

    Installing this update will prevent this control from being used as an ASLR bypass in any potential future exploits.

    MS14-025

    (Group Policy Preferences)

    Attacker having already compromised a domain-joined workstation leverages that access to query Group Policy Preferences to potentially discover obfuscated domain account credentials. Important 1 Likely to continue seeing attackers use this “post-exploitation” technique to move laterally across enterprise network. Security update prevents the feature from being used in the future but requires administrators to take action to remove passwords previously stored and still available. This issue and the methods for preventing its abuse are described in more detail at this SRD blog post.
    MS14-027

    (Shell)

    Attacker already running code on a machine as low privilege user takes advantage of elevated/high privileged process calling ShellExecute to elevate the low privileged process. Important 1 Discovered in use by limited number of commodity malware samples. Likely to continue seeing malware attempt to leverage this vulnerability to escalate from low privilege to higher privilege. Observed in the following malware families, each of which is already blocked by Microsoft anti-malware products:

    Backdoor:Win32/Koceg
    Backdoor:Win32/Optixpro.T
    Backdoor:Win32/Small
    Backdoor:Win32/Xtrat
    PWS:Win32/Zbot
    Rogue:Win32/Elepater
    Rogue:Win32/FakeRean
    Trojan:Win32/Dynamer!dtc
    Trojan:Win32/Malagent
    Trojan:Win32/Malex.gen
    Trojan:Win32/Meredrop
    Trojan:Win32/Otran
    Trojan:Win32/Rimod
    Trojan:Win32/Sisron
    TrojanDropper:Win32/Sirefef
    TrojanSpy:Win32/Juzkapy
    VirTool:MSIL/Injector
    VirTool:Win32/Obfuscator
    Virus:Win32/Neshta
    Worm:Win32/Autorun
    Worm:Win32/Fasong
    Worm:Win32/Ludbaruma
    Worm:Win32/Rahiwi

    MS14-022

    (SharePoint)

    Attacker able to upload arbitrary content to SharePoint server could potentially run code in the context of the SharePoint service account. Critical 1 Likely to see reliable exploit emerge in next 30 days. Attacker must be granted access to upload content to SharePoint server to trigger vulnerability. We haven’t typically seen this type of vulnerability widely exploited, despite its exploitable nature.
    MS14-023

    (Office)

    Attacker tricks victim into authenticating to Microsoft online service in such a way that authentication token can be captured and replayed by attacker. Important 1 Likely to see reliable exploit emerge in next 30 days. In addition to token replay vulnerability, this update also addresses a DLL preloading issue involving the Chinese grammar checker DLL. We’ve recently developed and posted updated documentation covering the best way to protect applications from this type of attack. You find that guidance in this blog post.
    MS14-026

    (.NET Framework)

    Custom application developed leveraging the .NET Remoting feature could grant attack code execution access in response to specially crafted data. Important 1 Likely to see reliable exploit emerge in next 30 days. .NET Remoting feature used very rarely, and primarily only with applications written based on .NET Framework version 2.
    MS14-028

    (iSCSI)

    Attacker able to reach iSCSI endpoint can potential cause persistent resource exhaustion denial-of-service attack on Windows host. Important 3 Denial of service only. No chance for direct code execution.  

    - Jonathan Ness, MSRC engineering team

  • 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